aduino Makefile tunning

[b . gruel]

Hello,

It's not a bug, but need help for my understanding.
I playing with and arduino mega 2560 board since few weeks (my goal is 
to learrning C by practice).


Everything was fine until i want play with external librairies 
explnations.


I bought a 9DoF (Adafruit_FXOS8700 / Adafruit_FXAS21002C) ad try to use 
exmaple file, but stock with the Makefile modification.


I found how to include Adafruit_Sensor by adding :
CINCS = -I$(ARDUINO)/cores/arduino $(LIBINC) \
-I$(ARDUINO)/variants/$(VARIANT) \
-Ilibrairies/Adafruit_Sensor

But i dont understand how to modify my Makefile to handle 
Adafruit_FXAS21002C and compile it. I try differents syntax /things 
without success.


My sketch looks like this :

/home/rhino/code/arduino/projects/sensor
$ ls -lt *
-rwxr-xr-x  1 rhino  rhino  6367 Jun 18 18:24 Makefile
-rw-r--r--  1 rhino  rhino   644 Jun 18 14:24 sensor.ino

librairies:
total 32
drwxr-xr-x  3 rhino  rhino  512 Jun 19 09:49 Adafruit_FXAS21002C
drwxr-xr-x  3 rhino  rhino  512 Jun 18 11:00 Adafruit_FXOS8700
drwxr-xr-x  2 rhino  rhino  512 Jun 18 10:59 Adafruit_Sensor
drwxr-xr-x  5 rhino  rhino  512 Jun 18 10:59 Adafruit_AHRS


Thank's for your help and your advices.

Bruno.

Re: [NEW] productivity/tudu

[Frederic Cambus]

On Mon, Jun 19, 2017 at 12:07:11AM +0200, Frederic Cambus wrote:

> Here is a new port: productivity/tudu

Upstream released a new version a few days ago, so here is an updated
tarball.

Comments? OK?


tudu.tar.gz
Description: application/tar-gz

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Stuart Henderson]

On 2017/06/04 04:40, Bryan Steele wrote:
> "As Shmuel reported in
> ,
> on x86-64 small structures in automatic storage are aligned to 16 bytes.
> This seems to be because of a mix-up between bits and bytes in the i386
> target code.
> 
> * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> 
> It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> and committed by martynas@ to base gcc4 shortly later.
> 
> http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> http://marc.info/?l=openbsd-cvs&m=139895377300712&w=2
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3&r2=1.4&f=h

Does this actually work?

I might be missing something from this, but I haven't been able to
elicit a SIGABRT from Ted's simple test program with any of the
compilers.

Any idea what's going on?

$ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; $i 
-o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done
gcc 12345678901234567890123456789012 0xabad1dea
egcc12345678901234567890123456789012 0xabad1dea
/usr/bin/clang  12345678901234567890123456789012 0xabad1dea
/usr/local/bin/clang12345678901234567890123456789012 0xabad1dea

Re: base/ports libobjc [Re: openvpn-auth-ldap problem]

[Stuart Henderson]

On 2017/06/15 09:10, Sebastian Reitenbach wrote:
> >
> > Make test doesn't work, I guess problem with a $SHELL, however, running 
> > 'gmake test' in the
> > build directory runs 38 tests, 0 failures, 5 errors.
> > The 5 errors are all related to the missing refCount from TRObject.
> >
> > Maybe the tests could be patched, or even just not built at all?
> 
> I decided to patch the tests instead of omitting them, so patch below now
> builds tests without warning and runs the remaining 28 tests without failures.

It doesn't matter if some tests fail. It's more transparent to just
let them fail, than it is to patch to disable them.

> > Someone who uses it, might want to test it?
> > I also have a LDAP server setup here, but no openvpn server around to test,
> > so could take a while to set it up properly.
> >
> > Other comments patches cleanup etc. welcome as well, as this was just
> > quickly hacked together so far ;)

