Proposed update to OpenSSH

[Andrew Moore]

A tentative macports/macports-ports PR #3835 to update OpenSSH to version 7.9p1 
has been submitted to help move forward Chih-Hsuan Yen’s PR #3822 to update 
OpenSSL to version 1.1.1b.  Per discussion on MacPorts Trac 
, patches to update both gsskex and hpn 
 variants have been added to the PR.

I’m interested in opinions on (at least) temporarily dropping macOS keychain 
integration as part of the gsskex (GSS-API authentication extension) variant.

The macOS keychain patch needs to be updated to OpenSSH 1.1 APIs.  It appears 
to be relatively straight forward - I got part way through the update before 
running out time. So the question is: would anyone oppose OpenSSH's gsskex 
variant being updated in stages in order to fast forward the OpenSSL 1.1 update?
-AM



smime.p7s
Description: S/MIME cryptographic signature

Re: GSoC 2019 [Collect build statistics]

[Mojca Miklavec]

On Mon, 11 Mar 2019 at 09:18, Arjun Salyan via macports-dev wrote:
>
> I have a couple of doubts here:
>
> 1. Once I install mpstats does it still send weekly reports? I could not find 
> the required code to do this in the port files. Code for manually submitting 
> is available in mpstats.tcl but I am unable to locate the code for automating 
> the submissions. What am I missing here?

Maybe try
port contents mpstats
and check the files that MacPorts reports as belonging to mpstats.

> 2. I am completely new to Buildbot. I went though their website buildbot.net, 
> I understand its functioning, but am not getting the practical approach. Can 
> you give me a brief idea of how it is implemented with Macports? Like what 
> are the events that are taking place and when?

Joshua already sent you the link to master.cfg which is the python
code that checks for new commits in the repository and starts the
builds. The other missing link might be
https://github.com/macports/mpbb, which are shell scripts used to
reduce the complexity of master.cfg (helper/convenience scripts
between buildbot and macports). The same scripts (mpbb) are used for
Travis and Azure pipelines.

(Joshua: I thought that buildbot watches the git repository on its
own, rather than listening to webhooks, but I might be wrong.)

The "results" are probably easiest to see here:
https://build.macports.org/waterfall

In principle it goes as follows:

- something is pushed to git(hub)
- buildbot sees the commits and triggers a build on every "port
watcher" (on different macOS versions)
  - a list of modified ports is established
  - for each port that needs to be built
- first the sources are fetched / mirrored (jobs-mirror)
- then the port is built and uploaded to the server in multiple steps
  - buildbot also notifies GitHub whether the build was successful or
not (you'll see a green checkbox / red cross next to commits in
macports-ports commit history)

The build can also be triggered manually.

Sadly we are still using buildbot 0.8 rather than 2.x. The github
repository contains instructions for running a buildbot master and
slave locally on your machine, so that you can test things, as Joshua
suggested.

If something is not clear, please ask in more detail.

Mojca

Re: GSoC 2019 [Collect build statistics]

[Mojca Miklavec]

On Mon, 11 Mar 2019 at 09:41, Arjun Salyan wrote:
> On Fri, Mar 8, 2019 at 11:08 PM Mojca Miklavec wrote:
>>
>> In the case of this Django app it probably makes sense to come up with a 
>> proof-of-concept demo (ideally including documentation about how to set it 
>> up and running, and either screenshot or hyperlink).
>
> Does this mean a static site about how the project would look or a dynamic 
> site with database and all the needed tables?

A static site (probably with made-up statistics data, but trying to
use proper port names etc.) and all the information as expected in the
final product would be super useful part of application itself. By
carefully planning what should be on the page and how to organize it,
it would be much easier and more straightforward to work on the
project during the summer, knowing precisely where the project should
be heading. Some basic css could be nice, but not absolutely needed:
it's more important to have the contents well-planned (even if drawn
with pencil and paper only).

A dynamic site on the other hand would serve as demonstration of your
skills. Yes, that includes the database, but not necessarily all the
tables. We did some brainstorming about design of the database during
the last GSOC application period, but that doesn't mean that the
design is final or perfect: the exact table layout would likely
change, both during project planning and implementation. When doing
the demo app, I would suggest to keep a logbook about the steps you
did; something that could later be turned into developer documentation
/ tutorial (how you created the project, how another developer can run
it on his machine).

The static and dynamic site could also be combined if needed (some
small part of the site would be dynamic, while the rest would be a
hardcoded example that you would later replace with real data from the
database).

Depending on your prior familiarity with the tools involved and the
time you want to invest into proposal / demo, think about what your
sample app could be (ideally something that you could simply build
upon / continue developing if you get selected; rather than some code
that you would later throw away). We can help you with ideas, but it
makes more sense to start with your initiative at first.

