Re: Search for a MacPorts Mascot: looking for talented artists

[Dave Horsfall]

On Wed, 21 Feb 2018, Arno Hautala wrote:


https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html


I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on 
shelves in time for the holidays and the hit plush toy craze of the 
season!


Please take careful note of the copyright notice for that image.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Re: Search for a MacPorts Mascot: looking for talented artists

[Arno Hautala]

On Wed, Feb 21, 2018 at 3:50 PM, David Strubbe  wrote:
> I suggest a port crane (to fit with our name), e.g.
> https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html

I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on
shelves in time for the holidays and the hit plush toy craze of the
season!

Re: Search for a MacPorts Mascot: looking for talented artists

[Jan Stary]

> > >> During the GSOC meeting in Mountain View we had some fruitful evening
> > discussions where we were heavily criticised for not having our own happy
> > fluffy animal mascot (like a flying platypus?) which we could take to every
> > meeting or hacking event where we show up.

http://assets.rebelcircus.com/blog/wp-content/uploads/2014/12/nakedmolerat.jpg

Re: distfile downloads failing on https

[Clemens Lang]

Hi Jan,

On Wed, Feb 21, 2018 at 08:14:13PM +0100, Jan Stary wrote:
> If I am reading
> https://guide.macports.org/chunked/reference.phases.html right, there
> is are no "fetch dependencies". Would it make sense to introduce fetch
> dependencies just like we have build dependencies and run
> dependencies, so that the affected ports could specify e.g. curl, and
> MP vuld use _that_ for those ports?

That's basically https://trac.macports.org/ticket/51516#comment:21. See
https://trac.macports.org/ticket/51516#comment:22 for a partial response
to that.

MacPorts does not use the curl command to download files, it uses the
libcurl library. We cannot simply switch to a different libcurl library,
and reimplementing the code in pextlib1.0/curl.c to use the curl command
line is a huge effort for little gain.

-- 
Clemens

Re: Search for a MacPorts Mascot: looking for talented artists

[David Strubbe]

I suggest a port crane (to fit with our name), e.g.
https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html

David

On Wed, Feb 21, 2018 at 12:38 PM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

>
> On 2018-02-21, at 12:36 PM, Dave Horsfall wrote:
>
> > On Wed, 21 Feb 2018, Mojca Miklavec wrote:
> >
> >> During the GSOC meeting in Mountain View we had some fruitful evening
> discussions where we were heavily criticised for not having our own happy
> fluffy animal mascot (like a flying platypus?) which we could take to every
> meeting or hacking event where we show up.
> >
> > A fluffy animal mascot is required in order to be taken seriously?
> Leave that sort of nonsense to the Penguins...
> >
>
>
> All things being equal, groups that are more fun to be in and have a
> rather lighthearted approach to things are always more popular.
>
> Ken
>
>

Re: distfile downloads failing on https

[Jan Stary]

On Feb 21 08:11:26, ken.cunningham.web...@gmail.com wrote:
> I should have been more descriptive about the /opt/bootstrap part of the post 
> below. 
> 
> Like  you, I didn't like the circular dependency. If you "sudo port uninstall 
> active", you're hooped. So here's what I actually do on all systems 10.4 to 
> 10.7
> 
> using Macports from this page  and more 
> specifically from here 
> 
>  and with reference to the instructions for 
> 
> 
> 1. install a copy of macports from source code into /opt/bootstrap
> 
> cd MacPorts-2.4.2
> ./configure --prefix=/opt/bootstrap 
> --with-applications-dir=/opt/bootstrap/applications
> make
> sudo make install
> cd ..
> rm -rf MacPorts-2.4.2
> 
> then as per 
> 
> bbedit /opt/bootstrap/etc/macports/macports.conf
> and add 
> startupitem_install no
> 
> 2. once that is finished, I do this
> 
> sudo /opt/bootstrap/bin/port sync
> sudo /opt/bootstrap/bin/port -v -N install curl
> 
> You should now have an independent free-standing macports installation with 
> curl

