Re: [macports-ports] branch master updated: libcaer: new port
Hi, On Sat, Mar 03, 2018 at 06:50:35AM +, Zero King wrote: > Let's discuss this during the meeting, I also have to check why it > failed to upload logs to the pastebin. From > https://travis-ci.org/macports/macports-ports/jobs/348478666#L316, it > seems to be a permission problem. Do we keep HTTP logs for > paste.macports.org? Checking the logs around that time (or start a new > build and analyze) should help. Turns out we misconfigured the rules that allow Travis CI to submit pastes to our server. We fixed this now and will keep an eye on the next PR builds. -- Clemens
Re: [macports-ports] branch master updated: libcaer: new port
On Thu, Mar 01, 2018 at 10:25:47PM +0100, Mojca Miklavec wrote: 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? Let's discuss this during the meeting, I also have to check why it failed to upload logs to the pastebin. From https://travis-ci.org/macports/macports-ports/jobs/348478666#L316, it seems to be a permission problem. Do we keep HTTP logs for paste.macports.org? Checking the logs around that time (or start a new build and analyze) should help. 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 -- Best regards, Zero King smime.p7s Description: S/MIME cryptographic signature
Re: [macports-ports] branch master updated: libcaer: new port
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
Re: [macports-ports] branch master updated: libcaer: new port
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.
Re: [macports-ports] branch master updated: libcaer: new port
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. Perry -- Perry E. Metzgerpe...@piermont.com
Re: [macports-ports] branch master updated: libcaer: new port
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
Re: [macports-ports] branch master updated: libcaer: new port
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? Perry -- Perry E. Metzgerpe...@piermont.com
Re: [macports-ports] branch master updated: libcaer: new port
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
Re: [macports-ports] branch master updated: libcaer: new port
> On Mar 1, 2018, at 11:23 AM, Perry E. Metzger 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
Re: [macports-ports] branch master updated: libcaer: new port
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. 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. Metzgerpe...@piermont.com
Re: [macports-ports] branch master updated: libcaer: new port
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 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? > > Perry > -- > Perry E. Metzgerpe...@piermont.com
Re: [macports-ports] branch master updated: libcaer: new port
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.
Re: [macports-ports] branch master updated: libcaer: new port
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
Re: [macports-ports] branch master updated: libcaer: new port
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.
Re: [macports-ports] branch master updated: libcaer: new port
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? Perry -- Perry E. Metzgerpe...@piermont.com
Re: [macports-ports] branch master updated: libcaer: new port
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.
