Re: Problem building py-cryptography

[Kubilay Kocak]

On 22/05/2021 12:31 am, Dan Langille wrote:

On Fri, May 21, 2021, at 10:29 AM, Dan Langille wrote:

On Thu, May 20, 2021, at 7:18 PM, Simon Wright wrote:

Thanks Kubs, I'm travelling at the moment and will check further when I'm
back home. The original build log was with libressl and ccache. I'll
repeat without both and attach a new build log.


FYI, I have build failures here today, based on FreeBSD 11.4.  Builds
fine on 12.2 though.

https://services.unixathome.org/poudriere/data/114R-dvl/2021-05-21_13h56m56s/logs/errors/py38-cryptography-2.9.2.log

===>  FAILED Applying FreeBSD patch-Fix-build-with-LibreSSL-3.3.2-5988
===> FAILED to apply cleanly FreeBSD patch(es)
patch-Fix-build-with-LibreSSL-3.3.2-5988

For me, on 11.4, fixed with:

rm py-cryptography/files/patch-Fix-build-with-LibreSSL-3.3.2-5988

With that file removed, 12.2 does not build.


Correction. It builds on 12.2. I was wrong, sorry.




If there are any remaining issues with cryptography and libressl or 
regressions, please re-open 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255241




hope this helps.



Apologies for the top post.

Regards,

Simon.

20 May 2021 13:50:54 Kubilay Kocak :


On 20/05/2021 2:17 pm, Simon Wright wrote:

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no
difference. Is
anyone else seeing this and can anyone point me in the right
direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl


Thanks Kubs. When I tested I removed libressl, tried the build again
and
it failed so I replaced libressl after the test.
Removing ccache (and with libressl) made no difference - still the
same
error. I then removed the libressl dependency and I reran the build -
no
ccache and no libressl - the build still failed, same error message.
Since no-one else has reported this I suppose it should be something
in
my environment . . . . But what? :)


While the build error *with libressl* is known, matching that reported
in:

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

Failing to build without libressl is unexpected.

Jump into the poudriere jail to confirm (or not) its libressl that's
being installed and used.  Could be:

   - Custom WRKDIRPREFIX?
   - An overriding jail or set (-z) specific poudriere foo-make.conf?

Note, the OP build log contains:

[pkg.home.santos-wright.net] |   |   `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] |   |   `-- Extracting libressl-3.3.3:

With defaults, base openssl will be used, and you wont see libressl as
a dependency in the build.

[1] build/temp.freebsd-13.0-RELEASE-amd64-3.8/_openssl.c:2172:19:
error:
expected identifier or '('
static const long SSL_OP_NO_DTLSv1 = 0;


Regards,
Simon.




make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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: Problem building py-cryptography

[Kubilay Kocak]

On 20/05/2021 2:17 pm, Simon Wright wrote:

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl



Thanks Kubs. When I tested I removed libressl, tried the build again and
it failed so I replaced libressl after the test.

Removing ccache (and with libressl) made no difference - still the same
error. I then removed the libressl dependency and I reran the build - no
ccache and no libressl - the build still failed, same error message.

Since no-one else has reported this I suppose it should be something in
my environment . . . . But what? :)


While the build error *with libressl* is known, matching that reported in:

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

Failing to build without libressl is unexpected.

Jump into the poudriere jail to confirm (or not) its libressl that's 
being installed and used.  Could be:


 - Custom WRKDIRPREFIX?
 - An overriding jail or set (-z) specific poudriere foo-make.conf?

Note, the OP build log contains:

[pkg.home.santos-wright.net] |   |   `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] |   |   `-- Extracting libressl-3.3.3:

With defaults, base openssl will be used, and you wont see libressl as a 
dependency in the build.


[1] build/temp.freebsd-13.0-RELEASE-amd64-3.8/_openssl.c:2172:19: error:
expected identifier or '('
static const long SSL_OP_NO_DTLSv1 = 0;


Regards,

Simon.





make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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: Problem building py-cryptography

[Kubilay Kocak]

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography

Thanks,

Simon Wright.


Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl





make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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: Error reinstalling python 3.8.10 from ports

[Kubilay Kocak]

On 20/05/2021 1:54 am, Xavier Humbert wrote:

Hi,

I got trouble with python 3.8.10 at reinstall stage :


===>   Registering installation for python38-3.8.10
pkg-static: Unable to access file 
/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No 
such file or directory
pkg-static: Unable to access file 
/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No 
such file or directory

And a bunch of others (the whole lib-dynload directory actually)

In fact those files are almost present : the are not  named eg 
_asyncio.cpython-38.so , but asyncio.cpython-38*d*.so


Where from comes this *d* letter, which is not in pkg-plist ?

Cheers,

Xavier



d is the debug ABI suffix, added with DEBUG option is enabled.

I recall an upstream discussion or issue on removing the use of ABI 
tags, but can't recall if it landed and if so what versions it was merge to.


CC'ing committer of the latest lang/python38 update

___
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: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4

[Kubilay Kocak]

On 15/05/2021 2:35 am, bob prohaska wrote:

On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote:


happy to help identify the root cause if you can jump on IRC
(#freebsd-python @ freenode)


If sorting out the conflict between python versions helps the
community in general I'm willing to try. I simply use make in
the ports tree, not wanting the disk and cpu overhead imposed
by ports management software. But, that approach seems to be
getting obsolete. I don't mind being a Luddite, but there's
no profit in being the _last_ Luddite.

8-)

I've never used IRC, is it somehow better than this list?

Thanks for writing,

bob prohaska




Quicker isolation of root causes over async back and forth. Happy to go 
over it with you at your favourite 'real-time medium'

___
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: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4

[Kubilay Kocak]

On 14/05/2021 11:35 am, bob prohaska wrote:

On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote:

You have apparently chosen to build/update ports via a
technique that requires you to manage the dependencies, at
least some of the time. (Not that when is necessarily
obvious up front.)



You give me too much credit 8-)


Your environment is now based on a mix of python37 and
python 38 related materials. You are likely going to
need to rework/rebuild/reinstall things to avoid that.

Hints may come from that UPDATING that I quoted but
things are more broken overall than what UPDATING is
intended to cover. You might end up needing to
uninstall a bunch of stuff until python is unused
(or only one python is used) and then follow the
notes if you have only python37 use and want to
get to python38. Finally rebuild/reinstall what
was uninstalled, based on python38 as a context.


Trying to deinstall both python37 and python38 didn't
suffice. Python38's reinstall fails with the same
conflict. Deleting the offending file doesn't help
If other things need to be deinstalled it's not clear
what they might be.
  

Due to how I build/install ports, I've not had to deal
with ending up with the mix so I'm not familiar with
the details for recovering from a messy mix.



Would use of poudriere help with this sort of problem?
It isn't trivial to configure, but this sort of difficulty
has been growing ever worse. I didn't want to deal with the
complexity and overhead, but maybe it's time.

Many thanks for patient counsel!

bob prohaska

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



happy to help identify the root cause if you can jump on IRC 
(#freebsd-python @ freenode)

___
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: Maintainer timeout on textproc/py-markdown update on Bugzilla - safe to commit?

[Kubilay Kocak]

On 5/05/2021 6:47 am, Michael Gmelin wrote:




On 4. May 2021, at 22:45, Neel Chauhan  wrote:

Hi,

There is an update to the port textproc/py-markdown but the maintainer, koobs@ 
has not responded even when (I believe) it could be committed.

Bugzilla PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239070

Assuming no dependent ports have an issue with this update, would it be safe to 
commit this with a maintainer timeout if koobs@ hasn't responded?

I'm asking since I don't want to prematurely commit ports.

This port needs to be updated in order to import GTK+ 4 which in turn needs to 
update x11-toolkits/pango (which in turn needs this update).



Cc Koobs - looking at the pr, it seems like it was complicated and a lot of 
other work had to be done first.

-m




There's no problem bumping issues and for me at least, I'm usually very 
clear on explicitly mentioning what needs to happen (even in my absence) 
for something to land so anyone can do that.


I will always approve and unblock well-tested change proposals.

___
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: need a mentor/reviewer for a nfs-over-tls port

[Kubilay Kocak]

On 27/01/2021 12:59 pm, Rick Macklem wrote:

Hi,

I am a src committer and have created a port for the
userland daemons needed to implement nfs-over-tls.

It is my understanding that I can commit the port
once it is reviewed and approved by someone with a
ports commit bit.
--> So I am looking for a volunteer.

brnrd@ agreed to do this in early December and
provided an initial review, with a couple of useful
changes that I applied to it.
However, for some reason he has since gone silent
and I have not been able to re-establish email
contact with him, so I am now wondering if
someone else can do this?

Thanks in advance for any help, rick
ps: I've attached the svn diff for it.




Happy to port mentor you Rick

Flick me an email (from your f.o to my .fo) and I'll take care of the rest

In the meantime, create a diff in phabricator and add me as a reviewer
___
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 figuring out category for new port

[Kubilay Kocak]

On 8/02/2021 2:28 pm, Adam Jimerson wrote:

On Sunday, February 7, 2021 9:05:31 PM EST Kubilay Kocak wrote:

www/py-adblock [1] as its primary use will be in and for browsers (in
this case qutebrowser (also in www)


Thanks for your input, that was my main thinking as well as to why it might go
under the www category.


You're welcome


One may consider adding 'net' as a secondary if it can be used outside
the browser (www) context (say like a pihole thingy)


Interesting thought, I don't see why other programs/projects wouldn't be able
to also use this port as it basically adds python bindings around the already
existing rust API exposed by the project.


I suppose the question then is, are there any non browser consumers for 
this software that already exist?


I'd just stick it in www until such time as one or more appears, adding 
'net' to CATEGORIES (secondary/virtual) when they do.



[1] noting the "canonical" and registered PyPI name from this project is
'adblock' not 'python-adblock' (the repo name)


Yeah I already figured that the port should have the "py-" prefix in the name to
follow the FreeBSD naming convention for python ports, even though the name is
not consistent between the repo and PyPI. Thus the port would be "py-adblock"
in the ports tree as well as follow the naming convention for the python
flavors "py36-", "py37-" when packaged.



Yep, use PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}, and setting 
USES=python: to the supported python versions range

___
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 figuring out category for new port

[Kubilay Kocak]

On 7/02/2021 1:58 pm, Adam Jimerson wrote:

Hello so I was wanting to make a new port for python-adblock
(https://github.com/ArniDagur/python-adblock) so it can be added as a
dependency of www/qutebrowser but I'm not quite sure what is the correct
category for such a port. I can easily see it falling under net, net-mgmt, or
www although I'm thinking since it is browser related it would fall under www.

I wanted to run this by the list to see which would be the better option.
Would www be the best option here?



www/py-adblock [1] as its primary use will be in and for browsers (in 
this case qutebrowser (also in www)


Previous adblock related ports have also been in www/:

  https://www.freshports.org/www/adblock/
  https://www.freshports.org/www/xpi-adblock_plus
  https://www.freshports.org/www/xpi-uBlock_origin/
  https://www.freshports.org/www/ziproxy/

One may consider adding 'net' as a secondary if it can be used outside 
the browser (www) context (say like a pihole thingy)


[1] noting the "canonical" and registered PyPI name from this project is 
'adblock' not 'python-adblock' (the repo name)



___
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: please update devel/android-tools-adb to 30.0.x

[Kubilay Kocak]

On 10/01/2021 2:17 pm, Masachika ISHIZUKA wrote:

I've updated my nexus5 to crDroid 7.2 (android 11).
After that, I couldn't connect via adb.
Please update devel/android-tools-adb to 30.0.x.

P.S. I can connect via adb 30.0.5 on ubuntu.
--
Masachika ISHIZUKA


Could you please create a Bugzilla issue with title:

devel/android-tools-adb: Update to 30.0.x

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

Re: svn commit: r558913 - in head/lang: python-doc-html python38

[Kubilay Kocak]

On 23/12/2020 1:41 pm, Dima Panov wrote:

Better will be resolve errors of packages building. It works for py39 which 
used same cpython build internals as this py38 update do now.


Agree, move forward better than a revert.

This is being tracked (reported by users) at:

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


--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)


On Wednesday, Dec 23, 2020 at 11:51 AM, wen heping mailto:wenheping2...@hotmail.com)> wrote:
python-3.8 is not the default python version, so we do not require a exprun for
its update before.

But I shall revert it if this update break other ports.

wen


发件人: Dima Panov
已发送: 2020 12 月 23 日 星期三 9:19
收件人: Wen Heping; svn-ports-...@freebsd.org; svn-ports-h...@freebsd.org; 
ports-committ...@freebsd.org
主题: Re: svn commit: r558913 - in head/lang: python-doc-html python38

Moin!


Did you ecen start exp-run for this update? Too many python ports fails to 
package after this update.

devel/gobject-introspection
devel/py-cffi
devel/py-coverage
devel/py-greenlet
textproc/py-libxml2
textproc/py-markupsafe

and many other claims about generated py-library.so is missing (gir, for 
example: lib/gobject-introspection/giscanner_giscanner.so: No such file or 
directory)

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)



On Wednesday, Dec 23, 2020 at 12:58 AM, Wen Heping mailto:w...@freebsd.org)> wrote:
Author: wen
Date: Tue Dec 22 14:58:05 2020
New Revision: 558913
URL: https://svnweb.freebsd.org/changeset/ports/558913

Log:
- Update to 3.8.7

Modified:
head/lang/python-doc-html/distinfo
head/lang/python38/Makefile
head/lang/python38/Makefile.version
head/lang/python38/distinfo
head/lang/python38/pkg-plist