I like the multiple installation and the extra setup even less.

> 3. now using a fresh copy of the Macports source
> 
> cd MacPorts-2.4.2
> ./configure --with-curlprefix=/opt/bootstrap
> make
> sudo make install
> 
> and then adjust your PATH to point to /opt/local/bin as usual for MacPorts.
> You are done. No more circular dependency.

Yes. One installation of MP depends on another installation.



If I am reading https://guide.macports.org/chunked/reference.phases.html
right, there is are no "fetch dependencies". Would it make sense
to introduce fetch dependencies just like we have build dependencies
and run dependencies, so that the affected ports could specify e.g. curl,
and MP vuld use _that_ for those ports?

> NOTE:
> when Macports updates to a new version,
> it does not remember the curlprefix,
> and so it installs against /usr/lib/libcurl again.

I install and upgrade manually from git.

> Sorry if this is long and seems complicated --
> I was trying to be as complete as possible.

No problem - thank you for the insight.

Jan

Re: Search for a MacPorts Mascot: looking for talented artists

[Ken Cunningham]

On 2018-02-21, at 12:36 PM, Dave Horsfall wrote:

> On Wed, 21 Feb 2018, Mojca Miklavec wrote:
> 
>> During the GSOC meeting in Mountain View we had some fruitful evening 
>> discussions where we were heavily criticised for not having our own happy 
>> fluffy animal mascot (like a flying platypus?) which we could take to every 
>> meeting or hacking event where we show up.
> 
> A fluffy animal mascot is required in order to be taken seriously?  Leave 
> that sort of nonsense to the Penguins...
> 


All things being equal, groups that are more fun to be in and have a rather 
lighthearted approach to things are always more popular.

Ken

Re: Search for a MacPorts Mascot: looking for talented artists

[Dave Horsfall]

On Wed, 21 Feb 2018, Mojca Miklavec wrote:

During the GSOC meeting in Mountain View we had some fruitful evening 
discussions where we were heavily criticised for not having our own 
happy fluffy animal mascot (like a flying platypus?) which we could take 
to every meeting or hacking event where we show up.


A fluffy animal mascot is required in order to be taken seriously?  Leave 
that sort of nonsense to the Penguins...


--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Re: Search for a MacPorts Mascot: looking for talented artists

[db]

On 21 Feb 2018, at 17:32, Mojca Miklavec  wrote:
> Something in the spirit of ...
>http://en.wikifur.com/w/images/4/46/Hexley_fork_450.png

I like that MacPorts lacks a mascot identity. But if you really need, want one, 
then I probably choose Darwin's Hexley. Another that I'd consider, and since 
there're already 20K+ ports, is some sort of behemoth, e.g.

http://monster.wikia.com/wiki/Behemoth
https://alexgilble.deviantart.com/art/Behemoth-The-Land-Monster-413063725

Re: lowdown not helped by snowleopardfixes

[Ken Cunningham]

On 2018-02-21, at 11:31 AM, Jan Stary wrote:

> Hm, doesn't the PortGroup add its stuff to LDFLAGS and LDADD
> (and whatever else) _after_ the port has done its configure?

not usually. eg. this portgroup adds:

configure.ldflags-append -lsnowleopardfixes


> I am probably missing something fundamental about how the PortGroups
> actually work.

They can be thought of as #include files for Portfile tcl code, exactly as if 
the code had been typed into the Portfile.

> Is there a place on the documentation where I shoud
> start reading? I don't think I saw it in the Guide.

They change rather frequently, and so the best documentation is in the actual 
portgroup tcl file.

K

Re: lowdown not helped by snowleopardfixes

[Jan Stary]

On Feb 21 08:46:21, ken.cunningham.web...@gmail.com wrote:
> lowdown uses it's own completely unique methods for configure

It's a hand written ./configure shell script, as opposed to the auto* hell.
https://github.com/kristapsdz/oconfigure
Some other portable projects do the same.