Since it is currently broken and packages are not being built,
I think it would be OK to just commit, then it will be easier for
anyone using it to give feedback.

Re: NEW: x11/xli

[Stuart Henderson]

On 2017/06/16 16:08, Brian Callahan wrote:
> 
> 
> On 06/16/17 09:11, Brian Callahan wrote:
> > 
> > On 6/16/2017 3:36 AM, Stuart Henderson wrote:
> > > This conflicts with xloadimage.
> > Ah! That makes sense. I'll tweak with @conflict markers.
> 
> New tarball attached, now with @conflict marker and improved do-install
> routine.
> Also attached is a diff for x11/xloadimage, marking it as conflicting with
> xli. I forget if you need to bump after adding @conflict so I played it safe
> and bumped.

Yes, it changes the package, so do bump.

> OK?

OK.  Though you might want to add -DHAVE_GUNZIP to CFLAGS so that it can
handle .gz as well as .Z compressed files (it executes the decompressor,
no lib dependency for that).

Re: NEW: fonts/oldschool-pc-fonts-1.0

[Stuart Henderson]

On 2017/06/16 23:18, Jakub Skrzypnik wrote:
> This time I ported (or, more precisely, "repackaged") the fonts from
> Ultimate Oldschool PC Font Pack project. These are actually accurate

The web page for them says "I do not claim any rights to the original
raster fonts on which this work is based", and "They are exact
duplicates of the original pixel fonts", and "The extra characters
were taken from international versions of the original hardware (if
available)".

It seems a bit of a stretch for someone who has converted them to
TTF to claim full copyright on them. Undoubtedly they have done a lot
of work sourcing, converting and designing missing international
characters, but it all feels like a derived work which would still
be subject to the original copyright which presumably would be owned
by companies like IBM and ATI.

None of this prevents them from going to ports with appropriate
PERMIT_* settings...

> But there's an idea to add them lately as "console fonts" when fcambus@
> is done with his pcvt work to remove that ugly Sun-lookalike
> default font. We'll see.

...but I think there's about zero chance of them going in the kernel
as console fonts.

Re: [NEW] productivity/tudu

[Stuart Henderson]

On 2017/06/19 12:42, Frederic Cambus wrote:
> On Mon, Jun 19, 2017 at 12:07:11AM +0200, Frederic Cambus wrote:
> 
> > Here is a new port: productivity/tudu
> 
> Upstream released a new version a few days ago, so here is an updated
> tarball.
> 
> Comments? OK?

Source files just say "version 3 of the License" and no "or later",
so please use "GPLv3 only" in the license marker.

It fails if you have LC_CTYPE=en_US.UTF-8 :

$ tudu
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort trap (core dumped) 

Re: base/ports libobjc [Re: openvpn-auth-ldap problem]

[Marc Espie]

On Fri, Jun 16, 2017 at 08:03:46PM +0100, Stuart Henderson wrote:
> On 2017/06/15 09:10, Sebastian Reitenbach wrote:
> > >
> > > Make test doesn't work, I guess problem with a $SHELL, however, running 
> > > 'gmake test' in the
> > > build directory runs 38 tests, 0 failures, 5 errors.
> > > The 5 errors are all related to the missing refCount from TRObject.
> > >
> > > Maybe the tests could be patched, or even just not built at all?
> > 
> > I decided to patch the tests instead of omitting them, so patch below now
> > builds tests without warning and runs the remaining 28 tests without 
> > failures.
> 
> It doesn't matter if some tests fail. It's more transparent to just
> let them fail, than it is to patch to disable them.
> 
> > > Someone who uses it, might want to test it?
> > > I also have a LDAP server setup here, but no openvpn server around to 
> > > test,
> > > so could take a while to set it up properly.
> > >
> > > Other comments patches cleanup etc. welcome as well, as this was just
> > > quickly hacked together so far ;)
> 
> Since it is currently broken and packages are not being built,
> I think it would be OK to just commit, then it will be easier for
> anyone using it to give feedback.

