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

[Jan Stary]

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/fluidsynth/issues/509
> https://github.com/macports/macports-ports/pull/3583

Shouldn't https://trac.macports.org/wiki/UsingTheRightCompiler
be precisely the place that explains this, convincigly? Does it?

Re: viewing code while respecting defines

[Jan Stary]

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 various OS versions.
> 
> It can get pretty mind-bending to try to follow the code path.
> 
> Is there any editor that shows you somewhat more clearly what code path you 
> will be following with certain sets of defines?

cpp(1)

Re: Identifying possible situations for interactivity

[Jan Stary]

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 archives so what I wrote doesn't die
> stuck in my drafts.

The port system should be as NON-interactive as possible.
A user starts a bulk build of, say, all audio ports and walks away.
It would be quite unfortunate if he had to be there the whole time.

The exeptions should only be exceptional: when a port is removed,
everything that depends on it should also be removed, but that
probably requires the user's Yes.

>  - after running `selfupdate`, MacPorts could ask the user if they
> next want to upgradeall their outdated ports.

No. This insistence on the latest bugs is a disease.
I want the version I have, which I know to work, unless I have
a reason to update (such as a security problem or a feature I wanted).

>  - modifications to configuration files:
> {{{
> Configuration file `/sw64/etc/shells'
>  ==> File on system created by you or by a script.
>  ==> File also in package provided by package maintainer.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : background this process to examine the situation
>  The default action is to keep your current version.
> *** shells (Y/I/N/O/D/Z) [default=N]
> }}}

An install should never touch configs in /etc (let alone in $HOME),
except if creating a brand new one. Notify the user that a port contains
a config different from one that aready exists, or has installed a new one,
and leave it to the user to do the editing.

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

[Jan Stary]

> > 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 due to the
> >>> used protocol). This is currently not implemented.
> >>> 
> >>> 'port -v checksums' does generate the size field in newer versions of
> >>> MacPorts. Until such a version becomes the released default, I think
> >>> it's fine not to require adding it in PRs.
> >> 
> >> Not accepting PRs until they add it is certainly not a good approach.
> >> Recommend using it in all the docs, certainly. But don't put extra
> >> burden on both contributors and reviewers for the sake of an
> >> unimplemented minor feature.
> > 
> > https://github.com/macports/macports-ports/pull/2371
> > has been rotting for two weeks for exactly that.
> 
> In this case, you removed the size from a port that already had it.

Yes, because it needlessly polutes the Portfile,
much like 'platforms'. It doesn't add anything.

> This is actively undoing the work of other contributors.

Yes; like if you remove a needless dependdency,
which someone took pains to include properly.

> Please try not to undermine what the rest of us are doing.

You don't seriously mean that in preparing
https://github.com/macports/macports-ports/pull/2371
I tried to undermine the work of others, do you.

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

[Jan Stary]

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 due to the
> > used protocol). This is currently not implemented.
> > 
> > 'port -v checksums' does generate the size field in newer versions of
> > MacPorts. Until such a version becomes the released default, I think
> > it's fine not to require adding it in PRs.
> 
> Not accepting PRs until they add it is certainly not a good approach.
> Recommend using it in all the docs, certainly. But don't put extra
> burden on both contributors and reviewers for the sake of an
> unimplemented minor feature.

https://github.com/macports/macports-ports/pull/2371
has been rotting for two weeks for exactly that.

Re: "size" documentation

[Jan Stary]

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 given that
> > finding two files of the same size with the same SHA-2 hash is
> > probably worth a doctoral dissertation at this point, but if we are
> > going to require it (why do we require it?), it should be documented,
> > and port lint should complain that it isn't there, and doing
> > port -v checksums should spit it out if it isn't there. 
> 
> The size is also useful for giving user feedback
> on the download time remaining. 

On Aug 17 22:06:13, c...@macports.org 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 due to the
> used protocol).

How many of the total number of ports have their distfiles served
by such servers? Would it be simpler to just not display a progress bar
in those cases, as opposed to introducing another keyword?

If the idea is to help display a progress bar (please make it in color),
why is it a 'checksum'? We already have much beter checksums.

curl it the one doing the download. If it can display a progress bar,
it will. If not, please leave it like that.

> This is currently not implemented.

Reminds me of 'platforms'.

Jan

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

[Jan Stary]

On Jul 21 10:10:14, michae...@macports.org wrote:
> "back in the day" & IIRC: Octave required modern GNU grep to handle locale 
> correctly; the built-in grep wasn't guaranteed to do so. That was probably 
> with some 3.X series. With the 4.X series maybe it's no 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 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, sed, flex?
> > 
> > Jan

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

[Jan Stary]

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, sed, flex?

Jan

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

[Jan Stary]

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

* devel/libtool

  Explicitly sets GREP=/usr/bin/grep so that libtool's GNU-centric
  ./configure does _not_ detect the possiby installed MP grep
  (which is GNU grep), as that would create a hidden dependency.

* graphics/openexr/Portfile:# avoid dependency on port:grep

  Also sets GREP=/usr/bin/grep to _avoid_ the dependency

* math/octave

  Depends on GNU grep, GNU sed, and all that.

* textproc/dict

  Also insists on GNU grep, but does not need it.
  https://github.com/macports/macports-ports/pull/2252


> There are certain incompatibilities between BSD grep and GNU grep. If
> you compare the man pages, you'll see that GNU grep lacks certain
> options provided by BSD grep (and vice versa) and that some options
> behave differently. For the sake of brevity, I do not want to enumerate
> all such incompatibilities here. But they do exist. I have run into
> trouble before when I've relied on GNU grep instead of BSD grep for
> certain scripts and so I've become wary about doing that anymore.

Great, so use the system grep.

 $ grep -V
 grep (BSD grep) 2.5.1-FreeBSD

> > Are there ports that require GNU grep and do not work with
> > the BSD grep at /usr/bin/grep?
> 
> Not that I know of, no.

I'll check with math/octave.

Jan

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

[Jan Stary]

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 suitability for commit rights, but maybe they
> >>> forgot to send you a preliminary confirmation of receiving your
> >>> request and were simply waiting for the votes to arrive.
> >>
> >> We never did anything like that... Why would we expected to confirm the
> >> reception of every single mail?
> > 
> > Probably not confirming reception of every single email, but I believe
> > it makes an enormous difference to the user asking for commit rights
> > if he gets a simple, totally generic email saying something like
> > "Thank you for contacting us and for volunteering to help us shape our
> > package manager into an even better product. Please be patient while
> > we are evaluating your recent contributions and don't hesitate to ping
> > us again in case you don't get an answer within two weeks." ... as
> > compared to not even knowing whether the email was sent to the correct
> > email address and not lost on the way due to spam filters.

"Dear valued commiter" is what this is missing.

Re: Agility

[Jan Stary]

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 commenting, and working things out, but that could 
> be just my preference.

In a github PR, you can comment on individual lines of code.
How exactly does trac "work beter for commenting"?

Jan

Re: Binary packages not rebuilding against updated libraries

[Jan Stary]

> 
> 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 the version numbers in e.g.
otool -L /opt/local/bin/openssl:
/opt/local/lib/libssl.45.dylib (compatibility version 46.0.0, current version 
46.1.0)

libssl.45.dylib is what the vanilla tarball itself produces.
Where exactly do the numbers 46.0.0 and 46.1.0 come from?

Jan

Re: Binary packages not rebuilding against updated libraries

[Jan Stary]

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
> >> 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 bit weird.
> > 
> > "Port A depends on library B. The port of library B has
> > just been rebuilt/upgraded. So port A needs to be rebuilt
> > as well now, if only to record the new dependency."
> 
> An update to port B cannot cause a new dependency in port A.

I mean dependency on the new lib.
Say a port produces a package containing 'bin/prog'
that depends (as in otool -L) on libz.1.2.11.dylib.
If zlib is updated, and provides libz.1.2.12.dylib now,
bin/prog ca no longer depend on libz.1.2.11.dylib
(which no longer exists), but on libz.1.2.12.dylib.
That's what I meant by "new dependency", in the
installed package of the port.

> > MP does not have that?
> Port A only has to be rebuilt if the compatibility version of port B
> changes in a way that makes it incompatible with the previous version
> (basically increasing soname on other systems). This is quite seldom.

Aren't most library port updates like that?

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.
Is that incompatible with the previous? That was libsndfile.so.5.0,
so yes, it's incompatible; that's why the maintainer named it so.
Hence, rebuild everything that depends on libsndfile
(without bumping _their_ revision).

In an ideal world, the decision could be based on the libfoo.X.Y.Z,
but often it cannot.

> If port B was updated and the compatibility version changed, the
> automatic run of 'port rev-upgrade' after the installation will detect
> that a binary/library of port A has broken linkage. It will then rebuild
> port A from source, ensuring you have a working installation locally.

Yes.

> To produce new packages, the revision of port A has to be increased.

That's what I don't get: new packages of what?
The packages that were installed before get rebuilt
with port rev-upgrade, automatically,
without anyone touching their Portfile.
Which ports need to get a new revision in the Portfile, and why?

Jan

Re: What "openmaintainer" means

[Jan Stary]

> 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 have that automated somehow (cron?)
or do you just "sudo port -vst install this"
manualy on each of those machines?

Re: What "openmaintainer" means

[Jan Stary]

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,
this guy actualy takes that on as a duty. (Presumably because he
regularly uses the port, knows the insides, and cares whether it
works as well as possible; he is personaly invested in it.)

In that sense, "openmaintainer" means nothing:
it means "I don't mind if you do my job for me".

Implementing fine-grained levels of open-maintainership
(with labels or Portfile declarations or whatever)
sounds like a commitee-designed paperwork nightmare.

(Am I actually allowed to propose this?
Oh, it has "minorrevisions" in the tags.
Is this a minor revision? I don't know?)

Ditch all that. If you have an idea about a port,
implement it (test it, etc) and propose it.
It is the maintainers job then to deal with it.

Re: Binary packages not rebuilding against updated libraries

[Jan Stary]

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:  
> > >>> Portfile authors need to manually "revbump" the library's
> > >>> dependent ports when supporting libraries change significantly.
> > >>>
> > >>> It's not automatically figured out by MacPorts.  
> > >>
> > >> Do we have a Trac issue for having it automatically determined,
> > >> btw?  
> > > 
> > > I doubt it, since I doubt there's anything we can do about it.
> > > How would you automate that?  
> > 
> > It should be possible, but it would be some work. You'd have to
> > install and run rev-upgrade on every dependent port each time any
> > port is updated, and if it finds broken files and the rebuild
> > succeeds in fixing them (i.e. a rev bump would fix the problem),
> > you could commit a rev bump.
> > 
> > One complication is that we don't currently have a reliable way of
> > programmatically rev bumping ports (it gets tricky when there are
> > subports for one thing). Just notifying maintainers would still be
> > a win though.
> 
> I don't know that this is needed. As I noted, there are other package
> systems that just note that they have to rebuild dependents if a

Exactly. OpenBSD's pkg_add(1) is an example.

Re: Binary packages not rebuilding against updated libraries

[Jan Stary]

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.
> >> 
> >> It's not automatically figured out by MacPorts.
> > 
> > Do we have a Trac issue for having it automatically determined, btw?
> 
> I doubt it, since I doubt there's anything we can do about it.
> How would you automate that?

Keep a record of what depends on what (as packaging managers do).
If A depends on B, and B has been rebuilt, reduild A too.
No "revision bump"; port A as such has not changed.

Re: Binary packages not rebuilding against updated libraries

[Jan Stary]

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 bit weird.

"Port A depends on library B. The port of library B has
just been rebuilt/upgraded. So port A needs to be rebuilt
as well now, if only to record the new dependency."

MP does not have that?

Re: How do I check what is autobuilding successfully?

[Jan Stary]

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 case, it means rethinkdb is not distributable.

wat makes a package distributable (or not)?

MP manpages (was: Migrating the guide to AsciiDoc)

[Jan Stary]

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.
> > 
> > You don't care that a 2008 workaround to a Debian bug
> > is included in every manpage of a MacPorts package system?
> > Or a 2009 workaround to a Solaris bug in GNU roff?
> > Don't you find it a prime example of clutter
> > that simply does not belong there?
> 
> No, I really do not care about these workarounds. Why should I care
> about workarounds in intermediate formats?
> I do not see anything of this in my terminal.

The asciidoc is what you don't see on you terminal.
The resulting man(7) page is what you see, rendered
by either groff (typically) or mandoc.

> Again, this is added to every man page produced by DocBook and not
> specific to the man pages generated for MacPorts. We are not maintaining
> the XSLT stylesheets that produce this output. If you think these
> workarounds are not necessary, the DocBook project is the right address
> for complaints.

I have no desire to "fix docbook", overengineered beyond absurdity.
My point is why do you want to use something like docbook
to produce the manpages?

> >>>> Then read the port-diagnose.1 below, written in mdoc(7).
> >>>> Which one is cleaner, simpler, more readable, more writable, shorter?
> >>>>
> >>>> I offer to rewrite them.
> >>
> >> We moved away from mdoc(7) with the NewHelpSystem [1]. It took us about
> >> five years to write all man pages, including conversion of the old man
> >> pages.
> > 
> > $ cd /opt/mports/macports-base/doc
> > $ wc -l *.txt *.1 *.5 *.7
> > 
> > That would make it about nine lines per day.>
> > BTW, was it mdoc(7) or man(7)?
> 
> mdoc(7).
> 
> You seem to count both the input and the output files. Also, some of the
> old files, such as portfile.7 and porthier.7, still have not been
> converted. The real progress was even slower than that.
> 
> > How did you write the mdoc(7) manpages then?
> 
> Those had been written before I even joined the project. Apparently
> someone wrote the original man pages, then left the project and no
> longer contributed. Nobody updated the man pages because they were
> written in a format nobody wanted to learn.

Are you sure _that_ was the reason? It's pretty damn trivial to
update an _existing_ mdoc(7) manpage (such as: add an option, etc).

> Therefore the plan came up
> to replace that format with something else that is easier to pick up for
> new contributors.

Honest question: how much did people start contributing documentation,
after the switch from mdoc(7) to asciidoc?

> Although there was already some work to use DocBook XML for the man
> pages, I proposed to use AsciiDoc in the NewHelpSystem. This format was
> already used by other projects to write man pages. Just to name popular
> examples, git and mercurial still use it. I do not think that the HTML
> version of their man pages is missing semantics. I do not think that our
> HTML version [1] is missing semantics, either.

What?

(> [1] https://man.macports.org/port-diagnose.1.html
has almost no content; let's take port.1.html as an example:)

port
[-bcdfknNopqRstuvy] [-D
portdir] [-F cmdfile]
[action] [actionflags]
 [[portname | pseudo-portname
 | port-expressions | port-url]]
  [[@version] [+/-variant ] 
  [option=value ]]

There is _no_ semantics in here. Or what denotes an option here?
Or its (optional) argument? Nothing. This is purely presentational:
"put this in bold, type a bracket here".

> Back then, I did not even know there was a difference between man(7) and
> mdoc(7). And even today, neither looks like a syntax new contributors
> without previous knowledge want to write in my opinion.

I do. I am willing to write it.
Please just say you simply don't want it.

> I see you are strongly attached to mdoc(7), but take a look around:
> except some *BSD projects nobody uses mdoc(7) to write man pages.

All of OpenBSD, FreeBSD and NetBSD, in fact. And MacOS of course.
(I love how you try to make it sound as something negligible.
Remember how everyone except some BSD projects was using ssh.com
before OpenSSH was started in some BSD project?)

$ vi `man -w ls`

> Most
> projects use lightweight markup languages such as AsciiDoc, Markdown, or
> restructuredText, or even pod2man for this task.

No, most project don't. and even if they did,
is that a reason to do it too?

> $ find /opt/local/share/man | wc -l
>15591
> $ find /opt/local/share/man -exec zgrep -l '^.Dt' {} + | w

Re: Migrating the guide to AsciiDoc

[Jan Stary]

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, 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. port-diagnose.1; read it, line by line.
> >> Note the 2008 workarounds to debian bugs.
> >> Note the 2009 workarouns to GNU roff.
> >> Note the pointless low-level roff(7) tweaks.
> > 
> > 
> > https://lists.gnu.org/archive/html/groff/2014-02/msg00109.html
> 
> I do not care about the raw input,

(apparently)

> I read man pages in rendered form with man(1).

I thought we are talking about _producing_ the manpages.
That _is_ the raw input (in whichever markup language).

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

You don't care that a 2008 workaround to a Debian bug
is included in every manpage of a MacPorts package system?
Or a 2009 workaround to a Solaris bug in GNU roff?
Don't you find it a prime example of clutter
that simply does not belong there?

> >> Then read the port-diagnose.1 below, written in mdoc(7).
> >> Which one is cleaner, simpler, more readable, more writable, shorter?
> >>
> >> I offer to rewrite them.
> 
> We moved away from mdoc(7) with the NewHelpSystem [1]. It took us about
> five years to write all man pages, including conversion of the old man
> pages.

$ cd /opt/mports/macports-base/doc
$ wc -l *.txt *.1 *.5 *.7

That would make it about nine lines per day.

BTW, was it mdoc(7) or man(7)?

> >> .Dd April 23, 2018
> >> .Dt PORT-DIAGNOSE 1
> >> .Os
> >> .Sh NAME
> >> .Nm port diagnose
> >> .Nd detects common issues with macports
> >> .Sh SYNOPSIS
> >> .Nm port
> >> .Ic diagnose
> >> .Op Fl -quiet
> >> .Sh DESCRIPTION
> >> .Nm port
> >> .Ic diagnose
> >> will check a list of common issues that could
> >> affect the user of MacPorts in one way or another.
> >> If any issues are found, a warning will be
> >> shown to the user included with a possible fix.
> >> .Pp
> >> With the
> >> .Fl -quiet
> >> option, only warnings and errors are displayed.
> >> .Sh SEE ALSO
> >> .Xr port 1
> >> .Sh AUTHORS
> >> .An Kyle Sammons Aq Mt ksamm...@macports.org
> 
> I really cannot see the benefits of this. To me, writing this by hand
> would be even more terrible than writing XML.

> I have no idea what any of
> these two-character commands mean.

How did you write the mdoc(7) manpages then?

> This syntax is far from being intuitive.

Nm  name
Op Fl   optional flag
Ar  argument
Sh  section header

Seriously, it takes about 15 minutes to get going.
http://mandoc.bsd.lv/man/mdoc.7.html


The main point is that mdoc(7) allows for constructs like

.Op Fl f Ar arg

meaning

there is an optional 'f' flag
which takes an 'arg' argument

as opposed to

switch to italics, type a bracket, a dash, "f",
then switch to boldface and type "arg"

in the physical roff markup of man(7).
Similarly for other constructs like cross-references,
filenames, author emails, env variables, etc.

> Yes, it seems to be possible to encode more semantics than with
> AsciiDoc. But do we really need that in a man page?

Yes; you can _search_ by those semantics then, such as by
a filename mentioned in FILES; or by AUTHORS; you get html manpages
for free and can do things like http://man.openbsd.org/ls#d
i.e. link to individual options and sections.

> But do we really need that in a man page?

Do we need 2008 workarounds to Debian bugs in a manpage?

> At least for terminal output, almost everything of that
> is lost with rendering anyway.

No it's not. And terminal output is not the only:
you get html, pdf, ps, even mandoc from it, without docbook;
mdoc(7) is a language that has been in UNIX for decades
and is very well supported everywhere.

> If you really care that much about the non-rendered file on disk,
> I would recommend to rewrite the DocBook XSLT to use the mdoc(7) format
> or contribute a native backend for it to AsciiDoctor.

I'm not touching DocBook, obviously.
My main motivation here is to get rid of it entirely.
And asciidoc has no way of even expressing the semantics.

Again, I am willing to do the work.
Please let me know if there is no interest.

Jan

Re: Migrating the guide to AsciiDoc

[Jan Stary]

On Apr 23 10:09:06, mo...@macports.org wrote:
> On 23 April 2018 at 09:42, Jan Stary <h...@stare.cz> 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 guide from xml (docbook) to asciidoc:
> >>
> >> https://github.com/macports/macports-guide/tree/master/guide/adoc
> >>
> >> This was initially explored by Aljaž and gives quite nice results
> >> out-of-the-box,
> >
> > Thank you. Any format is better than xml,
> > and any tool is better than docbook.
> >
> >> but there are still some issues with conversion that
> >> will have to be addressed either by fixing docbookrx itself or
> >> manually.
> >>
> >> If anyone is willing to help in the process, your help will be appreciated.
> >
> > Is asciidoc what the user is upposed to read directly, as in e.g.
> > https://github.com/macports/macports-guide/blob/master/guide/adoc/installing.adoc
> 
> No.
> 
> > or is that considered an "internal" format to be ultimately converted
> > to html and put on a web page such as https://guide.macports.org/
> > where the user will read it?
> 
> Yes. The guide should be converted to HTML (and ideally also PDF).

Can the conversion to PDF happen without docbook?
(i.e. can asciidoc(tor|*) produce pdf itself?)

> The fact that GitHub can interpret the format is just a bonus that
> might also help developers when editing the page, but it's not meant
> to be the final product.

> > The Plan section says
> >
> >  First convert .adoc files back to docbook .xml format
> >  and use the existing toolchain to generate the html pages
> >  (to avoid further delays).
> >
> > That makes no sense to me: why convert back?
> > Cannot html pages be generated from adoc directly?
> > (And if so, why not use the original xml?)
> 
> Yes, one can directly generate html. But we need to figure out how to
> do page splitting etc. This is why Rainer suggested to temporarily go
> through docbook again. This is not absolutely set in stone though, if
> someone polishes the process to sufficient details to allow
> straightforwand conversion, we can use that one.
> 
> (I believe the main reason why going through docbook was considered
> was because none of us took the time to figure out how to make a
> multi-page html from asciidoc directly.)

Apparently, it still cannot do multi-page output:
https://github.com/asciidoctor/asciidoctor/issues/626
https://github.com/openSUSE/asciidoctor/issues/9

Which means this does not get rid of docbook:
it adds to the top of it (or the bottom of it).

Jan

Re: Migrating the guide to AsciiDoc

[Jan Stary]

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 talking about content, but markup).
> > 
> > Look at e.g. port-diagnose.1; read it, line by line.
> > Note the 2008 workarounds to debian bugs.
> > Note the 2009 workarouns to GNU roff.
> > Note the pointless low-level roff(7) tweaks.
> 
> https://lists.gnu.org/archive/html/groff/2014-02/msg00109.html
> 

Also, having manpages written in asciidoc means we need
the abominable docbook to actually produce the man(7) pages, right?
At least that's what it says at the end of install:

* Warning: Using pre-generated man pages only.
* asciidoc, xsltproc (port libxslt) and docbook-xsl are required
  to generate man pages from source.

Jan


> > Then read the port-diagnose.1 below, written in mdoc(7).
> > Which one is cleaner, simpler, more readable, more writable, shorter?
> > 
> > I offer to rewrite them.
> > 
> > Jan
> > 
> > 
> > .Dd April 23, 2018
> > .Dt PORT-DIAGNOSE 1
> > .Os
> > .Sh NAME
> > .Nm port diagnose
> > .Nd detects common issues with macports
> > .Sh SYNOPSIS
> > .Nm port
> > .Ic diagnose
> > .Op Fl -quiet
> > .Sh DESCRIPTION
> > .Nm port
> > .Ic diagnose
> > will check a list of common issues that could
> > affect the user of MacPorts in one way or another.
> > If any issues are found, a warning will be
> > shown to the user included with a possible fix.
> > .Pp
> > With the
> > .Fl -quiet
> > option, only warnings and errors are displayed.
> > .Sh SEE ALSO
> > .Xr port 1
> > .Sh AUTHORS
> > .An Kyle Sammons Aq Mt ksamm...@macports.org

Re: Migrating the guide to AsciiDoc

[Jan Stary]

> > 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. port-diagnose.1; read it, line by line.
> Note the 2008 workarounds to debian bugs.
> Note the 2009 workarouns to GNU roff.
> Note the pointless low-level roff(7) tweaks.


https://lists.gnu.org/archive/html/groff/2014-02/msg00109.html


> Then read the port-diagnose.1 below, written in mdoc(7).
> Which one is cleaner, simpler, more readable, more writable, shorter?
> 
> I offer to rewrite them.
> 
>   Jan
> 
> 
> .Dd April 23, 2018
> .Dt PORT-DIAGNOSE 1
> .Os
> .Sh NAME
> .Nm port diagnose
> .Nd detects common issues with macports
> .Sh SYNOPSIS
> .Nm port
> .Ic diagnose
> .Op Fl -quiet
> .Sh DESCRIPTION
> .Nm port
> .Ic diagnose
> will check a list of common issues that could
> affect the user of MacPorts in one way or another.
> If any issues are found, a warning will be
> shown to the user included with a possible fix.
> .Pp
> With the
> .Fl -quiet
> option, only warnings and errors are displayed.
> .Sh SEE ALSO
> .Xr port 1
> .Sh AUTHORS
> .An Kyle Sammons Aq Mt ksamm...@macports.org

Re: Migrating the guide to AsciiDoc

[Jan Stary]

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 gives quite nice results
> out-of-the-box,

Thank you. Any format is better than xml,
and any tool is better than docbook.

> but there are still some issues with conversion that
> will have to be addressed either by fixing docbookrx itself or
> manually.
> 
> If anyone is willing to help in the process, your help will be appreciated.

Is asciidoc what the user is upposed to read directly, as in e.g.
https://github.com/macports/macports-guide/blob/master/guide/adoc/installing.adoc
or is that considered an "internal" format to be ultimately converted
to html and put on a web page such as https://guide.macports.org/
where the user will read it?

On Apr 22 11:39:23, rai...@macports.org wrote:
> AsciiDoc is both the name of the format and also the name of the
> original reference implementation in Python, but development on that
> ceased a few years ago. AsciiDoctor is an alternative implementation in
> Ruby and actively being developed.

Which one produced the current adoc from of the xml guide?


The Plan section says

 First convert .adoc files back to docbook .xml format
 and use the existing toolchain to generate the html pages
 (to avoid further delays).

That makes no sense to me: why convert back?
Cannot html pages be generated from adoc directly?
(And if so, why not use the original xml?)

> 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. port-diagnose.1; read it, line by line.
Note the 2008 workarounds to debian bugs.
Note the 2009 workarouns to GNU roff.
Note the pointless low-level roff(7) tweaks.

Then read the port-diagnose.1 below, written in mdoc(7).
Which one is cleaner, simpler, more readable, more writable, shorter?

I offer to rewrite them.

Jan


.Dd April 23, 2018
.Dt PORT-DIAGNOSE 1
.Os
.Sh NAME
.Nm port diagnose
.Nd detects common issues with macports
.Sh SYNOPSIS
.Nm port
.Ic diagnose
.Op Fl -quiet
.Sh DESCRIPTION
.Nm port
.Ic diagnose
will check a list of common issues that could
affect the user of MacPorts in one way or another.
If any issues are found, a warning will be
shown to the user included with a possible fix.
.Pp
With the
.Fl -quiet
option, only warnings and errors are displayed.
.Sh SEE ALSO
.Xr port 1
.Sh AUTHORS
.An Kyle Sammons Aq Mt ksamm...@macports.org

Re: Wrong time on Travis with macOS 10.13?

[Jan Stary]

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: Wrong time on Travis with macOS 10.13?

[Jan Stary]

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 know how to check if this is indeed the case and report it
> to Travis?
> 
> (There was definitely another report of the same issue recently on one
> of our PRs, I cannot find it right now though.)

Yes, same here:
https://github.com/macports/macports-ports/pull/1626

Jan

> 
> 
> --->  Patching Config_heavy.pl: s/-arch [a-z0-9_]+//g
> DEBUG: Executing reinplace: /usr/bin/sed -E {s/-arch [a-z0-9_]+//g}
>  >@file11
> DEBUG: euid/egid changed to: 0/0
> DEBUG: chowned 
> /opt/local/var/macports/build/_Users_travis_build_macports_macports-ports_lang_perl5/perl5.26/work/perl-5.26.2/lib/Config_heavy.pl
> to macports
> DEBUG: euid/egid changed to: 502/501
> DEBUG: euid/egid changed to: 0/0
> DEBUG: setting attributes on
> /opt/local/var/macports/build/_Users_travis_build_macports_macports-ports_lang_perl5/perl5.26/work/perl-5.26.2/lib/Config_heavy.pl
> DEBUG: euid/egid changed to: 502/501
> DEBUG: Privilege de-escalation not attempted as not running as root.
> DEBUG: Portfile is from the future - check date and time of your system
> while executing
> "open_statefile"
> (procedure "target_run" line 14)
> invoked from within
> "{*}$handler $ditem"
> Error: Portfile is from the future - check date and time of your system
> Error: See 
> /opt/local/var/macports/logs/_Users_travis_build_macports_macports-ports_lang_perl5/perl5.26/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port perl5.26 failed
> Build of dependency 'perl5.26' with variants '' failed, aborting.

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

[Jan Stary]

On Apr 20 09:50:50, jerem...@macports.org wrote:
> 
> > On Apr 18, 2018, at 21:17, Ryan Schmidt <ryandes...@macports.org> wrote:
> > 
> > 
> > On Apr 18, 2018, at 06:47, Jan Stary wrote:
> > 
> >>>> https://github.com/macports/macports-ports/commit/607997ade7f0bd99c7a7297d7a49ae79442b705f
> >> 
> >>>> aqua/qt5/Portfile| 2 +-
> >>>> aqua/qt55/Portfile   | 2 +-
> >>>> aqua/qt56/Portfile   | 2 +-
> >>>> aqua/qt57/Portfile   | 2 +-
> >>>> aqua/qt58/Portfile   | 2 +-
> >>>> aqua/qt59/Portfile   | 2 +-
> >>>> databases/msodbcsql/Portfile | 2 +-
> >>>> devel/cargo/Portfile | 2 +-
> >>>> devel/fbthrift/Portfile  | 2 +-
> >>>> devel/folly/Portfile | 2 +-
> >>>> devel/grpc/Portfile  | 2 +-
> >>>> devel/lua-luasec/Portfile| 2 +-
> >>>> devel/qca/Portfile   | 2 +-
> >>>> devel/wangle/Portfile| 2 +-
> >>>> finance/bitcoin/Portfile | 2 +-
> >>>> math/octave/Portfile | 2 +-
> >>>> net/libstrophe/Portfile  | 2 +-
> >>>> net/mosquitto/Portfile   | 2 +-
> >>>> net/profanity/Portfile   | 2 +-
> >>>> net/qpid-proton/Portfile | 2 +-
> >>>> net/snort/Portfile   | 2 +-
> >>>> science/ldas-tools-framecpp/Portfile | 2 +-
> >>>> textproc/html-xml-utils/Portfile | 2 +-
> >>>> www/phantomjs/Portfile   | 2 +-
> >>>> 24 files changed, 24 insertions(+), 24 deletions(-)
> >> 
> >> Thank you!
> >> 
> >> If I am reading the syntax right, path: as opposed to lib: means
> >> that only lib/libssl.dylib (relative path) under $prefix will be used.
> >> https://guide.macports.org/chunked/reference.dependencies.html
> >> Is that intended?
> > 
> > Yes, that is correct and intentional.
> > 
> > 
> >> How was this "misc" subset selected? Was it simply the missing ones?
> >> It seems that now all ports use this, with the following exceptions:
> >> 
> >>net/qpid-proton (+openssl)  port:openssl
> >>python/py-grpcio/Portfile:  port:openssl
> >> 
> >> Where these intentionally left out?
> > 
> > They weren't left out. qpid-proton was changed, but then subsequently 
> > reverted, for possibly invalid reasons:
> > 
> > https://github.com/macports/macports-ports/pull/1531#issuecomment-379178034
> > 
> > py-grpcio was not included in Jeremy's commit because it didn't exist at 
> > the time; it was added 3 days later:
> > 
> > https://github.com/macports/macports-ports/pull/1536
> > 
> > 
> >> Also, the following require a specific version:
> >> 
> >>devel/libpdel   lib:libssl.0.9:openssl
> >>mail/qpopperlib:libssl.0:openssl
> >>mail/sylpheed-devel (+ssl)  lib:libssl.0.9:openssl
> >>net/jabber  lib:libssl.0.9:openssl
> >>www/links1 (+ssl)   lib:libssl.0.9:openssl
> >> 
> >> Were these also intentinally left out? (And should
> >> ports that require openssl 0.9 be killed with fire?)
> > 
> > It seems unlikely that those ports require openssl 0.9 specifically, but 
> > rather that those ports have not been updated since we started recommending 
> > the use of port: dependencies instead of lib: dependencies a decade or more 
> > ago.
> 
> Yeah, the intention was just to update all of them consistently.  It's true 
> that some of those ports might not work with libressl, but IMO it would be 
> better to have a report of the build failure that we can act on to fix than 
> to have port err out because we missed something.

Absolutely.

> I haven't personally tried every single port (since actually some of them 
> have dependencies that fail to build on my system which I haven't worked 
> through)
> Thanks for pointing these out.  I'll take a look through them.

I removed them in https://github.com/macports/macports-ports/pull/1602
but Joshua brought qpopper, jabber and links1 back, with FreeBSD patches
(see recent commits).

I believe they should all go, because they are simply obsolete.
For example, we go to web.archive.org now (as a $hompage!)
to get the nonexistent content of www.eudora.com/products/unsupported/qpopper/ 
NB: "web.archive.org", "/unsupported/". Why do we want this?


> grep doesn't find everything unless you know what you're looking for ;)

The above is indeed a result of a naive grep for "libssl.0"

Thanks for looking into this.

Jan

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

[Jan Stary]

> > 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 yet!), but if a human (like me!) could manually invoke it on
> > a few ports at a time when they had free time, it might help to
> > clear out the backlog.
> 
> I'm a afraid this requires human labor that cannot be much helped
> by any automation. The gist of it is to work on the port itself,
> motivatad by need and/or love. The only way for any of
> https://trac.macports.org/query?status=new=submission
> to become an actual port is that _some_guy_ cares enough
> to _have_that_ in MP to turn it into a port, test etc,
> and prefrably create a PR to be merged. Whether this guy
> downloads the attached Portfile from a trac ticket or
> clones somebody's branch is a technicality compared to that.
> 
> For example, if anyone cared about dbxml
> https://trac.macports.org/ticket/24429
> we would have a dbxml port by now. The reason we don't
> is not that it's a trac submission, instead of a PR.

Come to think of it, automatically turning those trac port submissions
that have been rotting there for years into github PRs now
would only make it look like they are not rotting for years.

For example, https://trac.macports.org/ticket/22255
has been dead for eight years. But turn it into a PR,
and hey, there's a PR opened today!
But nothing has changed, really.

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

[Jan Stary]

(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 oh so many other projects.

> Part of this is because it is significantly easier to handle new ports
> and submitted patches that come in via pull requests on github than in
> trac tickets.
> 
> 1. You can comment on individual lines in a PR, which is really nice
>for code review purposes, and easily track which comments
>have been addressed.
> 2. When something arrives via PR, it is automatically put through the
>CI system, which, although flawed, provides reasonable assurance
>things build if it works.
> 3. It's easy to invoke (even with automation) appropriate people to
>look at a PR.
> 4. Merging the PR when it is ready is easy.

Also, it is easy to merge _other_ changes into the proposed PR,
including the master changes newer than the PR (rebase).

> I'm wondering if we should therefore encourage people to submit github
> PRs if they have working patches (or are submitting new ports) rather
> than trac tickets. (Not suggesting we should _prevent_ the latter,
> just that maybe we should explicitly encourage the former.)

I have switched to exclusively use github months ago.
I only deal with TRAC tickets if I have to; similarly,
I create github issues, not TRAC tickets.

> 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 yet!), but if a human (like me!) could manually invoke it on
> a few ports at a time when they had free time, it might help to
> clear out the backlog.

I'm a afraid this requires human labor that cannot be much helped
by any automation. The gist of it is to work on the port itself,
motivatad by need and/or love. The only way for any of
https://trac.macports.org/query?status=new=submission
to become an actual port is that _some_guy_ cares enough
to _have_that_ in MP to turn it into a port, test etc,
and prefrably create a PR to be merged. Whether this guy
downloads the attached Portfile from a trac ticket or
clones somebody's branch is a technicality compared to that.

For example, if anyone cared about dbxml
https://trac.macports.org/ticket/24429
we would have a dbxml port by now. The reason we don't
is not that it's a trac submission, instead of a PR.

On Apr 04 06:15:48, ryandes...@macports.org wrote:
> In my experience, port submissions, especially by new contributors, require 
> more cleanup than port updates. It's not uncommon for a submission to have 
> half a dozen or more things wrong with it.

Speaking as a user, I can attest to the fact that my submissions
usually need a fair amount of cleaning before being ready to merge.

> So you could either develop an automated system for copying a Portfile 
> submitted on Trac into a pull request -- and then have to check out that PR 
> branch into your git clone, fix all the problems, amend the commit, force 
> push it -- or you could just download the Portfile from Trac yourself, put it 
> into your git clone, fix it, commit it, and either send a PR or push to 
> master. And either way, you're going to want to make sure it builds locally 
> first. It doesn't seem like the former saves you that much time over the 
> latter, plus of course you've had to spend all that time developing the 
> automated Trac-to-PR system.

Exactly. Turning the trac into a PR _before_ the actual work is done
saves nothing.

On Apr 04 14:18:42, mo...@macports.org wrote:
> The time saved comes from the author doing the cleanup based on
> feedback (which you can leave while waiting for a bus or while going
> for a walk :) vs. one of us having to do all the changes, fiddling
> with branches.

That has nothing to do with trac vs PR:
the author can get feedback on the PR too (I do).

> Alternatively / in addition, what we currently lack is a page
> explaining how random unskilled users willing to spend some time
> helping us could do. If we were able to communicate clearly what such
> users can do when they just feel like helping us, this could be one of
> the suitable tasks.

That is imho a good way to get involved with MP.
The motivation has to come from within though:
nobody's gonna fix ports they neither use nor care about as a first step.

For example, I like audio. If there is a a problem with an audio port
that does something interesting, I will look at it. I will not do the
same for graphics, because I simply don't care. The random unskilled
user will need _some_ motivation beside "I feel like helping".

> checksums after github switch their algorithm etc.)

That's a good example of what I mean: what could 

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

[Jan Stary]

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 +-
> >  aqua/qt57/Portfile   | 2 +-
> >  aqua/qt58/Portfile   | 2 +-
> >  aqua/qt59/Portfile   | 2 +-
> >  databases/msodbcsql/Portfile | 2 +-
> >  devel/cargo/Portfile | 2 +-
> >  devel/fbthrift/Portfile  | 2 +-
> >  devel/folly/Portfile | 2 +-
> >  devel/grpc/Portfile  | 2 +-
> >  devel/lua-luasec/Portfile| 2 +-
> >  devel/qca/Portfile   | 2 +-
> >  devel/wangle/Portfile| 2 +-
> >  finance/bitcoin/Portfile | 2 +-
> >  math/octave/Portfile | 2 +-
> >  net/libstrophe/Portfile  | 2 +-
> >  net/mosquitto/Portfile   | 2 +-
> >  net/profanity/Portfile   | 2 +-
> >  net/qpid-proton/Portfile | 2 +-
> >  net/snort/Portfile   | 2 +-
> >  science/ldas-tools-framecpp/Portfile | 2 +-
> >  textproc/html-xml-utils/Portfile | 2 +-
> >  www/phantomjs/Portfile   | 2 +-
> >  24 files changed, 24 insertions(+), 24 deletions(-)

Thank you!

If I am reading the syntax right, path: as opposed to lib: means
that only lib/libssl.dylib (relative path) under $prefix will be used.
https://guide.macports.org/chunked/reference.dependencies.html
Is that intended?

How was this "misc" subset selected? Was it simply the missing ones?
It seems that now all ports use this, with the following exceptions:

net/qpid-proton (+openssl)  port:openssl
python/py-grpcio/Portfile:  port:openssl

Where these intentionally left out?


Also, the following require a specific version:

devel/libpdel   lib:libssl.0.9:openssl
mail/qpopperlib:libssl.0:openssl
mail/sylpheed-devel (+ssl)  lib:libssl.0.9:openssl
net/jabber  lib:libssl.0.9:openssl
www/links1 (+ssl)   lib:libssl.0.9:openssl

Were these also intentinally left out? (And should
ports that require openssl 0.9 be killed with fire?)

Jan

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

[Jan Stary]

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 of macOS were stuck with /usr/bin/git.

What versions of MacOS are "stuck" with what version of git?
What specific problems does it lead to?

> That does not seem to be a useful default to me,

Why?

> therefore it made sense
> to me to always use the latest version from ${prefix}/bin/git.

This requiring of the latest version of everything for anything
is a desease. I have a /usr/bin/git that works just fine.
(I also have a /usr/bin/python that works just fine, etc.)
Don't make me install a newer version because it is newer.

Re: port sync performance

[Jan Stary]

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 anyone know why this is? Is git doing something smarter? Is
> it just that "git pull" gets the benefit of github's CDN?
> 2) Would it be interesting to offer people the ability to use git for
> synchronization instead of rsync?
> 
> Perry
> -- 
> Perry E. Metzger  pmetz...@macports.org

Re: Relax port lint rule for patchfile naming

[Jan Stary]

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. No extra keyword/option for it.
(files/ is extra files to be added to WRKSRC; no keyword for it).

I believe it is simpler to what MP has now:
patchfiles need to be declared such with 'patchfiles',
and extra files need to be created _in_ the Portfile
(as e.g. textproc/mandoc does for configure.local).

Jan

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

[Jan Stary]

> > > 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 in the environment, which is what MacPorts
> > usually does.
> > 
> > $ export CC=foo
> > $ printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -
> > cc
> 
> That's on purpose: compile mandoc with
> whatever the local make(1) thinks $(CC) is.
> 
>   # You can manually override the compiler to be used.
>   # But that's rarely useful because ./configure asks your make(1)
>   # which compiler to use, and that answer will hardly be wrong.
> 
> mandoc's ./configure does not take CC from the environment.

In fact, configure says

  # --- default settings -
  # Initialize all variables here,
  # such that nothing can leak in from the environment.

> It determines it as above. You can override it of course,
> by setting CC=... in configure.local

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

[Jan Stary]

On Feb 28 08:03:31, ken.cunningham.web...@gmail.com wrote:
> The basic principle is that a build of a port on any darwin_N system
> anywhere will be identical to every other build on that darwin version
> on all other machines.

Does that mean that MP will set the same configure.cc for mandoc
on e.g. every Darwin 17.4.0? What of I have two of those,
with different Xcode on each?

Can you please indly point me to the place in MP base
where the value of configure.cc get decided?

> To do that, but build environment (and the runtime environment)
> need to be fully pre-defined.

As long as it's possible to have different Xcode versions on one darwin_N,
in what sense can the build environment be "fully pre-defined"? For example,
https://trac.macports.org/wiki/UsingTheRightCompiler says:

 For example, with Xcode 4.2 and later, CC is set to
 "/usr/bin/clang" so that there is no ambiguity.

"/usr/bin/clang" will be a different compiler with Xcode 4.2
and with Xcode 4.N


> See here: <https://reproducible-builds.org/> for more info,
> and why this is what we need. I hope you can come to accept
> some of these MacPorts policies

This makes sense, unlike what's being said at
https://trac.macports.org/wiki/UsingTheRightCompiler

Are these policies clearly described somewhere?


On Feb 28 10:20:56, ryandes...@macports.org wrote:
> >> I had my MacPorts configured to error out if `cc` is used
> >> using the method described at  UsingTheRightCompiler#testing.
> > 
> > Why would you do that?
> 
> To detect ports that do not use a specific compiler.
> MacPorts policy is that all ports shall use a specific compiler.

Is this policy described somewhere?

> > BTW, this is how configure.cc is described in the guide:
> > 
> >  configure.cc
> >Set CC compiler flags for selecting a C compiler.
> >Default: ???
> >Example:
> > 
> > "compiler flags for selecting a compiler"?
> 
> Rainer has 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, 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 -`
> > 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 in the environment, which is what MacPorts
> usually does.
> 
> $ export CC=foo
> $ printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -
> cc

That's on purpose: compile mandoc with
whatever the local make(1) thinks $(CC) is.

  # You can manually override the compiler to be used.
  # But that's rarely useful because ./configure asks your make(1)
  # which compiler to use, and that answer will hardly be wrong.

mandoc's ./configure does not take CC from the environment.
It determines it as above. You can override it of course,
by setting CC=... in configure.local

That seems to be the issue here: MP _wants_to_ tell mandoc what compiler
to use, but setting CC in the environment does not do it. Hence the CC
dance that we have in the Portfile now. Is this understanding correct?


> > It's true that /usr/bin/cc is a symlink to some suitable default compiler.
> > So call that, thus calling a suitable default compiler, _by_default_.
> 
> You are already assuming that 'cc' is /usr/bin/cc. If anyone has a
> /opt/local/bin/cc, it might be a different compiler.

If it is actually a C compiler, it will compile mandoc just fine.
If it is instead a shell script that errors out with "you must not run
this as your compiler", then it will not of course.

> In general, we do not want to use what the user selected as their
> preferred compiler, but what MacPorts selected to compile this port.

Is this strict policy clearly described somewhere, including the
rationale? Not in https://trac.macports.org/wiki/UsingTheRightCompiler

> > Yes, there are ports that do need to call some particular compiler,
> > but it's those ports' job then to find and use that.

> >> I had my MacPorts configured to error out if `cc` is used
> >> using the method described at  UsingTheRightCompiler#testing.
> > 
> > Why would you do that?
> >
> > Mandoc is extremely portable. I have yet to see a UNIX system where
> > it does not build. Except here: of cou

Re: LibreSSL and OpenSSL and *SSL

[Jan Stary]

> 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 working on it.

https://marc.info/?l=openbsd-misc=151974573718360=2


> Now we get to the real thing: LibreSSL is better.
> 
> For those who actually care: please do watch the original
> talks and slides about why LibreSSL even exists:
> 
> https://www.youtube.com/watch?v=GnBbhXBDmwU
> https://www.openbsd.org/papers/bsdcan14-libressl/
> 
> https://www.youtube.com/watch?v=WFMYeMNCcSY
> https://www.openbsd.org/papers/eurobsdcon2014-libressl.html
> 
> Yes, that's almost four years ago. So how much of the
> attrocities mentioned in the above have been fixed?
> Does it still use its own OPENSSL_malloc() that never frees?
> Does it still use its own OPENSSL_strfoo() that is almost,
> but not quite, indetical to the usual, well defined strfoo(3)?
> Has the depth of the #ifdef/#ifndef maze dropped from 17?
> Are the security vulnerabilities still rotting in the bug DB for years?
> Is it still impossible to enter the codebase from outside
> without untangling it for weeks?
> 
> The LibreSSL developers state explicitly that heartbleed
> was not why they started their fork. It was things like these.
> https://www.tedunangst.com/flak/post/origins-of-libressl

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

[Jan Stary]

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 of a port crane is what MP is missing.

Re: LibreSSL and OpenSSL and *SSL

[Jan Stary]

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 audio files, and for that it might need
> to make a secure connection. That's a very basic thing which should
> not depend on this or that version of this or that implementation.
> 
> The noncompatibility is tests for OPENSSL_VERSION_NUMBER<0x10002000L etc
> that already assume that OPENSSL is the only implementation. The patch
> is trivial: add defined(LIBRESSL_VERSION_NUMBER) in 11 places.
> 
> Obviously, I have not studied all the ports that depend on OpenSSL now,
> and I don't doubt that many of them depend on *SSL in a nontrvial way.
> But I would be willing to bet that in a lot of cases, the noncompatibilty
> between versions is similarly artificial: upstream simply did not take
> LibreSSL into consideration (yet).

Example: www/lynx

The latest release (which is the release in MP) is 2.8.8.
It was released in February 2014, before LibreSSL existed.

Does it "support" LibreSSL? Yes it does: with LibreSSL installed
and with "depends_lib-append path:lib/libssl.dylib:openssl" it will
compile against the installed LibreSSL, and works just fine.

/opt/local/bin/lynx:
/opt/local/lib/libidn.11.dylib 
/opt/local/lib/libncurses.6.dylib
/opt/local/lib/libssl.43.dylib
/opt/local/lib/libcrypto.41.dylib
/usr/lib/libSystem.B.dylib
/opt/local/lib/libintl.8.dylib
/opt/local/lib/libiconv.2.dylib

Now, this is a web browser. How much more involved can SSL usage get?
Yet it just works. I mean this as an example of showing that the
OpenSSL/LibreSSL "conflict" is largely avoidable.

Jan

Re: LibreSSL and OpenSSL and *SSL

[Jan Stary]

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   890800 Dec 1 20:39 /usr/lib/libssl.43.dylib

Is this the way MP could install both as well?
Tweak the names so that one is distinguishable from the other?

Jan

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: LibreSSL and OpenSSL and *SSL

[Jan Stary]

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  1236144 Jan 19 09:32 /usr/lib/libboringssl.dylib
> -rwxr-xr-x  1 root  wheel   392912 Dec1 20:39 
> /usr/lib/libssl.0.9.7.dylib
> -rwxr-xr-x  1 root  wheel   630144 Dec1 20:38 
> /usr/lib/libssl.0.9.8.dylib
> -rw-r--r--  1 root  wheel   947104 Dec1 20:38 /usr/lib/libssl.35.dylib
> -rw-r--r--  1 root  wheel   890800 Dec1 20:39 /usr/lib/libssl.43.dylib
> lrwxr-xr-x  1 root  wheel 15 Dec 10 11:39 /usr/lib/libssl.dylib -> 
> libssl.35.dylib
> 
> hans@fitbook:~$ ls -l /usr/lib/*tls*
> -rwxr-xr-x  1 root  wheel  287408 Dec  1 20:39 /usr/lib/libcoretls.dylib
> -rwxr-xr-x  1 root  wheel   60464 Dec  1 20:39 
> /usr/lib/libcoretls_cfhelpers.dylib
> -rw-r--r--  1 root  wheel  159264 Dec  1 20:39 /usr/lib/libtls.15.dylib
> -rw-r--r--  1 root  wheel   92032 Dec  1 20:39 /usr/lib/libtls.6.dylib
> lrwxr-xr-x  1 root  wheel  14 Dec 10 11:39 /usr/lib/libtls.dylib -> 
> libtls.6.dylib
> 
> hans@fitbook:~$ ls -l /usr/lib/*crypto*
> -rwxr-xr-x  1 root  wheel13520 Jan 19 09:32 /usr/lib/libapple_crypto.dylib
> -rwxr-xr-x  1 root  wheel  2023584 Dec1 20:39 
> /usr/lib/libcrypto.0.9.7.dylib
> -rwxr-xr-x  1 root  wheel  2599488 Dec1 20:38 
> /usr/lib/libcrypto.0.9.8.dylib
> -rw-r--r--  1 root  wheel  4228016 Dec1 20:39 
> /usr/lib/libcrypto.35.dylib
> -rw-r--r--  1 root  wheel  4274800 Dec1 20:39 
> /usr/lib/libcrypto.41.dylib
> lrwxr-xr-x  1 root  wheel 18 Dec 10 11:39 /usr/lib/libcrypto.dylib -> 
> libcrypto.35.dylib
> lrwxr-xr-x  1 root  wheel 54 Dec 10 11:39 /usr/lib/libk5crypto.dylib -> 
> /System/Library/Frameworks/Kerberos.framework/Kerberos
> 
> 
> The default SSL implementation is /usr/lib/libssl.dylib -> libssl.35.dylib,
> the base MacOS binaries are compiled against (wait for it) LibreSSL,
> 
>   hans@fitbook:~$ /usr/bin/curl --version
>   curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20
>   zlib/1.2.11 nghttp2/1.24.0
>   Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>   pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
>   Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
>   SSL libz HTTP2 UnixSockets HTTPS-proxy 
> 

Also,

  $ /usr/bin/openssl 
  OpenSSL> version
  LibreSSL 2.2.7


> and if you link with -lssl, you are using LibreSSL:
> 
>   hans@fitbook$ cc -o prog prog.c -lssl
>   hans@fitbook$ otool -L ./prog
>   ./prog:
> /usr/lib/libssl.35.dylib (compatibility version 36.0.0, current version 
> 36.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1252.0.0)
> 
> 
> Let me say it again:
> MacOS _has_already_moved_ to LibreSSL as the default.

The adoption seems to have started no later than with 10.11.4
https://eclecticlight.co/2016/03/23/the-tls-mess-in-os-x-el-capitan/
(The latest I have before this 10.13.2 is 10.6.8)

Jan

LibreSSL and OpenSSL and *SSL

[Jan Stary]

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 crypto/ssl/tls,
including OpenSSL, LibreSSL and (Google's) BoringSSL:

hans@fitbook:~$ ls -l /usr/lib/*ssl*
-rwxr-xr-x  1 root  wheel  1236144 Jan 19 09:32 /usr/lib/libboringssl.dylib
-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   890800 Dec  1 20:39 /usr/lib/libssl.43.dylib
lrwxr-xr-x  1 root  wheel   15 Dec 10 11:39 /usr/lib/libssl.dylib -> 
libssl.35.dylib

hans@fitbook:~$ ls -l /usr/lib/*tls*
-rwxr-xr-x  1 root  wheel  287408 Dec  1 20:39 /usr/lib/libcoretls.dylib
-rwxr-xr-x  1 root  wheel   60464 Dec  1 20:39 
/usr/lib/libcoretls_cfhelpers.dylib
-rw-r--r--  1 root  wheel  159264 Dec  1 20:39 /usr/lib/libtls.15.dylib
-rw-r--r--  1 root  wheel   92032 Dec  1 20:39 /usr/lib/libtls.6.dylib
lrwxr-xr-x  1 root  wheel  14 Dec 10 11:39 /usr/lib/libtls.dylib -> 
libtls.6.dylib

hans@fitbook:~$ ls -l /usr/lib/*crypto*
-rwxr-xr-x  1 root  wheel13520 Jan 19 09:32 /usr/lib/libapple_crypto.dylib
-rwxr-xr-x  1 root  wheel  2023584 Dec  1 20:39 /usr/lib/libcrypto.0.9.7.dylib
-rwxr-xr-x  1 root  wheel  2599488 Dec  1 20:38 /usr/lib/libcrypto.0.9.8.dylib
-rw-r--r--  1 root  wheel  4228016 Dec  1 20:39 /usr/lib/libcrypto.35.dylib
-rw-r--r--  1 root  wheel  4274800 Dec  1 20:39 /usr/lib/libcrypto.41.dylib
lrwxr-xr-x  1 root  wheel   18 Dec 10 11:39 /usr/lib/libcrypto.dylib -> 
libcrypto.35.dylib
lrwxr-xr-x  1 root  wheel   54 Dec 10 11:39 /usr/lib/libk5crypto.dylib -> 
/System/Library/Frameworks/Kerberos.framework/Kerberos


The default SSL implementation is /usr/lib/libssl.dylib -> libssl.35.dylib,
the base MacOS binaries are compiled against (wait for it) LibreSSL,

  hans@fitbook:~$ /usr/bin/curl --version
  curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20
  zlib/1.2.11 nghttp2/1.24.0
  Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
  pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
  Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
  SSL libz HTTP2 UnixSockets HTTPS-proxy 

and if you link with -lssl, you are using LibreSSL:

  hans@fitbook$ cc -o prog prog.c -lssl
  hans@fitbook$ otool -L ./prog
  ./prog:
/usr/lib/libssl.35.dylib (compatibility version 36.0.0, current version 36.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1252.0.0)


Let me say it again:
MacOS _has_already_moved_ to LibreSSL as the default.


(I'll reply to the comments from the original
closed thread in a followup mail.)

Jan

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

[Jan Stary]

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/nomaintainer%40macports.org/problems>. A 
> >> common error is that the homepage 404s out.
> >>
> >> Many of these ports still work install correctly, but have no homepage, no 
> >> homepage can seem to be found, and there is none on archive.org.
> >>
> >> Rather than just have it error out forever, I made this page in the spirit 
> >> of the gentoo page:
> >>
> >> <https://trac.macports.org/wiki/NoHomePage>
> 
> I like the idea of the placeholder wiki page with a detailed explanation.
> 
> >> If that is acceptable, I'd like to use it, or some variation of it, for 
> >> ports like biggersql, for example, to fix some of these errors.
> > 
> > What errors exactly will be "fixed" by that?
> 
> It documents that the upstream homepage is gone for good. That helps to
> understand this software is most likely a dead project.

Yes, but why set up a webpage for that?

> >> PS : Personally, I think asking users for a new homepage, if there is one, 
> >> is better than just deleting the homepage variable requirement in 
> >> Portfiles.
> > 
> > It might be useful to display a message when a port without a manpage is
> > installed, saying something like you put on the page above, but shorter:
> > 
> > $port does not have a manpage.
> > Please let $maintainer know if you know where it is.
> 
> This could add a lot of clutter,

So, two lines saying "this port does not have a homepage"
is "clutter", but an extra non-homepage is not?
How is it not the exact opposite?

> for example if a port is only installed as a dependency.

What difference foes it make whether a port without a homepage
is a dependency of something or not?

> I think the port notes should only contain information
> relevant to its usage.

Why? No realy: why do you think the port's notes should _not_
mention that the port does not have a homepage (yet an extra
non-homepage should be set up to say that)?

Jan

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

[Jan Stary]

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 be 
> > > sure.
> > > 
> > > K
> > 
> > I've been prospecting MacPorts errors reported by repology 
> > . A 
> > common error is that the homepage 404s out.
> > 
> > Many of these ports still work install correctly, but have no homepage, no 
> > homepage can seem to be found, and there is none on archive.org.
> > 
> > Rather than just have it error out forever, I made this page in the spirit 
> > of the gentoo page:
> > 
> > 
> > 
> > 
> > If that is acceptable, I'd like to use it, or some variation of it, for 
> > ports like biggersql, for example, to fix some of these errors.
> 
> What errors exactly will be "fixed" by that?
> 
> > PS : Personally, I think asking users for a new homepage, if there is one, 
> > is better than just deleting the homepage variable requirement in Portfiles.
> 
> It might be useful to display a message when a port without a manpage is
> installed, saying something like you put on the page above, but shorter:
> 
>   $port does not have a manpage.
>   Please let $maintainer know if you know where it is.
> 
> (But note that all the ports listed on that repology page have no maintainer.
> And honestly, how many times has it happened in the past that a user came up
> with "hey, this homepage you thought was dead is actually here now"?)
> 
> At any rate, this would imho be better displayed automaticaly with 
> "port notes" - not explicitly in Portfile of course, but implicitly
> for ports without a manpage. Meaning they don't have one in the Portfile,
> as opposed to "it has this 'homepage', but it's not really its homepage".
> 
> 
>   Jan
> 

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

[Jan Stary]

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
> 
> $ port lint
> --->  Verifying Portfile for aee
> Error: Missing required variable: homepage

Eh, that's because lint was _made_ to complain about this,
which doesn't mean it's not possible.

> b: IMHO not desirable

How is it desirable to pretend a piece of software
does have a homepage when it does not?

"But sir, I have to put _something_ under 'homepage' on this here form".

> > If the source code cannot be downloaded from somewhere,
> > how does the port even exist?
> 
> MacPorts mirrors most distfiles for this reason, amongst others.

Voila, that's its homepage then.

Jan

Re: libressl vs openssl

[Jan Stary]

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 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 because there are no 
> >> guarantees of API or ABI stability.”
> >> 
> >> If projects link statically against an SSL library, then BoringSSL maybe 
> >> fine, but probably not as a shared library used by many packages.
> > 
> > As opposed to a static library used by many packages?
> 
> Ideally, ports should not link with static libraries; they should link with 
> dynamic libraries. That way they receive bug fixes as soon as the port that 
> provides the library is updated.

Yes. But my note was regrding the suitabilty of LibreSSL/BoringSSL
as an alternative to OpenSSL - that has nothing to do with static/shared
- you can say the same about each of them.

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

[Jan Stary]

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 
> been mirrored somewhere reachable.

What's the point of having a "homepage" saying "there is no homepage"?
For ports that don't have a homepage, the simplest thing imho
is not to declare one in the Portfile.

> Dunno what you do about master_sites in such a case, exactly ...

If the source code cannot be downloaded from somewhere,
how does the port even exist?

Jan

Re: libressl vs openssl

[Jan Stary]

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 <h...@stare.cz> wrote:
> > > 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 the way-superior libressl (until Apple replaces
> > > it system wide. ha ha ha.)
> > I'm not sure I agree with the claim that libressl is necessarily
> > better.
> i would as well be cautions with the term "superior", at least when the
> criteria are not clear.

So here is a few, as a start:

Wraps malloc() -- and every other normal C function -- in its
VERYOWNBUGGY_malloc() that never frees, thus sabotaging any
memory-exploit mitigations the OS migth be doing?

Has its own snprintf() and memcmp() etc, with an _almost_ identical
interface and return values, but not quite?

Has its own broken random generator?

Nests #ifdefs to depth 17?

Has NO_OLD_ASN1 and NO_ASN1_OLD compile options
doing different things?

Defines a union of a couple different ints, calls accept(),
then inspect the different union members to determine which ones were
overwritten by the kernel, to find out what the size of socklen_t is?

Contains tens of thousands of lines of dead code
to support VMS or MS Visual C 1.52?

> In the past i have provided support for OpenSSL 1.0.* and 1.1.* and
> LibreSSL 2.6.3 and 2.6.4 for non-trivial projects , and from my experience
> this is not a simple drop-in replacement in general.
> One pain is that OpenSSL changed some calls between 1.0 and 1.1,

Could you please elaborate on the technical details?
Or point to some write-up on that?

> and another one is that LibreSSL claims to be OpenSSL 2.*
> (via |OPENSSL_VERSION_NUMBER|)
> which confuses source code that has to compare for version numbers
> for the above reasons.

Comparing a version number is not the hard part, right?
For example, this is how we currently unconfuse libevent:
https://github.com/macports/macports-ports/blob/master/devel/libevent/files/patch-libressl.diff

> The process is doable (see e.g. HardenedBSD [1], OpenBSD 5.6),

Well, OpenBSD is where it came from.

> but cooperation with upstream projects
> is probably required for some packages.

Definitely; I am going through the ports that depend on SSL
trying to sort it out at least in the ports I use. Some work
just fine with LibreSSL, some need patches, some just need to
be unconfused about the version.


Jan

Re: libressl vs openssl

[Jan Stary]

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 because there are no guarantees of API 
> or ABI stability.”
> 
> If projects link statically against an SSL library, then BoringSSL maybe 
> fine, but probably not as a shared library used by many packages.

As opposed to a static library used by many packages?

Re: libressl vs openssl

[Jan Stary]

On Jan 09 12:24:22, pe...@piermont.com wrote:
> On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary <h...@stare.cz> wrote:
> > 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 the way-superior libressl (until Apple replaces
> > it system wide. ha ha ha.)
> 
> I'm not sure I agree with the claim that libressl is necessarily better.

Please read and see the following to convince yourself that
it is desirable to replace OpenSSL with LibreSSL if at all possible.

https://www.openbsd.org/papers/bsdcan14-libressl/index.html
https://www.openbsd.org/papers/eurobsdcon2014-libressl.html
https://www.youtube.com/watch?v=GnBbhXBDmwU
https://www.youtube.com/watch?v=WFMYeMNCcSY
https://www.tedunangst.com/flak/post/worst-common-denominator-programming
https://marc.info/?l=openbsd-misc=139698608410938=2
https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
https://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Personally, I like the socklen_t bit the most:

  You want to create a variable the same size as socklen_t. One fairly
  obvious solution would be to declare a variable of type socklen_t.
  That's not how OpenSSL does things, however. Instead, let's create
  a union of a couple different ints, call accept(), then inspect the
  different union members to determine which ones were overwritten by the
  kernel. Oh, and don't forget to check for big endian versus little endian. 

Jan

Re: libressl vs openssl

[Jan Stary]

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 don't think upstream even considers "devel" releases in any sense,
a release is a release. Is there anything else from the port's view
that makes one of them "stable" and the other one "devel",
or is it just a name for previous and latest?

Jan

libressl vs openssl

[Jan Stary]

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 the way-superior libressl (until Apple replaces
it system wide. ha ha ha.)

I have a WIP that does that to some ports I use,
but as openssl and liressl are in conflict (obviously),
this needs to work for _all_ ports before such a switch can be made,
or users would be forced to choose between the two subsets.

Please tell me you have something like that in the works :-)

Jan

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

[Jan Stary]

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 think
> >> <https://travis-ci.org/macports/macports-ports/jobs/275966013>
> > 
> > On Sep 17 06:28:57, ken.cunningham.web...@gmail.com wrote:
> >> this is still going on. some travis builds have been running almost 6 
> >> hours, which would be great if they finally built something, but looks 
> >> like it just keeps resetting and starting over...
> > 
> > On Sep 17 15:35:44, rai...@macports.org wrote:
> >> Must be an error on the side of Travis. Our configuration just runs the
> >> command and whatever causes it to restart after the timeout must be
> >> something at Travis.
> > 
> > On Sep 17 15:53:23, rai...@macports.org wrote:
> >> I do not think it is our issue if it also happens for base, for which
> >> our configuration is minimal.
> >> Did anyone inform them? Maybe it slipped through their monitoring.
> > 
> > It is still happening, see e.g.
> > https://github.com/macports/macports-ports/pull/1186
> 
> This looks like a normal timeout.
> The build finished and I see no restarts.

Maybe I just don;t get the Travis terminology,
but it smultaneously finished _and_ timed out?

> The timeout after 50 minutes is expected.
> This is a limitation of Travis CI and cannot be increased.

Why? Surely it's a config constant.

> Pull requests for ports that need longer to build
> cannot be tested automatically.

So what should I do about e.g.
https://github.com/macports/macports-ports/pull/1189
which needs loger to build because it touches lirc?

Currently, such PRs seem kinda discriminated with
"All checks have failed" (sounds horrible, right?)
eventhough it's just Travis timing out.

Jan

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

[Jan Stary]

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:
> this is still going on. some travis builds have been running almost 6 hours, 
> which would be great if they finally built something, but looks like it just 
> keeps resetting and starting over...

On Sep 17 15:35:44, rai...@macports.org wrote:
> Must be an error on the side of Travis. Our configuration just runs the
> command and whatever causes it to restart after the timeout must be
> something at Travis.

On Sep 17 15:53:23, rai...@macports.org wrote:
> I do not think it is our issue if it also happens for base, for which
> our configuration is minimal.
> Did anyone inform them? Maybe it slipped through their monitoring.

It is still happening, see e.g.
https://github.com/macports/macports-ports/pull/1186

Jan

Re: Fix Sierra Trac query

[Jan Stary]

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 don't mean that Apple will stop inventing these names
(my bet is on rivers next, except Amazon of course).
I mean that we won't have this problem if we stop using them.

> > Is it because the tracker's querry cannot distinguish
> > between ^sierra$ (as in grep -w) and "sierra" as a substring?
> 
> Apparently, yes. The search for "sierra" will match "highsierra", as it
> contains the substring and there is no filter to match whole words only.
> 
> See Trac upstream: https://trac.edgewall.org/ticket/7558

That's nine years old, with "low" priority.
Does anyone belive it's going to happen?

Come to think of it, are here any opinions among the MP devs
whether to stay with trac at all? Now that we can send PR on github,
it would make sense to also use the github tracker. (Obviously, that
would be a vwry nontrivial move).

Jan

Re: Fix Sierra Trac query

[Jan Stary]

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?
> > 
> > Can someone please confirm this is the case?
> > Is it because the tracker's querry cannot distinguish
> > between ^sierra$ (as in grep -w) and "sierra" as a substring?
> 
> Correct, Trac does not have a regular expression search feature. There's a 
> very old ticket in Trac's upstream issue tracker requesting that feature. One 
> possible avenue of exploration would be for us to attempt to resolve that 
> issue and implement regex search in Trac.

Doesn't this alone rule out the method of using
keywords like "sierra" and "highsierra" to identify releases?

>  As a test I tried adding highsierra as a keyword to
>  https://trac.macports.org/ticket/53161
>  and indeed it disappeared from the Sierra list.
>  I then changed the keyword from highsierra to 10.13 ... and it also did 
>  not
>  work.
>  It appears the logic in the code has never worked for these sorts of
>  keywords. I just fixed this and now the ticket appears in both lists.
> >>> 
> >>> This ticket uses both keywords
> >>> but only appears on the HighSierra list.
> >> 
> >> Yup. That is because the query on the Sierra page says to find tickets 
> >> having the keyword highsierra but not the keyword sierra. Which isn't 
> >> really what we want.
> > 
> > Now I'm confused: why doesn't the query on that page
> > just search for 'highsierra' (or better yet, 10.13.?),
> > thus getting problems specific to that release
> > - and possibly other releases too, if that's the case?
> 
> Oops, I misspoke: I meant to say: the query on the SierraProblems page says 
> to find tickets where the keywords field contains the substring *sierra* but 
> not the substring *highsierra*. If this were not done, the SierraProblems 
> page would also list all High Sierra tickets, because "sierra" is a substring 
> of "highsierra". But excluding tickets that include the substring 
> "highsierra" in the keywords field on the SierraProblems page is not what we 
> want, because some tickets might list *both* the highsierra keyword and the 
> sierra keyword. That was the point of this email thread: to invite someone to 
> figure out a way to solve that problem.

OK, I see now.

> >>> On the other hand,
> >>> https://trac.macports.org/ticket/55262
> >>> uses no keywords and appears on both lists.
> >> 
> >> Yup. That's because the queries look not only in the keywords field
> >> but also in the summary, and that ticket says "High Sierra" in the summary.
> > 
> > Ah, so it's _not_ a list if tickets saying the keyword in the keywords?
> 
> It shows tickets having the keywords, and also tickets using likely words in 
> the summary, because some submitters put OS versions or names into the 
> summary instead of following our directions and putting it in the keywords.
> 
> 
>  So one work around is to start to try and use 10.13 and 10.12 etc.,
>  instead of highsierra, sierra.
> >>> 
> >>> Please.
> >> 
> >> As I'm sure I said before in this thread, we could do that,
> >> but I'm not thrilled about the massive amount of editing of existing 
> >> tickets
> >> required to convert all the existing keywords,
> > 
> > Would that need to be done maually?
> > Isn't thee a "s/^tiger$/10.4/" to be run over the database?
> > 
> > Looking at
> > 
> > https://trac.macports.org/wiki/SnowLeopardProblems
> > https://trac.macports.org/wiki/LionProblems
> > https://trac.macports.org/wiki/MavericksProblems
> > https://trac.macports.org/wiki/YosemiteProblems
> > https://trac.macports.org/wiki/ElCapitanProblems
> > https://trac.macports.org/wiki/SierraProblems
> > https://trac.macports.org/wiki/HighSierraProblems
> > 
> > there seem to be about three hundred tickets.
> 
> Yes it could conceivably be done with raw SQL queries in the database.
> 
> 
> > BTW, what are those "gaps" inbetween the sets of tickets
> > on each of those pages? For example, for SnowLeopardProblems,
> > there is 22 tickets + a few more + 1 ticket, in such sets.
> > It seems that the first is those who say just 'snowleopard'
> > in the keywords, the seconds set is those that say 'snowleopard'
> > and possibly something else, and for https://trac.macports.org/ticket/20909
> > I have no idea. How did it get there?
> 
> The *Problems wiki pages each have multiple queries. This is because Trac's 
> query syntax is not sufficiently advanced to allow us to construct a single 
> query that would return all results. Each query produces a list of tickets, 
> and the lists are separated by some whitespace because that's what Trac wants 
> to do. You can edit the pages and see what the queries are doing if you like. 
> On the SnowLeopardProblems page, the third set of 

Re: Python 2.7 – allow another db version beside 4.8

[Jan Stary]

On Dec 25 10:04:33, vi...@macports.org wrote:
> > On 24 Dec 2017, at 11:23, Jan Stary <h...@stare.cz> 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?
> >> 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 countless hours of comutation spent on nothing
> > except "having the newest version" (with the newest bugs).
> 
> Well my initial request was not about using the last version, but being able 
> to choose one version and stick to it through multiple ports that depend 
> thereon. I have a 128 GB SSD, and I’d rather not squander space with 
> installing different versions of the same software for no reason except that 
> the Portfile doesn’t offer the possibility to pick the version I want.

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, then I consider
_any_ installed python to satsfy this requirement,
unless there is a reason it has to be python36 (or whatever).

What is the right way to state this in a Portfile?

Jan

Re: Fix Sierra Trac query

[Jan Stary]

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 use two different ways of 
> tagging OS versions in the issue tracker, depending on the version of the OS. 
> I would find it simpler to use a single way to tag all OS versions in the 
> issue tracker.

So let's start tagging with the version numbers, like adults.
The confusion of also having names of cats and mountains
for the old releases will eventually die out as they get older.

> >> I really didn't intend to start a big discussion here.
> >> I just wanted to point out a small issue with one of our wiki pages
> >> and to invite someone with interest in fixing the page to do so.
> > 
> > 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?

Can someone please confirm this is the case?
Is it because the tracker's querry cannot distinguish
between ^sierra$ (as in grep -w) and "sierra" as a substring?

> > On Sep 26 15:58:04, smithsp wrote:
> >> If I go to "Apple symbol" -> "About this mac",
> >> I get a version number, not a name.
> > 
> > Exactly. Why would you use anything else to identify the OS version?
> "About this Mac" shows both the marketing name and the version number.

Yes it does. It also says 'macOS' where it used to say 'MacOSX'.
How is a random marketing name better then a number?
Why would you use that?

> > On Sep 27 16:13:45, jonesc wrote:
> >> As a test I tried adding highsierra as a keyword to
> >> https://trac.macports.org/ticket/53161
> >> and indeed it disappeared from the Sierra list.
> >> I then changed the keyword from highsierra to 10.13 ... and it also did not
> >> work.
> >> It appears the logic in the code has never worked for these sorts of
> >> keywords. I just fixed this and now the ticket appears in both lists.
> > 
> > This ticket uses both keywords
> > but only appears on the HighSierra list.
> 
> Yup. That is because the query on the Sierra page says to find tickets having 
> the keyword highsierra but not the keyword sierra. Which isn't really what we 
> want.

Now I'm confused: why doesn't the query on that page
just search for 'highsierra' (or better yet, 10.13.?),
thus getting problems specific to that release
- and possibly other releases too, if that's the case?

> > On the other hand,
> > https://trac.macports.org/ticket/55262
> > uses no keywords and appears on both lists.
> 
> Yup. That's because the queries look not only in the keywords field
> but also in the summary, and that ticket says "High Sierra" in the summary.

Ah, so it's _not_ a list if tickets saying the keyword in the keywords?

> >> So one work around is to start to try and use 10.13 and 10.12 etc.,
> >> instead of highsierra, sierra.
> > 
> > Please.
> 
> As I'm sure I said before in this thread, we could do that,
> but I'm not thrilled about the massive amount of editing of existing tickets
> required to convert all the existing keywords,

Would that need to be done maually?
Isn't thee a "s/^tiger$/10.4/" to be run over the database?

Looking at

https://trac.macports.org/wiki/SnowLeopardProblems
https://trac.macports.org/wiki/LionProblems
https://trac.macports.org/wiki/MavericksProblems
https://trac.macports.org/wiki/YosemiteProblems
https://trac.macports.org/wiki/ElCapitanProblems
https://trac.macports.org/wiki/SierraProblems
https://trac.macports.org/wiki/HighSierraProblems

there seem to be about three hundred tickets.

BTW, what are those "gaps" inbetween the sets of tickets
on each of those pages? For example, for SnowLeopardProblems,
there is 22 tickets + a few more + 1 ticket, in such sets.
It seems that the first is those who say just 'snowleopard'
in the keywords, the seconds set is those that say 'snowleopard'
and possibly something else, and for https://trac.macports.org/ticket/20909
I have no idea. How did it get there?

> and of all the email notifications that will go out to everyone as a result,
> which some might start to view as spam...

If I get an email saying that keyword 'snowleopard' in my ticket
has been changed to '10.6', I'll say hooray.

Jan

supported XCode versions

[Jan Stary]

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 test suite that verifies
that yes, indeed, this xcode version does work well wth this MacOS release?
Or does it simply mean it gets added there once Apple releases it?

Jan

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

[Jan Stary]

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/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44
> > > 
> > > /usr/bin/tar is a symlink to bsdtar. copyfile(3) copies the symlink, the
> > > previous method opened the file (dereferencing the symlink) and copied
> > > its contents.
> > > 
> > > When the symlink is copied (because copyfile(3) is used), the
> > > destination of the symlink is not copied, which eventually leads to file
> > > not found.
> > 
> > According to the documentation of copyfile(3), it should always follow
> > the symlink unless COPYFILE_NOFOLLOW was specified. I even checked its
> > implementation [1]. Internally, clonefileat(2) will only be called with
> > CLONE_NOFOLLOW when COPYFILE_NOFOLLOW was given – and we do not do that.
> > 
> > I did a quick test with the following code snippet which should be
> > roughly equivalent to what we use in our sip_copy_proc.c:
> > 
> > ---8<---
> > 
> > #include 
> > #include 
> > 
> > int main(int argc, char *argv[]) {
> > int ret;
> > 
> > ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
> >   COPYFILE_ALL | COPYFILE_CLONE);
> > if (ret) {
> > perror("copyfile");
> > return 1;
> > }
> > 
> > return 0;
> > }
> > 
> > --->8---
> > 
> > I could not reproduce the problem as described on 10.12.6 Sierra. After
> > running this program, /tmp/tar is a regular file and contains the same
> > contents as /usr/bin/bsdtar.
> > 
> > I also tested on a VM with 10.13.0 High Sierra, as I still had that
> > around. It also works there as expected.
> > 
> > Does this mean Apple has a regression how copyfile(3) works with
> > symlinks on macOS 10.13.2? Can somebody with 10.13.2 please test the
> > code above and confirm this?
> 
> On my 10.13.2, this results in
> 
> $ ls -l /tmp/tar 
> lrwxr-xr-x  1 hans  wheel  6 Dec 10 11:39 /tmp/tar -> bsdtar

But without the COPYFILE_CLONE, it works as expected:


#include 
#include 
#include 

#define SRC "/usr/bin/tar"
#define DST "/tmp/tar"

int
main()
{
/* With COPYFILE_CLONE, it doesn't follow the /usr/bin/tar symlink */
if (copyfile(SRC, DST, NULL, COPYFILE_ALL))
err(1, "%s to %s", SRC, DST);
return 0;
}


$ cc -o copyfile copyfile.c
$ ./copyfile

$ ls -l /usr/bin/{,bsd}tar /tmp/tar 
-rwxr-xr-x  1 hans  wheel  71024 Dec  1 20:38 /tmp/tar
-rwxr-xr-x  1 root  wheel  71024 Dec  1 20:38 /usr/bin/bsdtar
lrwxr-xr-x  1 root  wheel  6 Dec 10 11:39 /usr/bin/tar -> bsdtar

$ uname -a
Darwin fitbook.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 
PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

Jan

Re: Fix Sierra Trac query

[Jan Stary]

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://trac.macports.org/wiki/LionProblems
> > But we never fixed the problem, instead opting to never create a Mountain 
> > Lion Problems page.

LOL.

On Sep 26 08:40:44, 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 really didn't intend to start a big discussion here.
> I just wanted to point out a small issue with one of our wiki pages
> and to invite someone with interest in fixing the page to do so.

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?

On Sep 26 15:58:04, smit...@fusion.gat.com wrote:
> If I go to "Apple symbol" -> "About this mac",
> I get a version number, not a name.

Exactly. Why would you use anything else to identify the OS version?

On Sep 27 15:58:12, jon...@hep.phy.cam.ac.uk wrote:
> > Looks like Trac does not support the match operator we would need:
> > https://trac.edgewall.org/ticket/7558
> If thats the case I don't see what we can do (other that start to use a
> numerical keyword instead of highsierra, which I agree we don't want to back
> port to older systems, and having a mix is not ideal either).

It's not ideal, but it's still a good thing to start using
something that works as opposed to continue using something
that apparently does not.

On Sep 27 16:13:45, jon...@hep.phy.cam.ac.uk wrote:
> As a test I tried adding highsierra as a keyword to
> https://trac.macports.org/ticket/53161
> and indeed it disappeared from the Sierra list.
> I then changed the keyword from highsierra to 10.13 ... and it also did not
> work.
> It appears the logic in the code has never worked for these sorts of
> keywords. I just fixed this and now the ticket appears in both lists.

This ticket uses both keywords
but only appears on the HighSierra list.

On the other hand,
https://trac.macports.org/ticket/55262
uses no keywords and appears on both lists.

> So one work around is to start to try and use 10.13 and 10.12 etc.,
> instead of highsierra, sierra.

Please.

Jan

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

[Jan Stary]

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
> > 
> > /usr/bin/tar is a symlink to bsdtar. copyfile(3) copies the symlink, the
> > previous method opened the file (dereferencing the symlink) and copied
> > its contents.
> > 
> > When the symlink is copied (because copyfile(3) is used), the
> > destination of the symlink is not copied, which eventually leads to file
> > not found.
> 
> According to the documentation of copyfile(3), it should always follow
> the symlink unless COPYFILE_NOFOLLOW was specified. I even checked its
> implementation [1]. Internally, clonefileat(2) will only be called with
> CLONE_NOFOLLOW when COPYFILE_NOFOLLOW was given – and we do not do that.
> 
> I did a quick test with the following code snippet which should be
> roughly equivalent to what we use in our sip_copy_proc.c:
> 
> ---8<---
> 
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
> int ret;
> 
> ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
>   COPYFILE_ALL | COPYFILE_CLONE);
> if (ret) {
> perror("copyfile");
> return 1;
> }
> 
> return 0;
> }
> 
> --->8---
> 
> I could not reproduce the problem as described on 10.12.6 Sierra. After
> running this program, /tmp/tar is a regular file and contains the same
> contents as /usr/bin/bsdtar.
> 
> I also tested on a VM with 10.13.0 High Sierra, as I still had that
> around. It also works there as expected.
> 
> Does this mean Apple has a regression how copyfile(3) works with
> symlinks on macOS 10.13.2? Can somebody with 10.13.2 please test the
> code above and confirm this?

