Re: [macports-base] 01/06: fetch: Always use ${prefix}/bin/git for gitfetch

On Apr 17 14:33:12, rai...@macports.org wrote: > > https://lists.macports.org/pipermail/macports-dev/2018-March/037750.html > > The previous code always used /usr/bin/git, even if the git port was > installed. Only old versions of macOS got to use the latest version of > git, while recent versions

Re: Any testers for proposed opportunistic filesystem compression?

On Apr 12 22:58:54, ebori...@macports.org wrote: > https://github.com/macports/macports-base/pull/76 > * Slower to extract than when not in use -- shouldn't be a surprise. Yeah, about six times slower. Please don't. https://github.com/macports/macports-base/pull/76#issuecomment-382318841

Re: Update port:openssl dependency to path:lib/libssl.dylib:openssl

On Apr 02 10:26:17, ryandes...@macports.org wrote: > > https://github.com/macports/macports-ports/commit/607997ade7f0bd99c7a7297d7a49ae79442b705f > > aqua/qt5/Portfile| 2 +- > > aqua/qt55/Portfile | 2 +- > > aqua/qt56/Portfile | 2 +- > >

Re: Port and patch submissions via ticket vs. via PR.

(Not a member, speaking from a user point of view.) On Apr 01 12:02:23, pe...@piermont.com wrote: > As some of you have noticed, I've been trying to keep the PR queue > relatively clear. Thank you for that! It really is rewarding to see the PRs being acted upon in a timely manner, as opposed to o

Re: Port and patch submissions via ticket vs. via PR.

> > Also, Mojca brought the question of the hundreds of open tickets with > > port submissions a while back. It might be neat if we had some code > > that caused a special Github account to generate a PR for a port > > submission in trac. I wouldn't want this automatically invoked (at > > least not

Re: Update port:openssl dependency to path:lib/libssl.dylib:openssl

On Apr 20 09:50:50, jerem...@macports.org wrote: > > > On Apr 18, 2018, at 21:17, Ryan Schmidt wrote: > > > > > > On Apr 18, 2018, at 06:47, Jan Stary wrote: > > > >>>> https://github.com/macports/macports-ports/commit/607997ade7f0bd99c7a7297

Re: Wrong time on Travis with macOS 10.13?

On Apr 22 09:27:13, mo...@macports.org wrote: > In one of my PRs all the builds fail (only on xcode9.3) due to time > synchronisation issues: > > Portfile is from the future - check date and time of your system > > https://travis-ci.org/macports/macports-ports/builds/369674495 > > Does anyone kn

Re: Wrong time on Travis with macOS 10.13?

On Apr 22 10:58:41, h...@stare.cz wrote: > On Apr 22 09:27:13, mo...@macports.org wrote: > > In one of my PRs all the builds fail (only on xcode9.3) due to time > > synchronisation issues: > Yes, same here: > https://github.com/macports/macports-ports/pull/1626 It passes now.

Re: Migrating the guide to AsciiDoc

On Apr 22 09:29:53, mo...@macports.org wrote: > As requested during yesterday's meeting, here's the result of > automatic conversion of our guide from xml (docbook) to asciidoc: > > https://github.com/macports/macports-guide/tree/master/guide/adoc > > This was initially explored by Aljaž and

Re: Migrating the guide to AsciiDoc

> > We are already using the AsciiDoc format for our man pages, > > Manpages are supposed to be written in mdoc(7), the language of > manpages, just like e.g. /usr/share/man/man1/ls.1 is. > > The current port-* manpages are horrible > (not talking about content, but markup). > > Look at e.g. por

Re: Migrating the guide to AsciiDoc