I concur. Sounds like the most reasonable path.

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Sat, Jun 17, 2017 at 12:58:03PM +0100, Stuart Henderson wrote:
> On 2017/06/04 04:40, Bryan Steele wrote:
> > "As Shmuel reported in
> > ,
> > on x86-64 small structures in automatic storage are aligned to 16 bytes.
> > This seems to be because of a mix-up between bits and bytes in the i386
> > target code.
> > 
> > * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> > of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> > 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> > 
> > It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> > and committed by martynas@ to base gcc4 shortly later.
> > 
> > http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> > http://marc.info/?l=openbsd-cvs&m=139895377300712&w=2
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3&r2=1.4&f=h
> 
> Does this actually work?
> 
> I might be missing something from this, but I haven't been able to
> elicit a SIGABRT from Ted's simple test program with any of the
> compilers.
> 
> Any idea what's going on?
> 
> $ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; $i 
> -o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done
> gcc   12345678901234567890123456789012 0xabad1dea
> egcc  12345678901234567890123456789012 0xabad1dea
> /usr/bin/clang12345678901234567890123456789012 0xabad1dea
> /usr/local/bin/clang  12345678901234567890123456789012 0xabad1dea

It works with the example I gave previously, at least, I can't find
tedu@'s example, but there is always the possibility for alignment
or padding differences preventing it from reproducibly triggering
on every overflow.

http://marc.info/?l=openbsd-ports&m=149667837410983&w=2

$ pkg_info | grep gcc
gcc-4.9.4p5 GNU compiler collection: core C compiler
$ egcc ssp-test.c -o ssp-test-egcc  
$ ./ssp-test-egcc
Abort trap

Of course, there could *always* be more compiler bugs.. ;-)

-Bryan.

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Mon, Jun 19, 2017 at 10:33:26AM -0400, Bryan Steele wrote:
> On Sat, Jun 17, 2017 at 12:58:03PM +0100, Stuart Henderson wrote:
> > On 2017/06/04 04:40, Bryan Steele wrote:
> > > "As Shmuel reported in
> > > ,
> > > on x86-64 small structures in automatic storage are aligned to 16 bytes.
> > > This seems to be because of a mix-up between bits and bytes in the i386
> > > target code.
> > > 
> > > * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> > > of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> > > 
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> > > 
> > > It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> > > and committed by martynas@ to base gcc4 shortly later.
> > > 
> > > http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> > > http://marc.info/?l=openbsd-cvs&m=139895377300712&w=2
> > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3&r2=1.4&f=h
> > 
> > Does this actually work?
> > 
> > I might be missing something from this, but I haven't been able to
> > elicit a SIGABRT from Ted's simple test program with any of the
> > compilers.
> > 
> > Any idea what's going on?
> > 
> > $ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; 
> > $i -o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done
> > gcc 12345678901234567890123456789012 0xabad1dea
> > egcc12345678901234567890123456789012 0xabad1dea
> > /usr/bin/clang  12345678901234567890123456789012 0xabad1dea
> > /usr/local/bin/clang12345678901234567890123456789012 0xabad1dea
> 
> It works with the example I gave previously, at least, I can't find
> tedu@'s example, but there is always the possibility for alignment
> or padding differences preventing it from reproducibly triggering
> on every overflow.
> 
> http://marc.info/?l=openbsd-ports&m=149667837410983&w=2
> 
> $ pkg_info | grep gcc
> gcc-4.9.4p5 GNU compiler collection: core C compiler
> $ egcc ssp-test.c -o ssp-test-egcc  
> $ ./ssp-test-egcc
> Abort trap
> 
> Of course, there could *always* be more compiler bugs.. ;-)
> 
> -Bryan.

Found it
http://undeadly.org/cgi?action=article&sid=20131202075805