Modified: head/lang/python-doc-html/distinfo
==
--- head/lang/python-doc-html/distinfo Tue Dec 22 14:33:07 2020 (r558912)
+++ head/lang/python-doc-html/distinfo Tue Dec 22 14:58:05 2020 (r558913)
@@ -1,4 +1,4 @@
-TIMESTAMP = 1607436675
+TIMESTAMP = 1608648364
SHA256 (python/python-2.7.18-docs-html.tar.bz2) = 
3d05142817615e77cec99f686dca58289bbfe008af22f94a93262e8663db81c7
SIZE (python/python-2.7.18-docs-html.tar.bz2) = 4732851
SHA256 (python/python-2.7.18-docs-pdf-a4.tar.bz2) = 
ead357695e43c824ae1a83dd6cd3b4a47215658f3fa20111726ff7ef16a16dd2
@@ -23,14 +23,14 @@ SHA256 (python/python-3.7.9-docs-pdf-letter.tar.bz2) =
SIZE (python/python-3.7.9-docs-pdf-letter.tar.bz2) = 14332368
SHA256 (python/python-3.7.9-docs-text.tar.bz2) = 
b1a78d8303f9f334353ed3c3ad619190d4a8907eb137d894c1ffb457e523b518
SIZE (python/python-3.7.9-docs-text.tar.bz2) = 2291659
-SHA256 (python/python-3.8.6-docs-html.tar.bz2) = 
60b8e4c913e51367dcc661c3e3427a9a05a7dd69b3f032b93503acebb195e03f
-SIZE (python/python-3.8.6-docs-html.tar.bz2) = 6578280
-SHA256 (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 
8c8258d7781888ee48cb790f2e60bf2feb540f0c621a46684dc53e71fe74bc39
-SIZE (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 14711150
-SHA256 (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 
b8f29a407911e63161b3669d304180c44fc8cd65f9fba44473eab7714274f966
-SIZE (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 14825147
-SHA256 (python/python-3.8.6-docs-text.tar.bz2) = 
1def93d60e46c2925b4618ee02628cef9e8570c3aeb016ac5385576d953fa642
-SIZE (python/python-3.8.6-docs-text.tar.bz2) = 2409251
+SHA256 (python/python-3.8.7-docs-html.tar.bz2) = 
b6cd1c6eab3725711998e37655cbe2a87486d940cd98b558439a857e80df
+SIZE (python/python-3.8.7-docs-html.tar.bz2) = 6583700
+SHA256 (python/python-3.8.7-docs-pdf-a4.tar.bz2) = 
e6d2e8c3d4c413f4fbeb83f5686336364921dd13b31e880daa7161ac9739b70b
+SIZE (python/python-3.8.7-docs-pdf-a4.tar.bz2) = 14727427
+SHA256 (python/python-3.8.7-docs-pdf-letter.tar.bz2) = 
bc99b4ff989518fdde5dd9720cc74713c36b31cb9204bef12ea6957d3a2c8c9e
+SIZE (python/python-3.8.7-docs-pdf-letter.tar.bz2) = 14846046
+SHA256 (python/python-3.8.7-docs-text.tar.bz2) = 
f406249802f8c860dbd64ee7141c1394ed5fbb6908a72f29fd12580de62b5f6a
+SIZE (python/python-3.8.7-docs-text.tar.bz2) = 2413290
SHA256 (python/python-3.9.1-docs-html.tar.bz2) = 
c56e35cd0ee8f7b7fa115b1b58572c9319c2b3e65b823c1a9155734c0a9a751a
SIZE (python/python-3.9.1-docs-html.tar.bz2) = 6806786
SHA256 (python/python-3.9.1-docs-pdf-a4.tar.bz2) = 
3ab5ce54b1165c6575ae577e1fae7d7336d34e9c62ad4df790c02d9d354e2f19

Modified: head/lang/python38/Makefile
==
--- head/lang/python38/Makefile Tue Dec 22 14:33:07 2020 (r558912)
+++ head/lang/python38/Makefile Tue Dec 22 14:58:05 2020 (r558913)
@@ -3,7 +3,6 @@

PORTNAME= python
PORTVERSION= ${PYTHON_PORTVERSION}
-PORTREVISION= 1
CATEGORIES= lang python
MASTER_SITES= PYTHON/ftp/python/${PORTVERSION}
PKGNAMESUFFIX= ${PYTHON_SUFFIX}

Modified: head/lang/python38/Makefile.version

Re: Using gcc as a build dependency only

[Kubilay Kocak]

On 11/11/2020 7:55 am, Bob Eager wrote:

I have a port that, for reasons I won't go into, I build with gcc.

It all works fine with USE_GCC= yes - no problem.

The issue is that it's a build dependency and a run dependency. So
anyone wanting to use it has to install gcc, and is discouraged because
(a) it's big and (b) it drags in other stuff.

Presumably this is because it needs the gcc runtime, but I'm not sure.
And I can't see a runtime package that parallels the compiler.

Can anyone comment on this? And please don't say 'convert to clang'
because that isn't possible, at least not yet.


This is being tracked in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211154
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: www/py-html5lib with FLAVOR=py27 failed to build

[Kubilay Kocak]

On 27/07/2020 4:14 pm, Stefan Eßer wrote:

Am 27.07.20 um 07:03 schrieb Yasuhito FUTATSUKI:

In article <20200727.112301.1619120197420987885.y...@utahime.org>
y...@utahime.org writes:


From: KIRIYAMA Kazuhiko 
Subject: www/py-html5lib with FLAVOR=py27 failed to build
Date: Sat, 25 Jul 2020 15:17:04 +0900


www/py-html5lib with FLAVOR=py27 had failed to build:


I tried `cd /usr/ports/www/py-html5lib; make FLAVOR=py27 install` with
following conditions,

OS: 11.4-RELEASE, 12.1-RELEASE and 13-CURRENT r363475 (amd64)
Ports tree: head r543492

And in all cases it compeletes without any error.

Do you have any non-default setting about options or something related
to ports build?


www/py-html5lib@py27 run depends on devel/py-six@py27.
devel/py-six@py27 test depends on devel/py-pytest@py27.
devel/py-pytest@py27 test depends on devel/py-hypothesis@py27.
devel/py-hypothesis dropped py27 support on r538898.

So it can't be built with test. I guess it is the reason.


I consider it quite an annoyance that ports depending on Python 2.7
are deleted before the EoL of the interpreter has actually occurred.

I'm currently trying to resurrect a port (textproc/scancode-toolkit)
which for quite some time has already been available in an upgraded
version for Python 3 on Github, but was deleted in our ports tree.

It depends on other ports that work with Python 3 if only the USES
clause in the ports Makefile is fixed to include 3.6+ (I do not have
older Python versions installed and they might work with 3.0+, but I
cannot easily test that assumption). Some of these dependencies have
also been deleted from ports, despite being ready for Python 3.

IMHO ports that are currently marked to require Python 2.7 should be
updated to a version that works with 3.x (and many will do without
any change to the port except removing the restriction in the port's
Makefile, as I have found when working on scancode-toolbox).

Removal of Python-32.7 specific ports that are depended on by other
ports instead of just updating them or their port Makefile causes
friction and work for maintainers of dependent ports, who may not
have much experience with those dependencies (e.g. because they are
written in Python whole the port maintainer is not well versed in
that language and especially not in the steps required to migrate
a port from 2.7 to 3.x or to test whether it has been fully migrated
by the upstream).


The strategy, plan and execution for deprecation of Python 2.7 and the 
guidelines for deprecation and removal of Python 2.7 ports was not 
coordinated with, discussed with or executed by the Python team, as it 
should have been.


The issues associated with this as well as the impact it has had on the 
team, maintainers and and users has already been reported to core as one 
set of example symptoms that form part of a broader report.


Python is more than happy to address the issues associated with that 
plan. I encourage and welcome interested developers, users, maintainers 
who want to participate in improve the situation to join #freebsd-python 
on freenode.



--
koobs
@Python



___
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 Port: rsync-3.1.3_1

[Kubilay Kocak]

On 6/07/2020 5:09 pm, Dutchman01 via freebsd-ports wrote:

Please upgrade rsync to 3.2.2 releases

  


See:  
https://download.samba.org/pub/rsync/NEWS#3.2.0

  


Regards

Dutchy



Tracked in:

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

___
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: How to take action on a port?

[Kubilay Kocak]

On 8/06/2020 8:41 am, Dan Mahoney (Gushi) wrote:

Hey all,

I'm a port maintainer for a single port, and the Bugzilla is complaining 
to me about an open report.


(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246829)

I'm not a committer, and also don't have any ability to change the state 
of the bug other than commenting on it, but this *feels* like pilot 
error to me.


As this is a fairly quiet port (only two open issues right now), what is 
the correct way to resolve this?  (I.e. should I have access to do more 
in the bugzilla?)


I'd also like to take over maintainership for a few other ports with a 
low thrash rate (just to keep them from going abandoned), so getting 
better at this workflow is useful to me.


Best,





Hi Dan,

Bugzilla provides regular notifications to accounts that have issues 
(bugs) open with any flag who's value is set to "? "


The purpose of these flags is to request feedback, or ask for something 
from a specific account/email/person, and the notifications/reminders 
are a way of showing people a list of things that need their feedback


In this case for bug 246829, the flag is the maintainer-feedback flag, 
currently set to ? 

What people in the values of these flags need to do is to acknowledge 
the flag/feedback, by adding a comment, providing a patch or whatever 
else, and set the flags value to + or - (depending on the context of the 
request)


Setting a flags value (acknowledging it), means that that you wont 
receive notifications about that issue, unless and until that flag, or 
another flag is set to ? with your email address in its value.


So for this bug, since you've already provided feedback in comment 1, go 
ahead and set maintainer-feedback to +


If you believe the issue can be resolved at this point, be sure to 
include a comment specifically saying that, and what the resolution 
should be


In this case I'd suggest something like:

"This issue can be closed: Not A Bug" as the value provided in 
DEFAULT_VERSIONS is not a valid one


koobs






___
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: Out of memory building lang/ghc-8.8.3

[Kubilay Kocak]

On 5/05/2020 9:09 pm, andrew clarke wrote:

On 2020-05-05 14:19:50, Gleb Popov (arr...@freebsd.org) wrote:


On Tue, May 5, 2020 at 1:37 PM andrew clarke  wrote:


Beware anyone building lang/ghc-8.8.3 from the ports tree. Building it
here on FreeBSD 12.1-REL AMD64 with Poudriere, the build ran out of swap,
despite the PC having 8 GB RAM, 8 GB swap and not much else running.

My /usr/local/etc/poudriere.conf:

BASEFS=/poudriere
ZPOOL=zroot
FREEBSD_HOST=http://mirror.internode.net/
POUDRIERE_DATA=/poudriere/data
RESOLV_CONF=/etc/resolv.conf
DISTFILES_CACHE=/usr/ports/distfiles
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes
KEEP_OLD_PACKAGES=yes
PARALLEL_JOBS=8

Maybe I can retune the last three parameters to use less memory. I've not
tried yet.

This isn't really a whinge, I'm just surprised it failed. I'd have thought
8 GB was enough.

(ghc is a build dependency of textproc/hs-pandoc)



Did you have something else building at the same time?

On my laptop with 16 Gb of RAM I also see OOM failures when building
multiple "heavy" packages (llvmXX, gccX, ghc, rust, libreoffice)
simultaneously. In this case I use -J poudriere option to limit number of
jobs.


Nothing else building.

This is a headless server, so I've no need to build something the size of
libreoffice or chromium. I've noticed llvm10 takes a long time to build, but
8 GB seems plenty of memory for it.

The -J option sounds like the way to go, provided I remember to use it
next time. Or I could instead set PARALLEL_JOBS=1 in poudriere.conf but then
build performance will suffer for every port, which isn't ideal.

But perhaps there's an option to limit make jobs just for a single port, set in
/usr/local/etc/poudriere.d/make.conf ? That would be nice.


You can do it for OPTIONS in make.conf (or poudriere make/set .conf's):

# Per port options
# category_portname_{UN}SET=[ OPTION ]

graphics_cairo_UNSET=OPENGL
graphics_cairo_SET=X11

This doesn't help for non-OPTIONS variables, but we have this recently 
submitted feature/review:


https://reviews.freebsd.org/D24324

For use like:

devel_llvm80_VARS=DISABLE_MAKE_JOBS=yes
devel_llvm90_VARS=DISABLE_MAKE_JOBS=yes

This would satisfy this and other per-port specific build options cases.



___
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: reccomendations of conference / party audio video software ?

[Kubilay Kocak]

On 24/03/2020 9:31 pm, Baptiste Daroussin wrote:

On Sat, Mar 21, 2020 at 04:38:11PM +, Bob Eager wrote:

People have been saying good things about jitsi (Java based) bu the
port didn't work on a quick try (my ports tree isn't very new though
and there was no time to update it).


The port is about a previous thing from jitsi (a SIP client) when people speak
about Jitsi c'est speak about https://meet.jit.si aka https://jitsi.org/

The video bridge is in java and the frontend is in javascript with desktop apps
iirc for those who do not want to use a browser. Note that on freebsd desktops
it works well in firefox browser.

No login required, no decidated required it just works fine.

There is no port yet of the server part on freebsd but should not be hard to do
as it is fully opensource.


Working on it already


Best regards,
Bapt



___
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: reccomendations of conference / party audio video software ?

[Kubilay Kocak]

On 22/03/2020 3:06 am, Julian H. Stacey wrote:

Hi ports@
Any reccomendations of conference / social group party chat server software ?

As much more of the world goes into lock down & social distancing, ie
not meeting friends at the pub / restuarant etc on Saturday night
etc, BBC has shown some social groups have arranged a matrix of 10
to 20 faces from cameras on each of 10 to 20 screen, so groups can
chat virtualy, & drink localy @ home.

That needs servers. Doubtless there are big commercial firms offering,
but if some of us think it may be interesting adding such software
to our FreeBSD servers for use by friends, Any reccomendations what
to add from ports/ ?

Might it all be in https://www.freebsd.org/ports/multimedia.html
or more likely scattered ? Keywords to search with ?

What about client apps on android, apple & MS
('cos most friends are non tech & dont run BSD or Linux PCs etc)

What about bandwidth per user, dont want to impact server hosts.

If most of this has been asked before, an URL to a FAQ would be fine thanks.

Cheers
--
Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/
UK stole 750,000 votes from EU Brits:  http://stolenvotes.uk
http://petition.parliament.uk/petitions/300059 http://berklix.uk/brexit/#russia
Limit Corona:  http://berklix.eu/jhs/std/no_bugs.txt



Hi Julian,

A few of us are sorting our a couple of test/eval instances of NextCloud 
Talk and Riot.IM with Matrix for AV/conferencing for various use-cases 
including FreeBSD community oriented stuff.


Feel free to hit us up off-list if you'd like more info or be in that loop
___
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: pkgs for aarch64 stopped building

[Kubilay Kocak]

On 3/03/2020 3:09 am, Ronald Klop wrote:

Hi,

If I take a look at the pkg build server of aarch64: 
http://thunderx1.nyi.freebsd.org/ things are broken.


- head-arm64-default is already broken for a couple of weeks, because it 
can't build 'pkg'

- 113arm64-quarterly stays in 'parallel_build' while all cpu's are idle.

Is there maintenance being done? Where should I report this?

Regards,
Ronald.


Hi Ronald,

Bugzilla :: Ports & Packages :: Package Infrastructure
___
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: Unable to run "pkg update -f" on 13-CURRENT

[Kubilay Kocak]

On 2/03/2020 2:47 pm, Neel Chauhan wrote:

Hi freebsd-ports@,

I am running FreeBSD 13-CURRENT and I am getting this error on a "pkg 
update":


pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64
pkg: repository FreeBSD contains packages with wrong ABI: 
FreeBSD:13.0:amd64


I am running FreeBSD 13-CURRENT r358510.

Why is this happening?

I also filed a bug on Bugzilla: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549


-Neel

===

https://www.neelc.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"


There's a known issue with the official FreeBSD package builders (which 
use ports-mgmt/pkg-devel) causing mismatched ABI error messages for 
package users after a recent pkg-devel update.


Pull request addressing the issue has been submitted by Kyle (CC'd):

https://github.com/freebsd/pkg/pull/1817

The change needs to be deployed to the build cluster to resolve the issue
___
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: porting a python package with specific libraries versions as dependency

[Kubilay Kocak]

On 25/02/2020 7:22 pm, Alessandro Sagratini wrote:

Hello all,
I was discussing [1] about porting oci-cli to ports tree. It is a python package, that 
should not be a big deal, though, investigating a bit more "requires" field in 
setup.py [2], I noticed it depends on specific python libraries, for example oci-sdk 
2.10.5, configparser 3.5.0 or six 1.11.0.

What is the official FreeBSD packaging policy with regards to such python 
packages? What about installing something in a virtualenv?

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244224
[2] https://github.com/oracle/oci-cli/blob/master/setup.py

Let me know if you need anything else from me.
Thank you,
Alessandro

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



Hi Allesandro

I recently expanded on the existing Python Policy with regard to 
dependencies, including what to do with == dependencies.


https://wiki.freebsd.org/Python/PortsPolicy#Dependencies

The tldr is, == dependencies are not suitable for "packaging", they are 
suitable for "deployments".


To port these packages, they should be updated to >= counterparts (patch 
the setup.py, or source file for those dependencies).


Unfortunately this requires additional QA to do properly, as upstream 
may not have or be currently testing with later versions, and the 
versions of dependencies in the ports tree can be updated at any time.


This is why the vast majority of correctly packaged (upstream) packages 
use >= dependencies, leaving the x.y.z version specified as the 'lowest 
supported version' to allow flexibility.


Setting *_requires to ">=" upstream, does not prevent upstreams from 
testing specific versions themselves for their test environment, but its 
recommended they QA what they distribute, which ensures issues in newer 
versions of their dependencies are picked up early and often, *before* 
being released to users.


If you need more help or have questions regarding porting Python 
packages, jump on #freebsd-python on freenode IRC and we'll be happy to 
assist.



./koobs
___
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: parsedmarc

[Kubilay Kocak]

On 20/01/2020 2:23 am, Andrea Venturoli wrote:

Hello.

I'm trying to install parsedmarc:
https://domainaware.github.io/parsedmarc/

I've created a port (mail/py-parsedmarc) for it, but unfortunately, some 
dendend port are missing; so I created them too: they would be 
mail/py-imapclient, mail/py-mailsuite and dns/py-pubblicsuffix2.


That's however not enough, since they depend on other ports which do 
exists, but are too old.

Namely:
_ net/py-GeoIP2 >=3.0.0 (we have 2.9.0);
_ net/py-urllib3 >=1.25.7 (we have 1.25.6);
_ textproc/py-html2text>=2019.9.26 (we have 2018.1.9).



Is there any chance that these three port be updated?


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



Hi Andrea,

Please create Bugzilla issues for each of the dependency ports that need 
updating, and have your "[NEW PORT] mail/py-parsedmarc" bugzilla issue 
"depend on" those issue ID's


Also have your "[NEW PORT] mail/py-parsedmarc" issue ID depend on the 
other [NEW PORT] issues you create (mail/py-imapclient, 
mail/py-mailsuite and dns/py-pubblicsuffix2)

___
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: Portmaster failing

[Kubilay Kocak]

On 2/01/2020 7:37 am, @lbutlr wrote:

Portmaser -L errors out with

make: "/usr/ports/Mk/Uses/ssl.mk" line 97: You are using an unsupported SSL 
provider openssl

Make.conf:
DEFAULT_VERSIONS+=ssl=openssl apache=2.4 php=7.2 perl5=5.28 mysql=10.1m

Worked fine on Saturday, maybe Friday.





Tracked earlier and resolved here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243014
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with porting Python libraries

[Kubilay Kocak]

On 30/12/2019 4:54 am, Andrea Venturoli wrote:

Hi Andrea, nice first job on a Python port :)


# $FreeBSD$

PORTNAME=    IMAPClient


Lowercase this PORTNAME


PORTVERSION=    2.1.0
CATEGORIES=    mail python
PKGNAMEPREFIX=    ${PYTHON_PKGNAMEPREFIX}

MAINTAINER= m...@netfence.it
COMMENT=    Easy-to-use, Pythonic and complete IMAP client library

LICENSE=    BSD3CLAUSE


Add LICENSE_FILE pointing to license file if one exists in the source 
download


Both the PyPI sdist (MASTER_SITES=CHEESESHOP) and the GitHub repo have 
one: "COPYING"


RUN_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}

GH_ACCOUNT=    mjs
GH_PROJECT=    imapclient

NO_ARCH=    yes
USES=    python
USE_GITHUB=    yes


Use MASTER_SITES=CHEESESHOP if the project uploads a source tarball 
("sdist") there, unless there's a compelling temporary reason to use an 
alternative source, like missing license files, test files, etc.



USE_PYTHON=    autoplist distutils

.include 


For details Python Ports Policy & Guidelines/Tips:

https://wiki.freebsd.org/Python/PortsPolicy

If it doesn't answer any questions, needs clarifications or additions, 
let us know


If you need further help or just want to hang out, we have a 
#freebsd-python channel on freenode IRC, come and say hi :)


./koobs




___
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: dns/bind911 and 2019Q4 branch

[Kubilay Kocak]

On 20/10/2019 8:50 pm, Andrea Venturoli wrote:

On 2019-10-20 11:26, Mathieu Arnold wrote:


The ISC was very clear in that this update[1] is not a security related
release, so I have absolutely no plan to merge it.

1: https://lists.isc.org/pipermail/bind-announce/2019-October/001139.html



Sorry, I had already opened the bug as Kubilay suggested; fell free to 
close it, then.




I'm confused though, since the link you posted says:

To clarify, BIND 9.11.12 is not a security release, but BIND 9.14.7 and
9.15.5 are.

The two CVEs disclosed today affect only BIND 9.14 and 9.15; the BIND
9.11 branch is not vulnerable.


But on the release notes for 9.14 there are *3* CVEs and one 
(CVE-2019-6471) is also listed in the release notes for 9.11.


???

  bye & Thanks
 av.



All done (issue closed).

Thank you for raising the question and asking though Andrea, many 
security updates are in fact missed, and don't end up in quarterly branches.


Users can help us by identify things that slip through the cracks and 
reporting those issues, and requesting merges where they are necessary



___
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: dns/bind911 and 2019Q4 branch

[Kubilay Kocak]

On 20/10/2019 8:01 pm, Andrea Venturoli wrote:

Hello.

I'm currently testing using the ports quarterly branch.

I see dns/bind911 was updated from 9.11.11 to 9.11.12 in head.
AFAICT this fixes a security vulnerability.

Shouldn't this be merged in the 2019Q4 branch?
Will it?

  bye & Thanks
 av.


Hi Andrea,

Short answer: Yes

If there was a Bugzilla issue ("PR: x" in the commit log message) 
associated with the head commit, please re-open the issue and request a 
merge of the relevant commit.


If there wasn't a Bugzilla issue, please create one:

- cc ports-secteam
- keyword: security
- merge-quarterly ?

Thanks!

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

Re: Synth and gcc-aux status?

[Kubilay Kocak]

On 26/08/2019 12:57 pm, Thomas Mueller wrote:

What is the current status of synth with FreeBSD ports, and I could also ask 
about gcc-aux.

I see gcc-aux remains at v6 (gcc6-aux) while gcc is updated to 7.4.0 and 8.3, 
and even 9.1.

Is poudriere now the main tool for updating ports?


Poudriere has always been the main (FreeBSD) tool for QA and package 
building.


Note: While poudriere has overlapping functionality with portmaster and 
portupgrade, in the sense that they all "build ports", poudriere was 
designed primarily as a "package builder", not as a local port/package 
installation tool, though it *can* be used that way.



What is the status of portmaster and portupgrade now?


Both are maintained as far as I know. portmaster has FLAVOR support, I'm 
not sure about portupgrade re FLAVORS, though I do recall seeing reports 
of it not working in the not so distant past, so it may not.

___
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: Creation of a diff of a new port

[Kubilay Kocak]

On 7/08/2019 6:16 pm, Kurt Jaeger wrote:

Hi!


I can create a shar (example 3.2), but the handbook suggests to me that
I should be able to make a diff (example 3.1). If someone confirms that
I really should not be able to make a diff, I will update the handbook
appropriately.


New ports should be submitted as shar. Changes to existing ports
should be submitted as diff.



new ports can be submitted as shars or diffs. "new ports must/should be 
shar" is historic.

___
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: Clamav

[Kubilay Kocak]

On 7/08/2019 7:57 am, The Doctor via freebsd-ports wrote:

Wehen Will clamav be updated?

I understand there is a security issue?



The best / most effective method to report/request security releases or 
updates is in Bugzilla, I've created one for the ClamAV 0.101.3 version 
(security) update) here:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239684
___
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: Reviving a deleted port (pecl-inotify)

[Kubilay Kocak]

On 1/08/2019 7:15 pm, B.J.Scharp wrote:

Hi all,

Back in december when PHP 5.6 went eol, a lot of PECL ports got deleted,
many of which weren't updated or required with PHP 7.x

However, some of them actually had updates to get them going with PHP 7

An example of this is pecl-inotify
(https://www.freshports.org/devel/pecl-inotify/)

Version 2.0.0 was released way back in 2016 for PHP 7, but never ported
for FreeBSD, which only had version 0.1.6.

Updating the port to version 2.0.0 is as simple as changing the version
in the Makefile, and leaving everything else (including the patch)
as-is. I've been running it in production for several months now.

What is the preferred way to get this port back? Revive the old one, or
create a new port 'pecl-inotify2' ?


Revive + modifications

The committer assigning themselves the (bugzilla) issue will take care 
of reviving the port from the last revision prior to deletion using svn.


If you have an SVN ports repository and would like to do that to produce 
your diff, see:


https://www.freebsd.org/doc/en/articles/committers-guide/ports.html#ports-qa-re-adding


On that note, I've no experience submitting ports, just
modifying/creating them for my own servers. I'll probably be able to
figure it out with the Handbook, but if the current maintainer wants to
do it, I'll be happy to shoot him/her a diff or tar with my setup.


SDince the port has been deleted, there's no maintainer by definition, 
but feel free to CC the previous maintainer on any issue you create in 
bugzilla


If you have any porting questions or need help, #freebsd-ports @ 
freenode IRC


--
Regards,

koobs


___
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: portscount is down

[Kubilay Kocak]

On 26/06/2019 4:22 pm, Koichiro Iwao wrote:

Hi,

portscout.FreeBSD.org seems to be down (Error 503 Backend fetch failed)
for the last few days. Is anyone aware of this already?



Was not aware, though I recall using it at some point in the past two 
days however, so the issue may not be constant.


We (bugmeister) have however seen intermittent but ongoing similar 
symptoms for Bugzilla, which we reported to cluster admin (CC'd here), 
which may or may not be related.


If it continues and we don't hear back, we should create a bug to track 
the issue.


./koobs
___
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: Trouble making INDEX on one 11.2 system

[Kubilay Kocak]

On 20/06/2019 5:32 pm, Andrea Venturoli wrote:

Hello.

On one (and only one) of my 11.2/amd64 systems, portsdb -U has been 
consistently failing for several days, with the following error message:


make_index: /usr/ports/www/radicale: no entry for 
/usr/ports/www/py-requests1


I usually just delete www/radicale, since I don't use it, but now I'd 
like to get a hang on this.




Obviously this comes from the following line of www/radicale/Makefile:
HTTP_RUN_DEPENDS=   
${PYTHON_PKGNAMEPREFIX}requests1>=0:www/py-requests1@${PY_FLAVOR}


There's a py-request directory in /usr/ports/www, but no py-requests1.
I'm lost here: in my ignorance I would expect it to exist or else 
portsdb to fail on all my boxes...


Is there some sort of translation that should go on and remove that "1"?
Am I missing anything?


  bye & Thanks
 av.

P.S.
I have DEFAULT_VERSIONS+=python=2.7 in /etc/make.conf, but removing it 
doesn't seem to make any difference.


Hi Andrea,

I removed www/py-requests1 in 
http://svnweb.freebsd.org/changeset/ports/501970


I missed radicale's (conditional) dependence on requests1 via the HTTP 
option.


This was fixed in: https://svnweb.freebsd.org/changeset/ports/504619
___
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: Policy on closing bugs

[Kubilay Kocak]

On 24/05/2019 10:45 pm, Grzegorz Junka wrote:


On 24/05/2019 12:34, Kubilay Kocak wrote:

On 24/05/2019 9:52 pm, Grzegorz Junka wrote:


On 24/05/2019 11:30, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For 
example, is it OK to close a bug that is fixed upstream but not 
yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing reported" 
has been resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is 
there a specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not 
usually, no, that wouldn't be considered sufficient to be 
"resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, 
or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other 
issue trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that 
we like to have a real person assigned before in progress, and 
before close.


Happy to answer any more questions regarding issue tracking, etc 
anytime




Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK and 
what's not. Here is the defect:


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

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the 
defect has been closed, my intention was more to find out if maybe a 
new state "Postponed" could be added for a defect in a state like 
this one?




A very similar story with:

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

It's not scheduled to be removed per se yet. The removal is under 
discussion with no clear path agreed as far as I know. I understand 
that a maintainer doesn't want to spend time working on a port that 
will likely undergo significant changes or removal but is closing the 
defect the right thing to do? And again, a "Postponed" state seems to 
me to be more appropriate?


GrzegorzJ




The better resolution for this is again probably: Not Accepted (as 
WONTFIX), though I can understand why "Overcome by Events" was 
selected (wont be fixed *because* of a separate overruling issue).


From a reading of the associated bug (215036), it reads fairly clearly 
that the 0.x branch is not supported (security wise, in particular), 
and no further work will be done on it. That the port has been 
deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision.




Agreed in principle, but the port hasn't yet been marked as 
DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days (I 
synced my ports 18 May).



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


Indeed it has: https://svnweb.freebsd.org/changeset/ports/502453

The same day, 6 minutes after your comment about it not having an 
EXPIRATION_DATE :)


___
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: Policy on closing bugs

[Kubilay Kocak]

On 24/05/2019 9:52 pm, Grzegorz Junka wrote:


On 24/05/2019 11:30, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing reported" 
has been resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is there 
a specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not usually, 
no, that wouldn't be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, 
or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other issue 
trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before 
close.


Happy to answer any more questions regarding issue tracking, etc anytime



Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK and 
what's not. Here is the defect:


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

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the 
defect has been closed, my intention was more to find out if maybe a 
new state "Postponed" could be added for a defect in a state like this 
one?




A very similar story with:

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

It's not scheduled to be removed per se yet. The removal is under 
discussion with no clear path agreed as far as I know. I understand that 
a maintainer doesn't want to spend time working on a port that will 
likely undergo significant changes or removal but is closing the defect 
the right thing to do? And again, a "Postponed" state seems to me to be 
more appropriate?


GrzegorzJ




The better resolution for this is again probably: Not Accepted (as 
WONTFIX), though I can understand why "Overcome by Events" was selected 
(wont be fixed *because* of a separate overruling issue).


From a reading of the associated bug (215036), it reads fairly clearly 
that the 0.x branch is not supported (security wise, in particular), and 
no further work will be done on it. That the port has been deprecated 
(DEPRECATED/EXPIRY_DATE) is evidence of that decision.


./koobs

___
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: Policy on closing bugs

[Kubilay Kocak]

On 24/05/2019 9:30 pm, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a resolution 
has "occurred", but more precisely, the "thing reported" has been 
resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is there a 
specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not usually, 
no, that wouldn't be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, or 
a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other issue 
trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before close.


Happy to answer any more questions regarding issue tracking, etc anytime



Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a particular 
defect. I didn't mention it because I didn't want to be picky and seen 
as causing troubles :) Also wasn't sure what's OK and what's not. Here 
is the defect:


My pleasure. I understand the desire not to want "cause trouble", but 
it's also important that everyone feel comfortable asking questions, and 
understand/clarify how things works (or should work, ideally). We need 
to see more of it, not less.



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

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the defect 
has been closed, my intention was more to find out if maybe a new state 
"Postponed" could be added for a defect in a state like this one?


GrzegorzJ


So there's a few issues involved, that are worth making very distinct:

- A FreeBSD port/package and its users are affected
- Upstream has apparently fixed the issue, but there's not much detail 
about how, where, when, etc

- The bugs resolution type

We'll run through those individually so its hopefully more clear how 
they might interact/overlap with each other:


1) If a port/package is broken in some way, we want to fix it, and as 
maintainers, we have signed up to do that. This is not controversial.


For users, its not always (I would argue in most cases), possible or 
easy for them to distinguish between a port problem, and a software 
problem, and who (freebsd or upstream) should be primarily responsible 
to a) get the initial bug report b) fix it in the first instance. I 
personally don't believe users should be expected to know or do this, 
but its great if/when they can.