> and library function replacements, I see.

Yes. It comes wth tests.c and compats.c to detect an possibly provide
e.g. strtonum(3) and strlcat(3) etc on systems that don't have them.

> It clears out the LDFLAGS during the build,
> ergo the -lsnowleopardfixes not being honoured


Hm, doesn't the PortGroup add its stuff to LDFLAGS and LDADD
(and whatever else) _after_ the port has done its configure?

> it also replaces some functions on it's own, so there might be collisions if 
> -lsnowleopardfixes was patched into the build script link flags.

Yes.

> For a port like this, the best I could offer would be to patch in the missing 
> strndup definition into compats.c

I asked upstream to do that.
These guys go out of their way to be very portable.

> the author probably wouldn't mind adding strndup to the other functions he 
> tests for -- he already checks for lots of them.

Exactly.

> a definition for strndup.c is here 
>  but 
> requires strnlen as well to function.

They will most probably use
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strndup.c

> Sorry this is not one of the "drop in" fixes that the PG usually offers...

I am probably missing something fundamental about how the PortGroups
actually work. Is there a place on the documentation where I shoud
start reading? I don't think I saw it in the Guide.

Thanks,

Jan

Re: lowdown not helped by snowleopardfixes

[Ken Cunningham]

lowdown uses it's own completely unique methods for configure and library 
function replacements, I see.

It clears out the LDFLAGS during the build, ergo the -lsnowleopardfixes not 
being honoured

it also replaces some functions on it's own, so there might be collisions if 
-lsnowleopardfixes was patched into the build script link flags.

For a port like this, the best I could offer would be to patch in the missing 
strndup definition into compats.c

the author probably wouldn't mind adding strndup to the other functions he 
tests for -- he already checks for lots of them.

a definition for strndup.c is here 
 but requires 
strnlen as well to function.

Sorry this is not one of the "drop in" fixes that the PG usually offers...

Ken






On 2018-02-21, at 5:40 AM, Jan Stary wrote:

> Hi Ken,
> 
> when I created the textproc/lowdown port not long ago
> https://github.com/macports/macports-ports/pull/1241
> you kindly advised me to use
> 
>   PortGroup snowleopard_fixes 1.0
> 
> so that older MacOS sysem without e.g. strndup(3)
> can still compile lowdown.
> 
> However, it seems that the compilation still fails,
> at least on my 10.5.8 and 10.6.8. The snowleopardfixes port
> compiles and installs just fine, providing
> 
> $ nm /opt/local/lib/libsnowleopardfixes.dylib
> 1d46 s  stub helpers
> U ___error
>  t __mh_dylib_header
> U _getc
> 1ad9 T _getdelim
> 1ac7 T _getline
> U _malloc
> U _memchr
> U _memcmp
> U _memcpy
> 1c1c T _memmem
> U _realloc
> 1bca T _strndup
> 1a8c T _strnlen
> 1cbc T _wcsdup
> U _wcslen
> U _wmemcpy
> U dyld_stub_binder
> 
> 
> But when building lowdown itself (full log below)
> it fails on a missing strndup(3). The failing line is
> 
>   /usr/bin/gcc-4.2 -o lowdown main.o liblowdown.a -lm
>   Undefined symbols:
>   "_strndup", referenced from:
>   _xstrndup in liblowdown.a(xmalloc.o)
>   ld: symbol(s) not found
>   collect2: ld returned 1 exit status
> 
> The installed snowleopardfixes library doesn't seem
> to even enter into it at all. Am I missing something
> obvious about how the snowleopard_fixes portgroup
> is supposed to work?
> 
>   Jan
> 
> 
> 
> hans@mac:~$ sudo port -vs install lowdown
> --->  Computing dependencies for lowdown.
> --->  Fetching distfiles for lowdown
> --->  Verifying checksums for lowdown
> --->  Checksumming lowdown-0.3.1.tar.gz
> --->  Extracting lowdown
> --->  Extracting lowdown-0.3.1.tar.gz
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work"
>  && /usr/bin/gzip -dc 
> '/opt/local/var/macports/distfiles/lowdown/lowdown-0.3.1.tar.gz' | 
> /usr/bin/gnutar --no-same-owner -xf - 
> --->  Configuring lowdown
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
>  && ./configure  PREFIX=/opt/local 
> config.log: writing...
> configure.local: no (fully automatic configuration)
> arc4random: yes
> capsicum: no
> err: yes
> explicit_bzero: no
> getprogname: yes
> INFTIM: no
> md5: no
> memmem: no
> memrchr: no
> memset_s: no
> PATH_MAX: yes
> pledge: no
> program_invocation_short_name: no
> reallocarray: no
> recallocarray: no
> sandbox_init: no
> seccomp-filter: no
> SOCK_NONBLOCK: no
> strlcat: yes
> strlcpy: yes
> strtonum: no
> systrace: no
> zlib: yes
> __progname: yes
> config.h: written
> Makefile.configure: written
> --->  Building lowdown
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
>  && /usr/bin/make -w all 
> make: Entering directory 
> `/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1'
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o autolink.o autolink.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o buffer.o buffer.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o diff.o diff.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o document.o document.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o html.o html.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes 

Search for a MacPorts Mascot: looking for talented artists

[Mojca Miklavec]

Hi,

During the GSOC meeting in Mountain View we had some fruitful evening
discussions where we were heavily criticised for not having our own
happy fluffy animal mascot (like a flying platypus?) which we could
take to every meeting or hacking event where we show up.

Something in the spirit of ...
http://en.wikifur.com/w/images/4/46/Hexley_fork_450.png
http://www.libregeek.org/wp-content/uploads/2013/12/beastie.png

(This was brought up by a person wearing a soft traffic cone all the
time during the meeting, making quite a memorable impression on
probably each and every participant.)

Do we have any artists around to draw one? Any thoughts?
(We could probably come up with some small awards.)

Mojca

Re: distfile downloads failing on https

[Ken Cunningham]

I should have been more descriptive about the /opt/bootstrap part of the post 
below. 

Like  you, I didn't like the circular dependency. If you "sudo port uninstall 
active", you're hooped. So here's what I actually do on all systems 10.4 to 10.7

using Macports from this page  and more 
specifically from here 

 and with reference to the instructions for 


1. install a copy of macports from source code into /opt/bootstrap

cd MacPorts-2.4.2
./configure --prefix=/opt/bootstrap 
--with-applications-dir=/opt/bootstrap/applications
make
sudo make install
cd ..
rm -rf MacPorts-2.4.2

then as per 

bbedit /opt/bootstrap/etc/macports/macports.conf
and add 
startupitem_install no

2. once that is finished, I do this

sudo /opt/bootstrap/bin/port sync
sudo /opt/bootstrap/bin/port -v -N install curl

You should now have an independent free-standing macports installation with curl

3. now using a fresh copy of the Macports source

cd MacPorts-2.4.2
./configure --with-curlprefix=/opt/bootstrap
make
sudo make install

and then adjust your PATH to point to /opt/local/bin as usual for MacPorts.

You are done. No more circular dependency. You can use MacPorts as you wish to.

You can pretty much forget about /opt/bootstrap after that if you want to. The 
curl is 10 years newer, and so will likely last as long as you need. 


You can update /opt/bootstrap if you want to. You just have to keep the PATHs 
straight, which requires a clear head.

I always disable the PATH pointing to /opt/local/bin before I do this, and then 
either add the path to /opt/bootstrap/bin, or just:

sudo /opt/bootstrap/bin/port -v sync
sudo /opt/bootstrap/bin/port -v -N upgrade outdated



NOTE:

when Macports updates to a new version, it does not remember the curlprefix, 
and so it installs against /usr/lib/libcurl again.

For this reason, I always 

sudo port -v sync

to update macpports ports.

I manually install updates to macports using the souce code and the 
instructions in #3 above.

Sorry if this is long and seems complicated -- I was trying to be as complete 
as possible.

Ken






On 2018-02-21, at 4:18 AM, Jan Stary wrote:

> On Feb 21 12:43:28, h...@stare.cz wrote:
>> A more general proposed solution was to bunlde a newer curl with MP,
>> in partcular one built against a newer SSL/TLS library:
>> https://trac.macports.org/ticket/51516
> 
> It was also suggested there to recompile MP
> using its own already installed curl port.
> 
> Indeed,
> ./configure --with-curlprefix=/opt/local/
> results in MacPorts that uses its own /opt/local/bin/curl
> to download distfiles, and my immediate problem disappears.
> 
> But the circular dependency on itself doesn't seem right.
> 
> Should the curl port be a fetch dependency (if there is such a thing)
> for the affected ports, and should MP use the port's curl(1)
> to download their distfiles?
> 
>   Jan
> 

Re: lowdown not helped by snowleopardfixes

[Ken Cunningham]

I'll take a look. The PG adds -lsnowleopardfixes to the ldflags, but thats not 
showing up in your build for some reason. For some ports, you have to add the 
flag a different way, via a patch or similar...

K

> On Feb 21, 2018, at 05:40, Jan Stary  wrote:
> 
> Hi Ken,
> 
> when I created the textproc/lowdown port not long ago
> https://github.com/macports/macports-ports/pull/1241
> you kindly advised me to use
> 
>PortGroup snowleopard_fixes 1.0
> 
> so that older MacOS sysem without e.g. strndup(3)
> can still compile lowdown.
> 
> However, it seems that the compilation still fails,
> at least on my 10.5.8 and 10.6.8. The snowleopardfixes port
> compiles and installs just fine, providing
> 
> $ nm /opt/local/lib/libsnowleopardfixes.dylib
> 1d46 s  stub helpers
> U ___error
>  t __mh_dylib_header
> U _getc
> 1ad9 T _getdelim
> 1ac7 T _getline
> U _malloc
> U _memchr
> U _memcmp
> U _memcpy
> 1c1c T _memmem
> U _realloc
> 1bca T _strndup
> 1a8c T _strnlen
> 1cbc T _wcsdup
> U _wcslen
> U _wmemcpy
> U dyld_stub_binder
> 
> 
> But when building lowdown itself (full log below)
> it fails on a missing strndup(3). The failing line is
> 
>/usr/bin/gcc-4.2 -o lowdown main.o liblowdown.a -lm
>Undefined symbols:
>"_strndup", referenced from:
>_xstrndup in liblowdown.a(xmalloc.o)
>ld: symbol(s) not found
>collect2: ld returned 1 exit status
> 
> The installed snowleopardfixes library doesn't seem
> to even enter into it at all. Am I missing something
> obvious about how the snowleopard_fixes portgroup
> is supposed to work?
> 
>Jan
> 
> 
> 
> hans@mac:~$ sudo port -vs install lowdown
> --->  Computing dependencies for lowdown.
> --->  Fetching distfiles for lowdown
> --->  Verifying checksums for lowdown
> --->  Checksumming lowdown-0.3.1.tar.gz
> --->  Extracting lowdown
> --->  Extracting lowdown-0.3.1.tar.gz
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work"
>  && /usr/bin/gzip -dc 
> '/opt/local/var/macports/distfiles/lowdown/lowdown-0.3.1.tar.gz' | 
> /usr/bin/gnutar --no-same-owner -xf - 
> --->  Configuring lowdown
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
>  && ./configure  PREFIX=/opt/local 
> config.log: writing...
> configure.local: no (fully automatic configuration)
> arc4random: yes
> capsicum: no
> err: yes
> explicit_bzero: no
> getprogname: yes
> INFTIM: no
> md5: no
> memmem: no
> memrchr: no
> memset_s: no
> PATH_MAX: yes
> pledge: no
> program_invocation_short_name: no
> reallocarray: no
> recallocarray: no
> sandbox_init: no
> seccomp-filter: no
> SOCK_NONBLOCK: no
> strlcat: yes
> strlcpy: yes
> strtonum: no
> systrace: no
> zlib: yes
> __progname: yes
> config.h: written
> Makefile.configure: written
> --->  Building lowdown
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
>  && /usr/bin/make -w all 
> make: Entering directory 
> `/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1'
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o autolink.o autolink.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o buffer.o buffer.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o diff.o diff.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o document.o document.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o html.o html.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o html_escape.o html_escape.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o html_smartypants.o html_smartypants.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o library.o library.c
> /usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
> -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings 
> -Wno-unused-parameter   -c -o log.o log.c