On my 10.13.2, this results in

$ ls -l /tmp/tar 
lrwxr-xr-x  1 hans  wheel  6 Dec 10 11:39 /tmp/tar -> bsdtar

Jan 

Re: Python 2.7 – allow another db version beside 4.8

[Jan Stary]

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 countless hours of comutation spent on nothing
except "having the newest version" (with the newest bugs).

Jan

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

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|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$"
> >  ".libs/libsox.exp" > ".libs/libsox.expT"
> >
> > Can someone on 10.7 please check that this is the failing grep line?
> > (Not even in connection with SoX, just grep that regexp on anything.)
> 
> Confirming.

Thank you I will ask upstream whether the regexp can be simplified
(or is even up to date), to see if we can avoid the dependency on grep.

Jan

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

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 tonight.
> > 
> > Thank you Ken.
> > 
> > I looked on the detailed log of vanilla SoX 14.4.2 itself,
> > but cannot find the offending grep. Is it run by SoX's build system,
> > or is the nm/grep combo run by the building robot?
> 
> The addition of --disable-silent-rules in the patch was to hopefully show
> more of the failing command (and it's a good idea anyway since silent rules
> make logs much less useful).

'make V=1' disables the silent rules

$ ./configure --help
--enable-silent-rules   less verbose build output (undo: "make V=1")
--disable-silent-rules  verbose build output (undo: "make V=0")

