Re: [macports-ports] branch master updated: libcaer: new port

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ryan Schmidt-24

On Mar 1, 2018, at 07:10, Андрей Корнилов wrote:

> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/1143d9e29ce540771dbbfc578100f28ee04b3f28
>
> The following commit(s) were added to refs/heads/master by this push:
>
>      new 1143d9e  libcaer: new port
>
> 1143d9e is described below
>
>
> commit 1143d9e29ce540771dbbfc578100f28ee04b3f28
>
> Author: Andrew Kornilov
> AuthorDate: Thu Mar 1 13:48:04 2018 +0300
>
>
>     libcaer: new port

Thanks for the port!


> +license             BSD-2-Clause

MacPorts doesn't know that license by that name; we call this license "BSD". It's important to use the correct license name so that MacPorts can distribute binaries of ports that are distributable. Changing the license after a successful build does not currently cause the buildbot to reexamine the port to distribute binaries that didn't get distributed before, so it's important to get the license correct the first time. The list of licenses we currently use is documented here:

https://trac.macports.org/wiki/PortfileRecipes#licensekeyword


> +depends_lib-append  port:libusb

The port failed to build without pkgconfig.


I've committed fixes for these issues.


Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Perry E. Metzger
On Thu, 1 Mar 2018 07:48:35 -0600 Ryan Schmidt
<[hidden email]> wrote:
> > +depends_lib-append  port:libusb  
>
> The port failed to build without pkgconfig.

Should the CI infrastructure have noticed that? I've kind of been
assuming that if CI is green you can assume the thing is okay, but
that's not the case it would seem?

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ryan Schmidt-24

On Mar 1, 2018, at 07:59, Perry E. Metzger wrote:
> On Thu, 1 Mar 2018 07:48:35 -0600 Ryan Schmidt wrote:
>>> +depends_lib-append  port:libusb  
>>
>> The port failed to build without pkgconfig.
>
> Should the CI infrastructure have noticed that? I've kind of been
> assuming that if CI is green you can assume the thing is okay, but
> that's not the case it would seem?

The builds failed on the buildbot, which is how I noticed the problem. On the buildbot, we activate the dependencies and then make sure the dependencies' build dependencies are deactivated before building the port, thus exposing the problem. I see the build succeeded on Travis CI. I guess we don't do that same process on Travis CI. Whoever is handling our Travis CI stuff might want to look into that.
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Mojca Miklavec-2
On 1 March 2018 at 15:03, Ryan Schmidt wrote:

>
> On Mar 1, 2018, at 07:59, Perry E. Metzger wrote:
>> On Thu, 1 Mar 2018 07:48:35 -0600 Ryan Schmidt wrote:
>>>> +depends_lib-append  port:libusb
>>>
>>> The port failed to build without pkgconfig.
>>
>> Should the CI infrastructure have noticed that? I've kind of been
>> assuming that if CI is green you can assume the thing is okay, but
>> that's not the case it would seem?
>
> The builds failed on the buildbot, which is how I noticed the problem. On the buildbot, we activate the dependencies and then make sure the dependencies' build dependencies are deactivated before building the port, thus exposing the problem.

When exactly do we do that? I'm not aware of it. This is the script
being called:
    https://github.com/macports/mpbb/blob/master/mpbb-install-dependencies

I do remember some special handling of dependencies, but I fail to see
when the build dependencies would be deactivated.

We certainly remove dependencies between builds, but I'm not aware of
uninstallation of build dependencies. And in any case the go scripts
ultimately call mpbb, so if we change mpbb, it should automatically be
reflected in Travis as well.

> I see the build succeeded on Travis CI. I guess we don't do that same process on Travis CI. Whoever is handling our Travis CI stuff might want to look into that.

Here's the relevant log saying that 43 dependencies were installed,
including pkgconfig:
    https://travis-ci.org/macports/macports-ports/builds/347706617

In contrast our buildbot only installed 32:
    https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/20139/steps/install-dependencies/logs/dependencies

I strongly suspect that the difference lies in non-distributability of
certain packages which need to be built on Travis first and thus
recursively depend on pkgconfig from some dependency and that
pkg-config is never deactivated. While the same package on the
buildbot slave has already been installed and never even activates
pkgconfig in the first place. I kind of suspect that if you started
with a fresh machine that would not have that dependency installed,
the build would most likely succeed on buildbot as well.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ryan Schmidt-24

On Mar 1, 2018, at 09:50, Mojca Miklavec wrote:

>> The builds failed on the buildbot, which is how I noticed the problem. On the buildbot, we activate the dependencies and then make sure the dependencies' build dependencies are deactivated before building the port, thus exposing the problem.
>
> When exactly do we do that? I'm not aware of it. This is the script
> being called:
>    https://github.com/macports/mpbb/blob/master/mpbb-install-dependencies
>
> I do remember some special handling of dependencies, but I fail to see
> when the build dependencies would be deactivated.
>
> We certainly remove dependencies between builds, but I'm not aware of
> uninstallation of build dependencies. And in any case the go scripts
> ultimately call mpbb, so if we change mpbb, it should automatically be
> reflected in Travis as well.

I thought I had seen some output in a buildbot log at some point that suggested this is what we were doing. But I guess I misinterpreted the log, and we're not doing that after all.

Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ken Cunningham
In reply to this post by Perry E. Metzger
CI is not sufficient testing to commit, sadly.

There is no xcode 9 in travis at present.
misses many things, like liscence etc
doesn't check if destrooting is right

It's OK for a minor version update of an existing port, but all new ports or sig updates need to checked out locally, port lint nitpicked, looked over carefully, build with trace mode, destrooted, and installed before commiting....

and all that will only find 80% of the problems.

The rest show up on the builbots after the commit.

Ken