There are arguments on both sides of the (unfortunate) 
upstream/downstream divide, about users reporting bugs to the "wrong place".


Sometimes downstreams hack software to make it work or do things 
differently in their distribution/OS, and sometimes these things break, 
and upstreams get the report.


Sometimes upstreams break things, and downstreams get the reports.

It's a difficult problem to solve completely and permanently, so 
ultimately it's the relationship between downstreams/upstreams that is 
the most important thing to cultivate.


Having said that, at least in the former case, I don't think its too 
much of a burden for us to receive reports and close them (where 
appropriate) as "wont fix / not accepted" after commenting that the 
report should go upstream.


The question as to what and when is appropriate is very case dependent, 
but the minimum (in my opinion) is that it should be explicitly clear to 
the reporter and documented what the complete rationale, analysis is to 
resolving in that manner.


2) If an upstream has fixed an issue, all else being equal, we oug

Re: Policy on closing bugs

[Kubilay Kocak]

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, is 
it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a resolution 
has "occurred", but more precisely, the "thing reported" has been 
resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the issue, 
usually the specific nature of the request/proposal. Is there a specific 
bug you're referring to? I can speak to that case specifically if so.


For example however, if the bug was a "bug report for the port/package", 
fixed upstream hasn't fixed the port, so not usually, no, that wouldn't 
be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, or a 
DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other issue 
trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before close.


Happy to answer any more questions regarding issue tracking, etc anytime

--
Regards,

Kubilay
Bugmeister
___
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: audio/lv2 and textproc/py-rdflib have py36 vs. py27 conflict

[Kubilay Kocak]

On 13/05/2019 9:13 pm, Kubilay Kocak wrote:

On 13/05/2019 8:12 pm, Luis Espinoza Jr. wrote:

Hello all.


My system is FreeBSD 11.2-RELEASE-p9 AMD64. I update my ports tree with
portsnap and build my ports with portmaster. For several days I have been
trying to resolve a problem updating ffmpeg.

ffmpeg requires audio/lv2
lv2 requires textproc/py-rdflib

According to the data in the Freshports site, lv2 has a runtime 
dependency

on py36-rdflib but py-rdflib has build- and runtime dependencies on
lang/python27, and its package name is py27-rdflib.


Hi Luis,

I *think* the latter case (rdflib looking like it depends on python27 at 
freshports) is an artifact of the port not having been updated since 
June 2018, which was before the Python default version switch this year, 
and freshports not having regenerated/refreshed the page/information for 
the port.



Portmaster emits the following error compiling py-rdflib:
pkg-static: py36-rdflib-4.2.2 conflicts with py27-rdflib-4.2.2
(installs files into the same place). Problematic file: 
/usr/local/bin/csv2rdf

*** Error code 70


It's likely the case that you have py27-rdflib installed at the moment, 
and since the default version of Python has switched to 3.6, it now 
conflicts.


See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226634#c10 for 
the details explanation (it applies to any python package, not just 
setuptools)


What do you currently have set in /etc/make.conf for DEFAULT_VERSIONS ?



I have checked the UPDATING file and found no answer. Is there some 
standard
method for dealing with python27 vs. python36 conflicts, or is this a 
bug in the

lv2 dependencies that must be fixed by the maintainer?


Python ports/packages that install things in LOCALBASE/bin should be 
made concurrent safe, and the py-rdflib isn't.


I'll sort that out shortly, which will address the conflict, where only 
the *default version of the port/package will have the 
version-suffixless name.




Hi Luis,

The port has been updated to be concurrent safe in:

https://svnweb.freebsd.org/changeset/ports/501563

Thank you for your report

./koobs
___
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: audio/lv2 and textproc/py-rdflib have py36 vs. py27 conflict

[Kubilay Kocak]

On 13/05/2019 8:12 pm, Luis Espinoza Jr. wrote:

Hello all.


My system is FreeBSD 11.2-RELEASE-p9 AMD64. I update my ports tree with
portsnap and build my ports with portmaster. For several days I have been
trying to resolve a problem updating ffmpeg.

ffmpeg requires audio/lv2
lv2 requires textproc/py-rdflib

According to the data in the Freshports site, lv2 has a runtime dependency
on py36-rdflib but py-rdflib has build- and runtime dependencies on
lang/python27, and its package name is py27-rdflib.


Hi Luis,

I *think* the latter case (rdflib looking like it depends on python27 at 
freshports) is an artifact of the port not having been updated since 
June 2018, which was before the Python default version switch this year, 
and freshports not having regenerated/refreshed the page/information for 
the port.