Re: distfile downloads failing on https

[Ken Cunningham]

see https://trac.macports.org/ticket/51516#comment:19

for a workaround that works quite well on Tiger up until this gets fixed

K

> On Feb 21, 2018, at 04:26, Jan Stary  wrote:
> 
>> On Feb 21 13:18:47, h...@stare.cz wrote:
>>> On Feb 21 12:43:28, h...@stare.cz wrote:
>>> A more general proposed solution was to bunlde a newer curl with MP,
>>> in partcular one built against a newer SSL/TLS library:
>>> https://trac.macports.org/ticket/51516
>> 
>> It was also suggested there to recompile MP
>> using its own already installed curl port.
>> 
>> Indeed,
>> ./configure --with-curlprefix=/opt/local/
>> results in MacPorts that uses its own /opt/local/bin/curl
>> to download distfiles, and my immediate problem disappears.
> 
> The problem is not curl itself of course,
> but the SSL library it is linked against,
> as already stated in the ticket. On my system:
> 
> $ otool -L /usr/bin/curl
> /usr/bin/curl:
> /usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
> /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 
> 0.9.8)
> /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 
> 0.9.8)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 125.2.11)
> 
> $ otool -L /opt/local/bin/curl
> /opt/local/bin/curl:
> /opt/local/lib/libcurl.4.dylib (compatibility version 9.0.0, current version 
> 9.0.0)
> /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
> version 1.0.0)
> /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current 
> version 1.0.0)
> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 
> 1.2.11)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 125.2.11)
> 
> $ port provides /opt/local/lib/libssl.1.0.0.dylib
> /opt/local/lib/libssl.1.0.0.dylib is provided by: openssl
> 
>Jan
> 

