Re: [macports-ports] branch master updated: aacgain: Update to v1.9
On Apr 8, 2018, at 03:46, Jackson Isaacwrote: > Jackson Isaac (JacksonIsaac) pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/30c9fad4f1d0e000525c5f2bb5119453f3e373fa > > The following commit(s) were added to refs/heads/master by this push: > > new 30c9fad aacgain: Update to v1.9 > > 30c9fad is described below > > > commit 30c9fad4f1d0e000525c5f2bb5119453f3e373fa > > Author: Jackson Isaac Remember to set up your git clone (or your git defaults) so that your commits are authored by your MacPorts project email address. https://trac.macports.org/wiki/WorkingWithGit#setup > AuthorDate: Sun Apr 8 14:16:50 2018 +0530 > > > aacgain: Update to v1.9 > > Add modeline and fix mixed tabs and spaces. In the future, please make whitespace changes (along with adding the modeline if needed) in a separate commit from functional changes, so that the functional changes are easier to spot and review.
Re: [macports-ports] branch master updated: aacgain: Update to v1.9
Hi Ryan, On Sun, Apr 8, 2018 at 2:33 PM, Ryan Schmidt wrote: > > On Apr 8, 2018, at 03:46, Jackson Isaacwrote: > >> Jackson Isaac (JacksonIsaac) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/30c9fad4f1d0e000525c5f2bb5119453f3e373fa >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new 30c9fad aacgain: Update to v1.9 >> >> 30c9fad is described below >> >> >> commit 30c9fad4f1d0e000525c5f2bb5119453f3e373fa >> >> Author: Jackson Isaac > > Remember to set up your git clone (or your git defaults) so that your commits > are authored by your MacPorts project email address. > > https://trac.macports.org/wiki/WorkingWithGit#setup I was looking for this. For some reason my git checkout was not working like before. Thanks for the link :) > > >> AuthorDate: Sun Apr 8 14:16:50 2018 +0530 >> >> >> aacgain: Update to v1.9 >> >> Add modeline and fix mixed tabs and spaces. > > In the future, please make whitespace changes (along with adding the modeline > if needed) in a separate commit from functional changes, so that the > functional changes are easier to spot and review. > > Will keep this in mind. Actually, there was a bug in functional changes which I am fixing and will commit in few minutes. -- Jackson Isaac
Re: [macports-ports] branch master updated: aacgain: Update dirname in post-extract phase
On Apr 8, 2018, at 04:12, Jackson Isaac wrote:
> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/65defdc294622caa6e4c44d874286917a1d51ce1
>
> The following commit(s) were added to refs/heads/master by this push:
>
> new 65defdc aacgain: Update dirname in post-extract phase
>
> 65defdc is described below
>
>
> commit 65defdc294622caa6e4c44d874286917a1d51ce1
>
> Author: ijackson
> AuthorDate: Sun Apr 8 14:42:19 2018 +0530
>
>
> aacgain: Update dirname in post-extract phase
>
> Version and tarball name didn't match and
> hence there was an issue while applying patch.
>
> ---
> audio/aacgain/Portfile | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/audio/aacgain/Portfile b/audio/aacgain/Portfile
> index 481b021..bda6c74 100644
> --- a/audio/aacgain/Portfile
> +++ b/audio/aacgain/Portfile
> @@ -21,6 +21,10 @@ use_bzip2 yes
> checksums sha256
> 2bb8e27aa8f8434a4861fdbc70adb9cb4b47e1dfe472910d62d6042cb80a2ee1 \
> rmd160 8f97121f3797cde45f71839dbe14251b74365ccd
>
> +post-extract {
> +file rename ${workpath}/${name}-1.8 ${workpath}/${name}-${version}
> +}
Set worksrcdir instead of this.
However, don't do that, because this update was completely wrong. No version
1.9 exists at the download site. Take a look:
http://aacgain.altosdesign.com/alvarez/
There is only 1.8. Their web server is just configured in an improperly helpful
manner: If you request the file for the nonexistent 1.9, it silently redirects
you to the file for 1.8:
$ curl -I http://aacgain.altosdesign.com/alvarez/aacgain-1.9.tar.bz2
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Keep-Alive: timeout=15
Date: Sun, 08 Apr 2018 09:26:54 GMT
Server: Apache
Location: http://aacgain.altosdesign.com/alvarez/aacgain-1.8.tar.bz2
What I did not see in your previous commit which updated the port to "1.9",
because you combined whitespace changes with functional ones, is that the
checksums did not change. So what you've called 1.9 here is definitely
unchanged from 1.8.
The web site claims a version 1.9 exists, but I don't know where it is. If it
can't be found, the changes you made should be reverted to put the port back at
version 1.8. The epoch will have to be increased so that anybody who did
install 1.9 already will be downgraded back to 1.8.
It seems that you didn't try to build this before committing it, or you would
have at least seen the patch failure. Please always verify successful
installation of a port on your own system before committing.
Re: [macports-ports] branch master updated: aacgain: Update dirname in post-extract phase
On Sun, Apr 8, 2018 at 3:05 PM, Ryan Schmidt wrote:
>
> On Apr 8, 2018, at 04:12, Jackson Isaac wrote:
>
>> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/65defdc294622caa6e4c44d874286917a1d51ce1
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>
>> new 65defdc aacgain: Update dirname in post-extract phase
>>
>> 65defdc is described below
>>
>>
>> commit 65defdc294622caa6e4c44d874286917a1d51ce1
>>
>> Author: ijackson
>> AuthorDate: Sun Apr 8 14:42:19 2018 +0530
>>
>>
>> aacgain: Update dirname in post-extract phase
>>
>> Version and tarball name didn't match and
>> hence there was an issue while applying patch.
>>
>> ---
>> audio/aacgain/Portfile | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/audio/aacgain/Portfile b/audio/aacgain/Portfile
>> index 481b021..bda6c74 100644
>> --- a/audio/aacgain/Portfile
>> +++ b/audio/aacgain/Portfile
>> @@ -21,6 +21,10 @@ use_bzip2 yes
>> checksums sha256
>> 2bb8e27aa8f8434a4861fdbc70adb9cb4b47e1dfe472910d62d6042cb80a2ee1 \
>> rmd160 8f97121f3797cde45f71839dbe14251b74365ccd
>>
>> +post-extract {
>> +file rename ${workpath}/${name}-1.8 ${workpath}/${name}-${version}
>> +}
>
> Set worksrcdir instead of this.
>
> However, don't do that, because this update was completely wrong. No version
> 1.9 exists at the download site. Take a look:
>
> http://aacgain.altosdesign.com/alvarez/
>
> There is only 1.8. Their web server is just configured in an improperly
> helpful manner: If you request the file for the nonexistent 1.9, it silently
> redirects you to the file for 1.8:
>
> $ curl -I http://aacgain.altosdesign.com/alvarez/aacgain-1.9.tar.bz2
> HTTP/1.1 301 Moved Permanently
> Content-Type: text/html; charset=iso-8859-1
> Connection: keep-alive
> Keep-Alive: timeout=15
> Date: Sun, 08 Apr 2018 09:26:54 GMT
> Server: Apache
> Location: http://aacgain.altosdesign.com/alvarez/aacgain-1.8.tar.bz2
>
> What I did not see in your previous commit which updated the port to "1.9",
> because you combined whitespace changes with functional ones, is that the
> checksums did not change. So what you've called 1.9 here is definitely
> unchanged from 1.8.
>
> The web site claims a version 1.9 exists, but I don't know where it is. If it
> can't be found, the changes you made should be reverted to put the port back
> at version 1.8. The epoch will have to be increased so that anybody who did
> install 1.9 already will be downgraded back to 1.8.
I did find one at "https://github.com/mecke/aacgain"; but I was not so
sure if they both are by same author since 'alvarez' was mentioned at
http://aacgain.altosdesign.com and on github it was 'mecke'. Also the
commit log didn't help much either.
Looking at the README, it looks like this might possibly be the 1.9 version.
I would like to know what to do in such a scenario. Should I go
forward with the github version ?
>
> It seems that you didn't try to build this before committing it, or you would
> have at least seen the patch failure. Please always verify successful
> installation of a port on your own system before committing.
>
>
I did notice the patch failure and thought it might be because the
patch file was older and then I forgot to build it again with the new
patch file. It was a mistake from my side. Have got little rusty since
it has been quite some time updating ports.
--
Jackson Isaac
Re: CI system for PR builds
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 mostly written. What is needed is only a little bit of > coding and a lot of testing, which is very time consuming. > > So here is the full plan in detail: Thanks for writing this up. > Buildbot supports libvirt with "latent buildslaves", even in 0.8.12: > > http://docs.buildbot.net/0.8.12/manual/cfg-buildslaves.html#libvirt > > When a build is about to be executed on this buildslave, Buildbot > instructs clones the base image to a new (temporary) disk image and then > uses this new disk image to spin up a VM from a clean state. > > To run this on ESX or any other hypervisor than qemu, we would need to > implement the disk cloning manually as buildbot only uses qemu-img or cp > on the local machine. Probably we would want to use snapshots instead of > cloning full disks. We can customize this in parts by inheriting from > LibVirtSlave. > > This VM will then boot and it is supposed to have a buildslave installed > that will connect back to the buildbot master. From then on, the build > runs as usual. After the build finished, buildbot will shutdown the VM > and discard the modified disk image. > > The hardest part is to prepare this VM image. At best, it should be > automated so we can easily recreate it for macOS updates. > > 1) Install macOS > Not sure how much can be automated here. For a basic version [1], it > can just be the instructions that need to be clicked through. > 2) Install MacPorts into toolsprefix > 3) Install buildslave (and other tools) into the toolsprefix > 4) Install configuration for buildslave > Also set buildslave to start automatically after booting and to > connect to the master. > 5) Install MacPorts into /opt/local Yes there are tools to automate the OS install, like AutoDMG, which I have played with a few years ago, but there are many nuances and getting everything right is extremely time consuming, given how much time it takes to verify that any change had the desired outcome (since a complete OS install must be performed), not to mention how much disk space is required. I don't see any reason to automate the creation of these VM images. It should be no more difficult to set them up manually than it was for me to set up the ones we already use for buildbot today. > As far as I know, Ryan already has a script that could be used for some > of the steps. I have this: https://github.com/ryandesign/macports-infrastructure/blob/master/buildworker-bootstrap.sh Given a new machine with a fresh install of macOS, Xcode, and the command line tools, the script builds MacPorts from source in the private /opt/bblocal prefix used by the buildbot workers, installs the git port, and adds another ports tree from GitHub containing the ports used for the buildbot infrastructure. The administrator then installs the ports needed for this particular worker. (It's usually just the same port on each worker, except that they use different variants depending on whether the worker will build base or ports or both, and whether libc++ or libstdc++ will be used.) > When we have such an, we need to configure a builder in master.cfg that > uses LibVirtSlave. This builder needs a modified portbuilder_factory > that skips the deployment of archives. And finally a changesource that > listens to pull requests via a GitHub WebHook (or just some branch for > testing at first). > > At this point the setup would already be working. > > > If the goal is just to get anything working, you could stop reading > here. But I imagine this setup to be slow, as the VM cannot keep any > persistent state. Therefore, I already made up my mind how this could be > optimized. > > 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 packages available locally already. > > One possible optimization would be to mount distfiles and packages in > the VM over (read-only) NFS from another machine that provides the local > mirror. I'm not convinced that fetching via HTTP from the private mirror would be significantly slower than fetching via NFS from the private mirror. Either way, the files are coming from the fairly slow RAID card in the master Xserve. > mount -t nfs -o ro mirror:.../allpackages \ >/opt/local/var/macports/incoming/verified > > Now a 'port install' would just directly use the package from this > directory, which is much faster than doing the usual archivefetch. > However, this expects a flat hierarchy; a single directory containing > all packages. This may impose limitations we
Re: CI system for PR builds
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 attacker could modify the machines > in a way that packages built after that will be miscompiled. 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?
Re: CI system for PR builds
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 we will distribute to our users. A malicous attacker could modify the machines in a way that packages built after that will be miscompiled. 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 started when a PR is submitted or updated, and we usually review the code after the build completes. Unless CI builds are fast enough, manually triggering builds after code review would be a waste of manpower (we have to wait till the build completes). The CI system is useful because it can provide more information when we review the PRs. It would be less useful if we have to manually start the builds. -- Best regards, Zero King smime.p7s Description: S/MIME cryptographic signature
Re: CI system for PR builds
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 packages available locally already. >> >> One possible optimization would be to mount distfiles and packages in >> the VM over (read-only) NFS from another machine that provides the local >> mirror. > > I'm not convinced that fetching via HTTP from the private mirror would be > significantly slower than fetching via NFS from the private mirror. Either > way, the files are coming from the fairly slow RAID card in the master Xserve. The point is that the approach below would not "fetch" the file. It uses the package directly from NFS, without making a local copy first. >> mount -t nfs -o ro mirror:.../allpackages \ >>/opt/local/var/macports/incoming/verified >> >> Now a 'port install' would just directly use the package from this >> directory, which is much faster than doing the usual archivefetch. >> However, this expects a flat hierarchy; a single directory containing >> all packages. This may impose limitations we have yet to find. > > As you say, we don't have the packages in a flat hierarchy. How would you > propose that we create that? Are we talking about yet another parallel > hierarchy of hardlinks for our archive deployment script to maintain, like > the one we've been talking about in another thread for rearranging the > contents of the packages server? I am just throwing out ideas. Yes, right now this would require to create yet another hierarchy. Maybe with changes in base it could reuse a normal hierarchy. As I said, that is just for optimization once we have it running. We can ignore it for now. Maybe it turns out this is not necessary at all and I am overthinking. I would be fine with that outcome as well. :-) > If we are thinking about having PR test machines running OS X 10.8 or > earlier, then we have to consider the HTTPS fetch failure situation again. I > don't think we want to mirror distfiles for unapproved PRs to the main > distfiles server, so we may need a separate PR distfiles server that could > house the files temporarily and delete them later. I would not mirror distfiles for PRs at all. Testing with just supported versions of macOS should be enough. Anything on OS X 10.8 and earlier is expected to fail. We need to stop investing so much effort into legacy systems. Even just testing with one version would be able to detect the most common problems, like missing dependencies. Rainer
Re: [macports-ports] branch master updated: aacgain: Update dirname in post-extract phase
On Sun, Apr 8, 2018 at 3:33 PM, Jackson Isaac wrote:
> On Sun, Apr 8, 2018 at 3:05 PM, Ryan Schmidt wrote:
>>
>> On Apr 8, 2018, at 04:12, Jackson Isaac wrote:
>>
>>> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
>>> in repository macports-ports.
>>>
>>>
>>> https://github.com/macports/macports-ports/commit/65defdc294622caa6e4c44d874286917a1d51ce1
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>
>>> new 65defdc aacgain: Update dirname in post-extract phase
>>>
>>> 65defdc is described below
>>>
>>>
>>> commit 65defdc294622caa6e4c44d874286917a1d51ce1
>>>
>>> Author: ijackson
>>> AuthorDate: Sun Apr 8 14:42:19 2018 +0530
>>>
>>>
>>> aacgain: Update dirname in post-extract phase
>>>
>>> Version and tarball name didn't match and
>>> hence there was an issue while applying patch.
>>>
>>> ---
>>> audio/aacgain/Portfile | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/audio/aacgain/Portfile b/audio/aacgain/Portfile
>>> index 481b021..bda6c74 100644
>>> --- a/audio/aacgain/Portfile
>>> +++ b/audio/aacgain/Portfile
>>> @@ -21,6 +21,10 @@ use_bzip2 yes
>>> checksums sha256
>>> 2bb8e27aa8f8434a4861fdbc70adb9cb4b47e1dfe472910d62d6042cb80a2ee1 \
>>> rmd160 8f97121f3797cde45f71839dbe14251b74365ccd
>>>
>>> +post-extract {
>>> +file rename ${workpath}/${name}-1.8 ${workpath}/${name}-${version}
>>> +}
>>
>> Set worksrcdir instead of this.
>>
>> However, don't do that, because this update was completely wrong. No version
>> 1.9 exists at the download site. Take a look:
>>
>> http://aacgain.altosdesign.com/alvarez/
>>
>> There is only 1.8. Their web server is just configured in an improperly
>> helpful manner: If you request the file for the nonexistent 1.9, it silently
>> redirects you to the file for 1.8:
>>
>> $ curl -I http://aacgain.altosdesign.com/alvarez/aacgain-1.9.tar.bz2
>> HTTP/1.1 301 Moved Permanently
>> Content-Type: text/html; charset=iso-8859-1
>> Connection: keep-alive
>> Keep-Alive: timeout=15
>> Date: Sun, 08 Apr 2018 09:26:54 GMT
>> Server: Apache
>> Location: http://aacgain.altosdesign.com/alvarez/aacgain-1.8.tar.bz2
>>
>> What I did not see in your previous commit which updated the port to "1.9",
>> because you combined whitespace changes with functional ones, is that the
>> checksums did not change. So what you've called 1.9 here is definitely
>> unchanged from 1.8.
>>
>> The web site claims a version 1.9 exists, but I don't know where it is. If
>> it can't be found, the changes you made should be reverted to put the port
>> back at version 1.8. The epoch will have to be increased so that anybody who
>> did install 1.9 already will be downgraded back to 1.8.
>
> I did find one at "https://github.com/mecke/aacgain"; but I was not so
> sure if they both are by same author since 'alvarez' was mentioned at
> http://aacgain.altosdesign.com and on github it was 'mecke'. Also the
> commit log didn't help much either.
>
> Looking at the README, it looks like this might possibly be the 1.9 version.
>
> I would like to know what to do in such a scenario. Should I go
> forward with the github version ?
>
Github version is just code files and does not contain files for Unix
build which was part of the tarball created
by Alvarez.
Digging into the issue I came across a very old ticket for aacgain
reported by Ryan at https://trac.macports.org/ticket/25942.
Looks like someone had created the tarball for 1.9 and hosted it one
their own website since 'Alvarez' didn't create the
official 1.9 tarball yet. But the port was never updated.
--
Jackson Isaac
Re: CI system for PR builds
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 started when a PR is submitted or updated, > and we usually review the code after the build completes. Unless CI > builds are fast enough, manually triggering builds after code review > would be a waste of manpower (we have to wait till the build completes). > The CI system is useful because it can provide more information when we > review the PRs. It would be less useful if we have to manually start the > builds. That seems to waste at least buildtime and storage. Many updates and revbumps could be almost automatically deployed (after a quick review).
Re: CI system for PR builds
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 >>> are handled? >> CI builds are automatically started when a PR is submitted or updated, >> and we usually review the code after the build completes. Unless CI >> builds are fast enough, manually triggering builds after code review >> would be a waste of manpower (we have to wait till the build completes). >> The CI system is useful because it can provide more information when we >> review the PRs. It would be less useful if we have to manually start the >> builds. > > 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?
Re: CI system for PR builds
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 a PR builds in TravisCI, then is reviewed and eventually built by buildbot for distribution. If you would review a PR first, say for a minor version update, version and checksums changed, you could approve the change of couple of lines and trigger the build by buildbot and, if successful, upload the binary without further intervention. Is this now the case?
Re: CI system for PR builds
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). >> Isn't that we do now? > > It seems to me that a PR builds in TravisCI, then is reviewed and eventually > built by buildbot for distribution. If you would review a PR first, say for a > minor version update, version and checksums changed, you could approve the > change of couple of lines and trigger the build by buildbot and, if > successful, upload the binary without further intervention. Is this now the > case? 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.
Re: CI system for PR builds
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. That streamlined process is what keeps new and updated portfiles in my local repo…
Re: CI system for PR builds
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 of that build can >> inform our review. > > That streamlined process is what keeps new and updated portfiles in my local > repo… So is your suggestion to delete the MacPorts Travis CI integration? Don't test-build PRs?
Re: [macports-ports] branch master updated: aacgain: Update dirname in post-extract phase
On 2018-04-08 12:56, Jackson Isaac wrote: > On Sun, Apr 8, 2018 at 3:33 PM, Jackson Isaac wrote: >> I did find one at "https://github.com/mecke/aacgain"; but I was not so >> sure if they both are by same author since 'alvarez' was mentioned at >> http://aacgain.altosdesign.com and on github it was 'mecke'. Also the >> commit log didn't help much either. >> >> Looking at the README, it looks like this might possibly be the 1.9 version. >> >> I would like to know what to do in such a scenario. Should I go >> forward with the github version ? It looks like someone just took some source snapshot (maybe from upstream CVS), imported it into a Git repository, and pushed it to GitHub. There is no history attached to it, so it could also contain other modifications. Definitely not a maintained version, so it should not be used. > Github version is just code files and does not contain files for Unix > build which was part of the tarball created > by Alvarez. > > Digging into the issue I came across a very old ticket for aacgain > reported by Ryan at https://trac.macports.org/ticket/25942. > > Looks like someone had created the tarball for 1.9 and hosted it one > their own website since 'Alvarez' didn't create the > official 1.9 tarball yet. But the port was never updated. Option a: Leave it at version 1.8 Option b: Update to a "CVS" snapshot The repository was converted to git, the tag would be R1_9: https://sourceforge.net/p/mp3gain/code/ci/R1_9/tree/ Rainer
Re: CI system for PR builds
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 >>> purpose is to verify that it builds, and the results of that build can >>> inform our review. >> That streamlined process is what keeps new and updated portfiles in my local >> repo… > So is your suggestion to delete the MacPorts Travis CI integration? Don't > test-build PRs? Buildbot is a CI framework. Use that for testing. And automate deployment where possible.
Re: CI system for PR builds
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, immediately after it's submitted. The purpose is to verify that it builds, and the results of that build can inform our review. >>> That streamlined process is what keeps new and updated portfiles in my >>> local repo… >> So is your suggestion to delete the MacPorts Travis CI integration? Don't >> test-build PRs? > > Buildbot is a CI framework. Use that for testing. And automate deployment > where possible. We already automate deployment of built archives using buildbot. I already explained that we did not use buildbot to test PRs initially because we did not know how to do it exactly. You've seen many long detailed emails go by in this thread now, discussing how we might in future use buildbot for this.
Re: CI system for PR builds
> 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 portconfigure, and then forget about these older systems. Users of them who want something to work can put forward patches if they are reasonable. Someday spin the tickets off to a separate trac somewhere, if there is enough interest. Legacy systems should not slow down the progress of the current systems. A quick review on repology.org shows many maintainers have only 50 to 60% current ports. Ken
Re: CI system for PR builds
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 systems to libc++, put forward a modern > clang in portconfigure, and then forget about these older systems. > > Users of them who want something to work can put forward patches if they are > reasonable. > > Someday spin the tickets off to a separate trac somewhere, if there is enough > interest. > > Legacy systems should not slow down the progress of the current systems. A > quick review on repology.org shows many maintainers have only 50 to 60% > current ports. I know you love to keep saying this. And I have no objection to moving toward defaulting to libc++ on 10.6-10.8, as has been discussed in other threads. But Rainer's reply here was in response to my pointing out the https tls problem, which does not go away even when we move those systems to libc++. 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.
Re: CI system for PR builds
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 that has a 10 minute fix. Anyway, I didn't want to get anyone upset by this -- just trying to make it easier for everyone. Ken
Re: CI system for PR builds
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 understand why people would spend years working around a problem > that has a 10 minute fix. > > Anyway, I didn't want to get anyone upset by this -- just trying to make it > easier for everyone. I want to ship a working solution to all users of old systems, not tech-support all users of old systems into applying a 10-minute fix.
Re: CI system for PR builds
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 /tmp/distfiles-overlay.dmg -size 20g -fs HFS+J > hdiutil attach -nomount /tmp/distfiles-overlay.dmg # diskX in output > mount -t hfs -o rw,union /dev/diskXs1 /opt/local/var/macports/distfiles I discovered the hard way that union mounts are not supported in Mac OS. When I tried something with union mounts that did not work, and reported it to Apple tech support, they told me explicitly that they do not support union mounts. As I understand it, the issue is that there are two different sets of file access routines in the operating system. While the POSIX calls will support union mounts, the calls used by the internal Apple code bypass the POSIX calls, and use a different, lower access level. The result is that any type of AppKit, or other Apple-aware program (such as Finder, etc.) will fail to work properly. --- Entertaining minecraft videos http://YouTube.com/keybounce
Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion
On 2018-04-07 14:18, William H. Magill wrote:
> IRC is still quite popular in Europe, but is little used in the US.
IRC on our #macports channel is fine to ask questions for which you do
not want to write a lengthy email or to debug problems with quick
back-and-forth on what to check or try.
However, meetings on IRC are slow, as you have to wait for others to
type, you have no notifications whether others still have something to
say, etc.
For such a scheduled meeting, I would prefer audio chat as that would
make the communication more direct and faster.
> One alternative to IRC is “Discord” — it has the same “type text”
> capabilities as IRC, but as far as I’m concerned, it is MUCH easier to use.
> It also supports voice channels.
>
> And, yes, there is a Mac client - OSX and IOS - as well as access through the
> browser.
>
> https://discordapp.com
>
> It is pitched as “for gamers,” mainly because of its voice capabilities.
Discord looks fine to me. Apparently we would not even be the first open
source project to use it [1]. Apparently you can use it directly in a
browser without registration ("claiming the account").
The other well-known option would of course be Skype. However, with
Skype one person would have to collect interested developers first and
then invite them to a group call. With Discord it seems like you can
just create a room that everyone can join, which would be a lot simpler.
There is also Jitsi [2], an open source solution for video conferencing
via WebRTC in the browser. However, browser support seems to be limited,
especially with Safari.
Rainer
[1] https://discordapp.com/open-source
[2] https://jitsi.org/
Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion
Why not use WhatsApp
On Sun, Apr 8, 2018 at 10:42 Rainer Müller wrote:
> On 2018-04-07 14:18, William H. Magill wrote:
> > IRC is still quite popular in Europe, but is little used in the US.
> IRC on our #macports channel is fine to ask questions for which you do
> not want to write a lengthy email or to debug problems with quick
> back-and-forth on what to check or try.
>
> However, meetings on IRC are slow, as you have to wait for others to
> type, you have no notifications whether others still have something to
> say, etc.
>
> For such a scheduled meeting, I would prefer audio chat as that would
> make the communication more direct and faster.
>
> > One alternative to IRC is “Discord” — it has the same “type text”
> capabilities as IRC, but as far as I’m concerned, it is MUCH easier to use.
> > It also supports voice channels.
> >
> > And, yes, there is a Mac client - OSX and IOS - as well as access
> through the browser.
> >
> > https://discordapp.com
> >
> > It is pitched as “for gamers,” mainly because of its voice capabilities.
>
> Discord looks fine to me. Apparently we would not even be the first open
> source project to use it [1]. Apparently you can use it directly in a
> browser without registration ("claiming the account").
>
> The other well-known option would of course be Skype. However, with
> Skype one person would have to collect interested developers first and
> then invite them to a group call. With Discord it seems like you can
> just create a room that everyone can join, which would be a lot simpler.
>
> There is also Jitsi [2], an open source solution for video conferencing
> via WebRTC in the browser. However, browser support seems to be limited,
> especially with Safari.
>
> Rainer
>
> [1] https://discordapp.com/open-source
> [2] https://jitsi.org/
>
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-04-08 03:26, Joshua Root wrote:
> Joshua Root (jmroot) pushed a commit to branch master
> in repository macports-base.
>
> https://github.com/macports/macports-base/commit/3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947
>
> The following commit(s) were added to refs/heads/master by this push:
> new 3dde77d Honour startupitem.install at activation time 3dde77d is
> described below
>
> commit 3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947 Author: Joshua Root
>
> AuthorDate: Sun Apr 8 11:16:22 2018 +1000
>
> Honour startupitem.install at activation time When activating files,
> move plists from /Library/Launch* to ${prefix}/etc/Launch* if the port
> was built with startupitem_install on but it is currently off, and
> vice versa in the opposite case.
Somehow this seems complicated. Wouldn't it be simpler to always ship
the .plists in ${prefix}/etc/Launch* and only add symlinks in
/Library/Launch* on activation if startupitem_install allows it?
But I guess you did it this way to be compatible with older archives?
Rainer
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-4-9 07:55 , Rainer Müller wrote:
> On 2018-04-08 03:26, Joshua Root wrote:
>> Joshua Root (jmroot) pushed a commit to branch master
>> in repository macports-base.
>>
>> https://github.com/macports/macports-base/commit/3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947
>>
>> The following commit(s) were added to refs/heads/master by this push:
>> new 3dde77d Honour startupitem.install at activation time 3dde77d is
>> described below
>>
>> commit 3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947 Author: Joshua Root
>>
>> AuthorDate: Sun Apr 8 11:16:22 2018 +1000
>>
>> Honour startupitem.install at activation time When activating files,
>> move plists from /Library/Launch* to ${prefix}/etc/Launch* if the port
>> was built with startupitem_install on but it is currently off, and
>> vice versa in the opposite case.
> Somehow this seems complicated. Wouldn't it be simpler to always ship
> the .plists in ${prefix}/etc/Launch* and only add symlinks in
> /Library/Launch* on activation if startupitem_install allows it?
Not that much simpler, strangely enough.
> But I guess you did it this way to be compatible with older archives?
Indeed. It doesn't matter how startupitem.install was set when the
archives were built, this will DTRT either way.
- Josh
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-04-09 00:06, Joshua Root wrote:
> On 2018-4-9 07:55 , Rainer Müller wrote:
>> On 2018-04-08 03:26, Joshua Root wrote:
>>> Joshua Root (jmroot) pushed a commit to branch master
>>> in repository macports-base.
>>>
>>> https://github.com/macports/macports-base/commit/3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>> new 3dde77d Honour startupitem.install at activation time 3dde77d is
>>> described below
>>>
>>> commit 3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947 Author: Joshua Root
>>>
>>> AuthorDate: Sun Apr 8 11:16:22 2018 +1000
>>>
>>> Honour startupitem.install at activation time When activating files,
>>> move plists from /Library/Launch* to ${prefix}/etc/Launch* if the port
>>> was built with startupitem_install on but it is currently off, and
>>> vice versa in the opposite case.
>> Somehow this seems complicated. Wouldn't it be simpler to always ship
>> the .plists in ${prefix}/etc/Launch* and only add symlinks in
>> /Library/Launch* on activation if startupitem_install allows it?
>
> Not that much simpler, strangely enough.
Maybe not in the implementation, but simpler for me to grasp what's
going on. :-)
>> But I guess you did it this way to be compatible with older archives?
>
> Indeed. It doesn't matter how startupitem.install was set when the
> archives were built, this will DTRT either way.
This handles ports that create .plist files via startupitem.* or the new
startupitems. However, there are also ports that install custom .plist
file to ${destroot}/Library/Launch*. Some ports even do that
unconditionally.
Maybe we could rename all *.plist files in these directories to avoid
recreating this logic in many ports? If we handled this automatically at
activation time, ports would no longer have to deal with
${startupitem.install} at all.
Rainer
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-4-9 08:43 , Rainer Müller wrote:
> This handles ports that create .plist files via startupitem.* or the new
> startupitems. However, there are also ports that install custom .plist
> file to ${destroot}/Library/Launch*. Some ports even do that
> unconditionally.
Ports that do this should set 'startupitem.create no' and
'startupitem.type launchd', plus whatever other variables like
startupitem.name are needed based on what they called their plist.
I've been wondering if we should also have an option called something
like startupitem.file that could be set to a path, e.g.
${filespath}/my_job.plist, and then base would install it to the right
place.
- Josh
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-04-09 01:20, Joshua Root wrote:
> On 2018-4-9 08:43 , Rainer Müller wrote:
>> This handles ports that create .plist files via startupitem.* or the new
>> startupitems. However, there are also ports that install custom .plist
>> file to ${destroot}/Library/Launch*. Some ports even do that
>> unconditionally.
>
> Ports that do this should set 'startupitem.create no' and
> 'startupitem.type launchd', plus whatever other variables like
> startupitem.name are needed based on what they called their plist.
I found no port in or ports tree that does it that way.
There are only exactly two ports that use 'startupitem.create no':
mpstats and certsync.
But these do not set startupitem.type either. And even they create the
symlink in /Library/Launch* manually...
Other ports just install a .plist to
${prefix}/etc/Launch*/org.macports.${name}/*.plist and creates the
symlink at /Library/Launch*/*.plist without setting any startupitem.*
option. For example, mysql*-server (and the percona and mariadb forks).
As far as I can see, 'startupitem.create no' is not required right now
and not used. I do not think Portfile authors will understand why it
would be necessary. We should find a solution without it.
> I've been wondering if we should also have an option called something
> like startupitem.file that could be set to a path, e.g.
> ${filespath}/my_job.plist, and then base would install it to the right
> place.
This could work, except for ports where the upstream build system
already installs the .plist. For example, xinit.
https://github.com/macports/macports-ports/blob/master/x11/xinit/Portfile#L53
Rainer
Re: [macports-base] branch master updated: Honour startupitem.install at activation time
On 2018-4-9 10:20 , Rainer Müller wrote:
> On 2018-04-09 01:20, Joshua Root wrote:
>> On 2018-4-9 08:43 , Rainer Müller wrote:
>>> This handles ports that create .plist files via startupitem.* or the new
>>> startupitems. However, there are also ports that install custom .plist
>>> file to ${destroot}/Library/Launch*. Some ports even do that
>>> unconditionally.
>>
>> Ports that do this should set 'startupitem.create no' and
>> 'startupitem.type launchd', plus whatever other variables like
>> startupitem.name are needed based on what they called their plist.
>
> I found no port in or ports tree that does it that way.
That's because you can't do it with the released version of base.
> As far as I can see, 'startupitem.create no' is not required right now
> and not used. I do not think Portfile authors will understand why it
> would be necessary. We should find a solution without it.
You don't have to actually set it to no, that's the default, so you just
don't set it to yes.
- Josh