> On Mar 1, 2018, at 05:59, Perry E. Metzger <[hidden email]> wrote:
>
> On Thu, 1 Mar 2018 07:48:35 -0600 Ryan Schmidt
> <[hidden email]> wrote:
>>> +depends_lib-append  port:libusb  
>>
>> The port failed to build without pkgconfig.
>
> Should the CI infrastructure have noticed that? I've kind of been
> assuming that if CI is green you can assume the thing is okay, but
> that's not the case it would seem?
>
> Perry
> --
> Perry E. Metzger        [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Perry E. Metzger
On Thu, 1 Mar 2018 08:40:51 -0800 Ken Cunningham
<[hidden email]> wrote:

> CI is not sufficient testing to commit, sadly.
>
> There is no xcode 9 in travis at present.
> misses many things, like liscence etc
> doesn't check if destrooting is right
>
> It's OK for a minor version update of an existing port, but all new
> ports or sig updates need to checked out locally, port lint
> nitpicked, looked over carefully, build with trace mode,
> destrooted, and installed before commiting....
>
> and all that will only find 80% of the problems.
>
> The rest show up on the builbots after the commit.

Looking over things carefully seems reasonable. A machine can't
figure out that a Portfile should be written differently.

Having to build locally in several ways seems bad. The purpose of
automatic CI infrastructure is to free people from needing to do
such things, both because it reduces labor and because it reduces
error. The latter is the really important bit. Manual process is
error prone.

Maybe we need more flexible (and less likely to time out) CI than
Travis can give us that includes things like port lint, traced
builds, etc?

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ken Cunningham


> On Mar 1, 2018, at 11:23 AM, Perry E. Metzger <[hidden email]> wrote:
>
> Looking over things carefully seems reasonable. A machine can't
> figure out that a Portfile should be written differently.
>
> Having to build locally in several ways seems bad. The purpose of
> automatic CI infrastructure is to free people from needing to do
> such things, both because it reduces labor and because it reduces
> error. The latter is the really important bit. Manual process is
> error prone.
>
> Maybe we need more flexible (and less likely to time out) CI than
> Travis can give us that includes things like port lint, traced
> builds, etc?
>
> Perry


I think you might get an idea of whether committing from a PR based on eyeballing it and the CI output (without locally building it and looking it over in detail in the work directory) is working based on how many fixes have to be done (usually by Ryan) to the ports after they are initially committed.

Surgeons say 90% of the appys they remove should be pathological, and 10% or so normal.

That’s probably not a bad average to aim for...

Best,

Ken
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Mojca Miklavec-2
In reply to this post by Perry E. Metzger
On 1 March 2018 at 20:23, Perry E. Metzger wrote:

> On Thu, 1 Mar 2018 08:40:51 -0800 Ken Cunningham wrote:
>> CI is not sufficient testing to commit, sadly.
>>
>> There is no xcode 9 in travis at present.
>> misses many things, like liscence etc
>> doesn't check if destrooting is right
>>
>> It's OK for a minor version update of an existing port, but all new
>> ports or sig updates need to checked out locally, port lint
>> nitpicked, looked over carefully, build with trace mode,
>> destrooted, and installed before commiting....
>>
>> and all that will only find 80% of the problems.
>>
>> The rest show up on the builbots after the commit.
>
> Looking over things carefully seems reasonable. A machine can't
> figure out that a Portfile should be written differently.
>
> Having to build locally in several ways seems bad. The purpose of
> automatic CI infrastructure is to free people from needing to do
> such things, both because it reduces labor and because it reduces
> error. The latter is the really important bit. Manual process is
> error prone.

I semi-agree with both. There's certainly more that a committer can do
before clicking the button, but there's also more we could do on the
CI side to help avoiding doing the same mistakes over and over again.

Travis should probably list all the destrooted/installed files at the
end of the run, along with permissions (rwx). Zero, would you be
willing to add that to the log?

> Maybe we need more flexible (and less likely to time out) CI than
> Travis can give us that includes things like port lint, traced
> builds, etc?

That would be nice to have, but do you have any idea how to make a
safe setup (perhaps with a fresh/disposable VM for each PR)?

"port lint" and traced builds can be done on Travis as well.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Perry E. Metzger
On Thu, 1 Mar 2018 22:25:47 +0100 Mojca Miklavec <[hidden email]>
wrote:
> > Maybe we need more flexible (and less likely to time out) CI than
> > Travis can give us that includes things like port lint, traced
> > builds, etc?  
>
> That would be nice to have, but do you have any idea how to make a
> safe setup (perhaps with a fresh/disposable VM for each PR)?

It _is_ legal for us to run macOS VMs on Apple hardware, right? It's
only prohibited on non-Apple hardware?

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Mojca Miklavec-2
On 2 March 2018 at 01:41, Perry E. Metzger wrote:

> On Thu, 1 Mar 2018 22:25:47 +0100 Mojca Miklavec wrote:
>> > Maybe we need more flexible (and less likely to time out) CI than
>> > Travis can give us that includes things like port lint, traced
>> > builds, etc?
>>
>> That would be nice to have, but do you have any idea how to make a
>> safe setup (perhaps with a fresh/disposable VM for each PR)?
>
> It _is_ legal for us to run macOS VMs on Apple hardware, right? It's
> only prohibited on non-Apple hardware?

It's not a legal question. It's a technical question. We would ideally
want to efficiently start a new VM for each test and then nuke it once
the test in finished. Or implement some other way of reverting the
state to 100% where it was before the PR.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Perry E. Metzger
On Fri, 2 Mar 2018 01:44:03 +0100 Mojca Miklavec <[hidden email]>
wrote:

> On 2 March 2018 at 01:41, Perry E. Metzger wrote:
> > On Thu, 1 Mar 2018 22:25:47 +0100 Mojca Miklavec wrote:  
> >> > Maybe we need more flexible (and less likely to time out) CI
> >> > than Travis can give us that includes things like port lint,
> >> > traced builds, etc?  
> >>
> >> That would be nice to have, but do you have any idea how to make
> >> a safe setup (perhaps with a fresh/disposable VM for each PR)?  
> >
> > It _is_ legal for us to run macOS VMs on Apple hardware, right?
> > It's only prohibited on non-Apple hardware?  
>
> It's not a legal question. It's a technical question. We would
> ideally want to efficiently start a new VM for each test and then
> nuke it once the test in finished. Or implement some other way of
> reverting the state to 100% where it was before the PR.

Well, sure, but the host environment makes a bit of a difference for
the technical effort. For example, this means we can't (for example)
simply spin up a cluster in AWS at will. Perhaps using Docker for
macOS might be an option? I haven't played with it yet though.

Or is the build cluster already using VMs? I know nothing about it.

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

SPDX identifiers (was: [macports-ports] branch master updated: libcaer: new port)

Leonardo Brondani Schenkel-3
In reply to this post by Ryan Schmidt-24
On 2018-03-01 14:48, Ryan Schmidt wrote:
>> +license             BSD-2-Clause
>
> MacPorts doesn't know that license by that name; we call this license "BSD". It's important to use the correct license name so that MacPorts can distribute binaries of ports that are distributable. Changing the license after a successful build does not currently cause the buildbot to reexamine the port to distribute binaries that didn't get distributed before, so it's important to get the license correct the first time. The list of licenses we currently use is documented here:
>
> https://trac.macports.org/wiki/PortfileRecipes#licensekeyword

I think that we should consider using SPDX license identifiers [1] in
the ports. It was deliberately made to make it easier to track
compliance, as it is the use case here. They're very precise and they're
being adopted by quite a lot of projects nowadays, for example the Linux
kernel [2].

[1] https://spdx.org/licenses/
[2] https://lwn.net/Articles/739183/

If we use the same vocabulary as everybody else has many benefits, I
think, among them is the fact it refrains the project from having to
maintain its own list, removes ambiguity and it is also easier for
contributors, so they can use the same identifiers they're used to.

In case we want to do that, we could treat our own list as "legacy"
identifiers: ports are encouraged to use SPDX license identifiers, but
the old keywords are also accepted for compatibility.

// Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: SPDX identifiers (was: [macports-ports] branch master updated: libcaer: new port)

Eitan Adler
On 1 March 2018 at 23:35, Leonardo Brondani Schenkel
<[hidden email]> wrote:

> On 2018-03-01 14:48, Ryan Schmidt wrote:
>>>
>>> +license             BSD-2-Clause
>>
>>
>> MacPorts doesn't know that license by that name; we call this license
>> "BSD". It's important to use the correct license name so that MacPorts can
>> distribute binaries of ports that are distributable. Changing the license
>> after a successful build does not currently cause the buildbot to reexamine
>> the port to distribute binaries that didn't get distributed before, so it's
>> important to get the license correct the first time. The list of licenses we
>> currently use is documented here:
>>
>> https://trac.macports.org/wiki/PortfileRecipes#licensekeyword
>
>
> I think that we should consider using SPDX license identifiers [1] in the
> ports. It was deliberately made to make it easier to track compliance, as it
> is the use case here. They're very precise and they're being adopted by
> quite a lot of projects nowadays, for example the Linux kernel [2].

I was going to suggest the same thing. FreeBSD ports uses them and
they tend to work out quite well.

Very strong +1 to this model.

--
Eitan Adler
Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Ryan Schmidt-24
In reply to this post by Perry E. Metzger

On Mar 1, 2018, at 22:14, Perry E. Metzger wrote:

> On Fri, 2 Mar 2018 01:44:03 +0100 Mojca Miklavec wrote:
>> On 2 March 2018 at 01:41, Perry E. Metzger wrote:
>>> On Thu, 1 Mar 2018 22:25:47 +0100 Mojca Miklavec wrote:  
>>>>> Maybe we need more flexible (and less likely to time out) CI
>>>>> than Travis can give us that includes things like port lint,
>>>>> traced builds, etc?  
>>>>
>>>> That would be nice to have, but do you have any idea how to make
>>>> a safe setup (perhaps with a fresh/disposable VM for each PR)?  
>>>
>>> It _is_ legal for us to run macOS VMs on Apple hardware, right?
>>> It's only prohibited on non-Apple hardware?  
>>
>> It's not a legal question. It's a technical question. We would
>> ideally want to efficiently start a new VM for each test and then
>> nuke it once the test in finished. Or implement some other way of
>> reverting the state to 100% where it was before the PR.
>
> Well, sure, but the host environment makes a bit of a difference for
> the technical effort. For example, this means we can't (for example)
> simply spin up a cluster in AWS at will. Perhaps using Docker for
> macOS might be an option? I haven't played with it yet though.
>
> Or is the build cluster already using VMs? I know nothing about it.

Yes, macOS can only be legally virtualized on Apple hardware. Yes, we are running macOS virtualized (in VMware ESXi 6.0.0U2) on Apple hardware (Xserve3,1) for the buildbot.


Reply | Threaded
Open this post in threaded view
|

Re: [macports-ports] branch master updated: libcaer: new port

Mojca Miklavec-2
On 2 March 2018 at 11:26, Ryan Schmidt wrote:

>
> On Mar 1, 2018, at 22:14, Perry E. Metzger wrote:
> >
> > Well, sure, but the host environment makes a bit of a difference for
> > the technical effort. For example, this means we can't (for example)
> > simply spin up a cluster in AWS at will. Perhaps using Docker for
> > macOS might be an option? I haven't played with it yet though.
> >
> > Or is the build cluster already using VMs? I know nothing about it.
>
> Yes, macOS can only be legally virtualized on Apple hardware. Yes, we are running macOS virtualized (in VMware ESXi 6.0.0U2) on Apple hardware (Xserve3,1) for the buildbot.

I fail to see how this would be too relevant though. Nobody says that
PRs should be checked on the same infrastructure.
(The existing infrastructure might already be too busy to add enough
new VMs anyway.)

Read it as: you can design a better testing system in any way you
want. Finding the appropriate hardware can certainly be done later and
this doesn't exclude random people donating processor power of
machines they keep at home.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: SPDX identifiers

Ryan Schmidt-24
In reply to this post by Leonardo Brondani Schenkel-3

On Mar 2, 2018, at 01:35, Leonardo Brondani Schenkel wrote:

> On 2018-03-01 14:48, Ryan Schmidt wrote:
>>> +license             BSD-2-Clause
>> MacPorts doesn't know that license by that name; we call this license "BSD". It's important to use the correct license name so that MacPorts can distribute binaries of ports that are distributable. Changing the license after a successful build does not currently cause the buildbot to reexamine the port to distribute binaries that didn't get distributed before, so it's important to get the license correct the first time. The list of licenses we currently use is documented here:
>> https://trac.macports.org/wiki/PortfileRecipes#licensekeyword
>
> I think that we should consider using SPDX license identifiers [1] in the ports. It was deliberately made to make it easier to track compliance, as it is the use case here. They're very precise and they're being adopted by quite a lot of projects nowadays, for example the Linux kernel [2].
>
> [1] https://spdx.org/licenses/
> [2] https://lwn.net/Articles/739183/
>
> If we use the same vocabulary as everybody else has many benefits, I think, among them is the fact it refrains the project from having to maintain its own list, removes ambiguity and it is also easier for contributors, so they can use the same identifiers they're used to.
>
> In case we want to do that, we could treat our own list as "legacy" identifiers: ports are encouraged to use SPDX license identifiers, but the old keywords are also accepted for compatibility.

I'm open to that. But whatever changes are made, the port_binary_distributable.tcl script has to work correctly with those changes.

https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl

That script is used by the buildbot to determine which binaries we are allowed to distribute.

Reply | Threaded
Open this post in threaded view
|

Re: SPDX identifiers

Leonardo Brondani Schenkel-3
On 2018-03-02 14:59, Ryan Schmidt wrote:
> I'm open to that. But whatever changes are made, the port_binary_distributable.tcl script has to work correctly with those changes.
>
> https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl
>
> That script is used by the buildbot to determine which binaries we are allowed to distribute.

I can volunteer to do that (not immediately, but I believe I could do it
in the upcoming weeks). Just a thought: to make the implementation more
manageable, I could implement a mapping from SPDX to "license group"
(basically the ones that are there now) so the script still deals with a
smaller set of groups instead of all the possible individual license
variations. Would you find that agreeable?

A question: since it's important to get the license right, why aren't we
failing the builds for Portfiles with an unrecognized license?

// Leoanrdo.
Reply | Threaded
Open this post in threaded view
|

Re: SPDX identifiers

Leonardo Brondani Schenkel-3
On 2018-03-02 15:05, Leonardo Brondani Schenkel wrote:
> I can volunteer to do that (not immediately, but I believe I could do it
> in the upcoming weeks). Just a thought: to make the implementation more
> manageable, I could implement a mapping from SPDX to "license group"
> (basically the ones that are there now) so the script still deals with a
> smaller set of groups instead of all the possible individual license
> variations. Would you find that agreeable?

On a second inspection, I'm not sure if that mapping to the existing
license names buys much to be honest -- you already have the groups of
"good", "restrictive", etc. so I can just map directly. Anyway, will
give it a shot when I can and share the results here.
// Leonardo.

Reply | Threaded
Open this post in threaded view
|

Re: SPDX identifiers

Ryan Schmidt-24
In reply to this post by Leonardo Brondani Schenkel-3

On Mar 2, 2018, at 08:05, Leonardo Brondani Schenkel wrote:

> On 2018-03-02 14:59, Ryan Schmidt wrote:
>> I'm open to that. But whatever changes are made, the port_binary_distributable.tcl script has to work correctly with those changes.
>> https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl
>> That script is used by the buildbot to determine which binaries we are allowed to distribute.
>
> I can volunteer to do that (not immediately, but I believe I could do it in the upcoming weeks). Just a thought: to make the implementation more manageable, I could implement a mapping from SPDX to "license group" (basically the ones that are there now) so the script still deals with a smaller set of groups instead of all the possible individual license variations. Would you find that agreeable?

Josh should comment; it's been largely his script. It's large and I haven't tried to understand it all so I don't have any advice about how it should be changed.

> A question: since it's important to get the license right, why aren't we failing the builds for Portfiles with an unrecognized license?

At a most basic level, we don't do that because nobody has suggested we do that before.

The buildbot exists not only to distribute binaries, but also to verify that ports build. It might be confusing if the buildbot claimed that a port did not build, when in fact it did build but merely did not have a license set.

I would instead say that "port lint" is where a warning for a missing license should occur -- and already does.

Just having a license set in a portfile does not guarantee that we "got it right". The portfile author may have created the port by duplicating another portfile as a starting point, and forgot to change the license. The portfile author may have misinterpreted or misunderstood the license. The software's license may have changed in an updated version and the portfile author didn't notice.

12