pure, pure-gen and pd-pure updates
Hi everybody, these have been hanging in the pull requests for some time now, and the updates are important for Pure users as well as my students. Can someone with commit access please have a look and merge these. That would be much appreciated, thanks. https://github.com/macports/macports-ports/pull/350 https://github.com/macports/macports-ports/pull/335 https://github.com/macports/macports-ports/pull/357 Best, Albert P.S.: Everybody on the team, congrats for being selected for GSoC 2017! :) -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggr...@gmail.com WWW:https://plus.google.com/+AlbertGraef
Re: binary packages missing
> On Mar 4, 2017, at 2:52 PM, Mojca Miklavec wrote: > > On 4 March 2017 at 20:20, Mojca Miklavec wrote: >> On 4 March 2017 at 20:12, Mark Moll wrote: >>> Hi, >>> >>> For one of the packages I maintain, ompl, there are no recent binary >>> packages, despite the port being redistributable. I suspect it’s due to a >>> build time-out. The Python binding generation for the C++ library can take >>> an hour or two during which very little output is generated. Is it possible >>> to force an increase in build time for a particular build? >> >> Let's wait for a quiet moment at buildbots, rerun a build of that port >> and see what happens. > > https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/4029 > https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/22307 As expected, the build times out. Mark signature.asc Description: Message signed with OpenPGP
Timeout on the buildbot (wa: binary packages missing
On 4 March 2017 at 21:52, Mojca Miklavec wrote: > On 4 March 2017 at 20:20, Mojca Miklavec wrote: >> On 4 March 2017 at 20:12, Mark Moll wrote: >>> Hi, >>> >>> For one of the packages I maintain, ompl, there are no recent binary >>> packages, despite the port being redistributable. I suspect it’s due to a >>> build time-out. The Python binding generation for the C++ library can take >>> an hour or two during which very little output is generated. Is it possible >>> to force an increase in build time for a particular build? >> >> Let's wait for a quiet moment at buildbots, rerun a build of that port >> and see what happens. > > https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/4029 > https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/22307 Indeed, it's a timeout issue. By far the easiest thing to do would be to force the command to produce some output, but I don't know if there's anyone you could ask to let you do it (some verbose option being passed to a command ...). No output for 20 minutes is indeed a bit suspicious. See: http://docs.buildbot.net/latest/manual/cfg-buildsteps.html#using-shellcommands timeout: if the command fails to produce any output for this many seconds, it is assumed to be locked up and will be killed. This defaults to 1200 seconds. Pass None to disable. So we can disable it for all ports (and then experience serious problems when there will be infinite loops or some hanging involved). Another possible solution would be to introduce a checkbox (or another text field that accepts numeric values for timeout) and then trigger the build manually with that checkbox enabled for the ports where this is known to be a problem? Do you have any better suggestions? Please open a Trac ticket (with "buildbot" as a keyword) and provide some suggestions about the best way to deal with this problem in case you cannot solve it in a different way. We had that problems with git checkouts, but we added some flags to produce some output, I think. Mojca
Re: binary packages missing
On 4 March 2017 at 20:20, Mojca Miklavec wrote: > On 4 March 2017 at 20:12, Mark Moll wrote: >> Hi, >> >> For one of the packages I maintain, ompl, there are no recent binary >> packages, despite the port being redistributable. I suspect it’s due to a >> build time-out. The Python binding generation for the C++ library can take >> an hour or two during which very little output is generated. Is it possible >> to force an increase in build time for a particular build? > > Let's wait for a quiet moment at buildbots, rerun a build of that port > and see what happens. https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/4029 https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/22307 Mojca
Re: binary packages missing
On 4 March 2017 at 20:12, Mark Moll wrote: > Hi, > > For one of the packages I maintain, ompl, there are no recent binary > packages, despite the port being redistributable. I suspect it’s due to a > build time-out. The Python binding generation for the C++ library can take an > hour or two during which very little output is generated. Is it possible to > force an increase in build time for a particular build? Let's wait for a quiet moment at buildbots, rerun a build of that port and see what happens. (I could start it now, but then you need to keep observing when the build would start, so it's more convenient to find a moment when all the builds start at the same time.) Mojca PS: please update the email of this mailing list in your address book.
binary packages missing
Hi, For one of the packages I maintain, ompl, there are no recent binary packages, despite the port being redistributable. I suspect it’s due to a build time-out. The Python binding generation for the C++ library can take an hour or two during which very little output is generated. Is it possible to force an increase in build time for a particular build? Mark signature.asc Description: Message signed with OpenPGP
Re: buildbot: +quartz ?
> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec wrote: > > On 4 March 2017 at 03:51, Craig Treleaven wrote: >> I know that we would like to find a clean solution to building ports with >> non-default variants. As an interim step, however, I wonder if we might >> consider a buildbot that is configured to default to “+quartz”? > > We don't even need a separate buildbot. Just a relatively simple > improvement to the existing buildbot. > > See: > https://trac.macports.org/ticket/52742 > > I suggested adding a field to allow manually specifying arbitrary > values for variants. But we would need some automatism as well. > Perhaps something like the following: > > If variant quartz exists, build the port once again, but this time > with '+quartz' > > but covering all corner cases (when +x11 +quartz is allowed together > and when it is not …). If we use the existing buildbot instances, won’t they they try to upload built binaries to packages.macports.org? In another ticket [1], you noted the problem where an indirect dependency must be built with +quartz. This is why I felt a dedicated “PlusQuartz” buildbot might be a simple solution that we could get running quickly. [1] https://trac.macports.org/ticket/40294 I note that there have been tickets about this practically since the buildbots were first implemented. I think it would be better to get a partial solution implemented now rather than spend more years waiting for perfection. As they say: “Late answers are wrong answers." Craig (Second attempt to send; using lists.macports.org didn’t work.)
Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port
> On Mar 4, 2017, at 07:41, Joshua Root wrote: > > On 2017-3-5 00:24 , Ryan Schmidt wrote: >> >>> On Mar 4, 2017, at 07:22, Aljaž Srebrnič wrote: >>> >>> Well, yeah, they should be both distributable, so there’s no need to treat >>> them separately. I’ll update the license momentarily. There should be no >>> need to update the revision, right? >> >> There should be no need to update the revision, however the buildbot will >> not distribute the archives until the revision or version changes; this is a >> bug tracked at https://trac.macports.org/ticket/53548 and was supposed to be >> fixed but the fix apparently doesn't work. > > Have you actually tried it lately? > I just did and it worked fine. https://build.macports.org/builders/ports-10.6_i386_legacy-watcher/builds/5130
Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port
On 2017-3-5 00:24 , Ryan Schmidt wrote: On Mar 4, 2017, at 07:22, Aljaž Srebrnič wrote: Well, yeah, they should be both distributable, so there’s no need to treat them separately. I’ll update the license momentarily. There should be no need to update the revision, right? There should be no need to update the revision, however the buildbot will not distribute the archives until the revision or version changes; this is a bug tracked at https://trac.macports.org/ticket/53548 and was supposed to be fixed but the fix apparently doesn't work. Have you actually tried it lately?
Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port
> On Mar 4, 2017, at 07:22, Aljaž Srebrnič wrote: > >> On 04 mar 2017, at 14:17, Ryan Schmidt wrote: >> >>> >>> On Mar 4, 2017, at 07:09, Aljaž Srebrnič wrote: >>> >>> Aljaž Srebrnič (g5pw) pushed a commit to branch master >>> in repository macports-ports. >>> >>> >>> https://github.com/macports/macports-ports/commit/f807864e8533c48c999bd8fcaa5451aa64dc5a07 >>> >>> commit f807864e8533c48c999bd8fcaa5451aa64dc5a07 >>> >>> Author: Aljaž "g5pw" Srebrnič >>> AuthorDate: Sat Mar 4 13:17:05 2017 +0100 >>> >>> >>> textproc/terminal_markdown_viewer: new port >>> >>> >>> >>> Closes: https://trac.macports.org/ticket/53591 >> >> >>> +license BSD-3-Clause >> >> So far, we have only referred to this (and the 2-clause version) as "BSD". >> Referring to it by this other name causes it not to be distributable: >> >> $ ~/macports/macports-infrastructure/jobs/port_binary_distributable.tcl -v >> terminal_markdown_viewer >> "terminal_markdown_viewer" is not distributable because its license >> "bsd-3-clause" is not known to be distributable >> >> If we are going to change how we refer to the BSD license in MacPorts, then >> we would have to update that script, and change the thousands of ports under >> that license. So maybe it's simpler to just continue to say "license BSD" in >> this port instead. > > Well, yeah, they should be both distributable, so there’s no need to treat > them separately. I’ll update the license momentarily. There should be no need > to update the revision, right? There should be no need to update the revision, however the buildbot will not distribute the archives until the revision or version changes; this is a bug tracked at https://trac.macports.org/ticket/53548 and was supposed to be fixed but the fix apparently doesn't work.
Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port
> On 04 mar 2017, at 14:17, Ryan Schmidt wrote: > >> >> On Mar 4, 2017, at 07:09, Aljaž Srebrnič wrote: >> >> Aljaž Srebrnič (g5pw) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/f807864e8533c48c999bd8fcaa5451aa64dc5a07 >> >> commit f807864e8533c48c999bd8fcaa5451aa64dc5a07 >> >> Author: Aljaž "g5pw" Srebrnič >> AuthorDate: Sat Mar 4 13:17:05 2017 +0100 >> >> >>textproc/terminal_markdown_viewer: new port >> >> >> >>Closes: https://trac.macports.org/ticket/53591 > > >> +license BSD-3-Clause > > So far, we have only referred to this (and the 2-clause version) as "BSD". > Referring to it by this other name causes it not to be distributable: > > $ ~/macports/macports-infrastructure/jobs/port_binary_distributable.tcl -v > terminal_markdown_viewer > "terminal_markdown_viewer" is not distributable because its license > "bsd-3-clause" is not known to be distributable > > If we are going to change how we refer to the BSD license in MacPorts, then > we would have to update that script, and change the thousands of ports under > that license. So maybe it's simpler to just continue to say "license BSD" in > this port instead. Well, yeah, they should be both distributable, so there’s no need to treat them separately. I’ll update the license momentarily. There should be no need to update the revision, right? -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677
Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port
> On Mar 4, 2017, at 07:09, Aljaž Srebrnič wrote: > > Aljaž Srebrnič (g5pw) pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/f807864e8533c48c999bd8fcaa5451aa64dc5a07 > > commit f807864e8533c48c999bd8fcaa5451aa64dc5a07 > > Author: Aljaž "g5pw" Srebrnič > AuthorDate: Sat Mar 4 13:17:05 2017 +0100 > > > textproc/terminal_markdown_viewer: new port > > > > Closes: https://trac.macports.org/ticket/53591 > +license BSD-3-Clause So far, we have only referred to this (and the 2-clause version) as "BSD". Referring to it by this other name causes it not to be distributable: $ ~/macports/macports-infrastructure/jobs/port_binary_distributable.tcl -v terminal_markdown_viewer "terminal_markdown_viewer" is not distributable because its license "bsd-3-clause" is not known to be distributable If we are going to change how we refer to the BSD license in MacPorts, then we would have to update that script, and change the thousands of ports under that license. So maybe it's simpler to just continue to say "license BSD" in this port instead.
Re: buildbot: +quartz ?
On Mar 3, 2017, at 20:51, Craig Treleaven wrote: > (Second attempt to send; copying lists.macosforge.org address) You don't need to do that. Just write to lists.macports.org. If you forget and write to the old lists.macosforge.org address instead, it will forward to lists.macports.org, provided you don't use SPF.