Portmaster emits the following error compiling py-rdflib:
pkg-static: py36-rdflib-4.2.2 conflicts with py27-rdflib-4.2.2
(installs files into the same place). Problematic file: /usr/local/bin/csv2rdf
*** Error code 70


It's likely the case that you have py27-rdflib installed at the moment, 
and since the default version of Python has switched to 3.6, it now 
conflicts.


See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226634#c10 for 
the details explanation (it applies to any python package, not just 
setuptools)


What do you currently have set in /etc/make.conf for DEFAULT_VERSIONS ?



I have checked the UPDATING file and found no answer. Is there some standard
method for dealing with python27 vs. python36 conflicts, or is this a bug in the
lv2 dependencies that must be fixed by the maintainer?


Python ports/packages that install things in LOCALBASE/bin should be 
made concurrent safe, and the py-rdflib isn't.


I'll sort that out shortly, which will address the conflict, where only 
the *default version of the port/package will have the 
version-suffixless name.


___
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: BIND default options: dnstap

[Kubilay Kocak]

On 12/05/2019 5:09 am, Greg Rivers wrote:

I'd like to suggest that dnstap should be enabled by default going forward, 
starting with bind914. Doing so would be a no-op for people who don't use it, 
since it has to be specifically enabled in the configuration. I suspect there 
may be quite a few people like me who would appreciate the ability to use 
dnstap without building our own packages and maintaining our own repos. 
Thoughts?



Hi Greg,

I encourage you to open a Bugzilla issue with the suggestion.

Make sure to include the value it provides you, the 'noop' element, and 
describe the dependency changes (if any), as this tends to be the 
primary reason why OPTIONS aren't enabled by default. Though most 
maintainers are already aware of this, it doesn't hurt to mention it.


./koobs


___
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 to change ruby default version to 2.5

[Kubilay Kocak]

On 20/04/2019 9:56 pm, Hajimu UMEMOTO wrote:

Hi,


On Sat, 20 Apr 2019 06:59:16 +0200
Walter Schwarzenfeld  said:


w.schwarzenfeld> ===>>> Port directory: /usr/ports/databases/ruby-bdb

w.schwarzenfeld>     ===>>> This port is marked BROKEN
w.schwarzenfeld>     ===>>> does not build with Ruby 2.5

How about this patch?




Issue reported/tracked here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237410
___
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: [package - head-i386-default][graphics/hugin] Failed for hugin-2019.0.0_1 in build

[Kubilay Kocak]

On 20/04/2019 6:15 pm, Greg 'groggy' Lehey wrote:

I've received a number of these messages.  Based on the fact that they
seem to be a jail mismatch, I assume that this has nothing to do with
the port itself.  Can somebody confirm or deny this?  If I need to do
something, please explain.

Greg

On Friday, 19 April 2019 at  7:16:33 +, pkg-fall...@freebsd.org wrote:

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: g...@freebsd.org
Last committer: jbe...@freebsd.org
Ident:  $FreeBSD: head/graphics/hugin/Makefile 498698 2019-04-12 
06:36:31Z jbeich $
Log URL:
http://beefy11.nyi.freebsd.org/data/head-i386-default/p499228_s346255/logs/hugin-2019.0.0_1.log
Build URL:  
http://beefy11.nyi.freebsd.org/build.html?mastername=head-i386-default=p499228_s346255
Log:

=>> Building graphics/hugin
build started at Fri Apr 19 06:55:36 UTC 2019
port directory: /usr/ports/graphics/hugin
package name: hugin-2019.0.0_1
building for: FreeBSD head-i386-default-job-02 13.0-CURRENT FreeBSD 
13.0-CURRENT 1300018 i386
maintained by: g...@freebsd.org
Makefile ident:  $FreeBSD: head/graphics/hugin/Makefile 498698 2019-04-12 
06:36:31Z jbeich $
Poudriere version: 3.2.8-3-g02cc9753
Host OSVERSION: 139
Jail OSVERSION: 1300018
Job Id: 02

!!! Jail is newer than host. (Jail: 1300018, Host: 139) !!!
!!! This is not supported. !!!
!!! Host kernel must be same or newer than jail. !!!
!!! Expect build failures. !!!




The actual failure is at the bottom of the log link referenced in the email:

ld: error: src/hugin_base/libhuginbase.so.0.0: undefined reference to 
__atomic_load


___
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: Python conflict on RPI2

[Kubilay Kocak]

On 13/04/2019 12:09 pm, Jan Beich wrote:

bob prohaska  writes:


In tinkering with compiling firefox on an RPI2 attempts to use
portmaster fail with

===>   Registering installation for py36-setuptools-40.8.0_1
Installing py36-setuptools-40.8.0_1...
pkg-static: py36-setuptools-40.8.0_1 conflicts with
py27-setuptools-40.8.0 (installs files into the same place).
Problematic file: /usr/local/bin/easy_install
*** Error code 70


Reinstall py27-setuptools first. When PYTHON_DEFAULT is changed it
requires rebuilding USE_PYTHON=concurrent (or USES=uniquefiles)
consumers in order to make symlinks point to the new default.


As an additional followup to Jans comment, see the original bugzilla report:

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

comment 10 onward
___
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: python 3 subprocess performance

[Kubilay Kocak]

On 12/04/2019 8:41 pm, Dima Pasechnik wrote:

On Fri, Apr 12, 2019 at 9:46 AM Alexander Zagrebin  wrote:


В Fri, 12 Apr 2019 09:36:13 +0200
Dima Pasechnik  пишет:


On Fri, Apr 12, 2019 at 9:11 AM Alexander Zagrebin 
wrote:


В Thu, 11 Apr 2019 17:32:42 +0200
Jan Bramkamp  пишет:


The reason is that that python does something stupid (tm). It
tries to close all file descriptors (except a few whitelisted
ones) up to the maximum file descriptor number. It does this by
asking the kernel for the maximum possible number and closing
everything it doesn't want to keep. Some time later someone came
up with an optimization (read the open file descriptors
from /dev/fd). All of this pain and suffering is caused by good
old Ulrich Drepper braindamage:
https://sourceware.org/bugzilla/show_bug.cgi?id=10353.

Most Linux distros have lower default file descriptor limits than
FreeBSD making this workaround less painful. The correct solution
would be to teach python3 about closefrom(2).


Thank you for hint and testing!

Indeed the problem is in closing more than 400,000 file descriptors
in loop. It seems that all current versions of Python are affected.
Python2 uses False as default value for the close_fds parameter of
the Popen constructor, so this issue is mostly not visible.
Python3 has changed this default to True.

As Jan Bramkamp suggested, I've wrote simple patch to fix an issue
(see attached file). It seems the problem has gone.


The attachment has been stripped out. Could you paste the diff into
the message?


Yes, sure.

--- Modules/_posixsubprocess.c.orig 2018-12-24 00:37:14.0
+0300 +++ Modules/_posixsubprocess.c  2019-04-12
09:25:21.549389000 +0300 @@ -235,11 +235,15 @@
_close_fds_by_brute_force(long start_fd, }
  start_fd = keep_fd + 1;
  }
+#if defined(__FreeBSD__)
+closefrom(start_fd);
+#else
  if (start_fd <= end_fd) {
  for (fd_num = start_fd; fd_num < end_fd; ++fd_num) {
  close(fd_num);
  }
  }
+#endif
  }


If this is a Python issue, shouldn't this be reported upstream, on
https://bugs.python.org ?


May be. Rather, it is a FreeBSD-specific optimization.


Well, closefrom() is also available in Darwin (a.k.a. MacOSX :-)),
OpenBSD and NetBSD. (It's not documented in current MacOSX, but it is
there, I just checked)
Anyway, FreeBSD Python maintainers will ask for an upstream PR.

I can do such a PR is noone else is willing to...

Dima




Hi Dima,

Issue exists for this:

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

Pending *upstreamable* patches for lang/python*, that we can carry 
locally until released.


___
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 commiter: security update for databases/percona56-server

[Kubilay Kocak]

On 4/04/2019 3:47 am, Sergey Akhmatov wrote:

Hello,

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

More than month without maintainer feedback on security update:
https://vuxml.FreeBSD.org/freebsd/d3d02d3a-2242-11e9-b95c-b499baebfeaf.html

Can it be commited?


See also:

databases/percona57-{server,client} update to 5.7.25-28 (fixes several 
vulnerabilities)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236570
maintainer: feld (CC'd)

There is no bug report or patches for databases/percona55-{server,client}
maintainer: flo (CC'd)




___
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 is security/py-pywinrm limited to Python 2.7 only?

[Kubilay Kocak]

On 3/04/2019 7:02 pm, Pavel Timofeev wrote:

Hello.
I'm curious why security/py-pywinrm is limited to python 2.7 now.

I tried it with python 3.6:

--- security/py-pywinrm/Makefile.orig2019-04-03 10:45:08.434229000 +0300
+++ security/py-pywinrm/Makefile2019-04-03 10:45:13.713012000 +0300
@@ -19,7 +19,7 @@
  
${PYTHON_PKGNAMEPREFIX}requests-credssp>=0.0.1:security/py-requests-credssp@${PY_FLAVOR}

  NO_ARCH=yes
-USES=python:2.7
+USES=python
  USE_PYTHON=autoplist distutils

  .include 


Port was successfully rebuilt (on FBSD12) with python3.6.
Some basic operation works at least with ntlm auth,

What is/was wrong with the port? I suppose it's worth to document it
if there is a problem.


http://svnweb.freebsd.org/changeset/ports/469695

No further detail in the commit log message (beyond pkg-fallout)

Maintainer is CC'd

If the port passes QA and run time tests (its own test suite ideally) 
under Python 3.x, we can remove the limitation.


Just open up a Bugzilla issue with a patch after confirming QA
___
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 wllvm port (should be trivial)

[Kubilay Kocak]

On 2/04/2019 10:35 pm, Gleb Popov wrote:

Hello.

I need the following python application as build dependency of a port I'm
wokring on: https://pypi.org/project/wllvm/

I think, it should be pretty easy to port, I just don't have much time for
it ATM. It would be awesome if someone would pick this up and create the
port for me.



Hi Gleb,

I've just created the port, but if its a build dependency of a port you 
intend to maintain, its probably a very good idea that you maintain 
wllvm as well.


Are you OK with being the MAINTAINER?

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

Re: Need a committer for textproc/sigil update

[Kubilay Kocak]

On 31/03/2019 8:21 pm, Jonathan Chen wrote:

Hi,

Could a committer please take a look at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236766

It got picked up by swills@ a few days ago, and it appears to have
stalled. I'm unsure as to whether it's with me or the assignee.

Cheers.



Hi Jonathan,

It can take time once assigned to be committed. Periods of a few days to 
a week or so are not uncommon.


Steve usually picks up several/many issues he plans on working on in 
bulk, and commits them once they've been through review/QA.


Contributors can help by ensuring they've already run their changes 
through QA (portlint, poudriere at least), and confirming that they have 
passed, in their submission. Something like the following is good:


portlint: OK (looks fine.)
testport: OK (poudriere: , ,  tested)
maketest: OK (XXX of YYY tests PASS)

If it takes longer than a couple of weeks, we can reset assignment based 
on an 'assignee timeout'.


If there is no explicit request for feedback/additional changes, which 
people can request by setting maintainer-feedback to ? , 
then it's not with you.


./koobs


___
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: Warning in duplicity after py2-cryptograph update

[Kubilay Kocak]

On 24/03/2019 8:34 pm, Xavier wrote:

Hi everyone,

Since last update of python modules py27-cryprography and
py27-matplotlib, duplicity emits a warning :


CryptographyDeprecationWarning: Support for unsafe construction of public 
numbers from encoded data will be removed in a future version. Please use 
EllipticCurvePublicKey.from_encoded_point


Should I file a PR ?


A particular method was deprecated in the Python cryptography package, 
in 2.5. See the last entry in:


https://github.com/pyca/cryptography/blob/master/CHANGELOG.rst#25---2019-01-22

The issue is not related to matplotlib. sysutils/duplicity uses 
security/paramiko, which already has a bug reported for the issue:


https://github.com/paramiko/paramiko/issues/1369

./koobs
___
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: [PATCH] lang/python27 -- Fix namespace collision

[Kubilay Kocak]

On 26/02/2019 12:35 am, dimpase+free...@gmail.com wrote:

On 6/20/17 Kubilay Kosak wrote:

On 6/19/17 4:31 AM, Steve Kargl wrote:
On Sun, Jun 18, 2017 at 11:29:05AM -0700, Steve Kargl wrote:

Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle
trignometric functions cospi, sinpi, and tanpi.  When libm (aka
math.h) grows support for sinpi(x), lang/python27 has a namespace
collision.  The attached patch fixes the problem.


Is this issue relevant only for particular (and/or future) FreeBSD
versions ('where libm grows supports for x, y') or independent of base
entirely?



Also, could you open an upstream issue regarding this please, as a
long-term target for all local (Python port) patches is that they are
included upstream.


I've created a Python PR to fix this:

https://github.com/python/cpython/pull/12027

Dima


This also ensures we can document all patches with their relevant
upstream issue/commit references for our future selves and others.



./koobs

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



Thank you Dima! :)

I've added the upstream PR to #232792 [1] and will track upstream progress.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232792

./koobs
___
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: Rancid3 update to 3.9?

[Kubilay Kocak]

On 20/02/2019 2:19 pm, Kubilay Kocak wrote:

On 20/02/2019 10:23 am, Dan Mahoney (Gushi) wrote:

All,

Rancid3 has been updated to 3.9, upstream.  I've contacted the 
maintainer, but it might be stuck.  Would a patch be helpful?


-Dan Mahoney



Hi Dan,

Patches are always welcome (and desirable) :)

Best is a Bugzilla issue created "net-mgmt/rancid3: Update to 3.9" with 
a patch (unified diff against the port dir) attached. This will also 
automatically assign and notify the maintainer (CC'd).


Bonus points for QA testing it with portlint and poudriere, 
details/instructions here:


https://www.freebsd.org/doc/en/books/porters-handbook/testing.html

#freebsd-ports on freenode IRC if you have any questions or need help!

./koobs


net-mgmt/rancid3: Update 3.7 -> 3.9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235875

Thanks Kurt!
___
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: Rancid3 update to 3.9?

[Kubilay Kocak]

On 20/02/2019 10:23 am, Dan Mahoney (Gushi) wrote:

All,

Rancid3 has been updated to 3.9, upstream.  I've contacted the 
maintainer, but it might be stuck.  Would a patch be helpful?


-Dan Mahoney



Hi Dan,

Patches are always welcome (and desirable) :)

Best is a Bugzilla issue created "net-mgmt/rancid3: Update to 3.9" with 
a patch (unified diff against the port dir) attached. This will also 
automatically assign and notify the maintainer (CC'd).


Bonus points for QA testing it with portlint and poudriere, 
details/instructions here:


https://www.freebsd.org/doc/en/books/porters-handbook/testing.html

#freebsd-ports on freenode IRC if you have any questions or need help!

./koobs
___
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: chrome error: libglib-2.0.so.0: Undefined symbol "environ"

[Kubilay Kocak]

On 2/01/2019 2:21 pm, Julian H. Stacey wrote:

Hi ports@
anyone else seen this or have ideas please:
chrome
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

uname 13.0-CURRENT
/usr/src/.svn_revision 342578

ls -l /usr/local/lib/libglib*
lrwxr-xr-x  1 root  wheel   21 Nov 13 02:21 /usr/local/lib/libglib-1.2.so.0@ 
-> libglib-1.2.so.0.0.10
-rwxr-xr-x  1 root  wheel   228352 Nov 13 02:21 
/usr/local/lib/libglib-1.2.so.0.0.10*
-rw-r--r--  1 root  wheel  1992640 Dec 13 03:20 /usr/local/lib/libglib-2.0.a
lrwxr-xr-x  1 root  wheel   23 Dec 13 03:20 /usr/local/lib/libglib-2.0.so@ 
-> libglib-2.0.so.0.5600.3
lrwxr-xr-x  1 root  wheel   23 Dec 13 03:20 /usr/local/lib/libglib-2.0.so.0@ 
-> libglib-2.0.so.0.5600.3
-rwxr-xr-x  1 root  wheel  1076088 Nov 29  2014 
/usr/local/lib/libglib-2.0.so.0.4200.0*
-rwxr-xr-x  1 root  wheel  1079976 Jun 15  2015 
/usr/local/lib/libglib-2.0.so.0.4200.2*
-rwxr-xr-x  1 root  wheel  1081208 Nov  5  2015 
/usr/local/lib/libglib-2.0.so.0.4400.1*
-rwxr-xr-x  1 root  wheel  1084088 Nov 29  2016 
/usr/local/lib/libglib-2.0.so.0.4600.2*
-rwxr-xr-x  1 root  wheel  1167416 Dec 13 03:20 
/usr/local/lib/libglib-2.0.so.0.5600.3*
-rw-r--r--  1 root  wheel   365328 Nov 13 02:21 /usr/local/lib/libglib.a
lrwxr-xr-x  1 root  wheel   21 Nov 13 02:21 /usr/local/lib/libglib.so@ -> 
libglib-1.2.so.0.0.10

install -f glib

I also tried: pkg add -f chromium

cd /usr/ports/devel/glib20 ; make deinstall ; make install ; ldconfig -R

now started cd /usr/ports/www/chromium; make

Cheers,
Julian



Hi Julian,

There's a thread on freebsd-current [1] about it:

https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072516.html 



./koobs
___
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: Committ request - bug #233772

[Kubilay Kocak]

On 31/12/2018 11:57 pm, Lorenzo Salvadore via freebsd-ports wrote:

Hello.

It looks like the patch attached to bug #233772 is needed:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233772

It is an update of cad/z88: the user that requested the update
asks if the patch will be merged. The patch has been tested
with poudriere on 11.2-RELEASE, 12.0-RELEASE, both on
i386 and amd64.

Thanks.
Lorenzo Salvadore.


Kurt is on it
___
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

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

Re: Dropping maintainership for www/miniminiweb

[Kubilay Kocak]

On 20/12/2018 12:19 pm, Neel Chauhan wrote:

Hi freebsd-ports@,

May I please drop maintainership for www/miniminiweb only? However, I still 
want to maintain other ports.

Thanks,

Neel Chauhan



You may at any time, no permission required :)