On Apr 23 10:12:06, h...@stare.cz wrote: > > > We are already using the AsciiDoc format for our man pages, > > > > Manpages are supposed to be written in mdoc(7), the language of > > manpages, just like e.g. /usr/share/man/man1/ls.1 is. > > > > The current port-* manpages are horrible > > (not ta

Re: Migrating the guide to AsciiDoc

On Apr 23 10:09:06, mo...@macports.org wrote: > On 23 April 2018 at 09:42, Jan Stary wrote: > > On Apr 22 09:29:53, mo...@macports.org wrote: > >> As requested during yesterday's meeting, here's the result of > >> automatic conversion of our

Re: Migrating the guide to AsciiDoc

On Apr 23 13:17:10, rai...@macports.org wrote: > On 2018-04-23 10:12, Jan Stary wrote: > >>> We are already using the AsciiDoc format for our man pages, > >> > >> Manpages are supposed to be written in mdoc(7), the language of > >> manpages,

MP manpages (was: Migrating the guide to AsciiDoc)

On Apr 23 16:26:13, rai...@macports.org wrote: > On 2018-04-23 14:27, Jan Stary wrote: > >> These quirks are added by DocBook XSLT and are apparently required to > >> make the output compatible. If you disagree with that, talk to DocBook > >> why they added them.

Re: How do I check what is autobuilding successfully?

On Apr 25 14:44:51, ryandes...@macports.org wrote: > > On Apr 25, 2018, at 14:26, Perry E. Metzger wrote: > > > So the package in question is "rethinkdb", > > > packages.macports.org doesn't seem to show the package there. Does > > that mean it indeed hasn't built in a long time? > > In this ca

Re: Binary packages not rebuilding against updated libraries

On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote: > Portfile authors need to manually "revbump" > the library's dependent ports when > supporting libraries change significantly. > It's not automatically figured out by MacPorts. Wait, what? I'm still relatively new to MP and this seems a b

Re: Binary packages not rebuilding against updated libraries

On Apr 25 10:34:47, ryandes...@macports.org wrote: > > On Apr 25, 2018, at 09:02, Perry E. Metzger wrote: > > On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote: > >> Portfile authors need to manually "revbump" the library's dependent > >> ports when supporting libraries change significantly.

Re: Binary packages not rebuilding against updated libraries

On Apr 25 15:14:56, pmetz...@macports.org wrote: > On Thu, 26 Apr 2018 01:46:27 +1000 Joshua Root > wrote: > > On 2018-4-26 01:34 , Ryan Schmidt wrote: > > > > > > On Apr 25, 2018, at 09:02, Perry E. Metzger wrote: > > >> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote: > > >>> Portfi

Re: What "openmaintainer" means

It seems that maintainership is regarded as a status symbol in MP: the guy who sleeps with this Portfile. That's strange. Anyone can improve a port, be it a typo or a fundamental fix. Instead, it's supposed to be a responsibility. Out of all the people who can better this port for fun and profit,

Re: What "openmaintainer" means

> I test/verify on (currently) 10.5 PPC through 10.13 Intel (actual hardware; > not just a VM; 10.4 PPC & 10.5 Intel coming soon). Hence I'm very likely to > find and correct any build issues with my ports (and some others) and provide > fixes that work across the various OSXs. Cool. Do you hav

Re: Binary packages not rebuilding against updated libraries

On Apr 26 03:16:37, rai...@macports.org wrote: > On 2018-04-26 00:11, Jan Stary wrote: > > On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote: > >> Portfile authors need to manually "revbump" > >> the library's dependent ports when > >> s

Re: Binary packages not rebuilding against updated libraries

> > For comparison, the OpenBSD port system has resigned on upstreams' > library versioning, and versions the libraries itself. For example, > in audio/libsndfile (1.0.28): > > SHARED_LIBS += sndfile 6.0 # .1.28 > > and it installs /usr/local/lib/libsndfile.so.6.0. BTW, what's with t

Re: Agility

On Apr 25 09:25:44, ken.cunningham.web...@gmail.com wrote: > > We should allow (encourage even) WIP PRs to be submitted, when the work is > > in a state that warrants it. > > > > Chris > > Personally i would think those would better be trac tickets, as that model > seems to work better for comm

Re: Agility

On Apr 25 11:46:42, ryandes...@macports.org wrote: > When we switched to GitHub, we spent a lot of time considering whether to > move our Trac tickets to GitHub Issues. Smaller macOS forge projects were > happy with that change, but after careful consideration, we came to the > conclusion that G

Re: [macports-mgr] Question about MacPorts project membership application

On May 13 23:38:35, rai...@macports.org wrote: > On 2018-05-13 23:03, Mojca Miklavec wrote: > > On 13 May 2018 at 21:32, Rainer Müller wrote: > >> On 2018-05-13 18:30, Mojca Miklavec wrote: > >>> The portmgr team might need some time to check the contributions and > >>> verify candidate's suitabili

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

> So far, I have tested installing the vim and bash ports with this code > in place and the installation of each did indeed detect the gnubin > version of grep, so all seems well for the ports that use grep as a > build dependency. The only ports I found that specifically deal with grep are: * de

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

On Jul 21 12:21:55, h...@stare.cz wrote: > * math/octave > Depends on GNU grep, GNU sed, and all that. > I'll check with math/octave. Eh, that would take _days_ on my machine. Not touching that. Does anyone now why octave wants GNU grep etc? What exactly breaks if it uses the system grep, find,

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

o longer necessary; > IDK. Worth testing, IMHO. - MLD I tried first with port:grep etc (i.e. as the port is now), but even that does not build (see recent mail to macports-users@). Jan > On Sat, Jul 21, 2018, at 7:55 AM, Jan Stary wrote: > > On Jul 21 12:21:55, h...@stare.cz

Re: "size" documentation

On Aug 17 10:19:17, m...@macports.org wrote: > > On Aug 17, 2018, at 7:44 AM, Perry E. Metzger wrote: > > 3. There's no real documentation of the "size" parameter to > > checksums, and I'm constantly asking people to add the size. Note > > that I don't think "size" is a reasonable thing to require

Re: squash and merge, license documentation, "size" documentation

On Aug 21 22:58:07, j...@macports.org wrote: > On 2018-8-18 06:06 , Clemens Lang wrote: > > I think the idea of the size keyword is to start to use it to display > > download progress bars for servers that do not send a Content-Length > > HTTP header (or do not have an equivalent of such a header d

Re: squash and merge, license documentation, "size" documentation

> > On Aug 21 22:58:07, j...@macports.org wrote: > >> On 2018-8-18 06:06 , Clemens Lang wrote: > >>> I think the idea of the size keyword is to start to use it to display > >>> download progress bars for servers that do not send a Content-Length > >>> HTTP header (or do not have an equivalent of su

Re: Identifying possible situations for interactivity

On Sep 01 12:12:11, eg...@gwmail.gwu.edu wrote: > So I was going thru my drafts folder and found this unsent message in > it from a few years ago; much of it may no longer be relevant now that > MacPorts has already added interactivity, but I figured I might as > well send this anyways for the arch

Re: viewing code while respecting defines

On Sep 10 08:24:39, ken.cunningham.web...@gmail.com wrote: > I don't know if I asked this correctly, and it's not macports-specific, but I > don't know where else to ask. > > Some of the code I'm trying to tweak (llvm-N, webkit2-gtk-N, etc) has a lot > of #defines in it to modify code paths for

Re: How to defend "using the right compiler" in upstream projects

On Feb 10 15:40:29, mo...@macports.org wrote: > I need help explaining why it's important to us to use the right > compiler (even when the source is written in plain C and even Tiger > can build the source, so one cannot say that something is really > broken): > https://github.com/FluidSynth/fluid

Re: Prevent MacPorts editing .bash_profile

As discussed currently on -users, here is a diff that stops postflight messing with the user's config and edits the correspondng parts of installing.xml Jan --- Begin Message --- Here is a diff to postflight and an accompanying diff to installing.xml (what other places need to be touched

PATH deals with binaries, not libraries

On Mar 22 07:48:55, h...@stare.cz wrote: > As discussed currently on -users, here is a diff > that stops postflight messing with the user's config > and edits the correspondng parts of installing.xml Even if this gets rejected (as it seems to be the consensus to edit the user's shell configuration

port search --maintainer[s]

This is 2.4.99 from git running on 10.6.8. The 'port search' recognizes '--maintainer' and '--maintainers', but the guide says '--maintainer' and '--maintainer' while port-search.1 only says '--maintainer'. Attached please find a diff for each. There is also port-search.1.txt in git, which gets ou

port livecheck does not find new mandoc

This is 2.4.99 running on 10.6.8 port -d livecheck mandoc does not find http://mdocml.bsd.lv/snapshots/mdocml-1.14.1.tar.gz because it looks for "mandoc-(\d+(?:\.\d+)*)" i.e. the tarball differs from the port name. What is the right place to specify the right regex? Jan

Re: port search --maintainer[s]

(Sorry, attaching now). On Mar 30 18:18:41, h...@stare.cz wrote: > This is 2.4.99 from git running on 10.6.8. > The 'port search' recognizes '--maintainer' and '--maintainers', > but the guide says '--maintainer' and '--maintainer' > while port-search.1 only says '--maintainer'. > Attached please

manpages is mdoc(7)

Currently, the port-* manpages are written using the legacy man(7) language which uses low-level roff constructs to described presentational details. I propose to rewrite them into the _semantic_ markup of mdoc(7) language. Both have been around for decades and are well supported by groff. As an

Re: manpages is mdoc(7)

Err, the intended subject was "manpages in mdoc(7)" :-) But yes, manpages is mdoc(7), imho. On Mar 30 19:08:44, h...@stare.cz wrote: > Currently, the port-* manpages are written > using the legacy man(7) language which uses > low-level roff constructs to described presentational details. > > I pr

Re: port livecheck does not find new mandoc

On Mar 30 18:41:26, h...@stare.cz wrote: > This is 2.4.99 running on 10.6.8 > > port -d livecheck mandoc does not find > http://mdocml.bsd.lv/snapshots/mdocml-1.14.1.tar.gz > because it looks for "mandoc-(\d+(?:\.\d+)*)" > i.e. the tarball differs from the port name. > What is the right place to s

Re: manpages is mdoc(7)

On Mar 30 19:08:44, h...@stare.cz wrote: > I propose to rewrite them into the _semantic_ markup of mdoc(7) language. On Mar 30 20:59:31, rai...@macports.org wrote: > Our man pages are actually written in AsciiDoc and then converted to the roff > output. We only maintain the generated roff output i

Re: manpages is mdoc(7)

On Mar 30 21:47:38, rai...@macports.org wrote: > On 03/30/2017 09:26 PM, Jan Stary wrote: > > Just forget it. My intentions when proposing the mdoc(7) rewrite > > were the opposite of having asciidoc and docbook and xml/xsl ... > > While the dependencies seem quite heav

Re: port livecheck does not find new mandoc

On Mar 31 04:49:02, j...@macports.org wrote: > On 2017-3-31 03:41 , Jan Stary wrote: > > This is 2.4.99 running on 10.6.8 > > > > port -d livecheck mandoc does not find > > http://mdocml.bsd.lv/snapshots/mdocml-1.14.1.tar.gz > > because it looks for "mandoc

Re: port search --maintainer[s]

On Mar 30 21:06:59, rai...@macports.org wrote: > On 03/30/2017 06:18 PM, Jan Stary wrote: > > This is 2.4.99 from git running on 10.6.8. > > The 'port search' recognizes '--maintainer' and '--maintainers', > > but the guide says '--maintain

Re: port search --maintainer[s]

On Mar 31 02:07:15, rai...@macports.org wrote: > On 2017-03-30 23:44, Jan Stary wrote: > > On Mar 30 21:06:59, rai...@macports.org wrote: > >> On 03/30/2017 06:18 PM, Jan Stary wrote: > >>> This is 2.4.99 from git running on 10.6.8. > >>> The &

libsndfile no longer needs the files/*

https://github.com/macports/macports-ports/commit/b4ef71e535157c4bfec350f7d1b5a280bc1bc088 updates the Portfile but does not remove files/* - I forgot to mention that, sorry. Jan

Re: manpages is mdoc(7)

On Mar 31 23:07:06, ryandes...@macports.org wrote: > > Anyway, the mdoc(7) rewrite is apparently not happening. > > Right; the asciidoc rewrite of the manpages was just released to the public > in MacPorts 2.4 so there's probably no interest in changing it again so soon. But the age of the ascii

expired certificate

The certificate for https://lists.macosforge.org has expired on February 26. Jan

Re: manpages is mdoc(7)

On Apr 01 14:24:42, rai...@macports.org wrote: > > I'm not hoping to change the course here, > > but what were the manpages written in before this? > > porthier.7 is in mdoc(7), with .Dd June 1, 2007 > > - were all the base manpages im mdoc(7) before? > > Back when the NewHelpSystem [1] was starte

Re: manpages is mdoc(7)

> On Apr 01 14:24:42, rai...@macports.org wrote: > > Many open source projects generate their man pages from a high-level > > markup language. I am only aware of the various *BSD systems that keep > > writing roff directly. Just to clarify: * no-one is advocating "writing roff directly". * mdoc(7

Re: manpages is mdoc(7)

On Apr 01 09:24:22, keybou...@gmail.com wrote: > In the past, I attempted to write stuff with man page macros. > I could not find any actual docs on the macros or how to use them. > I found that there was no consistent style or rules > from reverse engineering the shipped system man pages. Whether

Re: [MacPorts] #54009: libsndfile @1.0.27: update to 1.0.28

libsndfile 1.0.28 has introduced "-Wvla" into its compilation options, which means it no longer builds on my 10.6.8 which comes with gcc 4.2.1. cc1: error: unrecognized command line option "-Wvla" I brought that up on the sndfile mailing list, upstream already has a fix for it in their git (i.e

Re: "dev" ports (=/= "devel" ports!)

On Apr 23 15:54:07, rjvber...@gmail.com wrote: > I'd like to draw some attention to a prototype implementation of a PortGroup > I wrote for creating "dev" ports, akin to Debian/Ubuntu's "-dev" packages: > https://trac.macports.org/ticket/52713 > I've been using this for a while now and find it pa

Re: "dev" ports (=/= "devel" ports!)

> > Those are all files that are only required when using port "A" > > as a dependency for *building* other software but not as a dependency > > for running that dependent software. > > The keyword here is "only". It is not unusual to install a library > (and its header files, and its pkgconfig fi

Re: Dropping recommendation to install system headers / command line tools

On Jul 04 03:10:38, ryandes...@macports.org wrote: > Last I checked, graphite2 would not build if CLTools were not installed: > https://trac.macports.org/ticket/49325 On a related note: a comment in this ticket says that xcode-select -p does not show whether you have the command l

Re: Dropping recommendation to install system headers / command line tools

On Jul 03 21:21:36, jerem...@macports.org wrote: > base currently outputs a warning if system headers are not installed. I > modified the warning a few months ago when I improved our support for > building against SDKs, and it now reads: > >Warning: System headers do not appear to be instal

Re: Dropping recommendation to install system headers / command line tools

On Jul 05 08:38:16, a...@alum.wpi.edu wrote: > On Wed, Jul 5, 2017 at 7:14 AM, Jan Stary wrote: > >> as it avoids /usr/local/{include,lib} contamination. What are the > >> thoughts on this? > > > > What contamination? I don't even have /usr/local/ > &

Re: Possible patch for sox build failure on 10.7

On Aug 09 08:44:02, ken.cunningham.web...@gmail.com wrote: > > On 2017-08-09, at 1:05 AM, Joshua Root wrote: > > > Perhaps someone with access to a 10.7 machine could try this. > > > > - Josh > > > > Yep, that should do it. Deactivating MacPorts grep, sox build fails - > activating MacPorts

Re: Possible patch for sox build failure on 10.7

s it run by SoX's build system, or is the nm/grep combo run by the building robot? Jan > > On 2017-08-09, at 9:55 AM, Jan Stary wrote: > > > On Aug 09 08:44:02, ken.cunningham.web...@gmail.com wrote: > >> > >> On 2017-08-09, at 1:05 AM, Joshua Root wr

Re: Possible patch for sox build failure on 10.7

On Aug 10 06:30:12, j...@macports.org wrote: > On 2017-8-9 23:15 , Jan Stary wrote: > > On Aug 09 15:06:35, ken.cunningham.web...@gmail.com wrote: > > > I can work with you on this. I'll build a failing version and email you > > > the entire log off-list

Re: Possible patch for sox build failure on 10.7

On Aug 12 10:56:57, mo...@macports.org wrote: > On 12 August 2017 at 10:36, Jan Stary wrote: > > > > libtool: link: /usr/bin/grep -E -e > > "^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelen

Re: Python 2.7 – allow another db version beside 4.8

On Dec 24 05:19:35, j...@macports.org wrote: > On 2017-12-24 04:28 , Clemens Lang wrote: > > Is there a reason to not just always use a newer version? > And to turn the question around, what is gained by using the newer version? Exactly. Insisting on the newest version of everything has cost me c

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

On Dec 19 15:09:25, rai...@macports.org wrote: > On 2017-12-18 00:20, Clemens Lang wrote: > > We debugged this on IRC recently. Turns out the culprit is > > > > https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44 > > >

Re: Fix Sierra Trac query

On Sep 26 01:39:38, jon...@hep.phy.cam.ac.uk wrote: > You could just avoid the problem by using the numerical OS designation. Exactly. It's 10.13. Why call it something else? > > We already had this problem long ago with the Lion Problems page showing > > Mountain Lion tickets as well: > > https

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

On Dec 24 11:44:21, h...@stare.cz wrote: > On Dec 19 15:09:25, rai...@macports.org wrote: > > On 2017-12-18 00:20, Clemens Lang wrote: > > > We debugged this on IRC recently. Turns out the culprit is > > > > > > https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e89

supported XCode versions

Thanks for commiting https://github.com/janstary/macports-ports/commit/0ca6b66fd5ffd8e348812e791b25364c29052071 The file xcode_versions.ini lists the "supported" versions of xcode for the individual MacOS versions. I wonder what exactly does it mean for an xcode version to be there. Is there some

Re: Fix Sierra Trac query

On Dec 24 13:56:08, ryandes...@macports.org wrote: > >>> Perhaps Chris is suggesting to just change the tag going forward. > >> I would find that more confusing. > > > > How is "10.13" confusing? > > How is it more confusing than "High Sierra"? > > I meant that I would find it more confusing to u

Re: Python 2.7 – allow another db version beside 4.8

On Dec 25 10:04:33, vi...@macports.org wrote: > > On 24 Dec 2017, at 11:23, Jan Stary wrote: > >> On Dec 24 05:19:35, j...@macports.org wrote: > >>> On 2017-12-24 04:28 , Clemens Lang wrote: > >>> Is there a reason to not just always use a newer version? >

Re: Fix Sierra Trac query

On Dec 25 15:16:24, ryandes...@macports.org wrote: > >>> The point of that page, if I get it, is to list problems > >>> specific to that vesion of the OS, and it doesn't, > >>> precisely because "sierra" matches "highsierra" (right?). > >>> So using these silly names is precisely the problem, no? >

Re: Fix Sierra Trac query

On Dec 26 01:47:11, rai...@macports.org wrote: > > The confusion of also having names of cats and mountains > > for the old releases will eventually die out as they get older. > > I doubt so, since Apple always introduced a codename for each release. > What makes you think they would stop this? I

Re: travis builds time out -- then keep restarting ???

On Sep 15 15:37:01, ken.cunningham.web...@gmail.com wrote: > Something funny is going on with travis today. > The builds keep restarting after timing out at 48 mins, I think > On Sep 17 06:28:57, ken.cunningham.web...@gmail.com wrote:

Re: travis builds time out -- then keep restarting ???

On Jan 02 22:20:25, rai...@macports.org wrote: > On 01/02/2018 11:13 AM, Jan Stary wrote: > > On Sep 15 15:37:01, ken.cunningham.web...@gmail.com wrote: > >> Something funny is going on with travis today. > >> The builds keep restarting after timing out at 48 mins, I

libressl vs openssl

Hi Jeremy, > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston Sequoia wrote: > > There are some things that I want to do to the port (and OpenSSL) It would be very nice if all ports currently depending on openssl would build against libressl, and we could get rid of openssl in favor of

Re: libressl vs openssl

Hi Jeremy, > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston Sequoia wrote: > > > There are some things that I want to do to the port (and OpenSSL) what is the strategy with the libressl port as opposed to libressl-devel? Currently, libressl is 2.5.5 and libressl-devel is 2.6.2. I

Re: libressl vs openssl

On Jan 09 12:24:22, pe...@piermont.com wrote: > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary wrote: > > Hi Jeremy, > > > > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston > > > Sequoia wrote: > > > > There are some things that

Re: libressl vs openssl

On Jan 09 09:40:23, bl...@orcaware.com wrote: > https://boringssl.googlesource.com/boringssl/ > > "Although BoringSSL is an open source project, it is not intended for general > use, as OpenSSL is. We don't recommend that third parties depend upon it. > Doing so is likely to be frustrating becau

Re: libressl vs openssl

On Jan 10 11:02:46, neum...@wu.ac.at wrote: > Am 09.01.18 um 18:24 schrieb Perry E. Metzger: > > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary wrote: > > > Hi Jeremy, > > > > > > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston > > >

Re: a no-homepage homepage for ports with dead homepages

On Jan 10 18:32:37, ken.cunningham.web...@gmail.com wrote: > I like this idea from gentoo, for a homepage we can use when old homepages > disappear, eg port "aee". > > > > We might do something like this as well, perhaps. It assumes the source has > be

Re: Python 2.7 – allow another db version beside 4.8

On Dec 27 11:56:53, vi...@macports.org wrote: > On 25 Dec 2017, at 20:30, Jan Stary wrote: > > > Generally, I tend to let the port/package use any version, > > unless there is a specific reason for some specific version. > > For example, if a port requires Python, t

Re: libressl vs openssl

On Jan 11 07:07:42, ryandes...@macports.org wrote: > > On Jan 10, 2018, at 14:49, Jan Stary wrote: > > > On Jan 09 09:40:23, Blair Zajac wrote: > >> https://boringssl.googlesource.com/boringssl/ > >> > >> "Although BoringSSL is an open source pr

Re: a no-homepage homepage for ports with dead homepages

On Jan 11 08:42:59, ken.cunningham.web...@gmail.com wrote: > > On 2018-01-11, at 12:24 AM, Jan Stary wrote: > > > > For ports that don't have a homepage, the simplest thing imho > > is not to declare one in the Portfile. > > a: not possible > > $ por

Re: a no-homepage homepage for ports with dead homepages

On Jan 11 11:49:40, ken.cunningham.web...@gmail.com wrote: > > On 2018-01-11, at 9:37 AM, Ken Cunningham wrote: > > > > > > But if I can find a saved one at archive.org, that would be better, to be > > sure. > > > > K > > I've been prospecting MacPorts errors reported by repology >

Re: a no-homepage homepage for ports with dead homepages

s/manpage/homepage/g of course; sorry. Jan On Jan 11 22:22:10, h...@stare.cz wrote: > On Jan 11 11:49:40, ken.cunningham.web...@gmail.com wrote: > > > > On 2018-01-11, at 9:37 AM, Ken Cunningham wrote: > > > > > > > > > > But if I can find a saved one at archive.org, that would be better, to

Re: a no-homepage homepage for ports with dead homepages

On Jan 12 11:12:17, rai...@macports.org wrote: > On 2018-01-11 22:22, Jan Stary wrote: > > On Jan 11 11:49:40, ken.cunningham.web...@gmail.com wrote: > >> I've been prospecting MacPorts errors reported by repology > >> <https://repology.org/maintainer/nomai

Re: a no-homepage homepage for ports with dead homepages

On Jan 14 13:42:26, rai...@macports.org wrote: > On 2018-01-14 12:34, Jan Stary wrote: > > On Jan 12 11:12:17, rai...@macports.org wrote: > >> On 2018-01-11 22:22, Jan Stary wrote: > >>> What errors exactly will be "fixed" by that? > >> > >>

LibreSSL and OpenSSL and *SSL

A simple patch to allow opusfile to build against LibreSSL https://github.com/macports/macports-ports/pull/1217 devolved into a OpenSSL/LibreSSL debate that probably belongs here instead. First things first: the newer releases of MacOS (10.13.2 here) already provide various implementations of cry

Re: LibreSSL and OpenSSL and *SSL

On Feb 21 16:05:41, h...@stare.cz wrote: > First things first: the newer releases of MacOS (10.13.2 here) > already provide various implementations of crypto/ssl/tls, > including OpenSSL, LibreSSL and (Google's) BoringSSL: > > hans@fitbook:~$ ls -l /usr/lib/*ssl* > -rwxr-xr-x 1 root wheel 12361

Re: LibreSSL and OpenSSL and *SSL

On Feb 16 19:36:56, notificati...@github.com wrote: > The two versions are not actually completely compatible true > and it is not clear that we should wish to support > the use of libressl in place of openssl Now that the base OS uses LibreSSL by default, I believe we should. Not only should w

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

> > >> 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.re

Re: LibreSSL and OpenSSL and *SSL

On Feb 21 16:05:41, h...@stare.cz wrote: > -rwxr-xr-x 1 root wheel 392912 Dec 1 20:39 /usr/lib/libssl.0.9.7.dylib > -rwxr-xr-x 1 root wheel 630144 Dec 1 20:38 /usr/lib/libssl.0.9.8.dylib > -rw-r--r-- 1 root wheel 947104 Dec 1 20:38 /usr/lib/libssl.35.dylib > -rw-r--r-- 1 root wheel

Re: LibreSSL and OpenSSL and *SSL

On Feb 21 21:21:21, h...@stare.cz wrote: > While it's true that the two version are not completely compatible, > in e.g. the opusfile port that started this, the incompatibilty > is completely artificial. > > Opus is an audio codec - why does it need to link with -lssl? > It wants to play remote a

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

On Feb 22 12:31:24, billc_li...@greenbuilder.com wrote: > A single port crane, done as a line drawing in the O'Reilly book cover > style (possibly anthropomorphized) would work well as a logo and could > probably be made into a plush toy if someone really wanted to take it that > far. A plush toy

Re: #55884: mandoc @1.14.3: not using the right compiler

The ticket is closed, so I will continue here. > Actually it's not specific to the universal variant. Rather, the problem > is that the port is not UsingTheRightCompiler. mandoc's ./configure sets CC to whatever make(1) thinks CC is: CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`

Re: LibreSSL and OpenSSL and *SSL

> On Feb 16 20:15:04, notificati...@github.com wrote: > > OpenSSL was once undersupported because they didn't have funds > > to have full time staff doing development and maintenance. > > That ended a long time ago after Heartbleed. > > The project is now fully funded and has excellent people worki

Re: #55884: mandoc @1.14.3: not using the right compiler

s now adjusted these descriptions in the guide. https://guide.macports.org/chunked/reference.phases.html still says "Set CC compiler flags for selecting a C compiler." On Feb 28 17:36:38, rai...@macports.org wrote: > On 2018-02-28 08:52, Jan Stary wrote: > > The ticket is closed,

Re: #55884: mandoc @1.14.3: not using the right compiler

> > > mandoc's ./configure sets CC to whatever make(1) thinks CC is: > > > CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -` > > > Why exactly is it "not the right compiler"? > > > > As env -i clears the environment, > > how is this supposed to work at all? > > This does not respect CC

Re: Relax port lint rule for patchfile naming

While we're here: > >> How will you distinguish patchfiles from others > The lint check in question doesn't look at the contents of files/, it > looks at the patchfiles option. what e.g. OpenBSD does is it has a patches/ subdirectory in the port dir. Anything in there is a patch to be applied. N

Re: port sync performance

On Mar 25 10:24:22, pmetz...@macports.org wrote: > Now that I'm a project member, I've noticed that the performance of > "port sync" is vastly lower than the performance of "git pull", > probably because rsync is much slower than git. I believe it also rebuilds the index after the pull. > 1) Does

  1   2   >