> This is not something that would be specific to
> the buildbot. I'm not sure, but given what is happening when the error
> occurs, the offending grep command may be invoked by (g)libtool.

Thank you Josh. I missed ./configure --disable-silent-libtool.
Then the full build log (attached) reveals

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|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$"
 ".libs/libsox.exp" > ".libs/libsox.expT"

Can someone on 10.7 please check that this is the failing grep line?
(Not even in connection with SoX, just grep that regexp on anything.)

Jan



typescript.gz
Description: application/gunzip

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

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

Thank you Ken.

I looked on the detailed log of vanilla SoX 14.4.2 itself,
but cannot find the offending grep. Is 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 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 grep fixes the build on 10.7. I have other things 
> >> installed that get pulled in (gsed, otools) so this is not a buildbot, but 
> >> grep should do the trick.
> > 
> > Can anyone please point to the actual grep call that causes this?
> > I would much rather simplify the grep call in SoX itself (if possible)
> > than depend on a specific version of grep (uggh).
> > 
> > Jan
> > 
> 

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

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 grep fixes the build on 10.7. I have other things 
> installed that get pulled in (gsed, otools) so this is not a buildbot, but 
> grep should do the trick.

Can anyone please point to the actual grep call that causes this?
I would much rather simplify the grep call in SoX itself (if possible)
than depend on a specific version of grep (uggh).