lowdown not helped by snowleopardfixes

[Jan Stary]

Hi Ken,

when I created the textproc/lowdown port not long ago
https://github.com/macports/macports-ports/pull/1241
you kindly advised me to use

PortGroup snowleopard_fixes 1.0

so that older MacOS sysem without e.g. strndup(3)
can still compile lowdown.

However, it seems that the compilation still fails,
at least on my 10.5.8 and 10.6.8. The snowleopardfixes port
compiles and installs just fine, providing

$ nm /opt/local/lib/libsnowleopardfixes.dylib
1d46 s  stub helpers
 U ___error
 t __mh_dylib_header
 U _getc
1ad9 T _getdelim
1ac7 T _getline
 U _malloc
 U _memchr
 U _memcmp
 U _memcpy
1c1c T _memmem
 U _realloc
1bca T _strndup
1a8c T _strnlen
1cbc T _wcsdup
 U _wcslen
 U _wmemcpy
 U dyld_stub_binder


But when building lowdown itself (full log below)
it fails on a missing strndup(3). The failing line is

/usr/bin/gcc-4.2 -o lowdown main.o liblowdown.a -lm
Undefined symbols:
"_strndup", referenced from:
_xstrndup in liblowdown.a(xmalloc.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

The installed snowleopardfixes library doesn't seem
to even enter into it at all. Am I missing something
obvious about how the snowleopard_fixes portgroup
is supposed to work?

Jan



hans@mac:~$ sudo port -vs install lowdown
--->  Computing dependencies for lowdown.
--->  Fetching distfiles for lowdown
--->  Verifying checksums for lowdown
--->  Checksumming lowdown-0.3.1.tar.gz
--->  Extracting lowdown
--->  Extracting lowdown-0.3.1.tar.gz
Executing:  cd 
"/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work"
 && /usr/bin/gzip -dc 
'/opt/local/var/macports/distfiles/lowdown/lowdown-0.3.1.tar.gz' | 
/usr/bin/gnutar --no-same-owner -xf - 
--->  Configuring lowdown
Executing:  cd 
"/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
 && ./configure  PREFIX=/opt/local 
config.log: writing...
configure.local: no (fully automatic configuration)
arc4random: yes
capsicum: no
err: yes
explicit_bzero: no
getprogname: yes
INFTIM: no
md5: no
memmem: no
memrchr: no
memset_s: no
PATH_MAX: yes
pledge: no
program_invocation_short_name: no
reallocarray: no
recallocarray: no
sandbox_init: no
seccomp-filter: no
SOCK_NONBLOCK: no
strlcat: yes
strlcpy: yes
strtonum: no
systrace: no
zlib: yes
__progname: yes
config.h: written
Makefile.configure: written
--->  Building lowdown
Executing:  cd 
"/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1"
 && /usr/bin/make -w all 
make: Entering directory 
`/opt/local/var/macports/build/_opt_mports_macports-ports_textproc_lowdown/lowdown/work/lowdown-0.3.1'
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o autolink.o autolink.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o buffer.o buffer.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o diff.o diff.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o document.o document.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o html.o html.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o html_escape.o html_escape.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o html_smartypants.o html_smartypants.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o library.o library.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o log.o log.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o nroff.o nroff.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c -o nroff_escape.o nroff_escape.c
/usr/bin/gcc-4.2 -pipe -Os -arch x86_64 -g -W -Wall -Wextra 
-Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter  
 -c 

Re: distfile downloads failing on https

[Jan Stary]

On Feb 21 12:43:28, h...@stare.cz wrote:
> A more general proposed solution was to bunlde a newer curl with MP,
> in partcular one built against a newer SSL/TLS library:
> https://trac.macports.org/ticket/51516

It was also suggested there to recompile MP
using its own already installed curl port.

Indeed,
./configure --with-curlprefix=/opt/local/
results in MacPorts that uses its own /opt/local/bin/curl
to download distfiles, and my immediate problem disappears.

But the circular dependency on itself doesn't seem right.

Should the curl port be a fetch dependency (if there is such a thing)
for the affected ports, and should MP use the port's curl(1)
to download their distfiles?

Jan

distfile downloads failing on https

[Jan Stary]

Recently, I have tweaked textproc/lowdown
https://github.com/macports/macports-ports/pull/1245
to download the distfile from a http master site, not a https one,
because the https server rejects the weak ssl of some older MacOS systems,
which could not download the distfile then.

That worked for a while, but now the server (kristaps.bsd.lv)
redirects any http request to https anyway, so the downloads fail again.
I understand this is a general problem, not specific to the lowdown port.

One workaround would be to have a copies of the distfiles in
http://distfiles.macports.org/, but it seems the distfile mirroring
has been broken for more than a year:
https://trac.macports.org/ticket/53347

A more general proposed solution was to bunlde a newer curl with MP,
in partcular one built against a newer SSL/TLS library:
https://trac.macports.org/ticket/51516

Is there any progress in any of these?

To be sure: when downloading a distfile, does MP always use the system's
native curl(1)? Or does it try the port's curl(1), if installed?
Or does it try the port's curl(1) _first_?

On this old system where I'm experiencing the problem, these are:

$ /usr/bin/curl --version
curl 7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8y
zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

$ /opt/local/bin/curl --version
curl 7.54.1 (x86_64-apple-darwin10.8.0) libcurl/7.54.1 OpenSSL/1.0.2n
zlib/1.2.11
Release-Date: 2017-06-14
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp smb smbs smtp smtps telnet tftp 
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy 

Jan