On 2018-04-12 20:14, db wrote:
> On 12 Apr 2018, at 18:52, Ryan Schmidt wrote:
>> 1. MacPorts does not have a method of declaring that a port does not build
>> on a version of macOS. Such a feature is being discussed:
>> https://trac.macports.org/ticket/15712
>> In the absence of this feature, we
On Apr 12, 2018, at 13:38, db wrote:
> On 12 Apr 2018, at 20:16, Ryan Schmidt wrote:
>> You may have noticed that discussion about the issue resumed 4 weeks ago,
>> and a milestone was assigned.
>
> I didn't notice the milestone. Is 2.6 next year's?
Milestones don't have specific dates. We wan
On 12 Apr 2018, at 20:16, Ryan Schmidt wrote:
> You may have noticed that discussion about the issue resumed 4 weeks ago, and
> a milestone was assigned.
I didn't notice the milestone. Is 2.6 next year's?
On 12 Apr 2018, at 19:52, Craig Treleaven wrote:
> Is there a playground somewhere to try out such features? For those of us
> that are somewhat git- and github-challenged.
Not that I'm aware of. Just fork some repo or create a new one and make it your
playground.
On Apr 12, 2018, at 13:14, db wrote:
> On 12 Apr 2018, at 18:52, Ryan Schmidt wrote:
>> 1. MacPorts does not have a method of declaring that a port does not build
>> on a version of macOS. Such a feature is being discussed:
>> https://trac.macports.org/ticket/15712
>> In the absence of this feat
On 12 Apr 2018, at 18:52, Ryan Schmidt wrote:
> 1. MacPorts does not have a method of declaring that a port does not build on
> a version of macOS. Such a feature is being discussed:
> https://trac.macports.org/ticket/15712
> In the absence of this feature, we write pre-fetch blocks that manually
> On Apr 12, 2018, at 1:35 PM, db wrote:
>
> On 12 Apr 2018, at 14:27, Mojca Miklavec wrote:
>> What nobody mentioned so far is that one can also simply click "Edit" on the
>> existing Portfile on GitHub interface and that will also open a pull request.
>
> Interesting. It seems that 'Create n
On 12 Apr 2018, at 14:27, Mojca Miklavec wrote:
> What nobody mentioned so far is that one can also simply click "Edit" on the
> existing Portfile on GitHub interface and that will also open a pull request.
Interesting. It seems that 'Create new file' would have a similar effect.
'Upload files'
On Apr 12, 2018, at 06:59, db wrote:
> On 8 Apr 2018, at 02:04, Rainer Müller wrote:
>> So here is the full plan in detail:
>
> Side note: Wouldn't it be feasible to adjust portfiles based on CI's
> feedback? Let's say, you have something build on 10.6-10.13, but for whatever
> reason it fails
On 12 April 2018 at 13:59, db wrote:
>
> Side note: Wouldn't it be feasible to adjust portfiles based on CI's
> feedback? Let's say, you have something build on 10.6-10.13, but for whatever
> reason it fails on 10.9, so that could be reflected in the portfile in order
> to avoid having users bui
On 12 April 2018 at 13:59, db wrote:
> On 11 Apr 2018, at 19:24, Perry E. Metzger wrote:
>> The main steps are:
>> […]
>> [By the way, if someone wants to turn this email into a document, I
>> was pretty careful writing what's above so that would be easy.]
>
> Thanks for the write-up. Although I pr
On 8 Apr 2018, at 02:04, Rainer Müller wrote:
> So here is the full plan in detail:
Side note: Wouldn't it be feasible to adjust portfiles based on CI's feedback?
Let's say, you have something build on 10.6-10.13, but for whatever reason it
fails on 10.9, so that could be reflected in the portf
On 11 Apr 2018, at 19:24, Perry E. Metzger wrote:
> The main steps are:
> […]
> [By the way, if someone wants to turn this email into a document, I
> was pretty careful writing what's above so that would be easy.]
Thanks for the write-up. Although I probably rather prefer the PR way, it's
gettin
On Wed, 11 Apr 2018 11:48:22 -0400 Craig Treleaven
wrote:
> At the moment, only 18 of 403 open submission tickets are less than
> 12 months old. A further 23 are between 12 months and 2 years
> old.
The PR queue was pretty long (about five pages of stuff!) when I
started working on it. It is now
On 2018-04-11 18:55, Perry E. Metzger wrote:
> Just a side note: other package building systems have dealt (in
> various ways) with being able to build things without privileges.
>
> For example, the Debian project has a cool tool called "fakeroot"
> which uses an LD_PRELOADed library to make thin
On Wed, 11 Apr 2018 16:50:02 +0200 db wrote:
> On 11 Apr 2018, at 15:44, Mojca Miklavec wrote:
> > Are you willing to open pull requests for your submissions?
>
> Sure. I just need to learn how and if I'm allowed to.
Anyone can submit a GitHub pull request to any GitHub repo. (The owner
can s
On Wed, 11 Apr 2018 15:01:24 +0200 Rainer Müller
wrote:
> On 2018-04-11 14:11, db wrote:
> > It means that ports I submitted like stem and ipfs are not
> > further reviewed, so new portfiles I write I just keep in my
> > local repo and don't bother submitting.
>
> There are more than 400 pendin
On Sun, 8 Apr 2018 12:20:34 +0200 db wrote:
> On 7 Apr 2018, at 19:44, Clemens Lang wrote:
> > Remember that Portfiles can execute arbitrary code and root
> > access is available from Portfiles. We do not want to run
> > arbitrary code in a PR on the same build machines we use to build
> > packag
On Sat, 7 Apr 2018 19:44:40 +0200 Clemens Lang
> Remember that Portfiles can execute arbitrary code and root access
> is available from Portfiles. We do not want to run arbitrary code
> in a PR on the same build machines we use to build packages that we
> will distribute to our users. A malicous a
> On Apr 11, 2018, at 10:37 AM, Mojca Miklavec wrote:
>
> On 11 April 2018 at 16:18, Joshua Root wrote:
>>
>> Certainly let's encourage contributors who have something to submit to
>> use PRs. But I don't know that simply moving existing tickets over to
>> PRs without the involvement of the orig
On 2018-04-11 16:43, Joshua Root wrote:
> On 2018-4-12 00:37 , Mojca Miklavec wrote:
>> We could move them to something like "changesneeded" (not sure where
>> exactly; they could get a special status, even if closed, but it
>> should be easy enough to find them should anyone have motivation to
>>
On 11 Apr 2018, at 15:44, Mojca Miklavec wrote:
> On 11 April 2018 at 14:11, db wrote:
>> On 10 Apr 2018, at 20:07, Mojca Miklavec wrote:
>>>
That streamlined process is what keeps new and updated portfiles in my
local repo…
>>> I have no clue what you wanted to say with this.
>> It me
On 2018-4-12 00:37 , Mojca Miklavec wrote:
> We could move them to something like "changesneeded" (not sure where
> exactly; they could get a special status, even if closed, but it
> should be easy enough to find them should anyone have motivation to
> fix the remaining issues). Just because none o
On 11 April 2018 at 16:18, Joshua Root wrote:
>
> Certainly let's encourage contributors who have something to submit to
> use PRs. But I don't know that simply moving existing tickets over to
> PRs without the involvement of the original contributor will be useful.
In any case I don't think that
On 2018-4-11 23:55 , Mojca Miklavec wrote:
> On 11 April 2018 at 15:47, G A wrote:
>> Can these 400 new or pending ports on Trac be rolled over into the repo as
>> PRs?
>
> Yes, that would be ideal, and any help doing that would be greatly
> appreciated.
>
> It would probably make sense to make
I've taken some of them on, including the oldest one (From Ryan, of all people)
for a game called enigma from a submission 10 years ago.
I advise you to be very careful with them, based on the ones I've seen.
Lots of them are not of high quality, build wrongly or against the wrong
libraries, a
On 11 April 2018 at 15:47, G A wrote:
> Can these 400 new or pending ports on Trac be rolled over into the repo as
> PRs?
Yes, that would be ideal, and any help doing that would be greatly appreciated.
It would probably make sense to make a mass-edit on Trac to invite
authors to submit PRs, but b
Can these 400 new or pending ports on Trac be rolled over into the repo as
PRs?
On Wed, Apr 11, 2018 at 06:01 Rainer Müller wrote:
> On 2018-04-11 14:11, db wrote:
> > I won't address every single point and just say that it might be
> interpreted as finger-pointing, but I'm actually curious abou
On 2018-04-11 14:11, db wrote:
> I won't address every single point and just say that it might be interpreted
> as finger-pointing, but I'm actually curious about what's the state of the
> project, how it got where it is, where is it going, should I build always
> from source, should I use anoth
On 10 Apr 2018, at 20:07, Mojca Miklavec wrote:
> On 7 April 2018 at 15:45, db wrote:
>> On 7 Apr 2018, at 14:37, Ryan Schmidt wrote:
>> Is buildbot running on your basement???
> Yes (not mine).
> […]
>> Testing and reproducibility, doesn't seem to me as user to be a prime
>> concern in MP.
> We
On 7 April 2018 at 15:45, db wrote:
> On 7 Apr 2018, at 14:37, Ryan Schmidt wrote:
>
> Is buildbot running on your basement???
Yes (not mine).
> Streamlining this process could have been something for GSoC.
Until the autumn of 2016 we had no concept of pull requests at all and
we had nearly no i
On 2018-04-07, at 5:04 PM, Rainer Müller wrote:
> For distfiles, it would be possibile to apply a trick with a union mount
> to create a local overlay that allows writing new files:
>
> mount -t nfs -o ro,union mirror:.../distfiles \
>/opt/local/var/macports/distfiles
> hdiutil create -o /tm
On Apr 8, 2018, at 10:20, Ken Cunningham wrote:
> On 2018-04-08, at 6:46 AM, Ryan Schmidt wrote:
>
>> Yes, I know you like to build your legacy MacPorts installs with a different
>> copy of curl. And yes, we have a ticket tracking that issue as well.
>
> It's my nature.
>
> I just can't unde
On 2018-04-08, at 6:46 AM, Ryan Schmidt wrote:
> Yes, I know you like to build your legacy MacPorts installs with a different
> copy of curl. And yes, we have a ticket tracking that issue as well.
It's my nature.
I just can't understand why people would spend years working around a problem
t
On Apr 8, 2018, at 08:40, Ken Cunningham wrote:
>
> On Apr 8, 2018, at 03:49, Rainer Müller wrote:
>
>> We need to stop investing
>> so much effort into legacy systems.
>
> True. Making current software build on ancient compliers is a waste of
> effort.
>
> Finish the plan to push all those
> On Apr 8, 2018, at 03:49, Rainer Müller wrote:
>
> We need to stop investing
> so much effort into legacy systems.
True. Making current software build on ancient compliers is a waste of effort.
Finish the plan to push all those systems to libc++, put forward a modern clang
in portconfigur
On Apr 8, 2018, at 07:02, db wrote:
> On 8 Apr 2018, at 13:50, Ryan Schmidt wrote:
>> On Apr 8, 2018, at 06:49, db wrote:
>> On 8 Apr 2018, at 13:34, Ryan Schmidt wrote:
No, as I think we've explained several times already, now, Travis CI
builds the proposed change automatically, immed
On 8 Apr 2018, at 13:50, Ryan Schmidt wrote:
> On Apr 8, 2018, at 06:49, db wrote:
> On 8 Apr 2018, at 13:34, Ryan Schmidt wrote:
>>> No, as I think we've explained several times already, now, Travis CI builds
>>> the proposed change automatically, immediately after it's submitted. The
>>> purpo
On Apr 8, 2018, at 06:49, db wrote:
> On 8 Apr 2018, at 13:34, Ryan Schmidt wrote:
>> No, as I think we've explained several times already, now, Travis CI builds
>> the proposed change automatically, immediately after it's submitted. The
>> purpose is to verify that it builds, and the results o
On 8 Apr 2018, at 13:34, Ryan Schmidt wrote:
> No, as I think we've explained several times already, now, Travis CI builds
> the proposed change automatically, immediately after it's submitted. The
> purpose is to verify that it builds, and the results of that build can inform
> our review.
Th
On Apr 8, 2018, at 06:32, db wrote:
> On 8 Apr 2018, at 13:18, Ryan Schmidt wrote:
>> On Apr 8, 2018, at 06:12, db wrote:
>>> That seems to waste at least buildtime and storage.
>> What do you mean?
>>> Many updates and revbumps could be almost automatically deployed (after a
>>> quick review).
>
On 8 Apr 2018, at 13:18, Ryan Schmidt wrote:
> On Apr 8, 2018, at 06:12, db wrote:
>> That seems to waste at least buildtime and storage.
> What do you mean?
>> Many updates and revbumps could be almost automatically deployed (after a
>> quick review).
> Isn't that we do now?
It seems to me that
On Apr 8, 2018, at 06:12, db wrote:
> On 8 Apr 2018, at 12:42, Zero King wrote:
>> On Sun, Apr 08, 2018 at 12:20:34PM +0200, db wrote:
>>> If you review the code before, that should never be the case and it would
>>> build just once if it succeeds, right? Or am I missing something how PRs
>>> ar
On 8 Apr 2018, at 12:42, Zero King wrote:
> On Sun, Apr 08, 2018 at 12:20:34PM +0200, db wrote:
>> If you review the code before, that should never be the case and it would
>> build just once if it succeeds, right? Or am I missing something how PRs are
>> handled?
> CI builds are automatically s
On 2018-04-08 12:06, Ryan Schmidt wrote:
>> As the buildbot has no local packages installed, operations like
>> checking for the existence of a package over HTTP and then fetching the
>> file will be slow. I expect this to be one major bottleneck. Our usual
>> portbuilders have all previously built
On Sun, Apr 08, 2018 at 12:20:34PM +0200, db wrote:
On 7 Apr 2018, at 19:44, Clemens Lang wrote:
Remember that Portfiles can execute arbitrary code and root access is
available from Portfiles. We do not want to run arbitrary code in a PR
on the same build machines we use to build packages that
On 7 Apr 2018, at 19:44, Clemens Lang wrote:
> Remember that Portfiles can execute arbitrary code and root access is
> available from Portfiles. We do not want to run arbitrary code in a PR
> on the same build machines we use to build packages that we will
> distribute to our users. A malicous att
On Apr 7, 2018, at 19:04, Rainer Müller wrote:
> On 2018-04-07 19:44, Clemens Lang wrote:
>> For these resons, we want to reset the machines to a clean state before
>> every build, which we could do with buildbot, but requires some python
>> magic that hasn't been written yet.
>
> I think this is
On 2018-04-07 19:44, Clemens Lang wrote:
> For these resons, we want to reset the machines to a clean state before
> every build, which we could do with buildbot, but requires some python
> magic that hasn't been written yet.
I think this is mostly written. What is needed is only a little bit of
c
On 2018-04-07 07:40, Mojca Miklavec wrote:
>>> - with a bit of legal questionability
>>
>> From my understanding, it is legal to virtualize macOS, as long as the
>> hypervisor is running on a Mac as well, which is possible.
>
> I'm aware that it's legal to virtualize macOS on mac hardware, it's
>
Hi,
On Sat, Apr 07, 2018 at 03:45:29PM +0200, db wrote:
> On 7 Apr 2018, at 14:37, Ryan Schmidt wrote:
> > Only after a PR has been approved and merged to master should a
> > binary be uploaded anywhere.
>
> That's what I meant — but reusing buildbot for testing the PRs.
Remember that Portfiles
Thanks for the explanation.
On 7 Apr 2018, at 14:37, Ryan Schmidt wrote:
> Only after a PR has been approved and merged to master should a binary be
> uploaded anywhere.
That's what I meant — but reusing buildbot for testing the PRs.
> Our buildbot system was originally set up in 2011 by macOS
On Apr 7, 2018, at 07:02, db wrote:
> On 7 Apr 2018, at 07:47, Mojca Miklavec wrote:
>> No, because that would make the infrastructure that distributes binaries to
>> all our users susceptible to malicious PRs.
>
> How is reviewing a PR, then letting it build and, if it succeeds, uploading
> t
On Apr 7, 2018, at 00:47, Mojca Miklavec wrote:
> On 3 April 2018 at 21:45, db wrote:
>> On 3 Apr 2018, at 18:04, Mojca Miklavec wrote:
>>> Travis has lots of limitations, but it offers both (a) and (b) for free.
>>
>> Couldn't (b) be the current infrastructure?
>
> No, because that would make
On Apr 7, 2018, at 00:40, Mojca Miklavec wrote:
> I'm aware that it's legal to virtualize macOS on mac hardware, it's
> just not 100% clear to me that all of the steps involved in setting up
> libvirt images are 100% OK. (Can those same images be used on Linux
> unmodified? If so, I would at leas
On 7 Apr 2018, at 07:47, Mojca Miklavec wrote:
> No, because that would make the infrastructure that distributes binaries to
> all our users susceptible to malicious PRs.
How is reviewing a PR, then letting it build and, if it succeeds, uploading the
binary, if not, reporting the results — diff
On 3 April 2018 at 21:45, db wrote:
> On 3 Apr 2018, at 18:04, Mojca Miklavec wrote:
>> Travis has lots of limitations, but it offers both (a) and (b) for free.
>
> Couldn't (b) be the current infrastructure?
No, because that would make the infrastructure that distributes
binaries to all our users
On 3 April 2018 at 19:26, Rainer Müller wrote:
> On 2018-04-03 13:37, Mojca Miklavec wrote:
>>> We can already trigger our Buildbot directly from GitHub and could spawn
>>> a VM from a snapshot using libvirt.
>>
>> My (potentially wrong) impression was that libvirt only works:
>> - from 10.11 on
>
On 3 Apr 2018, at 18:04, Mojca Miklavec wrote:
> Travis has lots of limitations, but it offers both (a) and (b) for free.
Couldn't (b) be the current infrastructure? If I understood correctly previous
posts, Travis builds PRs for 10.11-10.13, but then Buildbot builds the binaries
that are being
On 2018-04-03 13:37, Mojca Miklavec wrote:
>> We can already trigger our Buildbot directly from GitHub and could spawn
>> a VM from a snapshot using libvirt.
>
> My (potentially wrong) impression was that libvirt only works:
> - from 10.11 on
I think you are mixing things up here. libvirt offers a
On 3 April 2018 at 14:43, db wrote:
> On 3 Apr 2018, at 13:09, Rainer Müller wrote:
>> But what exactly do you think would be the benefit from such a complicated
>> setup (GitHub -> GitLab -> External Runner)?
>
> Testing? But hey, I only know MP's infrastructure from what I read in the
> list,
On 3 Apr 2018, at 13:09, Rainer Müller wrote:
> But what exactly do you think would be the benefit from such a complicated
> setup (GitHub -> GitLab -> External Runner)?
Testing? But hey, I only know MP's infrastructure from what I read in the list,
TravisCI does wonders and everything's jolly
On 3 April 2018 at 13:09, Rainer Müller wrote:
> On 2018-04-03 12:31, db wrote:
>> On 3 Apr 2018, at 02:20, Rainer Müller wrote:
>>> Then please explain what this would offer us at all?
>>
>> I'll try. GitLab let's you have external runners
>> (https://docs.gitlab.com/ee/ci/runners/README.html), w
On 2018-04-03 12:31, db wrote:
> On 3 Apr 2018, at 02:20, Rainer Müller wrote:
>> Then please explain what this would offer us at all?
>
> I'll try. GitLab let's you have external runners
> (https://docs.gitlab.com/ee/ci/runners/README.html), while TravisCI offers a
> certain amount of pipeline
On 3 Apr 2018, at 02:20, Rainer Müller wrote:
> Then please explain what this would offer us at all?
I'll try. GitLab let's you have external runners
(https://docs.gitlab.com/ee/ci/runners/README.html), while TravisCI offers a
certain amount of pipeline minutes and only supports the currently s
On 2018-04-03 01:18, db wrote:
> On 2 Apr 2018, at 23:09, Clemens Lang wrote:
>> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>>> GitLab 10.6 released with CI/CD for GitHub
>> Interesting, but I couldn't find any indication that this would support
>> builds on macOS. Do you have more info?
On 2 Apr 2018, at 23:09, Clemens Lang wrote:
> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>> GitLab 10.6 released with CI/CD for GitHub
> Interesting, but I couldn't find any indication that this would support
> builds on macOS. Do you have more info?
I think you and Mojca were referrin
At the end of the day, it's just a series of scripts you're defining in
a YAML file. You can likely have it work on anything.
On 04/02/2018 05:09 PM, Clemens Lang wrote:
> Hi,
>
> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>> GitLab 10.6 released with CI/CD for GitHub
>>
>> https://about
On 2 Apr 2018, at 23:09, Clemens Lang wrote:
> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>> GitLab 10.6 released with CI/CD for GitHub
> Interesting, but I couldn't find any indication that this would support
> builds on macOS. Do you have more info?
Nope, but I don't see why it wouldn
On 2 Apr 2018, at 22:53, Mojca Miklavec wrote:
> I fail to find any info about available runners for hosted CI infrastructure.
Is this what you're looking for? https://about.gitlab.com/features/github/
search for 'self-hosted'.
Hi,
On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
> GitLab 10.6 released with CI/CD for GitHub
>
> https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#open-source-projects
Interesting, but I couldn't find any indication that this would support
builds on macOS. Do you have more info?
I fail to find any info about available runners for hosted CI
infrastructure.
Mojca
V pon., 2. apr. 2018 20:43 je oseba db napisala:
> GitLab 10.6 released with CI/CD for GitHub
>
>
> https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#open-source-projects
GitLab 10.6 released with CI/CD for GitHub
https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#open-source-projects
On Mar 15, 2018, at 07:00, db wrote:
> On 15 Mar 2018, at 05:13, Ryan Schmidt wrote:
>> Because PRs come from untrusted sources, we have to assume their contents
>> are tainted. So after any PR is finished building, the VM is tainted and we
>> have to throw it away and make a new one from our te
On 15 Mar 2018, at 05:13, Ryan Schmidt wrote:
> Because PRs come from untrusted sources, we have to assume their contents are
> tainted. So after any PR is finished building, the VM is tainted and we have
> to throw it away and make a new one from our template for the next PR build.
> On Mar 14
On Mar 14, 2018, at 03:07, Rainer Müller wrote:
> On 2018-03-14 04:08, Ryan Schmidt wrote:
>> I was not aware of the existence of GitLab CI, but I haven't done a survey
>> of CI systems, mainly because we already selected one many years ago:
>> Buildbot. The problem, to my mind, was not that of s
On Mar 14, 2018, at 07:25, db wrote:
> On 14 Mar 2018, at 04:08, Ryan Schmidt wrote:
>> I was not aware of the existence of GitLab CI, but I haven't done a survey
>> of CI systems, mainly because we already selected one many years ago:
>> Buildbot.
>
> GitLab CI is now integrated in GitLab, but
On 14 Mar 2018, at 04:08, Ryan Schmidt wrote:
> I was not aware of the existence of GitLab CI, but I haven't done a survey of
> CI systems, mainly because we already selected one many years ago: Buildbot.
GitLab CI is now integrated in GitLab, but AFAIK doesn't integrate with GitHub
right now u
On 2018-03-14 04:08, Ryan Schmidt wrote:
> I was not aware of the existence of GitLab CI, but I haven't done a survey of
> CI systems, mainly because we already selected one many years ago: Buildbot.
> The problem, to my mind, was not that of selecting which CI system to use,
> but the fact that
On Mar 13, 2018, at 19:14, Rainer Müller wrote:
> On 2018-03-14 00:42, db wrote:
>> On 14 Mar 2018, at 00:22, Mojca Miklavec wrote:
>>> Because someone would need to write the code for an alternative CI
>>
>> Wouldn't self-hosted GitLab CI be good enough?
>
> Are you going to sponsor a dedicated
80 matches
Mail list logo