A good explanation from otto@ in the comments, as others reported
this before..

"Stack protection only protects the return address and frame pointer.
There's no way it will catch any stack based overflow. Due to alignment
rules on amd64, the buffer will live further in the stack frame, hence
the one byte overflow just falls into the alignment gap.

i386 allows it's stack frame to be packed tight."

http://undeadly.org/cgi?action=article&sid=20131202075805&pid=6

-Bryan.

Re: base/ports libobjc [Re: openvpn-auth-ldap problem]

[Jeremie Courreges-Anglas]

Marc Espie  writes:

> On Fri, Jun 16, 2017 at 08:03:46PM +0100, Stuart Henderson wrote:
>> On 2017/06/15 09:10, Sebastian Reitenbach wrote:
>> > >
>> > > Make test doesn't work, I guess problem with a $SHELL, however, running 
>> > > 'gmake test' in the
>> > > build directory runs 38 tests, 0 failures, 5 errors.
>> > > The 5 errors are all related to the missing refCount from TRObject.
>> > >
>> > > Maybe the tests could be patched, or even just not built at all?
>> > 
>> > I decided to patch the tests instead of omitting them, so patch below now
>> > builds tests without warning and runs the remaining 28 tests without 
>> > failures.
>> 
>> It doesn't matter if some tests fail. It's more transparent to just
>> let them fail, than it is to patch to disable them.
>> 
>> > > Someone who uses it, might want to test it?
>> > > I also have a LDAP server setup here, but no openvpn server around to 
>> > > test,
>> > > so could take a while to set it up properly.
>> > >
>> > > Other comments patches cleanup etc. welcome as well, as this was just
>> > > quickly hacked together so far ;)
>> 
>> Since it is currently broken and packages are not being built,
>> I think it would be OK to just commit, then it will be easier for
>> anyone using it to give feedback.
>
> I concur. Sounds like the most reasonable path.

+1

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: [NEW] productivity/tudu

[Frederic Cambus]

On Mon, Jun 19, 2017 at 11:54:18AM +0100, Stuart Henderson wrote:

> > > Here is a new port: productivity/tudu
> 
> Source files just say "version 3 of the License" and no "or later",
> so please use "GPLv3 only" in the license marker.

Done.

> It fails if you have LC_CTYPE=en_US.UTF-8 :
> 
> $ tudu
> terminate called after throwing an instance of 'std::runtime_error'
>   what():  locale::facet::_S_create_c_locale name not valid
> Abort trap (core dumped) 

Indeed, good catch. I was able to reproduce the issue, this is caused
by the locale("") calls.

Updated tarball attached adding a pre-configure target to disable those
calls.

Re: [NEW] productivity/tudu

[Frederic Cambus]

On Mon, Jun 19, 2017 at 05:35:33PM +0200, Frederic Cambus wrote:

> > $ tudu
> > terminate called after throwing an instance of 'std::runtime_error'
> >   what():  locale::facet::_S_create_c_locale name not valid
> > Abort trap (core dumped) 
> 
> Indeed, good catch. I was able to reproduce the issue, this is caused
> by the locale("") calls.
> 
> Updated tarball attached adding a pre-configure target to disable those
> calls.

And the actual tarball attached, sorry.


tudu.tar.gz
Description: application/tar-gz

[new] py-laspy 1.5.0

[Landry Breuil]

Hi,

here's a port for py-laspy, a python library/toolkit to manipulate LAS
files (point could data), cf https://github.com/laspy/laspy

The python3 FLAVOR requires py-opengl,python3 which i just commited.
Would be imported under geo/, tests working fine, looking for okays.

Landry


laspy-1.5.0.tgz
Description: application/tar-gz

Update: lang/jruby 9.1.8.0 -> 9.1.12.0

[Jeremy Evans]

This updates JRuby to the latest point release. Release announcements
at:

http://jruby.org/2017/05/16/jruby-9-1-9-0.html
http://jruby.org/2017/05/25/jruby-9-1-10-0.html
http://jruby.org/2017/06/14/jruby-9-1-11-0.html
http://jruby.org/2017/06/15/jruby-9-1-12-0.html

Tested on amd64.  Will be updating in a couple days unless I hear
objections.

Thanks,
Jeremy

Index: Makefile
===
RCS file: /cvs/ports/lang/jruby/Makefile,v
retrieving revision 1.63
diff -u -p -r1.63 Makefile
--- Makefile10 Apr 2017 11:46:22 -  1.63
+++ Makefile18 Jun 2017 22:20:56 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = amd64
 
 COMMENT =  pure-Java implementation of the Ruby language
 
-V =9.1.8.0
+V =9.1.12.0
 DISTNAME = jruby-bin-${V}
 PKGNAME =  jruby-${V}
 CATEGORIES =   lang lang/ruby
Index: distinfo
===
RCS file: /cvs/ports/lang/jruby/distinfo,v
retrieving revision 1.41
diff -u -p -r1.41 distinfo
--- distinfo8 Mar 2017 16:32:25 -   1.41
+++ distinfo18 Jun 2017 22:23:03 -
@@ -1,6 +1,6 @@
 SHA256 (jnr-jffi-1.2.2-0-g4c196bb.tar.gz) = 
xK/m48Z/YA+fg4yFJqcRxceFnT0F98y255Ju9eSE7b0=
-SHA256 (jruby-bin-9.1.8.0.tar.gz) = 
IKxQHJmnyzz1Pe1krBuLtuCw9ro0pBuLrMlxXNS7JgE=
+SHA256 (jruby-bin-9.1.12.0.tar.gz) = 
3bI8lfSzzD/BzFe4HLTO7ndklu3kArmm6wYizxXhpZc=
 SHA256 (jruby-launcher-1.1.1-java.gem) = 
0iJ3vtg6aMTK/AIJdpLChL3TSVYqpbp89chB4ywVlOE=
 SIZE (jnr-jffi-1.2.2-0-g4c196bb.tar.gz) = 1759433
-SIZE (jruby-bin-9.1.8.0.tar.gz) = 20521524
+SIZE (jruby-bin-9.1.12.0.tar.gz) = 20919880
 SIZE (jruby-launcher-1.1.1-java.gem) = 56832
Index: pkg/PLIST
===
RCS file: /cvs/ports/lang/jruby/pkg/PLIST,v
retrieving revision 1.37
diff -u -p -r1.37 PLIST
--- pkg/PLIST   8 Mar 2017 16:32:26 -   1.37
+++ pkg/PLIST   18 Jun 2017 22:44:47 -
@@ -45,7 +45,6 @@ jruby/lib/ruby/gems/1.8/specifications/d
 jruby/lib/ruby/gems/1.8/specifications/default/net-telnet-0.1.1.gemspec
 jruby/lib/ruby/gems/1.8/specifications/default/power_assert-0.2.3.gemspec
 jruby/lib/ruby/gems/1.8/specifications/default/psych-2.2.4-java.gemspec
-jruby/lib/ruby/gems/1.8/specifications/default/racc-1.4.14-java.gemspec
 jruby/lib/ruby/gems/1.8/specifications/default/rake-10.4.2.gemspec
 jruby/lib/ruby/gems/1.8/specifications/default/rdoc-4.2.0.gemspec
 jruby/lib/ruby/gems/1.8/specifications/default/test-unit-3.1.1.gemspec
@@ -202,9 +201,14 @@ jruby/lib/ruby/stdlib/getoptlong.rb
 jruby/lib/ruby/stdlib/hoe/
 jruby/lib/ruby/stdlib/hoe/minitest.rb
 jruby/lib/ruby/stdlib/io/