Standard procedure applies to this as with any change, just:

- submit a bugzilla issue with title: "cat/port: Reset MAINTAINER", with
- a patch including the change, and
- set maintainer-approval on the attachment to + (as current maintainer)

Then someone will take care of it

lastly, thank you for your efforts maintaining this (until now) and 
other ports Neel!


./koobs



___
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: Build failures for logitechmediaserver in poudriere

[Kubilay Kocak]

On 17/12/2018 9:31 pm, Jimmy Renner wrote:

Hi,

I'm getting some strange build failures for logitechmediaserver when 
building in poudriere. From ports everything is working fine, on the 
other hand the packaging step isn't done there :-)


I get a lot of these in the build log:
pkg-static: Unable to access file 
/wrkdirs/usr/ports/audio/logitechmediaserver/work/stage/usr/local/share/logitechmediaserver/CPAN/arch/5.28/Class/XSAccessor.pm:No 
such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/audio/logitechmediaserver/work/stage/usr/local/share/logitechmediaserver/CPAN/arch/5.28/Class/XSAccessor/Array.pm:No 
such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/audio/logitechmediaserver/work/stage/usr/local/share/logitechmediaserver/CPAN/arch/5.28/Class/XSAccessor/Heavy.pm:No 
such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/audio/logitechmediaserver/work/stage/usr/local/share/logitechmediaserver/CPAN/arch/5.28/DBI.pm:No 
such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/audio/logitechmediaserver/work/stage/usr/local/share/logitechmediaserver/CPAN/arch/5.28/DBI/Changes.pm:No 
such file or directory



Anyone has any idea what's causing this. Been banging my head a couple 
of days and am running out of ideas.


What is your system information (uname -a), and what exact port revision 
is failing to build? Any make.conf customisations?


If you're running on the latest tree (post perl5.28 update), there is an 
open issue with a patch adding perl 5.28 support you may to try:


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

./koobs
___
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 perl

[Kubilay Kocak]

On 14/12/2018 9:44 pm, Carmel NY wrote:

Using poudriere, I attempted to update my system to the new "perl 5.28". I
made the necessary changes in the "make.conf" files and then attempted to run
poudriere. At the very beginning of the run, poudriere issued a warning that
"security/py-certbot | py36-certbot-0.29.1_1,1" failed. This is from the end
of the log file:

===
===
===>  Patching for py36-certbot-0.29.1_1,1
===>  Applying FreeBSD patches for py36-certbot-0.29.1_1,1
Ignoring previously applied (or reversed) patch.
2 out of 2 hunks ignored--saving rejects to certbot/compat.py.rej
=> FreeBSD patch patch-certbot_compat.py failed to apply cleanly.
*** Error code 1

Stop.
make: stopped in /usr/ports/security/py-certbot
=>> Cleaning up wrkdir
===>  Cleaning for py36-certbot-0.29.1_1,1
build of security/py-certbot | py36-certbot-0.29.1_1,1 ended at Fri Dec 14
05:35:15 EST 2018 build time: 00:00:05
!!! build failure encountered !!!

Has anyone else had this problem?



Hi Carmel,

That was just reported here:

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

I'm trying to grok how this may be perl update related.

Can you try what I suggested in comment #1 and let me know (in the 
issue) how that goes.


./koobs
___
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 potential new porter seeking some clarifications

[Kubilay Kocak]

On 14/12/2018 7:09 pm, Kubilay Kocak wrote:

While special targets (check-plist) can be and are useful, the only form 
of QA we should be doing is 'all of it', and at the present moment, that 
is:


  1) portlint -AC (or better)
  2) poudriere testport (supported versions/archs, at least tier1 [1])
  3) make test for run-time QA [2]


I forgot:

4) DEVELOPER=yes in /etc/make.conf for extra sanity checks



Even (1) and (2) alone, while being the making up the bulk of our QA, 
which is notable not 'everything, everytime', is insufficient, as it 
mostly picks up only 'our' errors, not the softwares issues, which 
ultimately impact users.


[1] non tier1 is not as trivial as it should be to setup in poudriere.
[2] if test suites exist, TEST_DEPENDS and test: target should be hooked up

./koobs


___
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 potential new porter seeking some clarifications

[Kubilay Kocak]

On 14/12/2018 2:11 am, Lars Engels wrote:

On Thu, Dec 13, 2018 at 10:41:01PM +0800, Arthur Pirika wrote:

Hi all! I’m hoping to get into porting for FreeBSD, right now just
focusing on one package, a plugin for bitlbee, however I’d like to
extend my hand to maintain other ports in the future once I have more
knowledge and practice with the system.


Welcome! :-)


Before I start, though, I just need some clarifications of things from the 
porter’s handbook.

1. If I understand correctly, the version of the ports tree as fetched
by portsnap isn’t the best for working on the tree. I should instead
make another copy of the tree as an svn checkout? Distfiles, however,
still go to /usr/ports/distfiles


You can change this by setting DISTDIR variable in /etc/make.conf to a
directory you like. See ports(7) manpage.


2. Is it absolutely necessary to use poudriere before submitting a
port? I’m still getting to grips with how it works, and if I need to
get comfortable with it first, I’ll do so.


That really depends on the change's size. Trivial patches can often be
sub-/committed without a poudriere run. portlint -ac, make check-plist
and make package can find potential issues for you.
Bigger changes should be build in poudriere. You don't need to attach
the logs to the PR, though.


tldr: It is absolutely necessary if we don't want to shuffle 'quality' 
work to "someone else" as a project/culture/community, we want to pick 
up issues as early as possible and if we want our contributions as 
committers and not-yet-committers alike to be taken seriously, hopefully 
resulting in quicker times to commit in the latter case.


The degree of QA required, putting it gently, is not at all contingent 
on, or proportional to *change* size or "apparent" simplicity. That 
contention needs to go away.


Note: Lars, I'm certainly not pointing the finger at you here, or anyone 
else in particular.


The canonical example historically used, and sometimes (too often) 
described as 'simple' by both committers and contributors, mostly only 
ever used to imply that QA (or more of it) isn't necessary to get a 
Bugzilla issue assigned/closed more quickly, is the "minor PORTVERSION 
bump and a distinfo update".


In the meantime along with that two line "simple" patch, upstream has 
added/removed dependencies, added or removed a few files (pkg-plist), or 
at worst, broken/regressed something entirely, to name only a few cases.


While special targets (check-plist) can be and are useful, the only form 
of QA we should be doing is 'all of it', and at the present moment, that is:


 1) portlint -AC (or better)
 2) poudriere testport (supported versions/archs, at least tier1 [1])
 3) make test for run-time QA [2]

Even (1) and (2) alone, while being the making up the bulk of our QA, 
which is notable not 'everything, everytime', is insufficient, as it 
mostly picks up only 'our' errors, not the softwares issues, which 
ultimately impact users.


[1] non tier1 is not as trivial as it should be to setup in poudriere.
[2] if test suites exist, TEST_DEPENDS and test: target should be hooked up

./koobs
___
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: certbot lost certificates , and registration data

[Kubilay Kocak]

On 11/12/2018 1:43 am, Matthew Seaman wrote:

On 10/12/2018 14:10, Paul Macdonald via freebsd-ports wrote:


On 10/12/2018 13:15, Paul Macdonald via freebsd-questions wrote:


Is anyone else seeing py-certbot having lost all installed certs, and 
the initial registation data?


There was an update on the 7th

Upgrade of py27-certbot-0.28.0_1,1 to py27-certbot-0.29.1_1,1

and on 3 boxes tested so far, which all had certs, i now see no certs 
listed and a request to redo the initial registation on attempts to 
install a new cert.


i don't see any issues upstream here: 
https://github.com/letsencrypt/boulder/issues/ so not sure if this is 
FBSD thing or not.


Paul.



passing --config-dir /usr/local/etc/letsencrypt shows expected output, 
i suspect something has happend with that flag on the upgrade ( i see 
/etc/letsencrypt directories on affected servers)








This upstream commit:

https://github.com/certbot/certbot/commit/a23d76beb0e2c9539670766045314a5d50f582a2#diff-64ccdc74e8a07f9b039a6254093f1d0d 



breaks the post-patch target in the security/certbot port Makefile:

post-patch:
     @${REINPLACE_CMD} \
     -e 's|/etc/|${LOCALBASE}/etc/|' \
     -e 's|/var/lib|/var/db|' \
     ${WRKSRC}/${PORTNAME}/constants.py

Looks like the REINPLACE_CMD should be applied to 
${WRKSRC}/${PORTNAME}/compat.py now.


Or compat.py should be patched to grok FREEBSD_DEFAULT_FOLDERS

 Cheers,

 Matthew



Nice find Matthew.

Prefer the latter (and sent upstream). Can one of you create a bugzilla 
issue for this and cc me please.


If you'd like to give a representative/attempted patch a go, please do.

./koobs
___
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: print/py27-reportlab still won't build

[Kubilay Kocak]

On 3/12/2018 6:26 pm, Kevin Oberman wrote:

I have reproduced it and did so before the message, but I am not able to
re-open as it is not my ticket. I just discovered that ticket when I was
preparing to submit a ticket. It should be re-opened and set to "Affects
some people". I have copied Rob Belica, the originator of the ticket.

I added details of my configuration to the ticket.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


I was under the impression any user could re-open issues. I've done that 
for you now.


Thank you for the added detail in the bug.



On Sun, Dec 2, 2018 at 5:46 PM Kubilay Kocak  wrote:


On 3/12/2018 12:25 pm, Kevin Oberman wrote:

I see that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233323 was
closed last week as "Overcome by events". How was the problem overcome

and

by what event. I still am unable to build the port and, as a result,

can't

upgrade hplip. What am I missing?


Hi Kevin,

After confirming the issue is still reproducible after the revision
(r486170) detailed in comment [1], re-open the Bugzilla issue with
details [2][3] of the reproduction case.

I've corrected the resolution (Overcome By Events -> Unable to
Reproduce) to more accurately reflect the claimed resolution type.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233323#c1
[2] System info (uname -a), ports/pkg (latest? quarterly? make.conf)
[3] Full build/error log as an attachment (including OPTIONS, etc)

./koobs







___
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: print/py27-reportlab still won't build

[Kubilay Kocak]

On 3/12/2018 12:25 pm, Kevin Oberman wrote:

I see that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233323 was
closed last week as "Overcome by events". How was the problem overcome and
by what event. I still am unable to build the port and, as a result, can't
upgrade hplip. What am I missing?


Hi Kevin,

After confirming the issue is still reproducible after the revision 
(r486170) detailed in comment [1], re-open the Bugzilla issue with 
details [2][3] of the reproduction case.


I've corrected the resolution (Overcome By Events -> Unable to 
Reproduce) to more accurately reflect the claimed resolution type.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233323#c1
[2] System info (uname -a), ports/pkg (latest? quarterly? make.conf)
[3] Full build/error log as an attachment (including OPTIONS, etc)

./koobs


___
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: mail/imapfilter fails to build

[Kubilay Kocak]

On 14/11/2018 3:15 pm, tech-lists wrote:

Hi,

mail/imapfilter fails to build on 12-beta4

context:
FreeBSD 12.0-BETA4 #2 r340371
ports r484903
OpenSSL 1.1.1-freebsd





Being tracked in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232132
___
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: Git segfaulting in libcrypto.so when trying to clone.

[Kubilay Kocak]

On 17/10/2018 6:34 pm, Brennan Vincent wrote:

This also happens in the stock `git` installed from `pkg`, but I have installed 
it also from `/usr/ports` so I could enable debug symbols and get a proper 
stacktrace.

When cloning any https repo (or at least the ones from github that I tried), 
git segfaults in `git-remote-https`, and the core dump shows the following 
stack trace:

   * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46
 frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] 
getrn(lh=, data=0x0008013aba20) at lhash.c:434
 frame #2: 0x000800d04ebb 
libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at 
lhash.c:207
 frame #3: 0x000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x, 
type=, data="m\x04") at o_names.c:202
 frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at 
c_allc.c:83
 frame #5: 0x00080120a4b9 
libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] 
ossl_init_add_all_ciphers at init.c:216
 frame #6: 0x00080120a4b4 
libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205
 frame #7: 0x00080064de28 
libthr.so.3`_pthread_once(once_control=0x00080128a3b0, 
init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at 
thr_once.c:97
 frame #8: 0x000801209b69 
libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) 
at threads_pthread.c:113
 frame #9: 0x000801209f67 
libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) 
at init.c:611
 frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, 
settings=) at ssl_init.c:197
 frame #11: 0x000800525cb4 
libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883
 frame #12: 0x0008004a4a92 
libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722
 frame #13: 0x0008004a935f 
libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271
 frame #14: 0x00080045b455 
libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405
 frame #15: 0x0008004661ca 
libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154
 frame #16: 0x00080047c436 
libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934
 frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222
 frame #18: 0x0026a519 git-remote-https`step_active_slots at 
http.c:1293
 frame #19: 0x0026a596 
git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314
 frame #20: 0x0026a9f8 
git-remote-https`run_one_slot(slot=0x0008012fa4c0, 
results=0x7fffe0f8) at http.c:1509
 frame #21: 0x0026dc6a 
git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793
 frame #22: 0x0026ac5b 
git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869
 frame #23: 0x0026ac1c 
git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, options=0x7fffe1f0) at http.c:1910
 frame #24: 0x00264fbd git-remote-https`discover_refs(service="", 
for_push=0) at remote-curl.c:385
 frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at 
remote-curl.c:465
 frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, 
argv=0x7fffe470) at remote-curl.c:1369
 frame #27: 0x002707d7 git-remote-https`main(argc=3, 
argv=0x7fffe470) at common-main.c:45
 frame #28: 0x0026311b git-remote-https`_start(ap=, 
cleanup=) at crt1.c:76


Hi Brennan,

git gets its HTTP/HTTPS/etc support via curl, so it's likely an issue there.


Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... 
that seems wrong to me, but I'm not an expert.


There have been many instances in the past where software (from 
ports/packages) ends up linked against *both* OpenSSL from base and 
OpenSSL from ports, due to various issues. This is probably a similar issue.


The same problem can occur for anything that base provides, that can 
also be provided by ports, gssapi, ncurses, readline, among others come 
to mind.