Jan

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

[Jan Stary]

On Jul 05 08:38:16, a...@alum.wpi.edu wrote:
> On Wed, Jul 5, 2017 at 7:14 AM, Jan Stary <h...@stare.cz> wrote:
> >> as it avoids /usr/local/{include,lib} contamination.  What are the 
> >> thoughts on this?
> >
> > What contamination? I don't even have /usr/local/
> 
> You may not have /usr/local, but lots of people do. It's the default
> installation prefix when compiling most 3rd party tools and there are
> other 3rd party software installers that pick this path as well.

Of course; on most other UNIX systems, I install in /usr/local.
But one of the first things you come across when using MacPorts
is that you are not supposed to have anything in /usr/local

https://trac.macports.org/wiki/FAQ#defaultprefix
https://trac.macports.org/wiki/FAQ#usrlocal

Can I install software in /usr/local while using MacPorts?
No. ...


> The issue is that libraries installed here may be picked up instead of
> those installed by MacPorts in /opt/local.

Yes. I still believe that's exactly why MP should use /usr/local,
like most other systems do; but that's hardly gonna happen.

> I wonder though, would relying on having not installed the headers
> make things worse?

It's a UNIX system. Why would you rely on e.g.
/usr/include/unistd.h _not_ being there?

> Right now it seems MP assumes /usr/local needs to
> be hidden or excluded.