Another general suggestion (for any gsoc candidate): you don't need to
wait for the official GSOC submissions to start, and you definitely
don't want to wait for the final call. The sooner you send us a link
to your proposal and/or your demo, the earlier we can start providing
feedback, meaning that you would have plenty of time to make both
proposal and sample app better & higher chances to get selected.

Mojca

C11 compiler selection?

[Michael Dickens]

Do we have a portgroup or whatever to select a compiler for c11 compliance? In 
my testing using the c++11 1.1 PG isn't sufficient ... which might mean that 
the c++11 compiler compliance selection isn't correct (but I doubt it); or that 
c11 compiler compliance selection is different that that for c++11 (which is my 
guess). In a quick search I can find nothing obvious to do this in MP. Thanks 
for your thoughts / insights! - MLD  (ps> I need this for the latest 
GLFW-devel, which uses  ...)

Re: GSoC 2019 [Collect build statistics]

[Joshua Root]

On 2019-3-11 19:18 , Arjun Salyan wrote:
> I have a couple of doubts here:
> 
> 1. Once I install mpstats does it still send weekly reports? I could not
> find the required code to do this in the port files. Code for manually
> submitting is available in mpstats.tcl but I am unable to locate the
> code for automating the submissions. What am I missing here?

The launchd plist it installs causes it to run periodically.

> 2. I am completely new to Buildbot. I went though their website
> buildbot.net , I understand its functioning, but am
> not getting the practical approach. Can you give me a brief idea of how
> it is implemented with Macports? Like what are the events that are
> taking place and when?

Buildbot is a fairly complex multilayered system and takes a while to
grok. Our configuration is here:

(master.cfg is the main file there). It may help to try to set up a
small buildbot of your own?

The basic process is that whenever a commit is pushed to our GitHub
repo, buildbot is notified via a webhook, and then figures out which
ports were touched by the commit and builds them (on each OS version).

- Josh

Re: GSoC 2019 [Collect build statistics]

[Arjun Salyan via macports-dev]

I have a couple of doubts here:

1. Once I install mpstats does it still send weekly reports? I could not
find the required code to do this in the port files. Code for manually
submitting is available in mpstats.tcl but I am unable to locate the code
for automating the submissions. What am I missing here?

2. I am completely new to Buildbot. I went though their website buildbot.net,
I understand its functioning, but am not getting the practical approach.
Can you give me a brief idea of how it is implemented with Macports? Like
what are the events that are taking place and when?

Thank You.

On Sat, Mar 9, 2019 at 6:26 PM Joshua Root  wrote:

> On 2019-3-9 22:55 , Saagar Jha wrote:
> >
> > FWIW, while I am not opposed to MacPorts adding clearly communicated,
> > opt-in, self-hosted analytics; I would be /very/ strongly against doing
> > this if any of these conditions was not met. Doubly so if the initial
> > discussion to do this is made without users being able to provide input,
> > triply if the feature stays largely unchanged even when users complain,
> > and quadruply if this discussion is forcefully closed, unresolved,
> > because “the feature has already shipped”.
>
> Yes, gathering of this data needs to remain strictly opt-in, and using
> something like Google Analytics would be a whole new rabbit hole of
> issues that we don't want.
>
> It's already easy enough for users to participate by installing mpstats;
> the missing piece is advertising its existence and suggesting that users
> install it. The only reason we're not doing that is that the stats
> system still needs work.
>
> - Josh
>

Re: New Portfiles

[Rainer Müller]

On 11.03.19 01:13, MacPorts wrote:
> I don't remember why I ended up making a new port for html-tree.
> 
> There seem to be two different modules at cpan that use the name
> Web::Scraper. One uses Web::Scraper::LibXML. The port I created includes
> the module that uses Web::Scraper::LibXML.

It is in fact the same Web-Scraper module on CPAN. The existing port
p5-web-scraper already includes the Web::Scraper::LibXML interface.

$ port -q contents p5.26-web-scraper |grep LibXML
  /opt/local/lib/perl5/vendor_perl/5.26/Web/Scraper/LibXML.pm
  /opt/local/share/perl5.26/man/man3/Web::Scraper::LibXML.3pm

However, it is not functional as the HTML::TreeBuilder::LibXML
dependency you want to add is indeed missing at the moment.

$ perl5.26 -e 'use Web::Scraper::LibXML;'
Can't locate HTML/TreeBuilder/LibXML.pm in @INC (you may need to install
the HTML::TreeBuilder::LibXML module) [...]

I would advice to only add the dependency on p5-html-treebuilder-libxml
to the existing p5-web-scraper port after the former has been merged.

Rainer