`/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me.


If both exist in base, that's interesting (and probably a problem). I 
only have libcrypto.so.8 on a recent (month old) CURRENT build.


The openssl port (which curl can use) provides libcrypto.so.9 (in 
/usr/local/lib)



I can't reproduce this on a pristine install of 12.0-ALPHA10.



Some more system information might prove useful:

- FreeBSD version issue is reproducible on (uname -a)
- Output of ldd /usr/local/bin/curl
- Using quarterly or latest packages?
- What 

Re: net/ntopng: version jump by an order of magnitude

[Kubilay Kocak]

On 20/09/2018 6:40 am, Franco Fichtner wrote:
> Hi,
> 
> Small question:
> 
> https://github.com/freebsd/freebsd-ports/commit/0585180d
> 
> ... has a typo in the version number which was an ISO date
> originally.  Are we using this new date format now or is there
> going to be a PORTEPOCH amendment?

Up to the maintainer ultimately.

To avoid PORTEPOCH, either the typo'd datestamp scheme (0XX for month)
would need to continue until 3.7, or an alternate scheme created that is
both meaningful and > than (pkg version -t old new) the current value.

Or fix the typo and add PORTEPOCH.

Personally, I'd go the first option as it's only a minor typo that
doesn't affect ongoing existing-scheme version updates, and is the more
transient of the two (PORTEPOCH lives forever, bad scheme only lasts
till 3.7).

> 
> Cheers,
> Franco
> ___
> 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: weechat failing to load ruby.so after recent updates

[Kubilay Kocak]

On 11/09/2018 1:36 am, Todd Wasson wrote:
> Hi all, I recently restarted weechat for the first time in awhile (1-2
> months), and now it can't load ruby.so because of:
> 
> Error: unable to load plugin "/usr/local/lib/weechat/plugins/ruby.so"
> /usr/local/lib/weechat/plugins/ruby.so: Undefined symbol "ruby_version"
> 
> `strings /usr/local/lib/weechat/plugins/ruby.so` reveals that ruby_version
> is in the file.  I first saw this with the binary pkg installation, but
> I've rebuilt weechat from source from the ports tree and that didn't
> resolve the problem.  I also updated to 11.2-RELEASE after I first saw
> this, which also had no effect, incidentally.  ktrace revealed nothing
> useful, and I'm not sure what I should look for with dtrace.
> 
> Any thoughts?  I suspect this is more likely to be a FreeBSD-specific
> problem than a general weechat problem, as I see no reports (other than a
> random pastebin paste) of this anywhere online.  Any help would be
> appreciated!
> 
> 
> Todd

Hi Todd,

I can confirm the issue, also present on CURRENT using ports (so not
specific to packages or freebsd versions), after updating to weechat 2.2
(and ruby 2.4.4). Rebuilding both does not resolve the issue.

Best course of action is to report the issue so that at least the issue
is logged, and the maintainer (cc'd) can investigate:

"irc/weechat: Fails to load ruby plugin after update to 2.2 (Undefined
symbol "ruby_version)"

Feel free to CC me on it.

./koobs



___
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: x11/nvidia-driver no longer works under -current (r338323)

[Kubilay Kocak]

On 26/08/2018 9:07 pm, John wrote:

Hello lists,

x11/nvidia-driver is broken again.

Context: FreeBSD-12-ALPHA3 r338323 /  ports 478102 / amd64.

Tried to build with make distclean clean rmconfig && make MAKE_JOBS_UNSAFE=yes

It fails here:


Hi John,

It fails earlier, can you find and paste the 'error: ' line(s) ?

More importantly though, ports shouldn't be using -Werror so a good 
first step would be to identify its source and remove it.



=kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG 
-Werror=undef  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc 
-I. -I/usr/src/sys
  -I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer   -MD  -MF.depend.nvidia_pci.o -MTnvidia_pci.o 
-mcmodel=kernel -mno-r
ed-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototy
pes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unkn
own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-nega
tive-value -Wno-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 
-c nvidia_pci.c -o nvidia_pci.o
cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" -D__KERNEL__ 
-DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone 
-mcmodel
=kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG 
-Werror=undef  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc 
-I. -I/usr/src/sys
  -I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer   -MD  -MF.depend.nvidia_subr.o -MTnvidia_subr.o 
-mcmodel=kernel -mno
-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-proto
types -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-un
known-pragmas -Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-ne
gative-value -Wno-address-of-packed-member  -mno-aes -mno-avx  
-std=iso9899:1999 -c nvidia_subr.c -o nvidia_subr.o
*** Error code 1

Stop.
make[4]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia
*** Error code 1

Stop.
make[3]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src
*** Error code 1

Stop.
make[2]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/nvidia-driver
*** Error code 1

Stop.

Stop.
make: stopped in /usr/ports/x11/nvidia-driver

I can post more output if you need it.

thanks,


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

Re: Porting python applications and meeting dependency requirements

[Kubilay Kocak]

On 13/08/2018 7:52 am, Carsten Larsen wrote:
> Hi @ports
> 
> I am not so familiar with porting python applications. There seems to be
> some caveats, dependencies being one of them. Question is: Would it be
> difficult to make a port of The Onion Box? Source is on Github:
> https://github.com/ralphwetzel/theonionbox

It's also registered in PyPI: https://pypi.org/project/theonionbox/ with
its source distribution ('sdist') uploaded there.

Porting python packages is relatively straight forward, particular those
that use standard Python ecosystem mechanisms (distutils/setuptools,
etc). This looks fairly straightforward at a quick glance to port.

Dependencies are listed in setup.py:install_requires [1] which
correspond to RUN_DEPENDS

If some of the dependencies aren't in ports, they'll need porting first.

Some Python specific porting guidelines to help:

https://wiki.freebsd.org/Python/PortsPolicy

#freebsd-ports or #freebsd-python @ freenode IRC if you have any
questions or need help.

[1] https://github.com/ralphwetzel/theonionbox/blob/master/setup.py#L375

> Regard
> Carsten

./koobs
___
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: Blackbox does not compile, diff in here

[Kubilay Kocak]

On 9/08/2018 3:14 pm, Kubilay Kocak wrote:
> On 9/08/2018 3:05 pm, Erich Dollansky wrote:
>> Hi,
>>
>> On Thu, 9 Aug 2018 14:34:17 +1000
>> Kubilay Kocak  wrote:
>>
>>> On 9/08/2018 12:29 pm, Erich Dollansky wrote:
>>>>
>>>> I do not know if somebody spotted this already. Some casting was
>>>> done to the wrong types.  
>>>
>>> This looks like
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226708
>>>
>> yes, it is the same. But why could I compile blackbox without a problem
>> up to one or two months ago? Did the compiler to comprehend the problem
>> before?
> 
> The bug report doesn't contain system information (freebsd version/arch,
> date) so it's not immediately at this stage, but I have reproduced the
> error on 12-CURRENT (r336056) and am QA'ing other versions/archs as we
> speak.

Looks like it's Clang 6, so I'm guessing all reporters are running
12-CURRENT post clang 6 import.

See Also:

https://clang.debian.net/status.php?version=6.0=CXX11_NARROWING

> What's the uname -a of the system you are seeing this issue on? Could
> you add this information in the bug?
> 
> 
>> Erich
>>
>>
>>> The first and third chunks below appear to be
>>> noise/spurious/unnecessary though.
>>>
>>>> Erich
>>>>
>>>> PS I am not experienced in creating diffs for ports. This one was
>>>> done in the working directory's lib entry: 
>>>>
>>>>
>>>> --- EWMH.cc.180809  2005-01-24
>>>> 15:50:56.0 +0800 +++ EWMH.cc 2018-08-09
>>>> 10:10:05.630203000 +0800 @@ -204,7 +204,7 @@
>>>>  bool bt::EWMH::readNumberOfDesktops(Window target,
>>>>   unsigned int* number) const {
>>>>unsigned char* data = 0;
>>>> -  if (getProperty(target, XA_CARDINAL, net_number_of_desktops,
>>>> )) {
>>>> +  if (getProperty (target, XA_CARDINAL, net_number_of_desktops,
>>>> )) { *number =
>>>>static_cast(*(reinterpret_cast>>> *>(data)));   
>>>> @@ -246,8 +246,11 @@
>>>>  
>>>>  
>>>>  void bt::EWMH::setDesktopViewport(Window target, int x, int y)
>>>> const {
>>>> +   //
>>>> +   // 09.08.18 ed: the following statement was modified.
>>>> +   //
>>>>const unsigned long viewport[] =
>>>> -{ static_cast(x), static_cast(y) };
>>>> +{ static_cast(x), static_cast>>> long>(y) }; setProperty(target, XA_CARDINAL, net_desktop_viewport,
>>>>reinterpret_cast(viewport),
>>>> 2); }
>>>> @@ -644,8 +647,10 @@
>>>>  }
>>>>  
>>>>  
>>>> -bool bt::EWMH::getProperty(Window target, Atom type, Atom property,
>>>> -unsigned char** data) const {
>>>> +bool bt::EWMH::getProperty (Window target, Atom type, Atom
>>>> property,
>>>> +unsigned char  ** data)
>>>> const { Atom atom_return;
>>>>int size;
>>>>unsigned long nitems, bytes_left;
>>>> ___
>>>> 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: Blackbox does not compile, diff in here

[Kubilay Kocak]

On 9/08/2018 3:05 pm, Erich Dollansky wrote:
> Hi,
> 
> On Thu, 9 Aug 2018 14:34:17 +1000
> Kubilay Kocak  wrote:
> 
>> On 9/08/2018 12:29 pm, Erich Dollansky wrote:
>>>
>>> I do not know if somebody spotted this already. Some casting was
>>> done to the wrong types.  
>>
>> This looks like
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226708
>>
> yes, it is the same. But why could I compile blackbox without a problem
> up to one or two months ago? Did the compiler to comprehend the problem
> before?

The bug report doesn't contain system information (freebsd version/arch,
date) so it's not immediately at this stage, but I have reproduced the
error on 12-CURRENT (r336056) and am QA'ing other versions/archs as we
speak.

What's the uname -a of the system you are seeing this issue on? Could
you add this information in the bug?


> Erich
> 
> 
>> The first and third chunks below appear to be
>> noise/spurious/unnecessary though.
>>
>>> Erich
>>>
>>> PS I am not experienced in creating diffs for ports. This one was
>>> done in the working directory's lib entry: 
>>>
>>>
>>> --- EWMH.cc.180809  2005-01-24
>>> 15:50:56.0 +0800 +++ EWMH.cc 2018-08-09
>>> 10:10:05.630203000 +0800 @@ -204,7 +204,7 @@
>>>  bool bt::EWMH::readNumberOfDesktops(Window target,
>>>   unsigned int* number) const {
>>>unsigned char* data = 0;
>>> -  if (getProperty(target, XA_CARDINAL, net_number_of_desktops,
>>> )) {
>>> +  if (getProperty (target, XA_CARDINAL, net_number_of_desktops,
>>> )) { *number =
>>>static_cast(*(reinterpret_cast>> *>(data)));   
>>> @@ -246,8 +246,11 @@
>>>  
>>>  
>>>  void bt::EWMH::setDesktopViewport(Window target, int x, int y)
>>> const {
>>> +   //
>>> +   // 09.08.18 ed: the following statement was modified.
>>> +   //
>>>const unsigned long viewport[] =
>>> -{ static_cast(x), static_cast(y) };
>>> +{ static_cast(x), static_cast>> long>(y) }; setProperty(target, XA_CARDINAL, net_desktop_viewport,
>>>reinterpret_cast(viewport),
>>> 2); }
>>> @@ -644,8 +647,10 @@
>>>  }
>>>  
>>>  
>>> -bool bt::EWMH::getProperty(Window target, Atom type, Atom property,
>>> -unsigned char** data) const {
>>> +bool bt::EWMH::getProperty (Window target, Atom type, Atom
>>> property,
>>> +unsigned char  ** data)
>>> const { Atom atom_return;
>>>int size;
>>>unsigned long nitems, bytes_left;
>>> ___
>>> 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: Blackbox does not compile, diff in here

[Kubilay Kocak]

On 9/08/2018 12:29 pm, Erich Dollansky wrote:
> Hi,
> 
> I do not know if somebody spotted this already. Some casting was done
> to the wrong types.

Hi Erich,

This looks like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226708

The first and third chunks below appear to be noise/spurious/unnecessary
though.

> Erich
> 
> PS I am not experienced in creating diffs for ports. This one was done
> in the working directory's lib entry: 
> 
> 
> --- EWMH.cc.180809  2005-01-24
> 15:50:56.0 +0800 +++ EWMH.cc 2018-08-09 10:10:05.630203000
> +0800 @@ -204,7 +204,7 @@
>  bool bt::EWMH::readNumberOfDesktops(Window target,
>   unsigned int* number) const {
>unsigned char* data = 0;
> -  if (getProperty(target, XA_CARDINAL, net_number_of_desktops, ))
> {
> +  if (getProperty (target, XA_CARDINAL, net_number_of_desktops,
> )) { *number =
>static_cast(*(reinterpret_cast *>(data))); 
> @@ -246,8 +246,11 @@
>  
>  
>  void bt::EWMH::setDesktopViewport(Window target, int x, int y) const {
> +   //
> +   // 09.08.18 ed: the following statement was modified.
> +   //
>const unsigned long viewport[] =
> -{ static_cast(x), static_cast(y) };
> +{ static_cast(x), static_cast(y) };
>setProperty(target, XA_CARDINAL, net_desktop_viewport,
>reinterpret_cast(viewport), 2);
>  }
> @@ -644,8 +647,10 @@
>  }
>  
>  
> -bool bt::EWMH::getProperty(Window target, Atom type, Atom property,
> -unsigned char** data) const {
> +bool bt::EWMH::getProperty (Window target, Atom type, Atom property,
> +unsigned char  ** data) const {
>Atom atom_return;
>int size;
>unsigned long nitems, bytes_left;
> ___
> 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: Request for commit approval : jack_umidi

[Kubilay Kocak]

On 24/07/2018 7:39 pm, Hans Petter Selasky wrote:
> Update jack_umidi to version 1.0.9
> 
> Fix for long device names.
> 
> Approved by:   
> 
> --HPS
> 

Looks fine (syntactically), but hesitant to approve without QA
confirmation (poudriere, for packaging checks, etc)

But since the pkg-plist is defined within Makefile *_PLIST entries and
assuming its contents have been checked to not have changed ..

Approved: koobs (ports)
MFH: 2018Q3 (bugfix)
___
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: sysutils/ansible and FLAVOR (Python 3.6 support)

[Kubilay Kocak]

On 15/05/2018 5:02 pm, Christopher Hall wrote:
> Hello everyone,

Hi Christopher,

> I am looking at which is the best way to modify the sysutils/ansible
> port so that it will use Python3.6. Currently it has the "noflavors"
> option in the USE_PYTHON line son only a single packages with
> Python2.7 exists in the pkg repo.

tldr: Add PYTHON_PKGNAMEPREFIX to the port if you want to produce a py3x
version of the port. If you/we/users also want it from the official
package repositories, remove noflavors.

> Should it be renamed to sysutils/py-ansible and "noflavors" removed?
> To produce both py27-ansible and py36-ansible packages in repo,
> allowing a choice of Python version

The name of the directory is less relevant than whether a/the port uses
PYTHON_PKGNAMEPREFIX (to differentiate package names when built with/for
different Python versions. The current ansible port doesn't do this and
it should (since it correctly allows all python versions with
USES=python, without qualification)

> Alternatively, is it better to keep the name as sysutils/ansible and
> just change the "USES=python" to "USES=python:3.6+".  However this would
> make it a Python3 only package.
> 
> Any suggestions as to which approach would be preferable?

The Python team recommends that if a Python package supports multiple
Python versions (ansible does), then the port should reflect that and
not force one version or another, and use PYTHON_PKGNAMEPREFIX. This
includes Python packages supporting 2 & 3, and forcing 3.x or the
reverse, forcing 2.x.

This at *least* allows a user to select which version of the
port/package they want, using DEFAULT_VERSIONS overrides.

Separately, on the multiple flavours/package creation question in the
official package repositories, we also recommend that noflavors only be
used in the *very* rare cases where it is *entirely* irrelevant which
Python version is used, and where there isn't any value *whatsoever* in
having multiple packages, say if a user wants to transition between
using a 2.x version to 3.x on their own time at their own pace.

tldr, for maintainers:

- User choice should not be removed/precluded
- Be declarative, not imperative for Python ports/packages
- If it supports > 1 Python versions (any combination), use
PYTHON_PKGNAMEPREFIX
___
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: flavors and rc scripts

[Kubilay Kocak]

On 3/04/2018 5:26 pm, Gerhard Schmidt wrote:
> Hi,
> 
> I'm trying to build a python package that uses flavors to allow parallel
> installation for different python versions.
> 
> So far building an installing works fine till the start script comes in
> the picture.
> 
> The port should install a start script for each of the flavors
> installed, but USE_RC_SUBR installs the rc.script under the name given
> and don't add the prefix or suffix. When i use
> USE_RC_SUBR=${PYTHON_PKGNAMEPREFIX}scriptname i have to add a start
> script for every flavor.
> 
> Is there a way to gent USE_RC_SUBR to add the prefix or suffix.
> 

Hi Gerhard,

Good question.

USES=uniquefiles (or the same thing via USE_PYTHON=concurrent) *may* be
able to help you here, though I haven't seen it attempted (yet) for rc
scripts specifically.

For example, USE_PYTHON='concurrent' is a specific instantiation/use of
Uses/uniquefiles.mk, which creates version-specific copies of files,
with default filenames (optionally) symlinked to the version-suffixed
counterparts, for a certain set of files (script in localbase/bin, man
pages etc) in python ports.

You may either be able to:

a) 'extend' the list of files python.mk already looks for, for
prefixing/suffixing the rc script, or
b) use uniquefiles.mk variables directly in the port

Hope that helps.
___
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 status of the ical calendar program?

[Kubilay Kocak]

On 20/03/2018 11:39 pm, Bob Willcox wrote:
> Attempting to build ical on any of my 12.0-CURRENT systems results in this
> error:
> 
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 3836 warnings and 20 errors generated.
> *** [main.o] Error code 1
> 
> make[1]: stopped in /usr/ports/deskutils/ical/work/ical-2.2
> 1 error
> 
> make[1]: stopped in /usr/ports/deskutils/ical/work/ical-2.2
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/deskutils/ical
> 
> So it looks like ical is currently broken in CURRENT. Are there any plans to
> fix this? Alternatively, is there some other calendar program that folks use
> that is a good replacement. So far, the several I have tried (xcaledar,
> phpicalendar, gsimplecal, & gnome-calendar) don't seem like good substitutes.

Hi Bob,

The above log doesn't include the reasons why it failed (the error(s)
are further up), which will be the first port of call figuring out
what's happening.

Also note that CURRENT recently introduced Clang 6.0.0, which caused
many ports to fail, many of which haven't been fixed yet. This could be
one of them.

I'd start by opening a Bugzilla issue "deskutils/ical: Fails to build on
CURRENT", and include the full build log as an attachment. Please reply
here with the Bugzilla ID/url when you do so others can follow and/or
assist there.

Given the port doesn't currently have a maintainer, I'd then (either
myself, or with help from others here, on the mailing lists or on IRC)
try to isolate the issue and provide a patch.

./koobs
___
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: "converters/php72-mbstring" build failure

[Kubilay Kocak]

On 19/03/2018 9:33 pm, Kubilay Kocak wrote:
> On 19/03/2018 9:22 pm, Carmel NY wrote:
>> FreeBSD-11.1-RELEASE-p8
>>
>> I am attempting to update the "converters/php72-mbstring" port. The older
>> version build fine. The newest version fails with this error message:
>>
>> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
>> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>>^
>> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
>> #define re_pattern_buffer   php_mb_re_pattern_buffer
>> ^
>> /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring/php_mbregex.c:452:41:
>> error: incomplete definition of type 'struct php_mb_re_pattern_buffer' if 
>> (!rc
>> || rc->options != options || rc->enc != enc || rc->syntax != syntax) { ~~^
>> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
>> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>>^
>> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
>> #define re_pattern_buffer   php_mb_re_pattern_buffer
>> ^
>> /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring/php_mbregex.c:452:59:
>> error: incomplete definition of type 'struct php_mb_re_pattern_buffer' if 
>> (!rc
>> || rc->options != options || rc->enc != enc || rc->syntax != syntax) { ~~^
>> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
>> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>>^
>> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
>> #define re_pattern_buffer   php_mb_re_pattern_buffer
>> ^
>> 3 errors generated.
>> *** [php_mbregex.lo] Error code 1
>>
>> make[1]: stopped
>> in /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring
>> 1 error
>>
>> make[1]: stopped
>> in /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring
>> ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and
>> rebuild before reporting the failure to the maintainer.
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /xports/converters/php72-mbstring
>>
>>
>> The complete build log file is available here:
>> https://www.seibercom.net/converters___php72-mbstring.log
>>
>> I routinely use "synth" to build my ports, if it makes any difference.
>>
> 
> Hi Carmel,
> 
> The issue was picked up in this thread:
> https://lists.freebsd.org/pipermail/svn-ports-all/2018-March/177869.html
> 
> 

Also now here (with patch):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226717
___
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: "converters/php72-mbstring" build failure

[Kubilay Kocak]

On 19/03/2018 9:22 pm, Carmel NY wrote:
> FreeBSD-11.1-RELEASE-p8
> 
> I am attempting to update the "converters/php72-mbstring" port. The older
> version build fine. The newest version fails with this error message:
> 
> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>^
> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
> #define re_pattern_buffer   php_mb_re_pattern_buffer
> ^
> /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring/php_mbregex.c:452:41:
> error: incomplete definition of type 'struct php_mb_re_pattern_buffer' if (!rc
> || rc->options != options || rc->enc != enc || rc->syntax != syntax) { ~~^
> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>^
> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
> #define re_pattern_buffer   php_mb_re_pattern_buffer
> ^
> /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring/php_mbregex.c:452:59:
> error: incomplete definition of type 'struct php_mb_re_pattern_buffer' if (!rc
> || rc->options != options || rc->enc != enc || rc->syntax != syntax) { ~~^
> /usr/local/include/oniguruma.h:673:8: note: forward declaration of 'struct
> php_mb_re_pattern_buffer' struct re_pattern_buffer;
>^
> ./php_onig_compat.h:4:37: note: expanded from macro 're_pattern_buffer'
> #define re_pattern_buffer   php_mb_re_pattern_buffer
> ^
> 3 errors generated.
> *** [php_mbregex.lo] Error code 1
> 
> make[1]: stopped
> in /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring
> 1 error
> 
> make[1]: stopped
> in /construction/xports/converters/php72-mbstring/work/php-7.2.3/ext/mbstring
> ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and
> rebuild before reporting the failure to the maintainer.
> *** Error code 1
> 
> Stop.
> make: stopped in /xports/converters/php72-mbstring
> 
> 
> The complete build log file is available here:
> https://www.seibercom.net/converters___php72-mbstring.log
> 
> I routinely use "synth" to build my ports, if it makes any difference.
> 

Hi Carmel,

The issue was picked up in this thread:
https://lists.freebsd.org/pipermail/svn-ports-all/2018-March/177869.html


___
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: If a submitted port is in "enlightenment" category, who should maintain it?

[Kubilay Kocak]

On 2/26/18 9:45 AM, Yuri wrote:
> Can it/should it be assigned to enlightenm...@freebsd.org?

For new ports, it's a defacto, strongly encouraged guideline that new
ports should be MAINTAINER'd by the person who authored it, for reasons
outlined:

https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html

and

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html#maintain-port

> Does enlightenm...@freebsd.org need to be asked if they want to maintain
> it?

Yes, unless a team has explicitly said that its OK (the python team for
python ports is close to this). But this (new port) is different than
existing ports who's maintainers are being reset.

> Or the submitter should maintain it?

Yes, all else being equal, in almost all cases, unless there is a good
reason not to (say its a very important, highly impactful port that
*should* be maintained by the ports team responsible for that software
ecosystem)

> 
> Yuri
> 

___
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 a commiter [py-lxml]

[Kubilay Kocak]

On 2/20/18 6:47 PM, Loïc BLOT wrote:
> Hello
> 
> I pushed the following patch to update lxml. I need it before sending
> py-searx 0.14 update.
> 
> Can someone do it ?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226032
> 
> Thanks in advance
> 

The issue is currently pending maintainer feedback/timeout (2 weeks).

Also, there are two attachments, one should be obsoleted so as to
reduce/remove confusion

./koobs
___
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: new portmaster fails to build devel/py-libzfs@py36 because of failing cython

[Kubilay Kocak]

On 15/12/2017 8:50 pm, Johan Hendriks wrote:
> Hello all.

Hi Johan

> First of all thank you for the update of portmaster, much appreciated.
> 
> When i am updating my ports, portmaster fails with the following error.
> 
> > Compressing man pages (compress-man)
> ===>>> Starting check for runtime dependencies
> ===>>> Gathering dependency list for lang/cython@py36 from ports
> ===>>> Dependency check complete for lang/cython@py36
> 
> ===>>> devel/py-libzfs@py36 1/10 >> lang/cython@py36 (1/1)
> 
> ===>  Installing for py36-cython-0.26
> ===>  Checking if py36-cython already installed
> ===>   Registering installation for py36-cython-0.26 as automatic
> Installing py36-cython-0.26...
> pkg-static: py36-cython-0.26 conflicts with cython3-0.26 (installs files

notice the reference to cython3 here ---^

lang/cython and lang/cython3 use to both exist, one for python2, the
other for python3.

lang/cython3 was recently deleted, since lang/cython now supports
multiple concurrent installations with different python versions.

pkg delete cython3, then go again.

Let us know how it goes

> into the same place).  Problematic file: /usr/local/bin/cygdb-3.6
> *** Error code 70
> 
> Stop.
> make: stopped in /usr/ports/lang/cython
> 
> ===>>> Installation of py36-cython-0.26 (lang/cython@py36) failed
> ===>>> Aborting update
> 
> ===>>> Update for lang/cython@py36 failed
> ===>>> Aborting update
> 
> ===>>> Update for devel/py-libzfs@py36 failed
> ===>>> Aborting update
> 
> 
> Is there someting i can try or do?




> regards
> 
> Johan
> 

___
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 preferred MASTER_SITES for python port?

[Kubilay Kocak]

On 12/12/2017 1:28 am, Sergey Akhmatov wrote:
> 
> I've looked for the answer in Porters Handbook and at
> https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.

Python Policy wiki page has been updated:

https://wiki.freebsd.org/Python/PortsPolicy#MASTER_SITES

Thank you for the question and report :)

./koobs
___
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 preferred MASTER_SITES for python port?

[Kubilay Kocak]

On 12/12/2017 1:28 am, Sergey Akhmatov wrote:
> Hello.
> 
> Suppose I want to port some python package that exists in the Python
> Package Index (PyPI) and has it's source code available on some official
> website or github.
> 
> Is there any policy or recommended practice for choosing MASTER_SITES?
> Should I use "USE_GITHUB=yes" or "MASTER_SITES= CHEESESHOP" for such
> package?
> 
> I've looked for the answer in Porters Handbook and at
> https://wiki.freebsd.org/Python/PortsPolicy but haven't found it.
> 
> Thank you.
> 

Hi Sergey:

Use CHEESESHOP by default unless there is a compelling (temporary) case
not to.

Examples include certain files are not correctly packaged/included in
the PyPI sdist, such as test suite/files/data.

In these cases, use the alternative MASTER_SITES, open issues/PR's
upstream to get them included, and switch to CHEESESHOP when it lands.

This ensures an upstreams packaging/deployment pipeline is well tested
and standardised, as it is heavily relied upon (setuptools, autoplist,
documentation, discoverability, etc)

Note: Irrespective of MASTER_SITES, if a package is in PyPI it *must* be
named exactly by its . That is:

* SVN Directory: py-
* PORTNAME= 
* PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}

./koobs



___
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: net/freeradius3 maintainer is ignoring the port (timeout)

[Kubilay Kocak]

On 11/7/17 2:11 PM, John W. O'Brien wrote:
> Hello FreeBSD ports,
> 
> The maintainer of net/freeradius3 is unresponsive on two open bugs, both
> with proposed patches.
> 
> In one case [0], the submitter responded to feedback on 2016-02-03,
> there has been no further action on the part of the maintainer, and the
> port remains broken w.r.t. Kerberos.
> 
> In the other case [1], there was already one maintainer timeout (5 mo as
> of 2016-07-17). The bug was reassigned to the maintainer on 2017-08-18,
> and there has been no further action.
> 
> I would appreciate it if somebody could give these bugs the attention
> they need.
> 
> Also, I ask that if the maintainer is unable or unwilling to attend to
> reported problems, that the port be released so that others could more
> easily work to improve it.

If you'd like (or are offering) to maintain the port, please create a
separate issue updating the MAINTAINER line and have it depend on the
existing open issues (so they can be committed first).

The maintainer change can then be made after maintainer timeout (2+ weeks).

It's much easier and preferred to update maintainers with an explicit
offer and change (in a bug), than to release a port with the possible
prospect of having no maintainer.

> Regards,
> John
> 
> [0] net/freeradius3: Fix pkg-plist with IDN option
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202684
> [1] net/freeradius3: Does not link properly against selected kerberos
> implementation
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205493
> 


___
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: Bugzilla keeps returning "gateway timeout"

[Kubilay Kocak]

On 10/31/17 9:24 PM, Kubilay Kocak wrote:

> Bugmeister (team responsible for the FreeBSD Bugzilla service) is aware
> of the issue, which after initial investigation, has been reported
> (escalated) to the FreeBSD infrastructure team, Cluster Admin.
> 
> Root cause and estimated time to resolution (ETR) are currently unknown.
> 
> Updates will be provided via at least this list (freebsd-ports), but
> also potentially other appropriate channels as additional information
> becomes available.
> 

Cluster Admin has identified the primary cause and are working toward
resolving the issue [1].

Services interrupted are limited to those hosted in a single cluster.

Estimated time to resolution is ~1hr.

Services may be intermittently available until resolution is complete.

[1] https://twitter.com/clusteradm/status/925296641036472320

___
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: Bugzilla keeps returning "gateway timeout"

[Kubilay Kocak]

On 10/31/17 7:08 PM, Yuri wrote:
> 
> Somebody needs to look into it.
> 
> 
> Thanks!
> 
> Yuri
> 

Bugmeister (team responsible for the FreeBSD Bugzilla service) is aware
of the issue, which after initial investigation, has been reported
(escalated) to the FreeBSD infrastructure team, Cluster Admin.

Root cause and estimated time to resolution (ETR) are currently unknown.

Updates will be provided via at least this list (freebsd-ports), but
also potentially other appropriate channels as additional information
becomes available.

--
Regards,

Kubilay
Bugmeister




___
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: Files conflicts in ports

[Kubilay Kocak]

On 10/26/17 11:00 PM, Rodrigo Osorio wrote:
> 
> On 10/26/17 13:45, Kubilay Kocak wrote:
>> On 10/26/17 3:58 PM, L.Bartoletti wrote:
>>> Hi Rodrigo,
>>>
>>> Thank you for this precious tool.
>>>
>>> One question, seeing one of my ports which have conflicts
>>> (devel/py-gtfslib
>>> http://pkgtool.osorio.me/conflicts/lbartole...@tuxfamily.org.html). Is
>>> it or not good to install test files?
>>
>> They're all effectively upstream bugs: installing modules into shared
>> locations. 'tests' is a common enough module name that its one of the
>> most easily observed in practice.
>>
>> There's nothing intrinsically wrong with tests being installed, but they
>> should be under/within their package module directories.
>>
>> Most projects exclude them (from installation) with something like:
>>
>> packages = find_packages(exclude=[...]),
>>
>> Though doing the above for a project with this packaging 'bug' is not
>> really the correct solution. Maybe for a short term
>> files/patch-setup.py, but report it upstream
>>
>>> Regards.
>>>
>>> Loïc
>>>
>>> On 10.10.2017 20:52, Rodrigo Osorio wrote:
>>>> Dear port maintainers,
>>>>
>>>> It appears that a number of ports install files with the same names at
>>>> the same locations,
>>>> causing file conflicts and unexpected behaviors for users.
>>>>
>>>> To help solving this issue I ran a tool to list per maintainer the
>>>> conflicting ports with
>>>> the list of impacted files ; the list is updated every day at 4am UTC.
>>>>
>>>> http://pkgtool.osorio.me/conflicts/
>>>>
>>>> I believe most of the conflicts are trivial and can be solved with a
>>>> proper declaration in the CONFLICTS variable.
>>>> So take a look at it and don't hesitate to come back to me if you have
>>>> questions.
>>>>
>>>> best regards,
>>>>
>>>> - rodrigo
>>>>
> I agree with Kubilay, If tests aren't relevant for production use the
> can be skipped.
> The point here is many (if not all) py- packages install the same test
> files and this is wrong.
> 
> - rodrigo

Just to be explicit, in describing them as upstream bugs, I didn't also
mean they're *not* port bugs.

The above ports, and any port in fact, that currently install
conflicting files, must either:

- Add CONFLICTS[_*] with all of their conflicting ports, OR
- Not install them

This is separate from the issue of
value-of-installed-python-tests-for-*package*-users (*ports* users can
run them via the sdist in WRKSRC), and separate from the method of
resolving the conflict (removal, rename, upstream bug fix, patch, etc)

./koobs

___
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: Files conflicts in ports

[Kubilay Kocak]

On 10/26/17 3:58 PM, L.Bartoletti wrote:
> Hi Rodrigo,
> 
> Thank you for this precious tool.
> 
> One question, seeing one of my ports which have conflicts
> (devel/py-gtfslib
> http://pkgtool.osorio.me/conflicts/lbartole...@tuxfamily.org.html). Is
> it or not good to install test files?


They're all effectively upstream bugs: installing modules into shared
locations. 'tests' is a common enough module name that its one of the
most easily observed in practice.

There's nothing intrinsically wrong with tests being installed, but they
should be under/within their package module directories.

Most projects exclude them (from installation) with something like:

packages = find_packages(exclude=[...]),

Though doing the above for a project with this packaging 'bug' is not
really the correct solution. Maybe for a short term
files/patch-setup.py, but report it upstream

> Regards.
> 
> Loïc
> 
> On 10.10.2017 20:52, Rodrigo Osorio wrote:
>> Dear port maintainers,
>>
>> It appears that a number of ports install files with the same names at
>> the same locations,
>> causing file conflicts and unexpected behaviors for users.
>>
>> To help solving this issue I ran a tool to list per maintainer the
>> conflicting ports with
>> the list of impacted files ; the list is updated every day at 4am UTC.
>>
>> http://pkgtool.osorio.me/conflicts/
>>
>> I believe most of the conflicts are trivial and can be solved with a
>> proper declaration in the CONFLICTS variable.
>> So take a look at it and don't hesitate to come back to me if you have
>> questions.
>>
>> best regards,
>>
>> - rodrigo
>>
___
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 ports

[Kubilay Kocak]

On 10/18/17 8:29 AM, Jan Beich wrote:
> Guido Falsi  writes:
> 
>> On 10/17/2017 23:11, Guido Falsi wrote:
>>

 Thing is, recompiling with WITH_DEBUG doesn't help (I only get
 memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
 CMAKE_ARGS (the port uses CMake).
>>
>> Sorry, I clearly did not parse your message correctly.
>>
>> Looks strange though, WITH_DEBUG always worked for me... Usually I
>> compile the whole set in poudriere with WITH_DEBUG, to make sure all
>> libraries have symbols too.
> 
> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
> which may hinder stack unwinding, doesn't enable debug symbols for ports
> not respecting CFLAGS, often a nop for non-C/C++ ports, etc.

Could the framework WITH_DEBUG block remove this (and potentially) other
relevant flags from C*FLAGS if present with variable modifiers?

> Without an example it's hard to guess.


___
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: Porters Handbook section 4.4

[Kubilay Kocak]

On 9/26/17 2:53 PM, Russell Haley wrote:
> On Sun, Sep 24, 2017 at 10:02 PM, Kubilay Kocak <ko...@freebsd.org> wrote:
>> On 9/25/17 2:08 PM, Russell Haley wrote:
>>> Hi,
>>>
>>> Section 4.3 of the porters handbook talks about making modifications
>>> to a private copy of a tarball and recording the steps.
>>>
>>> Section 4.4 talks about changing directories into the affected ports
>>> dir and running make makepatch to generate patch files.
>>>
>>> I am unsure how the makepatch target is supposed to find my private
>>> directory. Since I was confused, I created patches, added them to the
>>> port, ran make, then ran make makepatch and the system re-generated
>>> new "makepatch" patches.
>>
>> Quite a number of new users have raised the same question on IRC.
>>
>>> So, my question is thus:
>>>
>>> To me, section 4.4 seems vague about where changes should be made,
>>> which is compounded by the information in section 4.3. Can the
>>> makepatch target ask for and find a private directory, or should the
>>> handbook be clarified to state that the changes should be made to the
>>> 'work' folder? If the later is true, I assume there is some proper
>>> workflow to keep changes from being destroyed while testing?
>>
>> The handbook section needs to be updated to be less ambiguous with
>> regard to where things should be done.
>>
>> I'd be happy to provide a docs committer with verbiage if they can help
>> with formatting/commit.
> Hi,
> 
> If you provide the verbiage, I'll attempt a patch. :)
> 
> Russ
> 
>>> If there is a section in the handbook clarifying this, please just say
>>> so and I will go find it.
>>>
>>> Thanks!
>>> Russ
>>
>> ./koobs

In section:

4.4. Patching

- Add new section (at/numbered 4.4.2)
  - Name: Automatic Patch Generation
- Renumber sections (4.4.2 -> 4.4.3)

Text:

The ports framework provides a {{{makepatch}} target, which when run,
automatically creates correctly named and formatted patch files in the
correct location. The general process is as follows:

% cd 
% make patch

Note: In the general case, {{{make patch}} is used (not just {{{make
extract}}} to extract the DISTFILES), because ports that contain
existing patches need to have the patches applied so that they are also
generated (regenerated) in the last step.

```
% cd work/ (WRKSRC)
```

At this point, make the source changes in WRKSRC:

```
% cp  .orig
% edit 
```

Repeat the above steps for each file at any location within WRKSRC that
needs a patch file created.

Go back to the main port directory:

```
% cd 
```

Finally, run the {{{makepatch}}} target

```
% make makepatch
```

The makepatch target recursively searches WRKSRC for /.orig
pairs within WRKSRC, and creates a patch file in PATCHDIR from each pair
(using diff).

NOTE: Any pre-existing patches in PATCHDIR that are *not* regenerated
during the above process are placed in a backup location in WRKDIR. This
backup location is deleted on {{{make clean}}}. This may occur when not
using {{{make patch}}} to extract the sources, because existing patches
are or were not applied, or if there are existing patch files that make
edits to multiple files in a single patch file, which will now be in
separate patch files after makepatch regeneration. Inspect and review
the patch files in PATCHDIR to ensure they have been created as expected.

== Other ==

- Patch files are stored in PATCHDIR, usually files/, from where they
will be automatically applied
+ Patch files are stored in PATCHDIR, by default `files/` in the port
directory, which are automatically applied in the 'patch' stage
___
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: Porters Handbook section 4.4

[Kubilay Kocak]

On 9/25/17 2:08 PM, Russell Haley wrote:
> Hi,
> 
> Section 4.3 of the porters handbook talks about making modifications
> to a private copy of a tarball and recording the steps.
> 
> Section 4.4 talks about changing directories into the affected ports
> dir and running make makepatch to generate patch files.
> 
> I am unsure how the makepatch target is supposed to find my private
> directory. Since I was confused, I created patches, added them to the
> port, ran make, then ran make makepatch and the system re-generated
> new "makepatch" patches.

Quite a number of new users have raised the same question on IRC.

> So, my question is thus:
> 
> To me, section 4.4 seems vague about where changes should be made,
> which is compounded by the information in section 4.3. Can the
> makepatch target ask for and find a private directory, or should the
> handbook be clarified to state that the changes should be made to the
> 'work' folder? If the later is true, I assume there is some proper
> workflow to keep changes from being destroyed while testing?

The handbook section needs to be updated to be less ambiguous with
regard to where things should be done.

I'd be happy to provide a docs committer with verbiage if they can help
with formatting/commit.

> If there is a section in the handbook clarifying this, please just say
> so and I will go find it.
> 
> Thanks!
> Russ

./koobs
___
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: How to add a configuration file with autoplist ?

[Kubilay Kocak]

On 9/25/17 6:16 AM, Helen Koike wrote:
> Hi,
> 
> According to
> https://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html
> , I need to add a @sample macro in pkg-plist to add a configuration file.
> 
> But I am also using USE_PYTHON= autoplist in my Makefile, so I don't
> have the pkg-plist file.
> 
> Should I remove autoplist and generate the pkg-plist by hand? Or is
> there another way to do this?
> 
> I'll need this to update the version of the package
> sysutils/py-google-compute-engine.
> 
> Thanks
> Helen

Hi Helen,

As far as I'm aware, autoplist, PLIST_* definitions and pkg-plist
entries can be used cumulatively (in combination with each other) to
produce a correct and complete installed files list

./koobs
___
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: compler warnings in ports not supported in gcc 4.2.1 (stable/10)

[Kubilay Kocak]

On 9/24/17 7:42 AM, Julian Elischer wrote:
> Trying to compile the emulators/open-vm-tools-nox11 port
> 
> but I end up dying with:
> 
> libtool: compile:  cc -DPACKAGE_NAME=\"open-vm-tools\"
> -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.1.5\"
> "-DPACKAGE_STRING=\"open-vm-tools 10.1.5\""
> -DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.1.5\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 -DHAVE_DLOPEN=1
> -DNO_PROCPS=1 -DNO_DNET=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_PARAM_H=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE__BOOL=1
> -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1
> -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I.
> -I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include
> -I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include
> -Wno-deprecated-declarations -isystem /usr/local/include
> -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -DNO_ICU -DVMX86_TOOLS -O2 -pipe
> -DPANZURA_DEV -DPZ_FBSD_10 -isystem /usr/local/include
> -fno-strict-aliasing -Wall -Werror -Wno-unused-function
> -Wno-address-of-packed-member -Wno-unknown-warning-option -Wno-unused
> -MT nicinfo_xdr.lo -MD -MP -MF .deps/nicinfo_xdr.Tpo -c nicinfo_xdr.c 
> -fPIC -DPIC -o .libs/nicinfo_xdr.o
> cc1: error: unrecognized command line option
> "-Wno-address-of-packed-member"
> cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
> *** [nicinfo_xdr.lo] Error code 1
> 
> 
> the system in question is compiled with gcc
> 
> 
> is there a supported way of making the port not set those flags on each
> cc1 command?

The port (all ports) should patch out -Werror. Upstream should not
include it (as a default flag) in distribution sources.

In the mean time, one can always:

CFLAGS=-Wno-error (user or port set, += if the latter)

___
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: GNS3 2.0.3

[Kubilay Kocak]

On 8/5/17 10:48 PM, W Howard via freebsd-ports wrote:
> Dear All, I would like to run the latest GNS3-gui in FreeBSD.
> 
> The ports tree only supports 0.8.7 so I am forced to run GNS3 gui in
> a VM and GNS3-server VM in a separate VM and network them together.
> 
> The latest GNS3-gui can be installed via pip3 command but I haven't
> made it past the SIP is missing error messages. I believe it requires
> qt5.
> 
> Would a port of this be possible in the near future? I just got a new
> PC and would love to keep only FreeBSD on it.
> 
> Cheers!

May be related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219641

Please note: Using pip (as root) to install things into the system
Python environment is explicitly unsupported and will cause issues
(conflicts, leftovers, etc).

An alternative is to use the pip --user [1] argument, or pip install
inside a virtualenv that inherits from the system environment to provide
dependencies that are installed there.

[1] See Also: https://github.com/pypa/pip/issues/1668
___
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: PR commit request

[Kubilay Kocak]

On 8/1/17 7:01 PM, Yasuhiro KIMURA wrote:
> Dear committers,
> 
> Would someone please commit following PR with maintainer timeout?
> 
> Bug 219984 - devel/magit: update to 2.10.3
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219984
> 
> 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"
> 

Note: While the original update patch has hit maintainer timeout, the
maintainer'ship change in the subsequent attachment (9 hours ago) is not
maintainer timeout.

Timeouts apply to 'existing' proposed changes. Timeouts cannot apply to
unsubmitted changes, as it does not afford/allow the maintainer the
requisite time to accept/deny it
___
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: StrongSwan CVE-2017-9023 vuln.xml entry correction

[Kubilay Kocak]

On 7/25/17 9:38 PM, Franco Fichtner wrote:
> Hi,
> 
> An OPNsense user writes that the vuln.xml entry for CVE-2017-9023
> has the wrong bound, it is less or equal to 5.5.2, not 5.5.3, see:
> 
> https://www.strongswan.org/blog/2017/05/30/strongswan-vulnerability-(cve-2017-9023).html
> 
> Can somebody correct this please?
> 
> 

This is being tracked in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220874
___
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: Writing a port make deinstall

[Kubilay Kocak]

On 7/12/17 12:38 PM, blubee blubeeme wrote:
> Hello FreeBSD ports team
> 
> I am writing a Makefile to install a port
> 
> I've written this much so far
> 
> PORTNAME=   epson-inkjet-printer-201401w
> PORTVERSION=   201401w
> PORTREVISION=   1
> PORTEPOCH=   0
> CATEGORIES=   print
> MASTER_SITES=
> https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/d95c03482376873661d7a8d4c165b385cd082cf3/:amd64
> \
> 
> https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/0c527f1eef727e350302db951a45d31319ee501b/:i386
> 
> DISTFILES_amd64=
> epson-inkjet-printer-201401w-1.0.0-1lsb3.2.x86_64.rpm:amd64
> DISTFILES_i386=epson-inkjet-printer-201401w-1.0.0-1lsb3.2.i486.rpm:i386
> 
> 
> LICENSE=   GPLv2
> DIST_SUBDIR=   ${PORTNAME}/${PORTVERSION}
> 
> COMMENT=   CUPS filter for Seiko Epson Color Ink Jet Printers
> 
> RESTRICTED=   GNU Lesser General Public License version 2.1. \
>This program links the following object codes  \
>   which are distributed under the conditions of  \
>   SEIKO EPSON CORPORATION SOFTWARE LICENSE AGREEMENT. \
>   *libEpson_201401w.so.1.0.0 \
>   *libEpson_201401w.MT.so.1.0.0
> 
> 
> NO_BUILD=   yes
> NO_WRKSUBDIR=   yes
> PLIST_SUB=   LINUXBASE=${LINUXBASE}
> USES=   linux
> USE_LINUX=   cups-libs jpeg
> 
> do-install:
> (gunzip ${WRKSRC}/opt/${PORTNAME}/ppds/Epson/*)
> (find ${WRKSRC}/opt/${PORTNAME}/ppds/Epson -type f -exec sed -i ""
> 's/\/opt\/epson/\/compat\/linux\/opt\/epson/g' {} \;)
> (cp -r ${WRKSRC}/opt/${PORTNAME} /compat/linux/opt/)
> (ln -s /compat/linux/opt/${PORTNAME}/ppds/Epson
> /usr/local/share/cups/model/)
> 
> #cleanup?
> # rm -r /usr/local/share/cups/model/Epson
> # rm -r /compat/linux/opt/epson-inkjet-printer-201401w/
> # rm -r ${WRKSRC}
> .include 
> 
> 
> I don't know how to make the cleanup work.
> 
> This Makefile passes works for installing the drivers and they work but
> doing
> 
> make deinstall clean
> 
> doesn't remove the files that I placed, the symlinks, etc.
> 
> How do I properly write this Makefile so deinstall works as expected?
> 
> Best,
> Owen

Hi Owen,

deinstall automatically works if and when all files/directories are
correctly referenced in the pkg-plist. Writing a deinstallation
procedure manually is not necessary.

Porters Handbook:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#porting-desc

See Also: PLIST_FILES and other pkg-plist related entries

Testing the port with poudriere and other tools will help you determine
what is not working, in particular which files were installed but not
referenced in the pkg-plist, and vice-versa.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing.html

For more help, there's also the #freebsd-ports IRC channel on freenode

Hope that helps :)

./koobs



___
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: [PATCH] lang/python27 -- Fix namespace collision

[Kubilay Kocak]

On 6/19/17 4:31 AM, Steve Kargl wrote:
> On Sun, Jun 18, 2017 at 11:29:05AM -0700, Steve Kargl wrote:
>> Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle
>> trignometric functions cospi, sinpi, and tanpi.  When libm (aka
>> math.h) grows support for sinpi(x), lang/python27 has a namespace
>> collision.  The attached patch fixes the problem.
>>

Hi Steve,

Is this issue relevant only for particular (and/or future) FreeBSD
versions ('where libm grows supports for x, y') or independent of base
entirely?

Also, could you open an upstream issue regarding this please, as a
long-term target for all local (Python port) patches is that they are
included upstream.

This also ensures we can document all patches with their relevant
upstream issue/commit references for our future selves and others.

./koobs

> Well, that's inconvenient.  Seems attachments are stripped.
> 
> --- Modules/mathmodule.c.orig 2017-06-18 11:09:05.938222000 -0700
> +++ Modules/mathmodule.c  2017-06-18 11:09:56.248307000 -0700
> @@ -71,7 +71,7 @@
>  static const double sqrtpi = 1.772453850905516027298167483341145182798;
>  
>  static double
> -sinpi(double x)
> +my_sinpi(double x)
>  {
>  double y, r;
>  int n;
> @@ -270,7 +270,7 @@
> integer. */
>  if (absx > 200.0) {
>  if (x < 0.0) {
> -return 0.0/sinpi(x);
> +return 0.0/my_sinpi(x);
>  }
>  else {
>  errno = ERANGE;
> @@ -294,7 +294,7 @@
>  }
>  z = z * lanczos_g / y;
>  if (x < 0.0) {
> -r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
> +r = -pi / my_sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
>  r -= z * r;
>  if (absx < 140.0) {
>  r /= pow(y, absx - 0.5);
> @@ -366,7 +366,7 @@
>  (x-0.5)*(log(x+lanczos_g-0.5)-1);
>  }
>  else {
> -r = log(pi) - log(fabs(sinpi(absx))) - log(absx) -
> +r = log(pi) - log(fabs(my_sinpi(absx))) - log(absx) -
>  (log(lanczos_sum(absx)) - lanczos_g +
>   (absx-0.5)*(log(absx+lanczos_g-0.5)-1));
>  }
> 


___
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

[Kubilay Kocak]

On 6/13/17 5:37 PM, Willem Jan Withagen wrote:
> 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

Hi Willem,

If you are offering to maintain these ports, I would recommend
submitting them yourself, but feel free to CC Dimitry (thank you for
helping to create them) and python@freebsdorg so our python team
committers are notified

Also, prior to submitting them, please confirm the ports (and any future
changes) pass QA (portlint, poudriere, et al). For more information and
instructions see:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing.html

___
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: svnup is b0rken!

[Kubilay Kocak]

On 6/13/17 4:03 AM, Maxim Sobolev wrote:
> Hi, latest version of the svnup package is broken on several of my boxes.
> I've tried few public svn mirrors makes no difference.
> 
> -Max
> 
> [sobomax@van01 ~/projects/softswitch]$ svnup ports
> # Revision: 443456
> 
> Command Failure: HTTP/1.1 400 Bad Request
> Date: Mon, 12 Jun 2017 18:01:09 GMT
> Server: Apache
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
> 
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> 
> 

The issue is being tracked here:

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

tldr: Affects SVN over http[s] (WebDAV), due to mirrors no longer
(unknown reason) supporting REPORT command.

No response from cluster admin (who are svn admin) yet.


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