The FAQ explicitly says you should not install anything in there.

Jan

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

[Jan Stary]

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 installed. Most ports should 
> build corectly, but if you experience problems due to a port depending on 
> system headers, please file a ticket at https://trac.macports.org.
>Warning: You can install them as part of the Xcode Command Line Tools 
> package by running `xcode-select --install'.
> 
> How many developers are using Xcode with the system headers installed vs 
> without system headers?

It's a UNIX system. I want it to have /usr/include/unistd.h etc.

> If you are using system headers (currently installed through the CLTools 
> package and through similar means on older OS versions), can you please 
> indicate why you are unable to use an SDK?

The question seems to imply that I should _not_ use system headers
unless I absolutely have to. That puzzles me.

> I haven't seen any tickets about issues when using an SDK over system headers,
> and the only issue I'm aware of is with gcc ports (which is an upstream bug 
> and mostly worked around).

Even if failing to build a compiler is "the only issue", it's a pretty major 
one, no?
GNU does not even consider it a proper bug yet (it's UNCONFORMED):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

> I'd like to remove this warning in order to indicate that building against an 
> SDK is now a more supported configuration.  IMO, it should be the *preferred* 
> configuration

Why?

> as it avoids /usr/local/{include,lib} contamination.  What are the thoughts 
> on this?

What contamination? I don't even have /usr/local/

Jan

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

[Jan Stary]

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 line tools installed.

Yet that's exactly what "port diagnose" uses.
https://trac.macports.org/ticket/53909

Jan

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

[Jan Stary]

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 particularly useful for 
> avoiding build conflicts. That kind of conflict usually arises when the 
> presence of certain files from a port A interferes with building port B. Most 
> often that concerns headerfiles but "linker interface" libraries can also be 
> at cause, or even pkgconfig/cmake files.

Can you please describe the motivating situation in detail,
i.e. what header files were conflicting with what?

Also, I am not entirely clear on what you mean by
"link libraries" (as opposed to "libraries").

I remember from my Debian days (long ago) how strange this felt.
I have installed, say, libpng. So there is /usr/local/libpng.so
and the programs that need png run hapilly. But I cannot write
any program that uses the library, because? There is no png.h;
I need to install a separate libpng-dev for that.

Please don't. Or at least only in very specific cases that need it.
Even if one library's header file(s) conflict with other library's
header file (example?), the solution is imho not to not install the
header files.

Have one port, say 'png', that installs the library, the headers,
and the manpages. Please don't go the Debian way where a modest
workstation needs to have hundreds of packages installed.

> 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 files, and its documentation)
because you want to develop software using that library.
Please don't make it needlessly complicated by requiring
more than one port to be installed.

I admit there are packeges where a separate -doc might be in order
(as a subport? or a variant? is there an agreement?) if the documentation
is considerably bigger than the library itself, or is just a copy
of a set of html pages to be found on the upstream's homepage.

> I think that it should even be possible to use this kind of approach for 
> ports that cannot be built when an older version is already installed; such 
> ports could probably declare a build conflict with their own -dev port 
> (possibly even deactivate it in an appropriate stage).

That's the kind of mess I'm talking about.
"Declare a build conflict with you own -dev port."
Please don't.

Jan

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

[Jan Stary]

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. check first that the compiler support -Wvla).

It builds fine with e.g. gcc-4.3 that comes with macports.

Until upstreams releases the fixed version, what do I do?
Rather than messing with the choice of compiler (which I never did before),
I would just patch the -Wvla away.

Are there any objections to that?
(I thought I would ask here before posting the Portfile diff).

Jan



> #54009: libsndfile @1.0.27: update to 1.0.28
> --+
>  Reporter:  l2dy  |  Owner:  janstary
>  Type:  update| Status:  new
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:
>  Keywords:  security  |   Port:  libsndfile
> --+
>  CVE-2017-7585 CVE-2017-7586 CVE-2017-7741 CVE-2017-7742.
> 
>  All low impact from Red Hat CVE Database.

Re: manpages is mdoc(7)

[Jan Stary]

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 you mean the man(7) macros or the mdoc(7) macros,
they have been around and clearly documented for decades,
on each and every UNIX system. To quote http://man.openbsd.org/mdoc

  The mdoc language first appeared as a troff macro package in 4.4BSD.
  It was later significantly updated by Werner Lemberg and Ruslan Ermilov
  in groff-1.17. 

(Seriously, are you pretending to not know that?)

> After a lot of attempts to decipher rules,
> find what seemed to be non-existent docs, etc.,
> I came away with the following:
> As long as it looked close enough, that was good enough.

That's the impression I got so far in the reactions.

So let's use the horrendous docbook-xsl to produce
low-level roff of abysmal quality - it still looks close enough.

> If you are going to talk about re-writing something in a new language,
> it isn't enough to say that it is documented; point out the docs.

The new language is as old as 4.4BSD,
and the documentation for it is exactly as old.

> If you are going to say that "Oh, this language is better
> because it makes semantic separation, and you can make it
> look appropriate yourself", make sure you are not falling
> into the stupidity of the HTML to CSS trap
> -- going from "Here's a simple, uniform, consistent way to say
> bold or underline" to "Here's a site dependent way to format,
> that will differ from site to site, that isn't even easy for
> an end user to adjust or change, that tries to make your monitor
> look like the dev's monitor even if the two monitors are completely
> different in all aspects, that changes the rules for scrolling,
> for letting people see stuff, that leaks privacy data,
> that while it can say "this is a paragraph" or "this is a link"
> or "this is someone's name" or "this is a video", etc.,
> in reality everyone wants to declare different things in different ways,
> and the end user only gets one override style sheet that
> if used will replace everything else by everyone
> making it completely useless in the end".

Could you please elaborate on each of those points, specifically?
How is mdoc(7) "site dependent"? What "rules for scrolling"? etc.
How does it "leak privacy data"? (And what what "privacy data"
are in the manpages?) etc

> Yes, I'm bitter about that.

Apparently.

> Seriously: Being able to say "This is to be emphasized"
> or "This is to be stressed" or "This is to be ignored"
> is not really much different than "This is to be bold"
> or "this is to be italic" or "this is to be strikethrough"
> or having a display translate strikethrough into greyed-out
> because it can't do strikethrough.

That's a strawman attack. mdoc(7) doesn't do _any_ of that.
On the contrary, it has annotations for "this is an optional argument",
"this is a variable name" etc - precisely the things you need to say
in a manpage for a piece of software.

> Man page rules allowed specifying the important stuff -- standard section 
> headers, command name, etc. The language was badly documented,

No it wasn't, and isn't.

> and not really consistently templated. Gnu switched to a "info" language.
> Apple just made PDF's from their own internal stuff and didn't even bother
> with man pages.

What's that nine thousand files doing
in my OSX's /usr/share/man then?

> The TL;DR: Based on what has happened historically, it really does look like 
> the -man macros for roff don't provide enough function and are too hard to 
> use for what is provided.

That's why I suggest to use mdoc(7), as opposed to man(7),
to be used for the manpages.

> Use something that is usable if displayed raw,
> that has conversions into other formats (such as -man),

>From the mdoc(7) source, the following are easily generated
using either gorff or mandoc:

ascii
html
man
markdown
pdf
ps

> and doesn't fall into the "everything behaves differently" trap.

I don't know what you mean by that,
and how mdoc(7) "falls into that trap".

> An ascii-based rewrite sounds like it fits that. 

mdoc(7) does not fit that by definition, if you want
something that is usable if displayed raw,
which rules out any kind of markup.

Jan

expired certificate

[Jan Stary]

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

Jan

Re: port search --maintainer[s]

[Jan Stary]

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 '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.
> >>
> >> Note that all long options can be shortened as long as they are unique, so 
> >> you
> >> could even use 'port search --maint foobar'.
> > 
> > $ port search --maint mandoc
> > Error: "port search --maint" is ambiguous: 
> >   port search --maintainer
> >   port search --maintainers
> 
> Sorry, that's what happens when I do not test my examples...
> 
> >> Maybe we want to simplify the code
> >> and leave out the explicit singular forms (although we cannot do that for
> >> "categories")?
> > 
> > I don't understand why there is more then one at all.
> 
> In natural language you would use either singular or plural, depending
> on the way it is used in a query. The port command just tries to be as
> convenient as possible.

But it's the other way now: if e.g. '--maintainers' was be the only one,
with unique shortenings working, you would also have '--maintaniner'
and '--maintain'. With both --maintainer and --maintainers recognized
as separated --options, it has to be one of the two, literaly,
because everything else is ambiquous. So recognizign only --maintainers
would actually be more convenient.

I suggest we only keep --maintainers and --variants.

With --categories, we don't have --category as a shortening,
but having --category makes --cat ambiguous, as above ...

Jan

Re: port search --maintainer[s]

[Jan Stary]

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 '--maintainer' and '--maintainer'
> > while port-search.1 only says '--maintainer'.
> > Attached please find a diff for each.
> 
> Note that all long options can be shortened as long as they are unique, so you
> could even use 'port search --maint foobar'.

$ port search --maint mandoc
Error: "port search --maint" is ambiguous: 
  port search --maintainer
  port search --maintainers

> Maybe we want to simplify the code
> and leave out the explicit singular forms (although we cannot do that for
> "categories")?

I don't understand why there is more then one at all.

Anyway, the "--maintainer, --maintainer" in the guide cannot be right,
and the port-search manpage does mention e.g. *--variant*, *--variants*::
so why should --maintainer(s) be different?

Jan

Re: port livecheck does not find new mandoc

[Jan Stary]

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-(\d+(?:\.\d+)*)"
> > i.e. the tarball differs from the port name.
> > What is the right place to specify the right regex?
> 
> In this case it should just need livecheck.name set to mdocml.

Edited, thanks; new Portfile comming.

Jan

Re: manpages is mdoc(7)

[Jan Stary]

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 heavy,

(to say the least)

> languages like man(7)/mdoc(7) just fell out of fashion

The vast majority of UNIX manpages is written in these languages.

> and rarely anyone still understands it or is willing to learn it...
> The intention of using AsciiDoc is to make contributions easier, and it has
> proven its fitness for this task in other open source projects such as Git.

I doubt very much that people cannot read or write mdoc(7).
As for contributions, does that mean people contributed
those asciidoc rewriter to macports?

Anyway, the mdoc(7) rewrite is apparently not happening.

Jas

Re: manpages is mdoc(7)

[Jan Stary]

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 in the repository to solve
> the problem of installing base without any external dependencies.
> 
> Changing the output format would require
> adjusting the corresponding DocBook XSL stylesheets [...]

Just forget it. My intentions when proposing the mdoc(7) rewrite
were the opposite of having asciidoc and docbook and xml/xsl ...

Jan

Re: port livecheck does not find new mandoc

[Jan Stary]

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 specify the right regex?

I mean, Portfile says

distnamemdocml-${version}

so why does livecheck look "mandoc-(\d+(?:\.\d+)*)" ?

Jan

Re: manpages is mdoc(7)

[Jan Stary]

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 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 example, please see a proposed rewrite of port-cat.1
> (and compare it to the current version).
> 
> I there any interest in this?
> 
>   Jan
> 
> 
> .Dd March 30, 2017
> .Dt PORT-CAT 1
> .Os
> .Sh NAME
> .Nm port-cat
> .Nd print the contents of a Portfile
> .Sh SYNOPSIS
> .Nm
> .Op Fl D Ar portdir
> .Ic cat
> .Op Ar portname | pseudo-portname | port-expressions | port-url
> .Sh DESCRIPTION
> Print the
> .Pa Portfile
> of the given port(s).
> Note that the latest version in your local ports tree is printed.
> .Sh SEE ALSO
> .Xr port 1 ,
> .Xr port-selfupdate
> .Sh AUTHORS
> .An Clemens Lang Aq mt c...@macports.org

manpages is mdoc(7)

[Jan Stary]

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 example, please see a proposed rewrite of port-cat.1
(and compare it to the current version).

I there any interest in this?

Jan


.Dd March 30, 2017
.Dt PORT-CAT 1
.Os
.Sh NAME
.Nm port-cat
.Nd print the contents of a Portfile
.Sh SYNOPSIS
.Nm
.Op Fl D Ar portdir
.Ic cat
.Op Ar portname | pseudo-portname | port-expressions | port-url
.Sh DESCRIPTION
Print the
.Pa Portfile
of the given port(s).
Note that the latest version in your local ports tree is printed.
.Sh SEE ALSO
.Xr port 1 ,
.Xr port-selfupdate
.Sh AUTHORS
.An Clemens Lang Aq mt c...@macports.org

Re: port search --maintainer[s]

[Jan Stary]

(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 find a diff for each.
> 
> There is also port-search.1.txt in git, which gets out of sync with this.
> Why are the generated *.txt files in the repository?
> 
>   Jan
> 
diff --git a/doc/port-search.1 b/doc/port-search.1
index 2f5b7130..a95c9b0d 100644
--- a/doc/port-search.1
+++ b/doc/port-search.1
@@ -114,7 +114,7 @@ Test the search string against ports\*(Aq descriptions\&.
 Search for the keyword(s) in the homepage property\&.
 .RE
 .PP
-\fB\-\-maintainer\fR
+\fB\-\-maintainer\fR, \fB\-\-maintainers\fR
 .RS 4
 Search for ports maintained by a specific maintainer\&. Note that there also 
is a pseudo\-portname selector available for maintainer addresses\&. See
 \fBport\fR(1)
diff --git a/guide/xml/using.xml b/guide/xml/using.xml
index 84802be..069df38 100644
--- a/guide/xml/using.xml
+++ b/guide/xml/using.xml
@@ -329,7 +329,7 @@ Found 11 ports.
 
 
 
---maintainer, 
--maintainer
+--maintainer, 
--maintainers
 
 Search for ports maintained by a 
specific maintainer.
 

port livecheck does not find new mandoc

[Jan Stary]

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

port search --maintainer[s]

[Jan Stary]

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 out of sync with this.
Why are the generated *.txt files in the repository?

Jan

PATH deals with binaries, not libraries

[Jan Stary]

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 during the install),
there is one bit of wording in installig.xml that I think
should be changed (see diff below).

The PATH is where shell commands and shell scripts look for binaries.
It has nothing to do with where a running binary looks for _libraries_,
right? (Or does it?)

Also, the MacPorts paths are "prepended", not "appended" to the PATH.
And it doesn't change the "default" PATH, it changes what the user has.
And it doesn't matter whether it's "ported software".

Jan


diff --git a/guide/xml/installing.xml b/guide/xml/installing.xml
index 31f8719..9dcb4be 100644
--- a/guide/xml/installing.xml
+++ b/guide/xml/installing.xml
@@ -436,10 +436,9 @@
 
 Required: PATH variable
 
-This variable is set by the postflight script to 
append the MacPorts executable paths to the
-default path as shown. The MacPorts paths are appended 
at the front of PATH
-so the MacPorts libraries will take precedence over 
vendor-supplied libraries for ported
-software at runtime.
+This variable is set by the postflight script to 
prepend the MacPorts executable paths to the
+current path as shown. This puts the MacPorts paths at 
the front of PATH
+so that the MacPorts binaries will take precedence 
over vendor-supplied binaries.
 
 export 
PATH=/opt/local/bin:/opt/local/sbin:$PATH
 

Re: Prevent MacPorts editing .bash_profile

[Jan Stary]

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 if this goes through?)

Jan


diff --git a/portmgr/dmg/postflight.in b/portmgr/dmg/postflight.in
index 750553f0..a3a8bd80 100755
--- a/portmgr/dmg/postflight.in
+++ b/portmgr/dmg/postflight.in
@@ -87,28 +87,6 @@ function update_macports {
 fi
 }
 
-# Through this command we write an environment variable to an appropriate 
shell configuration file,
-# backing up the original only if it exists and if it doesn't contain the 
${OUR_STRING} identification string,
-# which hints that we've already tweaked it and therefore already backed it up.
-function write_setting () {
-if [[ -f "${HOME}/.${CONF_FILE}" ]] && ! grep "${OUR_BASESTRING}" 
"${HOME}/.${CONF_FILE}" > /dev/null; then
-echo "Backing up your ${HOME}/.${CONF_FILE} shell confguration file as 
${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX} before adapting it for MacPorts."
-/bin/cp -fp "${HOME}/.${CONF_FILE}" 
"${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}" || {
-echo "An attempt to backup your original configuration file 
failed! Please set your MacPorts compatible environment manually."
-update_macports
-exit 1
-}
-echo -e "\n##\n# Your previous ${HOME}/.${CONF_FILE} file was backed 
up as ${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}\n##" >> "${HOME}/.${CONF_FILE}"
-fi
-{
-echo -e "\n# ${OUR_STRING}: adding an appropriate ${1} variable for 
use with MacPorts."
-echo "${ENV_COMMAND} ${1}${ASSIGN}${2}"
-echo -e "# Finished adapting your ${1} environment variable for use 
with MacPorts.\n"
-} >> "${HOME}/.${CONF_FILE}"
-chown "${USER}" "${HOME}/.${CONF_FILE}" || echo "Warning: unable to adapt 
permissions on your ${HOME}/.${CONF_FILE} shell configuration file!"
-echo "An appropriate ${1} variable has been added to your shell 
environment by the MacPorts installer."
-}
-
 function cleanup_man () {
 # Remove old non-compressed man pages
 echo -e "\nRemoving old man pages..."
@@ -195,8 +173,6 @@ function create_run_user {
 fi
 }
 
-echo "The MacPorts Project, postflight script version ${VERSION}: checking the 
shell environment for user \"${USER}\"."
-
 # create macports user
 create_run_user
 # Set up config files
@@ -207,78 +183,11 @@ cleanup_man
 delete_old_tcl_package_link
 delete_old_tcl_packages
 
-# Determine the user's shell, in order to choose an appropriate configuration 
file we'll be tweaking.
-# Exit nicely if the shell is any other than bash or tcsh, as that's 
considered non-standard.
-USHELL=$(${DSCL} . -read "/Users/${USER}" shell) || {
-echo "An attempt to determine your shell name failed! Please set your 
MacPorts compatible environment manually."
-update_macports
-exit 1
-}
-# leave full path to shell
-USHELL=${USHELL#*shell: }
-
-case "${USHELL}" in
-*/tcsh)
-echo "Detected the tcsh shell."
-LOGIN_FLAG=""
-ENV_COMMAND="setenv"
-ASSIGN=" "
-if [[ -f "${HOME}/.tcshrc" ]]; then
-CONF_FILE=tcshrc
-elif [[ -f "${HOME}/.cshrc" ]]; then
-CONF_FILE=cshrc
-else
-CONF_FILE=tcshrc
-fi
-;;
-*/bash)
-echo "Detected the bash shell."
-LOGIN_FLAG="-l"
-ENV_COMMAND="export"
-ASSIGN="="
-if [[ -f "${HOME}/.bash_profile" ]]; then
-CONF_FILE=bash_profile
-elif [[ -f "${HOME}/.bash_login" ]]; then
-CONF_FILE=bash_login
-else
-CONF_FILE=profile
-fi
-;;
-*)
-echo "Unknown shell ($USHELL)! Please set your MacPorts compatible 
environment manually."
-update_macports
-exit 0
-;;
-esac
-
-# Adding our setting to the PATH variable if not already there:
-# Run as the $USER: /usr/bin/su $USER -l
-# Run a command in the shell: -c "/usr/bin/printenv PATH"
-# Only process the last line output (profile may print info): tail -n 1
-# Output each path on its own line: tr ":" "\n"
-# Look for exactly the BINPATH: grep "^${BINPATH}$"
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv PATH" | tail -n 1 | tr ":" 
"\n" | grep "^${BINPATH}$" > /dev/null; then
-echo "Your shell already has the right PATH environment variable for use 
with MacPorts!"
-else
-write_setting PATH "\"${BINPATH}:${SBINPATH}:\$PATH\""
-fi
-
-# Adding our setting to the MANPATH variable only if it exists:
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" > /dev/null; then
-# check for MANPAGES already in MANPATH
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" | tail -n 1 | 
tr ":" "\n" | grep "^${MANPAGES}$" >/dev/null; then
-echo "Your shell already has the right MANPATH environment