-jruby/lib/ruby/stdlib/io/bsd_console.rb
+jruby/lib/ruby/stdlib/io/console/
 jruby/lib/ruby/stdlib/io/console.rb
-jruby/lib/ruby/stdlib/io/linux_console.rb
+jruby/lib/ruby/stdlib/io/console/bsd_console.rb
+jruby/lib/ruby/stdlib/io/console/common.rb
+jruby/lib/ruby/stdlib/io/console/linux_console.rb
+jruby/lib/ruby/stdlib/io/console/native_console.rb
+jruby/lib/ruby/stdlib/io/console/stty_console.rb
+jruby/lib/ruby/stdlib/io/console/stub_console.rb
 jruby/lib/ruby/stdlib/io/nonblock.rb
 jruby/lib/ruby/stdlib/ipaddr.rb
 jruby/lib/ruby/stdlib/irb/
@@ -538,24 +542,10 @@ jruby/lib/ruby/stdlib/psych/y.rb
 jruby/lib/ruby/stdlib/psych_jars.rb
 jruby/lib/ruby/stdlib/pty.rb
 jruby/lib/ruby/stdlib/racc/
-jruby/lib/ruby/stdlib/racc.rb
-jruby/lib/ruby/stdlib/racc/compat.rb
 jruby/lib/ruby/stdlib/racc/cparse-jruby.jar
-jruby/lib/ruby/stdlib/racc/debugflags.rb
-jruby/lib/ruby/stdlib/racc/exception.rb
-jruby/lib/ruby/stdlib/racc/grammar.rb
-jruby/lib/ruby/stdlib/racc/grammarfileparser.rb
-jruby/lib/ruby/stdlib/racc/info.rb
-jruby/lib/ruby/stdlib/racc/iset.rb
-jruby/lib/ruby/stdlib/racc/logfilegenerator.rb
-jruby/lib/ruby/stdlib/racc/parser-text.rb
 jruby/lib/ruby/stdlib/racc/parser.rb
-jruby/lib/ruby/stdlib/racc/parserfilegenerator.rb
-jruby/lib/ruby/stdlib/racc/pre-setup
-jruby/lib/ruby/stdlib/racc/sourcetext.rb
-jruby/lib/ruby/stdlib/racc/state.rb
-jruby/lib/ruby/stdlib/racc/statetransitiontable.rb
-jruby/lib/ruby/stdlib/racc/static.rb
+jruby/lib/ruby/stdlib/racc/rdoc/
+jruby/lib/ruby/stdlib/racc/rdoc/grammar.en.rdoc
 jruby/lib/ruby/stdlib/rake/
 jruby/lib/ruby/stdlib/rake.rb
 jruby/lib/ruby/stdlib/rake/alt_system.rb
@@ -1096,6 +1086,7 @@ jruby/lib/ruby/stdlib/rubygems/security/
 jruby/lib/ruby/stdlib/rubygems/security/policy.rb
 jruby/lib/ruby/stdlib/rubygems/security/signer.rb
 jruby/lib/ruby/stdlib/rubygems/security/trust_dir.rb
+jruby/lib/ruby/stdlib/rubygems/security_option.rb
 jruby/lib/ruby/stdlib/rubygems/server.rb
 jruby/lib/ruby/stdlib/rubygems/source/
 jruby/lib/ruby/stdlib/rubygems/source.rb

add py3 flavor for www/py-urllib3

[Alexandr Shadchin]

Hi,

Add py3 flavor, need for update py-requests. Also enable test.

OK ?

-- 
Alexandr Shadchin

Index: Makefile
===
RCS file: /cvs/ports/www/py-urllib3/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile9 May 2017 06:12:09 -   1.11
+++ Makefile19 Jun 2017 20:14:40 -
@@ -5,6 +5,7 @@ COMMENT=HTTP library for Python
 MODPY_EGG_VERSION=1.21.1
 DISTNAME=  urllib3-${MODPY_EGG_VERSION}
 PKGNAME=   py-urllib3-${MODPY_EGG_VERSION}
+REVISION=  0
 
 CATEGORIES=www
 
@@ -19,5 +20,16 @@ MODPY_PI =   Yes
 MODULES=   lang/python
 
 MODPY_SETUPTOOLS= Yes
+
+TEST_DEPENDS = devel/py-nose${MODPY_FLAVOR} \
+   devel/py-mock${MODPY_FLAVOR} \
+   sysutils/py-psutil${MODPY_FLAVOR} \
+   www/py-tornado${MODPY_FLAVOR}
+
+FLAVORS =  python3
+FLAVOR ?=
+
+do-test:
+   cd ${WRKSRC} && ${LOCALBASE}/bin/nosetests${MODPY_BIN_SUFFIX} test
 
 .include 
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/py-urllib3/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   9 May 2017 06:12:09 -   1.6
+++ pkg/PLIST   19 Jun 2017 20:14:40 -
@@ -7,80 +7,87 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/urllib3-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
 
lib/python${MODPY_VERSION}/site-packages/urllib3-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/urllib3/__init__.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}_collections.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}connection.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}connectionpool.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}fields.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}filepost.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}poolmanager.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}request.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/${MODPY_PYCACHE}response.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/urllib3/_collections.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/_collections.pyc
 lib/python${MODPY_VERSION}/site-packages/urllib3/connection.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/connection.pyc
 lib/python${MODPY_VERSION}/site-packages/urllib3/connectionpool.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/connectionpool.pyc
 lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/
 lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/__init__.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}appengine.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}ntlmpool.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}pyopenssl.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}securetransport.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/${MODPY_PYCACHE}socks.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/
 
lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/__init__.py
-lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/${MODPY_PYCACHE}bindings.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_securetransport/${MODPY_PYCACHE}low_level.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/urllib3/contrib/_

UPDATE: net/py-idna 2.5

[Alexandr Shadchin]

Hi,

This diff updates py-idna to the latest release.
Tested on amd64.

Comments ? OK ?

-- 
Alexandr Shadchin

Index: Makefile
===
RCS file: /cvs/ports/net/py-idna/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile2 Mar 2017 14:34:10 -   1.7
+++ Makefile19 Jun 2017 20:33:43 -
@@ -2,7 +2,7 @@
 
 COMMENT =  Python library to support the IDNA protocol
 
-MODPY_EGG_VERSION =2.4
+MODPY_EGG_VERSION =2.5
 DISTNAME = idna-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 CATEGORIES =   net
Index: distinfo
===
RCS file: /cvs/ports/net/py-idna/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo2 Mar 2017 14:34:10 -   1.5
+++ distinfo19 Jun 2017 20:33:43 -
@@ -1,2 +1,2 @@
-SHA256 (idna-2.4.tar.gz) = KgcWX2KI9Lkgqoq0NXweWQc8XWLgSKQAUQmCdp4Dm9k=
-SIZE (idna-2.4.tar.gz) = 130182
+SHA256 (idna-2.5.tar.gz) = PLXOCARsTjpWD8AvE40Kxj4A+M5ZAaVrMuyLeZQIKqs=
+SIZE (idna-2.5.tar.gz) = 130211

Re: UPDATE: devel/py-futures 3.0.5 => 3.1.1

[Alexandr Shadchin]

On Fri, Jun 09, 2017 at 12:11:49PM -0400, Brian Callahan wrote:
> Hi ports --
> 
> Attached is a diff for devel/py-futures, bringing it to its latest version.
> Notably, the license changed from BSD to PSF.
> 
> Take maintainer.
> 
> ~Brian
> 

ok shadchin@

> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/py-futures/Makefile,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 Makefile
> --- Makefile  27 Aug 2016 16:09:36 -  1.7
> +++ Makefile  9 Jun 2017 16:13:28 -
> @@ -2,12 +2,13 @@
>  
>  COMMENT= futures implementation for Python
>  
> -MODPY_EGG_VERSION=   3.0.5
> +MODPY_EGG_VERSION=   3.1.1
>  DISTNAME=futures-${MODPY_EGG_VERSION}
>  PKGNAME= py-${DISTNAME}
>  CATEGORIES=  devel
> +MAINTAINER=  Brian Callahan 
>  
> -# BSD
> +# Python Software Foundation license
>  PERMIT_PACKAGE_CDROM=Yes
>  
>  MODULES= lang/python
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/py-futures/distinfo,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 distinfo
> --- distinfo  27 Aug 2016 16:09:36 -  1.4
> +++ distinfo  9 Jun 2017 16:13:28 -
> @@ -1,2 +1,2 @@
> -SHA256 (futures-3.0.5.tar.gz) = BUJSUUXVr8mEyI+RSgyFx3Un9llGYX7bUnT3JAb5gd8=
> -SIZE (futures-3.0.5.tar.gz) = 25153
> +SHA256 (futures-3.1.1.tar.gz) = Uey0Xwrdg8gGxo5LBhBvkNsmBYWyXvKr/NoL2VwBMv0=
> +SIZE (futures-3.1.1.tar.gz) = 26471
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/py-futures/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 PLIST
> --- pkg/PLIST 29 Dec 2015 15:50:58 -  1.2
> +++ pkg/PLIST 9 Jun 2017 16:13:28 -
> @@ -16,5 +16,4 @@ lib/python${MODPY_VERSION}/site-packages
>  
> lib/python${MODPY_VERSION}/site-packages/futures-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
>  
> lib/python${MODPY_VERSION}/site-packages/futures-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
>  
> lib/python${MODPY_VERSION}/site-packages/futures-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
> -lib/python${MODPY_VERSION}/site-packages/futures-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/pbr.json
>  
> lib/python${MODPY_VERSION}/site-packages/futures-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt


-- 
Alexandr Shadchin

Re: UPDATE: net/py-idna 2.5

[Brian Callahan]

On 6/19/2017 4:34 PM, Alexandr Shadchin wrote:
> Hi,
>
> This diff updates py-idna to the latest release.
> Tested on amd64.
>
> Comments ? OK ?
>

ok bcallah@

Re: Maxima can't start maxima -- works now!

[Austin Hook]

Using 6.0 on an AMD64  wxMaxima seems to run for me.  

I installed the ports directory, and commented out the "Broken" tag in 
the makefile.  Did a make, and it ran for quite a while -- so many parts 
to it.  Encountered one problem the first time:  ran out of inodes...

(WTF!) Couldn't imagine how it is possible to run out of them on a 
standard install of 6.0 and only a few dozen ports installed.  Anyway 
without debugging that curiosity, I just moved the ports directory out of 
/usr and over to an unused, large and empty partition I had left over at 
the end of my hard drive. Put a symlink in /usr.  Then it seemed to take 
half of forever, but the make went to completion.  wxMaxima works fine.  
Or at least now I can integrate the equations to simulate getting my 
satellite into orbit  :-)

I presume upstream fixed it.  So ports folk, give it a try in the latest 
6.1 or current.  

I can hardly believe it has been marked broken since back in 2014 and no 
one needed it that badly.  Well I guess xmaxima, or even just maxima for 
command line addicts is good enough.

Austin

On Mon, 21 Jul 2014, Edd Barrett wrote:

> On Sun, Jul 20, 2014 at 07:03:38PM +0100, Edd Barrett wrote:
> > Looks like wxMaxima uses a wx routine to start a server but encounters
> > an exception:
> 
> I raised a bug upstream, but have not heard back...
> 
> https://github.com/andrejv/wxmaxima/issues/339
> 
> -- 
> Best Regards
> Edd Barrett
> 
> http://www.theunixzoo.co.uk
>