Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)
> On Nov 1, 2016, at 5:47 PM, Rainer Müller wrote: > > On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote: >> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master >> in repository macports-ports. >> >> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70 > >> [...] > >> commit 864eb7639d6774a7853767be6b15384c790bfe70 >> Author: Jeremy Huddleston Sequoia >> AuthorDate: Tue Nov 1 16:52:53 2016 -0700 >> >>libcxx: Bump to 3.9.0 (#52666) >> >>Signed-off-by: Jeremy Huddleston Sequoia > > Please do not use the # syntax anymore in commit messages. This is now > reserved for references to pull requests on GitHub. Instead, paste the > full URL to the Trac ticket into the commit message: > > Closes https://trac.macports.org/ticket/52666 > > When you add keywords such as "closes", "fixes", "fix" in front of the > ticket URL, the ticket will also automatically be closed with a > reference to the commit. Can you pass multiple tickets (closes x y z)? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removing "$Id$" lines
> On Oct 31, 2016, at 6:02 PM, Rainer Müller wrote: > > On 2016-11-01 01:03, Ryan Schmidt wrote: >> On Oct 31, 2016, at 17:17, Dan Ports wrote: >>> >>> Any reason not to just bulk-remove them all at once? >> >> That would probably tie up the buildbot for weeks or months. We could >> cancel those builds, but even the act of scheduling 20,000 builds per >> builder is much more than we've ever attempted before and I think it >> would not be happy about it. At the very least, I would want to wait >> until I've switched the buildbot from SQLite to PostgreSQL. > > Can we maybe decide on special commands in commit messages that cause > the buildbot to completely ignore the commit? Such things should not > limit us to what we can commit or not. > > Perhaps a footer line (similar to Signed-off-by) at the end, such as: > > buildbot: ignore Would it work as well to have the buildbots ignore commits with unchanged epoch_version_revision. — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Issues with oudated ports / GitHub
> On Oct 7, 2016, at 4:02 PM, Rainer Müller wrote: > > On 2016-10-07 20:58, Christopher Jones wrote: >> >>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez >>> wrote: >>> On Oct 7, 2016, at 2:09 PM, Chris Jones wrote: Currently, once they find out about svn, and trac >>> >>> We will still use Trac for issue tracking, although I believe >>> someone is looking into integrating GitHub sign in. > > Trac will stay. Clemens and I already wrote new modules for the > trac-github plugin [1] in order to allow both login with GitHub as main > authentication provider, migrating old tickets from mail addresses to > the GitHub accounts and all permissions in Trac will be based on team > memberships on GitHub. > > The only downside is that references to tickets will have to become full > URLs to Trac, because GitHub claims the #12345 syntax for their own > issue tracker and pull requests. Commits which contain such an URL will > automatically be linked from the corresponding ticket. See comment below, we use #12345 syntax in with our Redmine issue tracker. >> Personally I think we have to migrate away from trac as well. Pull >> requests in GitHub will largely replace what happens in trac for >> submission of patches and the discussion of them. If we stick with >> trac for issues then for me it will be an utter mess. > > Pull requests can be used in addition to tickets. For simple port > updates, there will be no need to open a ticket. > > We evaluated several options, including issue trackers provided by > GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the > conclusion that Trac is still the best option at hand. > > Especially with hosting our own installation, we will finally be able to > make more modifications and use custom plugins, that we never got > deployed at Mac OS Forge (for example [2]). Redmine is outstanding in my opinion. There is a Redmine github plugin [1] allowing Redmine installation to receive Github post-receive notifications. Redmine parses commit messages for configurable strings and can change issue status and add commit references to issue. Redmine can work with Subversion, Darcs, Mercurial, Bazaar, Git, and others. Oh, and Redmine is a quick and easy rails install away. [1] https://github.com/koppen/redmine_github_hook — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: reinplace permission denied mariadb-server
> On Oct 7, 2016, at 8:09 AM, Ryan Schmidt wrote:
>
>
>> On Oct 7, 2016, at 9:48 AM, Bradley Giesbrecht wrote:
>>
>> Hi,
>>
>>
>> mariadb-server is a support of mariadb.
>>
>>
>> In post-extract I copy a file from filespath and in post-patch I patch the
>> file with reinplace:
>> port cat mariadb-server:
>> ...
>> post-extract {
>> file mkdir ${worksrcpath}/macports
>> copy ${filespath}/org.macports.mysql-server.plist
>> ${worksrcpath}/macports/org.macports.${subport}.plist
>> }
>>
>> post-patch {
>> reinplace "s|@NAME@|${subport}|g" \
>> ${worksrcpath}/macports/org.macports.${subport}.plist
>> reinplace "s|@PREFIX@|${prefix}|g" \
>> ${worksrcpath}/macports/org.macports.${subport}.plist
>> reinplace "s|@NAMEMYSQL@|${name_mysql}|g" \
>> ${worksrcpath}/macports/org.macports.${subport}.plist
>> }
>> …
>>
>>
>> During post-patch I am getting a permission denied error:
>> sudo port patch mariadb-server
>> Error: reinplace: error copying
>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_databases_mariadb/mariadb-server/work/.tmp/org.macports.mariadb-server.plist.sed.rypaXG9w"
>> to
>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_databases_mariadb/mariadb-server/work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist":
>> permission denied
>>
>>
>> ls -la ./files/org.macports.mysql-server.plist
>> ./work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist
>> -rw-r--r-- 1 brad admin 805 Oct 6 08:10
>> ./files/org.macports.mysql-server.plist
>> -rw-r--r-- 1 macports admin 805 Oct 6 08:10
>> ./work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist
>>
>>
>> Is there an error in my file copy for reinplace patching?
>
> This is the bug:
>
> https://trac.macports.org/ticket/50918
>
> You can work around it by copying the file in pre-extract instead of
> post-extract.
Thanks Ryan, changing to pre-extract does not solve the problem nor does coping
the file to $worksrcpath instead of $worksrcpath/macports. This port has no
distfiles so $worksrcpath has to be created in the portfile resulting in the
same permissions problem.
Coping the file to $workpath is working.
—
Brad
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
reinplace permission denied mariadb-server
Hi,
mariadb-server is a support of mariadb.
In post-extract I copy a file from filespath and in post-patch I patch the file
with reinplace:
port cat mariadb-server:
...
post-extract {
file mkdir ${worksrcpath}/macports
copy ${filespath}/org.macports.mysql-server.plist
${worksrcpath}/macports/org.macports.${subport}.plist
}
post-patch {
reinplace "s|@NAME@|${subport}|g" \
${worksrcpath}/macports/org.macports.${subport}.plist
reinplace "s|@PREFIX@|${prefix}|g" \
${worksrcpath}/macports/org.macports.${subport}.plist
reinplace "s|@NAMEMYSQL@|${name_mysql}|g" \
${worksrcpath}/macports/org.macports.${subport}.plist
}
…
During post-patch I am getting a permission denied error:
sudo port patch mariadb-server
Error: reinplace: error copying
"/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_databases_mariadb/mariadb-server/work/.tmp/org.macports.mariadb-server.plist.sed.rypaXG9w"
to
"/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_databases_mariadb/mariadb-server/work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist":
permission denied
ls -la ./files/org.macports.mysql-server.plist
./work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist
-rw-r--r-- 1 brad admin 805 Oct 6 08:10
./files/org.macports.mysql-server.plist
-rw-r--r-- 1 macports admin 805 Oct 6 08:10
./work/mariadb-5.5.52/macports/org.macports.mariadb-server.plist
Is there an error in my file copy for reinplace patching?
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg
> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez wrote: > >> On Sep 5, 2016, at 8:42 AM, Craig Treleaven wrote: >> >> Not to belabour the issue, but should it not be the impact to port users >> that determines whether a change is “minor” or not? > > I believe the "minorness" of the change is wholly up to the maintainer. > >> The number of lines, by itself, doesn’t necessarily determine that impact. >> For example, a 1 or 2 line change in one of the database ports might make a >> new database engine the default. > > It is certainly true that a small change with great impact is not minor, but > a large change with little impact is also not minor. As an extreme example, I > would not appreciate a commit to one of my ports that had no impact on the > installation yet completely rearranged the portfile. I'd have to waste time > reading and understanding the committer's code, looking for edge cases and > failure modes, reworking local commits that no longer apply, etc. > > (This situation can already happen via timeout, but in that case there is a > clear, objective policy that maintainers implicitly agree to when they take > up maintainership.) > > My rule of thumb is that fixing typos and broken builds is almost always okay > under openmaintainer. Many maintainers also permit minor version bumps and > bug fixes, but some don't. In all cases, it's safest to wait out the 72 hours. I was going to add to the ticket but maybe this is a better place to discuss for now. I have attempted to keep the mysql ports similar to make maintaining them easier. I have a few questions regarding these changes. 1. Will "port load mariadb-server" work? 2. Has this been tested on older systems? 3. Can the pkg run concurrently with the port? I assume pkg installs into $prefix, am I right? 4. Is there any reason the same changes would not work for the mysql*-server, mariadb*-server and persona-server ports? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: snapd
> On Jun 17, 2016, at 11:00 PM, Mojca Miklavec wrote: > > I would absolutely *love* > to be able to install MacPorts (or HomeBrew or snap or anything else > for that matter) and create a port/package where I would list the > dependencies and then make a package that would automatically generate > a self-contained .app. As would for example the octave folks, but how would a self contained .app bundle handle all the “add-on” octave ports that likely all want to work together? port echo name:octave Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [149320] trunk/dports/lang/qore-mysql-module
Base should be enhanced to allow dots “.” in variant names.
We could then write variant names like "mariadb10.0” and “mariadb10.1" instead
of the ambiguous “mariadb100” and “mariadb101”.
Regards,
Bradley Giesbrecht (pixilla)
> On Jun 10, 2016, at 11:56 PM, Jeremy Huddleston Sequoia
> wrote:
>
> Failed to parse file lang/qore-mysql-module/Portfile: Variant name
> mariadb-10.0 contains invalid characters
>
>> On Jun 10, 2016, at 23:15, davidnich...@macports.org wrote:
>>
>> Revision
>> 149320
>> Author
>> davidnich...@macports.org
>> Date
>> 2016-06-10 23:15:48 -0700 (Fri, 10 Jun 2016)
>> Log Message
>>
>> qore-mysql-module: updated to v2.0.2 and added support for newer mysql and
>> mariadb ports
>> Modified Paths
>>
>> • trunk/dports/lang/qore-mysql-module/Portfile
>> Removed Paths
>>
>> • trunk/dports/lang/qore-mysql-module/files/
>> Diff
>>
>> Modified: trunk/dports/lang/qore-mysql-module/Portfile (149319 => 149320)
>>
>> --- trunk/dports/lang/qore-mysql-module/Portfile 2016-06-11 06:01:57 UTC
>> (rev 149319)
>> +++ trunk/dports/lang/qore-mysql-module/Portfile 2016-06-11 06:15:48 UTC
>> (rev 149320)
>>
>> @@ -4,8 +4,7 @@
>>
>> PortSystem 1.0
>>
>>
>>
>> nameqore-mysql-module
>>
>> -version 2.0.1
>> -revision1
>>
>> +version 2.0.2
>>
>> categories lang
>>
>> license LGPL-2.1
>>
>> maintainers davidnichols
>>
>> @@ -14,32 +13,39 @@
>>
>> use_bzip2 yes
>>
>> homepagehttp://qore.org
>> platforms darwin
>>
>> -master_sitessourceforge:qore
>>
>> +master_sites
>> https://github.com/qorelanguage/module-mysql/releases/download/v${version}
>>
>>
>> -checksums md5 28e9a89f7e543f46ddb6bb3dcc838c2c \
>> -sha1 4c219ce39d2fc0c025e1dc46fe7a6a8bff5f0020 \
>> -rmd160 172c9f9ebee4b638e470e096e1537d6decff3af3
>>
>> +checksums md5 29800c39a41c90824ef530c551ae4a7e \
>> +sha1 5abf5c0ddea7719bee45dae0cbea76d8afe13dbe \
>> +rmd160 c3459e518186bfc4176cbb8b06adf5d68bcd4943
>>
>>
>>
>> -patchfiles patch-configure
>>
>> +variant mariadb conflicts mariadb-10.0 mariadb-10.1 mysql51 mysql55 mysql56
>> mysql57 percona description {use mariadb} {}
>> +variant mariadb-10.0 conflicts mariadb mariadb-10.1 mysql51 mysql55 mysql56
>> mysql57 percona description {use mariadb-10.0} {}
>> +variant mariadb-10.1 conflicts mariadb mariadb-10.0 mysql51 mysql55 mysql56
>> mysql57 percona description {use mariadb-10.1} {}
>> +variant mysql51 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql55 mysql56
>> mysql57 percona description {use mysql 5.1} {}
>> +variant mysql55 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql56
>> mysql57 percona description {use mysql 5.5} {}
>> +variant mysql56 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55
>> mysql57 percona description {use mysql 5.6} {}
>> +variant mysql57 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55
>> mysql56 percona description {use mysql 5.7} {}
>> +variant percona conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55
>> mysql56 mysql57 description {use percona} {}
>>
>>
>>
>> -variant mariadb conflicts mysql51 mysql55 mysql56 percona description {use
>> mariadb} {}
>> -variant mysql51 conflicts mariadb mysql55 mysql56 percona description {use
>> mysql 5.1} {}
>> -variant mysql55 conflicts mariadb mysql51 mysql56 percona description {use
>> mysql 5.5} {}
>> -variant mysql56 conflicts mariadb mysql51 mysql55 percona description {use
>> mysql 5.6} {}
>> -variant percona conflicts mariadb mysql51 mysql55 mysql56 description {use
>> percona} {}
>> -
>> -if {![variant_isset mariadb] && ![variant_isset mysql51] && ![variant_isset
>> mysql55] && ![variant_isset mysql56] && ![variant_isset percona]} {
>>
>> +if {![variant_isset mariadb] && ![variant_isset mariadb-10.0] &&
>> ![variant_isset mariadb-10.1] && ![variant_isset mysql51] && ![variant_isset
>> mysql55] && ![variant_isset mysql56] && ![variant_isset mysql57] &&
>> ![variant_isset percona]} {
>>
>> default_variants +mar
Re: code-signing (log message and potential "fixes")
> On May 21, 2016, at 4:33 PM, Rainer Müller wrote: > > On 05/21/2016 04:33 PM, René J.V. Bertin wrote: >> ..., >> wouldn't it be possible to design an interface that allows users to specify >> an identity in macports.conf, and ports to invoke codesign in the >> post-activate stage? > > Yes, of course. This would be the way to implement code-signing. When > previously > discussed, the suggestion was to generate a local identity automatically. > > Although I am not aware of a method to automatically generate and import a > certificate into the System keychain for code signing except using the > Certificate Assistant in Keychain Access.app. > > For the details of code-signing, see these instructions for example: > https://sourceware.org/gdb/wiki/BuildingOnDarwin OpenSSL might be able to accomplish the same task and it is possible with OpenSSL to write a config file that fills in all the required fields. Port could write such a config per user. https://developer.apple.com/library/mac/technotes/tn2206/_index.html Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: *-devel ports for llvm and gcc
> On May 4, 2016, at 7:47 AM, Ryan Schmidt wrote: > > >> On May 4, 2016, at 9:38 AM, Rainer Müller wrote: >> >> On 2016-05-04 15:20, Ryan Schmidt wrote: >>>> In my opinion, llvm-3.8 and llvm-3.9 should really have a -devel >>>> prefix as long as they provide pre-releases. The same also applies >>>> to gcc6. With the *-devel naming scheme it would be easy to >>>> identify the latest stable version. >>> >>> I disagree. We currently have two naming schemes: >>> >>> foo and foo-devel: this means the ports install different versions of >>> the same software to the same places; the ports conflict and are >>> drop-in replacements for one another. Other ports declare >>> dependencies on this port using path:-syntax. >>> >>> foo1, foo2, foo3: this means the ports install different versions of >>> the same software to different places; the ports do not conflict. >>> Other ports declare variants for each version they want to support. >> >> Actually I agree with this. My request was that in addition to that any >> port providing unstable/pre-release software should have a *-devel suffix. >> >> In this case, if the port is made to track the development of what will >> become LLVM 3.9, it should be named llvm-3.9-devel. Only after LLVM 3.9 >> is released as a stable version it should be renamed to llvm-3.9. The >> ports llvm-3.9 and llvm-3.9-devel are still drop-in replacements. > > This makes it much more difficult on developers when the time comes for a > port to graduate from development to stable status, as I'm currently doing > with gcc6. I don't want to impose that extra work on myself or other > developers. > > >> Users should easily see which port provides a stable version and which >> tracks a pre-release. > > Maybe there's another way we can indicate whether a port is stable or not. categories lang unstable ? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fail port when using Local repository
> On Apr 20, 2016, at 11:34 PM, Ryan Schmidt wrote: > > > On Apr 20, 2016, at 11:22 PM, Abdulrahman Alshammari wrote: >> >> I want to check if the local port works fine with the portfile I added >> locally. I follow the instruction in the documentation. I got this error: >> >> Failed to parse file devel/civl/Portfile: invalid command name "(2)" > > The portfile has invalid syntax, right before "(2)", specifically, a > semicolon. Both of the semicolons in the long description need to be escaped > with a backslash: \; Quick draw Ryan wins again:) Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: variants
> On Apr 12, 2016, at 5:41 AM, Takeshi Enomoto wrote: > >> The implementation I propose is: pass on default variants like for >> user-selected variants, nothing more or less. > > The compiliation does not have to be avoided for variants, > but it would be nice if the default variants were proliferated. What would the variants be for "port install all”? Would there be the potential to see a lot of variant conflicts? I think the way default variants are handled now is best. Let those users that need special variant combinations figure out that special combination rather then have ports installed with variable variants depending on what else might be installed at the time. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: variants
> On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke <mailto:dl...@geeklair.net>> wrote: > On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto <mailto:take...@macports.org>> wrote: > > If there is a reason behind treating default_variants and manually set > > variants, > > I’d like to know. > > I'm not sure what the initial reasoning was, but I think the current behavior > is correct. > > When a port is installed as a dependency of some other port, it should be > installed the same way as if it were installed manually first. > > ie. A requires B: > > port install A > and > > port install B && port install A > > should result in the same final install. > > On Apr 11, 2016, at 12:29 PM, David Strubbe wrote: > > Well, that is not the current behavior if a variant is specified manually. > What happens is: > > port install A +var > > does > > port install B +var && port install A +var. > > Why do you think it would be inappropriate to do that for default variants? Binaries are only provided for default variants so you might loose binary packages for dependencies due to variants you don’t care about in the dependency. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: registry backup (and upgrade --force)
> On Apr 4, 2016, at 9:45 AM, Bradley Giesbrecht wrote: > >> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote: >> >> Bradley Giesbrecht wrote: >> >>> Did you keep a copy of the registry? If so, try opening it with the sqlite >>> client. >> >> Thanks for the suggestion. Curiously that went just fine, but it also seems >> to >> contradict the previous claim that any interaction with an sqlite3 db >> modifies >> it. I did a .dump which completed without errors, but the file'smodification >> date never changed. Ditto for a .backup . >> >> I could move the current registry aside and restore the backup (or the >> additional backup made with the .backup command), but that would be of >> academic >> interest only as the information in the file is now out of date. > > In my experience, without simply opening the database in the sqlite client > “fixed” ports access to the database, no dumps or no special commands, just > open, close and run port. s/without simply/simply/ Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: registry backup (and upgrade --force)
> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote: > > Bradley Giesbrecht wrote: > >> Did you keep a copy of the registry? If so, try opening it with the sqlite >> client. > > Thanks for the suggestion. Curiously that went just fine, but it also seems > to > contradict the previous claim that any interaction with an sqlite3 db > modifies > it. I did a .dump which completed without errors, but the file'smodification > date never changed. Ditto for a .backup . > > I could move the current registry aside and restore the backup (or the > additional backup made with the .backup command), but that would be of > academic > interest only as the information in the file is now out of date. In my experience, without simply opening the database in the sqlite client “fixed” ports access to the database, no dumps or no special commands, just open, close and run port. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: registry backup (and upgrade --force)
> On Apr 3, 2016, at 2:31 AM, René J.V. Bertin wrote: > > Hi, > > I just went through a bit of a hairy exercise. With a bit too much > distraction and hurry going on I did a `port upgrade --force` of a port I'd > just rebuilt from source so I forgot both the -s and the (crucial) -n > options. Seeing the resulting "reinstall all dependencies" begin to happen, I > hit ^C, but not before I had already replaced my libiconv with an apparently > incompatible binary package. > > Subsequent port commands hung without even a line of debug output, which I > finally presumed due to registry corruption. There was no backup in > var/macports/registry, but fortunately I had an up-to-date copy in my > previous TM backup (evidently the Latest backup already contained the > corrupted file). Did you try opening the sqlite registry database using the sqlite command line client after the “corruption”? In the past when I experienced issues with port accessing the registry I would open the registry with the sqlite client which would do some maintenance procedure (vacuum ?) which fixed the registry in all the 5 to 10 times I have experienced registry access issues. Did you keep a copy of the registry? If so, try opening it with the sqlite client. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [146276] trunk/dports/databases
> On Mar 6, 2016, at 11:22 AM, Mojca Miklavec wrote: > > On 6 March 2016 at 18:01, Bradley Giesbrecht wrote: >> >> We could remove all ports that depend on mysql4 and mysql5 exclusively or >> via default variants. The remaining ports would then have their mysql4 or >> mysql5 variant removed. >> >> The removed ports could be brought back if someone was interested in fixing >> them. > > That would be a bit harsh, wouldn't it? I bet that a number of ports > would work with a different database without any additional patches. > > I asked long ago if someone could provide guidelines for transition, > but nobody did. It's not clear to me what the suggested way is, so > that we could at least make some consistent changes rather than every > port switching to a different database with completely different code. I propose that someone other then me fix base to allow variants with the same naming convention as port names. This would allow variants with hyphens and dots. So the hyphens will be problematic, ok. But the dots are somewhat important. Is +mariadb_101 mariadb 1.01 10.1 or 100? I looked at updating base to allow dots in variant names and it didn’t look to difficult, at one point a I had a patch that worked in my testing, but I didn’t feel comfortable enough with base to make the change and the discussion on the list didn’t get much traction although I remember people mentioning it would be good to not have ambiguous version strings in names of ports and variants. Coming up with a standard variant name for the mariadb-10.0 and mariadb-10.1 is the place to start in my opinion. A second thought is to create a mysql portgroup which sets some helper variables like $mysql_lib_path, $mysql_include_path and $mysql_config_path. The portgroup might also have a method to create mysql stub variants to enforce variant naming conventions with commented code blocks to show how to test if a variant is active and examples of using the portgroups helper variables. Can we get dots in variant names into base soon? If not, what should be the standard for variant names when the port it is targeting has dots in its name? — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [146276] trunk/dports/databases
> On Mar 5, 2016, at 3:39 AM, Ryan Schmidt wrote: > >> >> On Mar 3, 2016, at 6:10 PM, Bradley Giesbrecht wrote: >> >>> On Mar 3, 2016, at 12:14 AM, Juan Manuel Palacios wrote: >>> >>> Bradley, >>> >>> I think you and I already discussed this in some thread, but I can’t >>> remember right now… >>> >>> What’s the point of the mysql5 port now a-days? I’d say it’s redundant with >>> mysql51, but not even, ‘cause it’s outdated with respect to it, 5.1.72 Vs. >>> 5.1.73. Shouldn’t we just obsolete that port and have it replaced by >>> mysql51? >> >> >> These ports have dependencies on mysql5 either directly or through variants: >> port info --name --variants depends:"(\W|^)mysql5(\W|$)" or >> variant:"(\W|^)mysql5(\W|$)" | grep -E "^name:|^variants:.*mysql5|—" >> >> Ticket discussing issue: >> https://trac.macports.org/ticket/43431 > > It's been so long, I think it's probably find to make mysql5 replaced_by > mysql51, even if there are still ports depending on mysql5. The old php5- > ports were deleted awhile ago, even though there are still ancient ports > declaring dependencies on them. We could remove all ports that depend on mysql4 and mysql5 exclusively or via default variants. The remaining ports would then have their mysql4 or mysql5 variant removed. The removed ports could be brought back if someone was interested in fixing them. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [146276] trunk/dports/databases
> On Mar 3, 2016, at 12:14 AM, Juan Manuel Palacios wrote: > > Bradley, > > I think you and I already discussed this in some thread, but I can’t remember > right now… > > What’s the point of the mysql5 port now a-days? I’d say it’s redundant with > mysql51, but not even, ‘cause it’s outdated with respect to it, 5.1.72 Vs. > 5.1.73. Shouldn’t we just obsolete that port and have it replaced by mysql51? These ports have dependencies on mysql5 either directly or through variants: port info --name --variants depends:"(\W|^)mysql5(\W|$)" or variant:"(\W|^)mysql5(\W|$)" | grep -E "^name:|^variants:.*mysql5|—" Ticket discussing issue: https://trac.macports.org/ticket/43431 Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Apache2 rev bump for OpenSSL update
> On Mar 3, 2016, at 12:09 AM, Juan Manuel Palacios wrote: >> On Mar 3, 2016, at 3:35 AM, Ryan Schmidt wrote: >>> On Mar 3, 2016, at 00:18, Juan Manuel Palacios wrote: >>> >>> Apache 2 rev-bumped, cf. r146274. >>> >>> On a side note, and if I may in this same thread, do we have any policy for >>> not moving the Apache 2.4 port out of “dev”? Not too sure when it became >>> the recommended release series by the ASF, but it certainly isn’t dev any >>> longer. >> >> There's a ticket you can read. We can't just replace the current apache2 >> port with the current apache24-devel port because it also changes the >> directory layout. > > Yeah, that I understand, we keep versioned ports for other packages too, e.g. > mysql55, mysql56, mysql57, and other examples. And we don’t replace one with > the other for a myriad of reasons. With versioned apache24 modules like apache24-mod_python27. > So we could deprecate the apache24-devel port and create apache24, maybe even > also deprecating apache2 and eventually replacing it with apache22, which > needless to say would be compatible with the former, and would live on in > parallel to apache24, just as mysql55 does to mysql56, etc. > > You have a URL for that ticket that you mention? https://trac.macports.org/ticket/35824 — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Apache2 rev bump for OpenSSL update
Done in: https://trac.macports.org/changeset/146276 https://trac.macports.org/changeset/146277 Regards, Bradley Giesbrecht (pixilla) > On Mar 2, 2016, at 7:03 PM, Bradley Giesbrecht wrote: > > All the mysql ports with the exception of mysql5 are revbumped by > incrementing the revision_client var just after the version number in the > Portfile. > > $ port echo name:^\(mariadb[0-9.-]*\|percona\|mysql5[0-9]*\)$ > mariadb > mariadb-10.0 > mariadb-10.1 > mysql5 > mysql51 > mysql55 > mysql56 > mysql57 > percona > > I can do it, is this the openssl revision to reference in the commit message? > https://trac.macports.org/changeset/146162 > > > Regards, > Bradley Giesbrecht (pixilla) > > > > >> On Mar 2, 2016, at 5:42 PM, Juan Manuel Palacios wrote: >> >> True enough. I’ll at least take care of the Apache 2 port in a bit if no one >> beats me to it, and I’ll see what can be done for the MySQL ports. >> >>> On Mar 2, 2016, at 9:10 PM, Ryan Schmidt wrote: >>> >>> On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios wrote: >>>> >>>>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt wrote: >>>>> >>>>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios wrote: >>>>>> >>>>>> Hey Ryan, >>>>>> >>>>>> The Apache 2 port is failing a reload with the "Symbol not found: >>>>>> _SSLv2_client_method” error (Referenced from: >>>>>> /opt/local/apache2/modules/mod_ssl.so\n Expected in: >>>>>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, >>>>>> which removed SSLv2. >>>>>> >>>>>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the >>>>>> new OpenSSL? >>>>> >>>>> And all the other ports that link with openssl. >>>> >>>> Indeed, but I aint maintainer ;) >>>> >>>> I got Apache to work simply by forcing a rebuild against new OpenSSL. >>> >>> >>> I consider it the responsibility of the committer who updated the openssl >>> port to the version that changed its library ABI to revbump the ports that >>> link with it, regardless of maintainer status. It should have been done at >>> the same time that openssl was updated of course. I'm not working on it so >>> someone else is welcome to do it. >>> >>> >>> >> >> ___ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> https://lists.macosforge.org/mailman/listinfo/macports-dev > ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Apache2 rev bump for OpenSSL update
All the mysql ports with the exception of mysql5 are revbumped by incrementing the revision_client var just after the version number in the Portfile. $ port echo name:^\(mariadb[0-9.-]*\|percona\|mysql5[0-9]*\)$ mariadb mariadb-10.0 mariadb-10.1 mysql5 mysql51 mysql55 mysql56 mysql57 percona I can do it, is this the openssl revision to reference in the commit message? https://trac.macports.org/changeset/146162 Regards, Bradley Giesbrecht (pixilla) > On Mar 2, 2016, at 5:42 PM, Juan Manuel Palacios wrote: > > True enough. I’ll at least take care of the Apache 2 port in a bit if no one > beats me to it, and I’ll see what can be done for the MySQL ports. > >> On Mar 2, 2016, at 9:10 PM, Ryan Schmidt wrote: >> >> On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios wrote: >>> >>>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt wrote: >>>> >>>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios wrote: >>>>> >>>>> Hey Ryan, >>>>> >>>>> The Apache 2 port is failing a reload with the "Symbol not found: >>>>> _SSLv2_client_method” error (Referenced from: >>>>> /opt/local/apache2/modules/mod_ssl.so\n Expected in: >>>>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, >>>>> which removed SSLv2. >>>>> >>>>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the >>>>> new OpenSSL? >>>> >>>> And all the other ports that link with openssl. >>> >>> Indeed, but I aint maintainer ;) >>> >>> I got Apache to work simply by forcing a rebuild against new OpenSSL. >> >> >> I consider it the responsibility of the committer who updated the openssl >> port to the version that changed its library ABI to revbump the ports that >> link with it, regardless of maintainer status. It should have been done at >> the same time that openssl was updated of course. I'm not working on it so >> someone else is welcome to do it. >> >> >> > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #50678: makeicns does not build on Snow Leopard with libc++
> On Feb 27, 2016, at 2:13 PM, MacPorts wrote: > > #50678: makeicns does not build on Snow Leopard with libc++ > -+- > Reporter: steven.dwyer@… | Owner: mk@… > Type: defect | Status: new > Priority: Normal | Milestone: > Component: ports |Version: 2.3.4 > Resolution: | Keywords: snowleopard > Port: makeicns| > -+- > > Comment (by mk@…): > > pixilla, do you perhaps have a clue what's going on here? I don't even > have SL anymore to test this. Me either. When I get some time I can get a SN vm up and test it but that will likely be a couple weeks from now. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
cmake order of includes
When building mysql56 with the bundled yassl instead of macports openssl, cmake finds the openssl headers in prefix before the bundled yassl headers in worksrcpath because cmake is including prefix/include before the bundled yassl/include resulting in a build error. Is there a standard way to correct this? The mysql56 port patches cmake/install_layout.cmake and adding the worksrcpath include path there does work. Does a port or cmake port group variable/method exist to fix this or is patching the way to go? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Now Accepting GSoC 2016 Mentor Organization Applications
> On Feb 18, 2016, at 6:50 AM, Rainer Müller wrote: > > On 2016-02-12 13:56, Rainer Müller wrote: >> Paging those who handled this last year, is there any interest to >> participate again? > > I shortly discussed this with Clemens in private conversation. With the > deadline approaching, I just want to get out that we will skip > participation in GSoC this year. > > Last year, we reached our goal of merging all base work after the summer > to trunk. This was a success compared to previous years, as previous > implemented features are still dormant in branches. > > However, now on trunk it is still in an unfinished state. In my opinion > it would be difficult to branch off new feature branches for students to > work on from this state. This currently also blocks new releases. > > This year, we should focus on integration of branches from previous > editions of GSoC. Let us finish and release these features before > starting new work. Makes sense, thank you for getting the message out. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC port-util project
Thanks and good luck! Here is my scripts dir: https://trac.macports.org/browser/users/pixilla/scripts?rev=137458&order=name <https://trac.macports.org/browser/users/pixilla/scripts?rev=137458&order=name> Any developers interested in share links to their scripts or a list functionality they provide please do. Regards, Bradley Giesbrecht (pixilla) > On Feb 18, 2016, at 1:47 AM, Aljaž 'g5pw' Srebrnič wrote: > > That’s interesting! I have some tools and a wrapper that I use on a daily > basis, I’m gonna talk about it on the MacPorts Meeting, but the sources are > here: https://github.com/g5pw/port-wrapper > <https://github.com/g5pw/port-wrapper>. could be used as an > inspiration/starting point for a discussion! > > On 16 febbraio 2016 at 15:26:05, Brandon Allbery (allber...@gmail.com > <mailto:allber...@gmail.com>) wrote: > >> I would like to propose a port-util dev tools project for GS0C 2016. >> >> Over time people have suggested adding functionality to port that would aid >> in MacPorts development. >> To keep port lean and user friendly many of these ideas have not made it >> into base. >> >> The port-util tool would tap into base for core logic and provide a >> pluggable architecture for extending that functionality for audiences beyond >> end users. >> >> RFC > -- > Aljaž Srebrnič a.k.a g5pw > My public key: http://bit.ly/g5pw_pubkey <http://bit.ly/g5pw_pubkey> ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Now Accepting GSoC 2016 Mentor Organization Applications
Me too. Regards, Bradley Giesbrecht (pixilla) > On Feb 15, 2016, at 4:25 PM, Michael Dickens wrote: > > I've enjoyed being a mentor thus far, so I'm game for seeing what comes > up if others are. Is SNC going to lead the way again? - MLD > > On Fri, Feb 12, 2016, at 07:56 AM, Rainer Müller wrote: >> Paging those who handled this last year, is there any interest to >> participate again? > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC port-util project
> On Feb 15, 2016, at 6:59 PM, Michael Dickens wrote:
>
> On Mon, Feb 15, 2016, at 09:33 PM, Mihai Moldovan wrote:
>> On 16.02.2016 01:34 AM, Michael Dickens wrote:
>>> An example would be a "check and try update" task that would: do a
>>> livecheck and if found to be old then automatically try to do the
>>> update: change the version, download the distfile, update the checksums
>>> in the Portfile, try to upgrade using -s -k to specify from source and
>>> to keep stuff around if successful.
>>
>> Just a thought on this particular item... maybe it's just me OCDing, but
>> I don't
>> think a procedure like this should be sanctioned. Blindly updating like
>> this is
>> dangerous, because you run into problems with also updated dependencies,
>> which
>> you might not even see.
>>
>> I generally diff the old and new version (if possible using SCM as that's
>> more
>> comfortable) and look through what might have changed within the
>> autotools files
>> (or whatever build system the port is using.)
>>
>> It's a tedious task, but you risk missing changes otherwise.
>
> I somehow doubt that most of us Portfile-level developers do a lot of
> SCM diffing between versions. I know for myself that there's just not
> enough time in the day to do so for every port I maintain. For some
> ports I do do this, just just a few. That said, if any specific MP dev
> want to do SCM diffing then that's his/her right IMHO. I don't think
> this MO should be required of all MP devs on all ports.
>
> I see this particular item as a quick way to test to see if a port needs
> updating, and if so then test to see if it is easily updatable. It has
> everything to do with buildability, and nothing to do with diffing
> between versions.
>
> All of this said, I think we're talking hypotheticals here anyway. I'm
> not even sure this is what pixilla meant in the first place. - MLD
This is along the lines of what I had in mind.
I have a bunch of scripts for creating patches, checking for updates, checking
trac for tickets, svn {st,diff,ci} etc…, and I know others do to. I don’t know
if TCL has this capability but I would be handy at times to dump all declared
vars instead of hunting through port groups, man pages and other portfiles. And
env vars.
Ideally a port-util that could act like port (load the same libs) but be
extended via plugins to included things best left out of the port command.
—
Brad
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
GSoC port-util project
I would like to propose a port-util dev tools project for GS0C 2016. Over time people have suggested adding functionality to port that would aid in MacPorts development. To keep port lean and user friendly many of these ideas have not made it into base. The port-util tool would tap into base for core logic and provide a pluggable architecture for extending that functionality for audiences beyond end users. RFC Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Review Request
> On Feb 6, 2016, at 12:18 PM, Casey Rodarmor wrote: > > Hi there, > > May I request a review of https://trac.macports.org/ticket/50540? It's a > pretty simple new port. Oddly, in my email client the above url is a link to https://www.google.com/calendar/event?action=VIEW&eid=czZ1bmFxYmVkaWRrZDIxNTQ4MWI5ZGpoMW8gY2FzZXlAcm9kYXJtb3IuY29t Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [143621] trunk/dports/lang/perl5/Portfile
> On Dec 15, 2015, at 4:10 PM, Bradley Giesbrecht wrote: > > Perhaps patchfiles could take a path as a value? > > patchfiles patch-current.diff > patchfiles patch-relative-to-filespath.diff Whoops: patchfiles somedir/patch-relative-path.diff > patchfiles /why/would/we/want/this/patch-full-path.diff Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [143621] trunk/dports/lang/perl5/Portfile
Perhaps patchfiles could take a path as a value?
patchfiles patch-current.diff
patchfiles patch-relative-to-filespath.diff
patchfiles /why/would/we/want/this/patch-full-path.diff
I should have check first, does patchfiles already work this way?
Regards,
Bradley Giesbrecht (pixilla)
> On Dec 15, 2015, at 4:02 PM, mcalh...@macports.org wrote:
>
> Revision
> 143621 <https://trac.macports.org/changeset/143621>Author
> mcalh...@macports.org <mailto:mcalh...@macports.org>Date
> 2015-12-15 16:02:40 -0800 (Tue, 15 Dec 2015)
> Log Message
>
> perl5: allow patch file to be found in new file structure of r143612
> <https://trac.macports.org/changeset/143612>
> Modified Paths
>
> trunk/dports/lang/perl5/Portfile
> Diff
>
> <>Modified: trunk/dports/lang/perl5/Portfile (143620 => 143621)
>
> --- trunk/dports/lang/perl5/Portfile 2015-12-16 00:00:52 UTC (rev 143620)
> +++ trunk/dports/lang/perl5/Portfile 2015-12-16 00:02:40 UTC (rev 143621)
> @@ -121,7 +121,7 @@
>
> if {[variant_isset universal]} {
> post-configure {
> -system "cd ${worksrcpath} && ed - ${worksrcpath}/config.h <
> ${filespath}/config.h.ed"
> +system "cd ${worksrcpath} && ed - ${worksrcpath}/config.h <
> ${filespath}/${perl5.major}/config.h.ed"
> }
> }
>
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> <mailto:macports-chan...@lists.macosforge.org>
> https://lists.macosforge.org/mailman/listinfo/macports-changes
> <https://lists.macosforge.org/mailman/listinfo/macports-changes>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New Mac OS Forge administrator
> On Nov 19, 2015, at 6:49 PM, Ryan Schmidt wrote: > > Dear MacPorts users and developers, > > I'm pleased finally to be able to tell you that I have been hired to be your > new Mac OS Forge administrator. I have been involved in improving MacPorts > for years as a committer and as a manager, and now as a Mac OS Forge > administrator I will work on ensuring our infrastructure runs smoothly too. > > I apologize for the downtime we've experienced in the past months. My > priority right now is to resolve the existing issues, as I become familiar > with the systems. > > Please continue to report new problems with MacPorts infrastructure (server > not working) as you have before, using the server/hosting component in Trac > or via email to admin at macosforge dot org. And continue to report MacPorts > administrative issues (mailing list issues, commit access requests) to > portmgr at macports dot org. > > Thanks for your patience and support and thank you for using MacPorts. > > -Ryan Bam, confidence restored! Congratulations. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: buildbot failure in MacPorts on buildports-yosemite-x86_64
> On Nov 18, 2015, at 3:14 PM, nore...@macports.org wrote:
>
> The Buildbot has detected a failed build on builder
> buildports-yosemite-x86_64 while building MacPorts.
> Full details are available at:
> http://build.macports.org/builders/buildports-yosemite-x86_64/builds/6247
>
> Buildbot URL: http://build.macports.org/
>
> Buildslave for this Build: apple-yosemite-x86_64-ports
>
> Build Reason: The web-page 'force build' button was pressed by 'ryandesign
> ': force build
>
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed compile status
It would be pretty awesome if the port(s) that triggered my email to be
included in this notice could be represented in the email body as:
...
Build Port: {port name} FAILED
…
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: buildbot failure in MacPorts on buildports-lion-x86_64
> On Oct 15, 2015, at 4:16 PM, Ryan Schmidt wrote: > > On Oct 15, 2015, at 17:56, Bradley Giesbrecht <mailto:pixi...@macports.org>> wrote: > >>> On Oct 15, 2015, at 3:39 PM, nore...@macports.org wrote: >>> >>> The Buildbot has detected a failed build on builder buildports-lion-x86_64 >>> while building MacPorts. >>> Full details are available at: >>> http://build.macports.org/builders/buildports-lion-x86_64/builds/31003 >>> >>> Buildbot URL: http://build.macports.org/ >>> >>> Buildslave for this Build: apple-lion-x86_64-ports >>> >>> Build Reason: The web-page 'force build' button was pressed by 'devans >>> ': force build >>> >>> Build Source Stamp: HEAD >>> Blamelist: >>> >>> BUILD FAILED: failed status >> >> Logs have image errors: >> ... >> org.macports.activate for port ncurses returned: Image error: >> /opt/local/bin/captoinfo already exists and does not belong to a registered >> port. >> … > > The problem is being worked on. See #48486. Thanks, I saw that ticket just after I sent this message. It’s wonderful to see some progress with the trac/svn/buildbot/vms! Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: buildbot failure in MacPorts on buildports-lion-x86_64
> On Oct 15, 2015, at 3:39 PM, nore...@macports.org wrote: > > The Buildbot has detected a failed build on builder buildports-lion-x86_64 > while building MacPorts. > Full details are available at: > http://build.macports.org/builders/buildports-lion-x86_64/builds/31003 > > Buildbot URL: http://build.macports.org/ > > Buildslave for this Build: apple-lion-x86_64-ports > > Build Reason: The web-page 'force build' button was pressed by 'devans > ': force build > > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed status Logs have image errors: ... org.macports.activate for port ncurses returned: Image error: /opt/local/bin/captoinfo already exists and does not belong to a registered port. … — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [140813] trunk/dports/science/OpenCoarrays/Portfile
> On Oct 3, 2015, at 2:44 PM, Clemens Lang wrote: > > > > - On 3 Oct, 2015, at 23:33, Bradley Giesbrecht pixi...@macports.org wrote: > >> I understood that even with mpstatl installed it was still opt-in and the >> user >> had to make a config change to actually report. Is my understanding >> incorrect? > > mpstats uses startupitem.autoload to automatically start statistics reporting > after installation. It sends reports on a random weekday on the hour and two > minutes after you've installed it. > > See also: $> port notes mpstats: > Installing this port automatically enables weekly reporting of data to the > stats > server. Uninstall or deactivate this port if you want to stop providing > data to > MacPorts. Thank you Clemens for the explantation. I read the Portfile and saw the startupitem.autoload which was a new control to me. My concern is that since there is consensus that we should not report without user intention that a mistake like mine where I did not know mpstat used startupitem.autoload that one cannot easily fix the issue for anyone who installed before the problem was fixed. They now have mpstat. I like that mpstat uses startupitem.autoload, I think it make the port simpler for those that want it. Is there a macports mechanism for declaring a port cannot be a dependent? — Brad ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [140813] trunk/dports/science/OpenCoarrays/Portfile
> On Oct 3, 2015, at 1:21 PM, Clemens Lang wrote: > > > > - On 3 Oct, 2015, at 22:14, Clemens Lang c...@macports.org wrote: > >> I don't think forcing users to participate in statistics collection like >> this is OK with their consent, at least not according to German data > > > I obviously meant withOUT their explicit consent, sorry for the typo. I understood that even with mpstatl installed it was still opt-in and the user had to make a config change to actually report. Is my understanding incorrect? — Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration instructions
> On Sep 14, 2015, at 1:10 PM, David Strubbe wrote:
>
> Hello all,
>
> I have just updated to Yosemite and used the migration instructions at
> http://trac.macports.org/wiki/Migration
> <http://trac.macports.org/wiki/Migration>
>
> I want to point out two issues:
>
> 1. Running "sudo port clean all" takes a huge amount of time. Apparently many
> hours for me; I didn't have the patience to let it finish. Instead we should
> clean just the ports that have incomplete builds (probably just a few in most
> cases) which can be found by looking at /opt/local/var/macports/builds and
> /optlocal/var/macports/logs I think, saving a lot of time.
Assuming default prefix would this [1] cover it?
> 2. The list of ports generated in myports.txt and requested.txt will include
> ports that are deactivated, including one line for each version of a port,
> whether active or not. One line total regardless of number of versions would
> be sufficient. Re-installing deactivated ports should probably not be done by
> default since that is not returning you to the original state and there was
> probably a reason (such as conflicts) why the ports were deactivated.
Untested, try this [2] to only install requested ports WITH variants. I’m not
sure the last sed match works if there are variants name ".*_[0-9]".
[1] for port in $(find /opt/local/var/macports/{build,logs} -depth 2 -type d |
awk -F/ '{print $NF}') ; do sudo port clean $port ; done
[2] port -q installed requested and active | sed -e 's,^ *,,' -e 's,
(active),,' -e 's,@[^_]*_[0-9]*,,’
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [139676] branches/gsoc15-dependency/base/vendor/libsolv.tar.gz
> On Aug 24, 2015, at 11:01 PM, Joshua Root wrote: > > On 2015-8-25 15:45 , Jackson Isaac wrote: >> What if we can commit the extracted folder rather than the tarball ? >> This way we can see the files and also track the changes. Also it will >> be easier to make changes and not push the whole tarball every now and >> then. > > Right, that was the alternative I had in mind. Why not a patch file? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [137557] users/chunyang
Chunyang, Regarding MacPorts contributions please consider using the BSD; or if the BSD license is not possible use another less restrictive license like LGPL. -- Brad On Jun 19, 2015, at 4:10 AM, Ryan Schmidt wrote: > > On Jun 17, 2015, at 11:55 AM, Bradley Giesbrecht wrote: > >> On Jun 16, 2015, at 12:32 AM, Chunyang Xu wrote: >> >>> On Tue, Jun 16, 2015 at 3:03 PM, Ryan Schmidt >>> wrote: >>>> >>>>> On Jun 14, 2015, at 11:35 AM, chuny...@macports.org wrote: >>>>> >>>>> Revision >>>>> 137557 >>>>> Author >>>>> chuny...@macports.org >>>>> Date >>>>> 2015-06-14 09:35:29 -0700 (Sun, 14 Jun 2015) >>>>> Log Message >>>>> >>>>> users/chunyang: port.el: New folder >>>>> Added Paths >>>>> >>>>>• users/chunyang/port.el/ >>>>>• users/chunyang/port.el/port.el >>>>> Diff >>>>> >>>>> Added: users/chunyang/port.el/port.el (0 => 137557) >>>>> >>>>> --- users/chunyang/port.el/port.el(rev 0) >>>>> +++ users/chunyang/port.el/port.el2015-06-14 16:35:29 UTC (rev 137557) >>>>> @@ -0,0 +1,30 @@ >>>>> +;;; port.el --- a Emacs interface for MacPorts port(1) -*- >>>>> lexical-binding: t; -*- >>>>> + >>>>> +;; Copyright (C) 2015 Chunyang Xu >>>>> + >>>>> +;; Author: Chunyang Xu >>>>> +;; Keywords: MacPorts >>>>> + >>>>> +;; This program is free software; you can redistribute it and/or modify >>>>> +;; it under the terms of the GNU General Public License as published by >>>>> +;; the Free Software Foundation, either version 3 of the License, or >>>>> +;; (at your option) any later version. >>>>> + >>>>> +;; This program is distributed in the hope that it will be useful, >>>>> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>>> +;; GNU General Public License for more details. >>>>> + >>>>> +;; You should have received a copy of the GNU General Public License >>>>> +;; along with this program. If not, see <http://www.gnu.org/licenses/>. >>>> >>>> Really? GPL? >>> >>> Yes. It's a Emacs package under my user folder and GPL is the most >>> common choice for Emacs packages. >> >> >> Ryan, does MacPorts have a recommended/preferred license? > > I wasn't sure if this port.el was something that was meant to be a part of > MacPorts itself, or would remain separate, for example to be installed by a > separate port. > > For code that will be contributed to the MacPorts project, GPL-3 and later > are not an ideal license choice because Apple employees are prohibited, by > company policy, from examining it. Several Apple employees do participate in > MacPorts, and it is unfortunate when one of them is prevented from > contributing to an aspect of MacPorts because of its choice of license. > > The rest of the MacPorts base code is under the BSD license. It is nice when > all of a project is under a single license. > Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [137557] users/chunyang
On Jun 16, 2015, at 12:32 AM, Chunyang Xu wrote: > On Tue, Jun 16, 2015 at 3:03 PM, Ryan Schmidt wrote: >> >>> On Jun 14, 2015, at 11:35 AM, chuny...@macports.org wrote: >>> >>> Revision >>> 137557 >>> Author >>> chuny...@macports.org >>> Date >>> 2015-06-14 09:35:29 -0700 (Sun, 14 Jun 2015) >>> Log Message >>> >>> users/chunyang: port.el: New folder >>> Added Paths >>> >>> • users/chunyang/port.el/ >>> • users/chunyang/port.el/port.el >>> Diff >>> >>> Added: users/chunyang/port.el/port.el (0 => 137557) >>> >>> --- users/chunyang/port.el/port.el(rev 0) >>> +++ users/chunyang/port.el/port.el2015-06-14 16:35:29 UTC (rev 137557) >>> @@ -0,0 +1,30 @@ >>> +;;; port.el --- a Emacs interface for MacPorts port(1) -*- >>> lexical-binding: t; -*- >>> + >>> +;; Copyright (C) 2015 Chunyang Xu >>> + >>> +;; Author: Chunyang Xu >>> +;; Keywords: MacPorts >>> + >>> +;; This program is free software; you can redistribute it and/or modify >>> +;; it under the terms of the GNU General Public License as published by >>> +;; the Free Software Foundation, either version 3 of the License, or >>> +;; (at your option) any later version. >>> + >>> +;; This program is distributed in the hope that it will be useful, >>> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of >>> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> +;; GNU General Public License for more details. >>> + >>> +;; You should have received a copy of the GNU General Public License >>> +;; along with this program. If not, see <http://www.gnu.org/licenses/>. >> >> Really? GPL? > > Yes. It's a Emacs package under my user folder and GPL is the most > common choice for Emacs packages. Ryan, does MacPorts have a recommended/preferred license? Regards, Bradley Giesbrecht (pixilla) Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Contributing to MacPorts (specifically to introduce am improved concurrent qt5-mac)
On Jun 11, 2015, at 11:33 AM, René J.V. Bertin wrote:
> On Thursday June 11 2015 10:57:15 Bradley Giesbrecht wrote:
>
> This seems relevant for the ML, so replying through there.
>
>>> It seems we'd actually need a buildslave set-up/clone for what you're
>>> proposing.
>>
>> It is a build slave for kde ci already. If it takes a week to chew through a
>> build I can live with that if it lays the foundation for an acceptable patch.
>
> I suppose that the KDE CI requires no intervention as long as no errors are
> encountered, and I presume the same is true for the MacPorts buildbots. It is
> not true for the macports VM, to my knowledge. At least until now I have
> simply been using it as a remote account on a machine where I build
> individual ports (and their dependencies).
>
>> Are you saying you have a minimal patch that qt{4,5}-mac that does not add
>> subports or variants? I have not seen it.
>
> No, you cannot, because I did those tests before getting access to your VM.
> And the qt4-mac port has always had an additional subport that is meant to
> ease transition by "unbreaking" every existing dependent after upgrading to a
> concurrent Qt4 install.
>
> I'd have to add that I personally have zero interest in getting port versions
> accepted that do not include the subports I judged useful.
Subports are simply ports that share Portfile info with other subports in the
same Portfile. You already have a private repo with modified Portfiles, what is
the problem with making your subports separate ports or keeping your private
repo?
My interest is in making qt4-mac and qt5-mac co-installable so developers can
work on qt5 projects without being forced to deactivate qt4.
>> What I want to do is deconflict qt4/5 and revbump every qt4/5 dependent port
>> on macports.pixilla.com and then do a massive build of and produce a report
>> so the maintainers of qt4/5 dependent ports can know what to expect and to
>> get constructive feedback form the community.
>
> So basically you'd want to build every Qt4 port first in its current form
> against the existing port, and then do a revbump somehow, and rebuild
> everything? I wonder if Michael has ever done something that wild when
> updating Qt (except by letting the buildbots handle it), and I'm not even
> sure I agree it's up to us to do the work for all maintainers of all
> dependents. They too stand something to gain from a concurrent Qt4/Qt5
> installability, presuming they'd want to update and follow upstream when
> those move to Qt5.
> I'll say it once more: properly written dependent ports use variables from
> the PortGroup if they have any business with where Qt is installed at all,
> and as long as they do they build. I've rebuilt a large and representative
> enough sample of Qt4 dependents to be confident that well-behaved ports will
> simply build.
I would like the supporting data from a test build. It will help answer
questions about the effect of the patch on other ports.
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: generating extra documentation (port:kdelibs4)
On May 11, 2015, at 12:51 AM, René J.V. Bertin wrote: > On Saturday May 09 2015 06:47:02 Ryan Schmidt wrote: > >> I don't understand... why would you build documentation in post-activate? >> why is this situation so unusual that normal MacPorts procedures cannot >> accommodate it? > > The point is that if I couple this documentation too tightly to the port it > documents, you get a situation where it is rebuilt each time the port is > updated, even if that's just a revision bump to force a rebuild against some > changed dependency. That's overkill which carries a cost I don't want. That > was one of the reasons why I initially thought of making the generation > dependent on an env. variable. However, if documentation is not rebuilt every > time, you cannot have it installed through the usual destroot, because then > it would not be present anymore after the previous version/build has been > deactivated. > > It's true I could create a subport that drops part of the main ports > versioning, for instance so that 4.14.x.y becomes 4.14 . That's something > that can be captured rather easily in tcl code. Still, after looking a bit > more at the actual generation process, I'm beginning to think I'd be using an > external script anyway. I don't even know yet exactly what it will take to > generate the monolithic .qch file I have in mind, but it could well be > needlessly complex to do that in inline tcl code. And from there it's just a > small step to install such a script (along with the main port) so that > interested users can invoke it directly themselves. I think I follow and admire your desire to not over burden the user/system with superfluous builds. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] generating extra documentation (port:kdelibs4)
On May 8, 2015, at 1:28 AM, René J.V. Bertin wrote: > On Thursday May 07 2015 14:03:28 Bradley Giesbrecht wrote: > > Hi, > >> Due to license conflicts the MacPorts kdelibs4 port is not binary >> distributable > > The port-check-distributable command says differently (but I've never checked > since I always build with a number of non-default variants) mp-distributable kdelibs4 "kdelibs4" is not distributable because its license "gpl" conflicts with license "APSL-2" of dependency "ld64" Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] generating extra documentation (port:kdelibs4)
On May 7, 2015, at 10:18 AM, René J.V. Bertin wrote: > Hi, > > I thought it'd be nice to have the kdelibs4 documentation in Qt help (.qch) > format. It is available online, but seriously outdated and will of course not > reflect any OS X specific changes that we made. > > There is a script in the doc/api directory that generates this documentation > file, but it hogs the computer for over an hour. My initial thought had been > to generate it unconditionally if the user selects the +docs variant, but not > when there is so much overhead. What alternatives are there? I could create a > subport, but that would still cause this documentation to be rebuilt each > time an update is pushed and the user does an `upgrade outdated`, which seems > overkill to me. If it were just me I'd let the generation depend on the > presence of a specific env. variable, in the +docs variant; would that be > acceptable? Due to license conflicts the MacPorts kdelibs4 port is not binary distributable, but, if the license for the docs is friendly a subport could avoid the time required for doc generation when there is a buildbot for the users platform and the user has the default prefix. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] PortfileRecipes modified
On Apr 22, 2015, at 4:59 PM, Joshua Root wrote:
> Couple more points:
Thank you for your insights.
> On 2015-4-23 07:22 , Lawrence Velázquez wrote:
>> On Apr 22, 2015, at 5:01 PM, MacPorts wrote:
>>
>>> Page "PortfileRecipes" was changed by pixi...@macports.org
>>> Diff URL:
>>> <https://trac.macports.org/wiki/PortfileRecipes?action=diff&version=84>
>>> Revision 84
>>> Changes:
>>> ---8<--8<--8<--8<--8<--8<--8<--8<
>>> Index: PortfileRecipes
>>> =
>>> --- PortfileRecipes (version: 83)
>>> +++ PortfileRecipes (version: 84)
>>> @@ -18,6 +18,31 @@
>>> }}}
>>> These split the version string into an array and return the desired element.
>>> These examples are based on [browser:trunk/dports/lang/php5 php5].
>>> +
>>> +== Compare versions == #vercmp
>>> +
>>> +||= Mac OS X Version Info =||
>>> +||= Darwin =||= OS X =||= Name =||
>>> +|| 7.0 || 10.3 || Panther ||
>>> +|| 8.0 || 10.4 || Tiger ||
>>> +|| 9.0 || 10.5 || Leopard ||
>>> +|| 10.0 || 10.6 || Snow Leopard ||
>>> +|| 11.0.0 || 10.7 || Lion ||
>>> +|| 12.0.0 || 10.8 || Mountain Lion ||
>>> +|| 13.0.0 || 10.9 || Mavericks ||
>>> +|| 14.0.0 || 10.10 || Yosemite ||
>>> +
>>> +{{{
>>> +set check.version 13.0.0
>>> +if {[vercmp ${check.version} ${os.version}] = 1} {
>
> I'm not sure vercmp always returns one of [1,0,-1];
The portfile man only mentions these three returns:
man portfile | less +/vercmp
> we generally check
> the result the same way you do for strcmp, with < 0 or > 0 or == 0.
> Speaking of which, a single equals sign is not correct here.
Thanks, I incorrectly assumed "=" since tcl doesn't use it for assignment, I
should have tested.
>>> +puts "Yosemite or newer"
>>> +} elseif {[vercmp ${check.version} ${os.version}] = 0} {
>>> +puts "Mavricks"
> ^ typo
>
>>> +}
>>> +} elseif {[vercmp ${check.version} ${os.version}] = -1} {
>>> +puts "Mountain Lion or older"
>>> +}
>>> +}}}
>
> - Josh
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] PortfileRecipes modified
On Apr 22, 2015, at 2:22 PM, Lawrence Velázquez wrote:
> On Apr 22, 2015, at 5:01 PM, MacPorts wrote:
>
>> Page "PortfileRecipes" was changed by pixi...@macports.org
>> Diff URL:
>> <https://trac.macports.org/wiki/PortfileRecipes?action=diff&version=84>
>> Revision 84
>> Changes:
>> ---8<--8<--8<--8<--8<--8<--8<--8<
>> Index: PortfileRecipes
>> =
>> --- PortfileRecipes (version: 83)
>> +++ PortfileRecipes (version: 84)
>> @@ -18,6 +18,31 @@
>> }}}
>> These split the version string into an array and return the desired element.
>> These examples are based on [browser:trunk/dports/lang/php5 php5].
>> +
>> +== Compare versions == #vercmp
>> +
>> +||= Mac OS X Version Info =||
>> +||= Darwin =||= OS X =||= Name =||
>> +|| 7.0 || 10.3 || Panther ||
>> +|| 8.0 || 10.4 || Tiger ||
>> +|| 9.0 || 10.5 || Leopard ||
>> +|| 10.0 || 10.6 || Snow Leopard ||
>> +|| 11.0.0 || 10.7 || Lion ||
>> +|| 12.0.0 || 10.8 || Mountain Lion ||
>> +|| 13.0.0 || 10.9 || Mavericks ||
>> +|| 14.0.0 || 10.10 || Yosemite ||
>> +
>> +{{{
>> +set check.version 13.0.0
>> +if {[vercmp ${check.version} ${os.version}] = 1} {
>> +puts "Yosemite or newer"
>> +} elseif {[vercmp ${check.version} ${os.version}] = 0} {
>> +puts "Mavricks"
>> +}
>> +} elseif {[vercmp ${check.version} ${os.version}] = -1} {
>> +puts "Mountain Lion or older"
>> +}
>> +}}}
>>
>> == Fetching from a URL that uses GET parameters == #fetchwithgetparams
>>
>> ---8<--8<--8<--8<--8<--8<--8<--8<
>
> Ehh. This is technically correct, but (to my knowledge) practically no ports
> do this. Simply checking against os.major is much more common and is
> sufficient for most purposes. I also find it easier to understand.
>
>if {${os.major} < 10} {
># do something on systems older than Snow Leopard
>}
Thank you for the feedback. I failed to find a table of darwin version, os x
version and os x name for a comment I wanted to leave on the docker port
submission ticket [1].
Regarding this wiki edit the version table was my interest, perhaps there is a
better place to document versions.
I was hesitant to add ${os.major} without explaining what it meant in relation
to the table.
Perhaps changing the example to use os.major with a short comment like:
# os.major is the left most dot separated number of the darwin version.
You are a much better writer then I so feel free to move, edit or delete my
work here.
[1] https://trac.macports.org/ticket/43260#comment:13
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port: new action_environment and/or environment mode
On Apr 14, 2015, at 2:01 PM, Lawrence Velázquez wrote: > On Apr 14, 2015, at 4:59 PM, Lawrence Velázquez wrote: > >> the "environment" is already something specific to *nix. > > That is, the term "environment" already has a specific meaning in *nix. Yes, I don't like the name for that reason. I think "port config" is a good choice. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port: new action_environment and/or environment mode
On Apr 14, 2015, at 1:59 PM, Lawrence Velázquez wrote: > On Apr 14, 2015, at 4:31 PM, Bradley Giesbrecht wrote: > >> I opened a ticket for this simple base patch: >> https://trac.macports.org/ticket/47442 >> >> My knowledge of tcl and base is limited, I know my code needs cleanup and >> tests. Looking for feedback to decide if I should continue. >> >> The goal is a simpler way for users to provide env vars. >> >> Votes up or down if you think this is worth the bloat will be appreciated. > > This is generally a good idea, and something I've also thought about > implementing. It'd be nice to avoid implementing this inside macports.tcl, > though. I followed the implementation of "port version". Do you have an example of an action implemented differently? > > > I don't know if "port environment" is a great action name, since the > "environment" is already something specific to *nix. I've always envisioned > something like this: > > $ port config > prefix=/opt/local > portdbpath=/opt/local/var/macports > [...] > > $ port config prefix > /opt/local > > $ port config build_arch > x86_64 > > $ port config foobarbaz > [write "Nonexistent setting" to stderr, return non-zero] This is what I would like as well. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
port: new action_environment and/or environment mode
I opened a ticket for this simple base patch: https://trac.macports.org/ticket/47442 My knowledge of tcl and base is limited, I know my code needs cleanup and tests. Looking for feedback to decide if I should continue. The goal is a simpler way for users to provide env vars. Votes up or down if you think this is worth the bloat will be appreciated. Example 1: $ port -e version ---> /opt/local/etc/macports/macports.conf: prefix: /opt/local ---> /opt/local/etc/macports/macports.conf: portdbpath: /opt/local/var/macports ---> /opt/local/etc/macports/macports.conf: applications_dir: /Applications/MacPorts ---> /opt/local/etc/macports/macports.conf: frameworks_dir: /opt/local/Library/Frameworks ---> /opt/local/etc/macports/macports.conf: sources_conf: /opt/local/etc/macports/sources.conf ---> /opt/local/etc/macports/macports.conf: variants_conf: /opt/local/etc/macports/variants.conf ---> /opt/local/etc/macports/macports.conf: universal_archs: x86_64 i386 ---> /opt/local/etc/macports/macports.conf: revupgrade_autorun: no ---> /opt/local/etc/macports/sources.conf: file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports default ---> /opt/local/etc/macports/sources.conf: file:///Users/brad/misc/macports/users/gaurav/pypi2port/dports nosync Version: 2.3.99 Example 2: $ port env ---> port_cmd_version: 2.3.99 ---> bootstrap_options: applications_dir: /Applications/MacPorts ---> bootstrap_options: build_arch: x86_64 ---> bootstrap_options: buildmakejobs: 0 ---> bootstrap_options: buildnicevalue: 0 ---> bootstrap_options: ccache_dir: /opt/local/var/macports/build/.ccache ---> bootstrap_options: ccache_size: 2G ---> bootstrap_options: configureccache: no ---> bootstrap_options: configuredistcc: no ---> bootstrap_options: configurepipe: yes ---> bootstrap_options: cxx_stdlib: libc++ ---> bootstrap_options: delete_la_files: yes ---> bootstrap_options: destroot_umask: 022 ---> bootstrap_options: developer_dir: /Applications/Xcode.app/Contents/Developer ---> bootstrap_options: frameworks_dir: /opt/local/Library/Frameworks ---> bootstrap_options: keeplogs: no ---> bootstrap_options: macosx_deployment_target: 10.9 ---> bootstrap_options: macosx_sdk_version: 10.9 ---> bootstrap_options: macportsuser: macports ---> bootstrap_options: place_worksymlink: yes ---> bootstrap_options: portarchivetype: tbz2 ---> bootstrap_options: portautoclean: yes ---> bootstrap_options: portdbpath: /opt/local/var/macports ---> bootstrap_options: porttrace: no ---> bootstrap_options: portverbose: no ---> bootstrap_options: prefix: /opt/local ---> bootstrap_options: revupgrade_autorun: no ---> bootstrap_options: revupgrade_mode: rebuild ---> bootstrap_options: rsync_dir: release/tarballs/base.tar ---> bootstrap_options: rsync_options: -rtzv --delete-after ---> bootstrap_options: rsync_server: rsync.macports.org ---> bootstrap_options: sandbox_enable: yes ---> bootstrap_options: sources_conf: /opt/local/etc/macports/sources.conf ---> bootstrap_options: startupitem_install: yes ---> bootstrap_options: startupitem_type: default ---> bootstrap_options: universal_archs: x86_64 i386 ---> bootstrap_options: variants_conf: /opt/local/etc/macports/variants.conf ---> bootstrap_options: xcodebuildcmd: /usr/bin/xcodebuild ---> bootstrap_options: xcodeversion: 6.2 ---> port_tree_sources: file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports default ---> port_tree_sources: file:///Users/brad/misc/macports/users/gaurav/pypi2port/dports nosync ---> global_variations: +gcc48 +universal -x11 +no_x11 +quartz Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
fetch ssl errors on _some_ buildbots
From what appears to be the same servers the Mavericks and Yosemite buildbots were able to fetch via https while Snow Leopard, Lion and Mountain Lion buildbots were not. Is this known and expected behavior or something for the macosforge admins to look into? Evidence: https://build.macports.org/builders/buildports-yosemite-x86_64/builds/2504/steps/compile/logs/stdio ... ---> Attempting to fetch rspamd-0.8.3.tar.xz from https://rspamd.com/downloads % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 739k 100 739k0 0 275k 0 0:00:02 0:00:02 --:--:-- 275k DEBUG: Privilege de-escalation not attempted as not running as root. ... https://build.macports.org/builders/buildports-mavericks-x86_64/builds/11700/steps/compile/logs/stdio ... 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0---> Attempting to fetch rspamd-0.8.3.tar.xz from https://rspamd.com/downloads 100 739k 100 739k0 0 178k 0 0:00:04 0:00:04 --:--:-- 178k DEBUG: Privilege de-escalation not attempted as not running as root. DEBUG: checksum phase started at Sat Mar 21 12:22:01 PDT 2015 DEBUG: Executing org.macports.checksum (rspamd) ... https://build.macports.org/builders/buildports-mtln-x86_64/builds/22136/steps/compile/logs/stdio ... ---> Attempting to fetch rspamd-0.8.3.tar.xz from https://rspamd.com/downloads % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0DEBUG: Fetching distfile failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure ---> Attempting to fetch rspamd-0.8.3.tar.xz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/rspamd ... https://build.macports.org/builders/buildports-lion-x86_64/builds/27766/steps/compile/logs/stdio ... ---> Attempting to fetch rspamd-0.8.3.tar.xz from https://rspamd.com/downloads % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 DEBUG: Fetching distfile failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure ... https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/34437/steps/compile/logs/stdio ... ---> Attempting to fetch rspamd-0.8.3.tar.xz from https://rspamd.com/downloads DEBUG: Fetching distfile failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure ---> Attempting to fetch rspamd-0.8.3.tar.xz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/rspamd % Total% Received % Xferd Average Speed TimeTime Time Current ... Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: determining the how and why of a port dependencies
On Mar 21, 2015, at 12:03 PM, René J.V. Bertin wrote: > On Saturday March 21 2015 10:46:07 Bradley Giesbrecht wrote: > > Hi, > >> I use sed in a script and am open to something easier: >> https://svn.macports.org/repository/macports/users/pixilla/scripts/mp-rdeps-grid > > Impressive :) > > Starting from the end seems a bit simpler, and also should cater for any > depth. I haven't (yet) figured out how to *not* replace and then restore the > 1st ' ' on each line, but that may not even be possible: > > `port -q rdeps "$@" | sed -e '/^-/d' -e 's/ \([^ ]\)/ \| \1/g' -e 's/ /\. > /g' -e 's/^\./ /'` > > Why do you need the first pattern, removing lines that start with a dash? Not sure, written a while ago, probably when the pattern contains many ports they are separated by "--" and I was not interested in the separation. Here it is without, perhaps this is better: port -q rdeps dependentof:zlib | sed -e 's/ /\.\./g' -e 's/^\.\./ /g' -e 's/\.\./\. /g' -e 's/\. \([^\.]\)/\| \1/g' Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: determining the how and why of a port dependencies
On Mar 21, 2015, at 9:46 AM, René J.V. Bertin wrote: > On Saturday March 21 2015 11:35:03 Lawrence Velázquez wrote: > > > $ port rdeps kde4-baseapps > > $ port rdeps --full kde4-baseapps > > Doh, I knew that ... > > It's not ideal(ly readable) but it'll do. > Would it be hard to add an (optional) ascii rendering of a tree, i.e. using > '|' characters to do something like > > git > | curl > . | pkgconfig > . . | libiconv > . . . | gperf > . | libidn > . . | libiconv > . . . | gperf > . . | gettext > . . . | expat > . . . | libiconv > . . . . | gperf > . . . | ncurses > > Which looks a lot busier but which should make it less easy to lose track of > depth when you have to scroll up and down the tree. I use sed in a script and am open to something easier: https://svn.macports.org/repository/macports/users/pixilla/scripts/mp-rdeps-grid mp-rdeps-grid --full kde4-workspace Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On Mar 14, 2015, at 2:26 PM, Marko Käning wrote: > Brad, > > On 14 Mar 2015, at 22:20 , Bradley Giesbrecht wrote: >> The users I am attempting to serve currently get nothing because installing >> Xcode, CLT, MacPorts and then installing deps with non-default variants >> before building the target (octave in this case) is beyond their >> capabilities or patience. > > I absolutely can see where you are coming from… :-) > > Did you read the thread entitled > > "A (non)success story of digiKam on OSX/MacPorts involving kde4-workspace > and qtcurve” > > which I wrote this afternoon? Same thing! Yes I did. Yes, same thing. > Installing all these dependencies is only acceptable for techies like us, but > a normal > user will never bother to deal with all the hassle. I think we have an opportunity to extend what MacPorts does well to include relocatable packages or mdmg packages in a way that third parties can build distributable packages untethered from MacPorts and Xcode. Gimp, Kdenlive, digiKam, Octave and many KDE "things" would sing praises to MacPorts. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On Mar 14, 2015, at 12:18 PM, Rainer Müller wrote: > On 2015-03-14 14:44, Clemens Lang wrote: >> - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org >> wrote: >> >>> Has there been a discussion about having the MacPorts buildbots also build >>> mdmg >>> files? >>> >>> This may require a lot of resources so perhaps mdmg could be run for some >>> percentage of requested ports using mpstats? > > Not all ports will work when installed as mdmg. The main problem would > be that post-activate scripts are not converted to postflight scripts. > > There once was a dp_lite (DarwinPorts Lite) to extract a minimal runtime > to be included in standalone installers. > > As we now ship Tcl with base, we probably even had to include a Tcl > interpreter. Our code base is also not organized to isolate a few > commands. As post-activate scripts might run any command, I guess we > would end up with almost everything anyway... > >> What would be your use case for that? If you are looking for packages you can >> install without installing MacPorts, I'd argue it's a bad idea to have our >> buildbots generate those, because of the prefix conflict. > > Even when using a different prefix (ignoring all user confusion), this > would give the wrong impression of being an officially supported method > of installation. Users do not get any upgrade path with mdmg packages. The users I am attempting to serve currently get nothing because installing Xcode, CLT, MacPorts and then installing deps with non-default variants before building the target (octave in this case) is beyond their capabilities or patience. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg [eom]
On Mar 14, 2015, at 6:44 AM, Clemens Lang wrote: > Hi, > > - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org > wrote: > >> Has there been a discussion about having the MacPorts buildbots also build >> mdmg >> files? >> >> This may require a lot of resources so perhaps mdmg could be run for some >> percentage of requested ports using mpstats? > > What would be your use case for that? If you are looking for packages you can > install without installing MacPorts, Yes. > I'd argue it's a bad idea to have our > buildbots generate those, because of the prefix conflict. And I'd agree though there are groups of consumers (sciences) that would likely never install MacPorts if they could use installers. This is not the best use of MacPorts resources. I quash my idea. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
MacPorts hosted mdmg
Has there been a discussion about having the MacPorts buildbots also build mdmg files? This may require a lot of resources so perhaps mdmg could be run for some percentage of requested ports using mpstats? Another idea may be to add a logged in buildbot user to manually schedule an mdmg build, thoughts? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: find last build of port on buildbot
On Mar 10, 2015, at 8:12 PM, Ryan Schmidt wrote: > On Mar 10, 2015, at 22:08, Bradley Giesbrecht wrote: >> >> Is there a way to search the buildbots for that last build for a given port? > > If there is, I don't know how. That's why I plan to cross-reference buildbot > builds on the port pages of the new MacPorts web site. Keeping the last logfile per port in a db would be pretty special :) Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
find last build of port on buildbot
Is there a way to search the buildbots for that last build for a given port? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC relocatable packages
On Mar 6, 2015, at 2:50 PM, Joshua Root wrote: > On 2015-3-7 07:12 , Bradley Giesbrecht wrote: >> What would be the challenges of producing relocatable packages where a port >> and all its macports dependents would be prefixed to the package dir and >> shared libs would use relative paths? > > Convincing everything to use relative paths, mainly. I guess you're > thinking @rpath for the mach-o files, but paths can end up hardcoded > into them in other ways, and in other file types. Thank you for the reply Josh. I'm prepared to except that not all ports will play nice. Some upstream partners may be very interested fixing their software to make this work. At the GSoC 2014 Mentors Convention (I attended) this idea was put forth by the Octave group. They struggle supporting their user base on [^linux] and what they would really like is a Mac OS X like dmg installer where they could drop a directory somewhere and work from there. They even talked about finding financing if that might help. The Octave dependency tree has deep roots making maintenance all the more difficult. If all Octave deps are at current release than Octave is probably broke. I believe many other package authors would love a feature like this for OS X; keeping MacPorts at the forefront of relevance for opensource on OS X. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
GSoC relocatable packages
What would be the challenges of producing relocatable packages where a port and all its macports dependents would be prefixed to the package dir and shared libs would use relative paths? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
hiredis: fix dylib path
Hi, The new hiredis port does not use configure and the dylib files have broken paths. I can use install_name_tool to fix them but are there make or env args to build it correctly to begin with? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port upgrade outdated order
On Mar 4, 2015, at 10:46 AM, René J.V. Bertin wrote:
>> Also, you'd have to make sure that foo-B builds correctly or, if
>> it fails, activate foo-A again after it failed. I don't know whether
>> MacPorts base can do this. I doubt it does.
>
> No, I think it can't. However, if a conflict is not a build conflict the
> deactivation could be done very late, even after foo-B's archive has been
> unpacked in the temp. directory in ${prefix}/var/macports/software/foo-B . At
> that point you can be pretty sure that everything will be fine.
>
> BTW, I've already raised a suggestion recently that the same thing could be
> done while doing an upgrade (or reinstall through `port -n upgrade --force
> foo`), to reduce the time that the system spends without any active version.
Reducing the "no active version time" would be a welcome improvement.
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: pypi2port: two files with the same content
On Feb 19, 2015, at 11:33 AM, Mojca Miklavec wrote: > So I have two suggestions: > - It would be great to create a Portfile, so that "port install > pypi2port" would automatically install the script to $prefix/bin, > similar to cpan2port. > - It would be nice (but not absolutely necessary) to support Python 3. Hi Mojca, Thank you for your interest in pypi2port. Both or your suggestions were part of the roadmap but we ran out of time. How would we handle the distfiles and versioning for a pypi2port Portfile? I believe we should also add a license blurb to the top of the pypi2port.py file, do you know of a MacPorts approved license text? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] subport and keyword questions/suggestions
On Jan 29, 2015, at 3:59 AM, René J.V. Bertin wrote: > - Do the build slaves build the default variants of subports? Subports are simply ports that share code with the containing port so all processing of the derived "Portfile" is standard. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: subport and keyword questions/suggestions
On Feb 15, 2015, at 10:33 AM, Marko Käning wrote: >> I *think* that the mechanism that's currently in place to let client ports >> accept qt5-mac-devel instead of qt5-mac should also let them accept >> qt5-mac[-devel]-kde instead of qt5-mac, but that remains to be confirmed. > > Which mechanism is used there? I guess it won’t be as simple > anymore as using depends_lib: > --- > depends_lib-append path:lib/libaqbanking.dylib:aqbanking5 > --- > since now the various qt5-mac-* installs will all have very > different paths... I imagine if needed the "path" dependency could be extended to allow multiple paths: --- depends_lib-append path:lib/qt4-mac/lib.dylib:lib/qt5-mac-kde/lib.dylib:lib/qt5-mac-devel/lib.dylib:qt5-mac --- Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: requested not set when package given to port but installed as dep
On Feb 15, 2015, at 2:02 PM, Marko Käning wrote: > Hi Brad, > > On 15 Feb 2015, at 22:45 , Bradley Giesbrecht wrote: > >> Is this a bug? >> >> $ port installed requested and \( name:^foo$ or name:^bar$ \) >> None of the specified ports are installed. >> $ sudo port install foo bar >> ---> Computing dependencies for foo >> The following dependencies will be installed: bar > > this looks like bar is a dependency of foo, right? Correct. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
requested not set when package given to port but installed as dep
Is this a bug? $ port installed requested and \( name:^foo$ or name:^bar$ \) None of the specified ports are installed. $ sudo port install foo bar ---> Computing dependencies for foo The following dependencies will be installed: bar Continue? [Y/n]: ---> Installing bar @0.0.0_0 ---> Activating bar @0.0.0_0 ---> Installing foo @0.0.0_0 ---> Activating foo @0.0.0_0 $ port installed requested and \( name:^foo$ or name:^bar$ \) The following ports are currently installed: foo @0.0.0_0 (active) Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: depends_run should ignore +/- universal?!
On Jan 22, 2015, at 1:49 AM, René J.V. Bertin wrote: > On Wednesday January 21 2015 17:10:38 Bradley Giesbrecht wrote: > >>>> I've tried changing the version in the +infinality variant, so that for >>>> instance port:freetype is at 2.5.4 and port:freetype+infinality at >>>> 2.5.4.150101 . That works, but something in MacPorts breaks. I can do >>>> `port patch freetype +infinality` to check whether the patches apply >>>> correctly, but when I continue with `port configure freetype +infinality` >>>> the process continues all the way to the install or until the 1st error. >>> >>> That sounds like a bug. It would be great if you could open a ticket about >>> it and provide a minimal test case. >> >> I wonder if port livecheck considers installed variants? > > Even if it did (or not...), I'm guessing it does not. > how would that lead to the behaviour I observed? It would not, but I believe changing the version in a variant breaks livecheck. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: depends_run should ignore +/- universal?!
On Jan 21, 2015, at 3:03 PM, Lawrence Velázquez wrote: > On Jan 21, 2015, at 5:10 PM, René J.V. Bertin wrote: > >> The situation is this: Infinality are patches that improve rendering but >> don't change anything else. So a variant is the logical way to go, as it >> won't break dependencies. > > Sure. > >> Those patches evolve, and thus have a version number, which is simply a >> date. If it were me, I'd put that version number into the revision, which >> corresponds almost perfectly to the intended use of that variable. > > No, it doesn't. The revision is basically versioning for portfiles and > MacPorts' own fixes. The Infinality patches are more like a supplemental > upstream. > >> I've tried changing the version in the +infinality variant, so that for >> instance port:freetype is at 2.5.4 and port:freetype+infinality at >> 2.5.4.150101 . That works, but something in MacPorts breaks. I can do `port >> patch freetype +infinality` to check whether the patches apply correctly, >> but when I continue with `port configure freetype +infinality` the process >> continues all the way to the install or until the 1st error. > > That sounds like a bug. It would be great if you could open a ticket about it > and provide a minimal test case. I wonder if port livecheck considers installed variants? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Change in qt/qtbase[dev]: QStandardPaths: Add XDG_CONFIG_DIRS and XDG_DATA_DIRS paths ...
On Jan 14, 2015, at 6:53 AM, René J.V. Bertin wrote:
> On Wednesday January 14 2015 14:44:12 Jeremy Whiting wrote:
>> Jeremy Whiting has posted comments on this change.
>
> Jeremy, could you summarise the changes please?
>
>>
>> Change subject: QStandardPaths: Add XDG_CONFIG_DIRS and XDG_DATA_DIRS paths
>> on OSX.
>> ..
>>
>>
>> Patch Set 3:
>>> What is the intended way of deploying and running a KDE application on Mac
>>> OS X?
>>>
>>> One way that I can see is to create real bundles. So if Kate uses
>>> kf5-karchive, it would include this and other frameworks it needs in its
>>> own bundle. The application would be entirely self-contained and there
>>> would be no relevance for any XDG environment variables AFAICS. I
>>> personally think this is a good way of deploying applications, because it
>>> is very user friendly.
>>>
>>> Another way that I can see is through frameworks like (home)brew, where
>>> each
>>> application will end up in its own prefix, right? (something like
>>> /usr/local/Cellar/Kate/5.0/...) How would frameworks cooperate with
>>> cellars
>>> and how would any environment variables - that are required for running -
>>> be set? Is this something the user would have to do in the terminal?> >
>> Simon,
>>
>> Exactly, there are two ways, one including all libraries and data files
>> within the .app itself, and two, using homebrew/fink/macports to install the
>> application and it's dependencies. From what I've seen with macports you set
>> your prefix and it adds environment variables to your user's startup script
>> (.profile iirc) so the prefix you set is initialized by the
>> homebrew/fink/macports setup itself.
>
> It's been a while since I installed MacPorts from scratch, and I don't think
> it ever actually modified my startup script, but in principle you only need
> to add /opt/local/bin (or ${prefix}/bin) to your path.
If you install MacPorts from the binary installer a postflight script [1] is
run which does/can set vars in .profile; while installing from source leaves
the task of env modification to the user.
[1]
https://guide.macports.org/chunked/installing.shell.html#installing.shell.postflight
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: scope of "local" PortGroup definition files
On Jan 9, 2015, at 8:36 AM, René J.V. Bertin wrote: > On Friday January 09 2015 07:28:43 Bradley Giesbrecht wrote: > >> Is your local tree in sources.conf? >> grep -v -E "(^ *#|^$)" /opt/local/etc/macports/sources.conf > > Yes. It's my understanding that is required if you want it to be taken into > account ... You can have a local ports that are not in sources.conf and you interact with them by giving port the path to the port dir rather then the name. >> If you used svn instead of rsync port sync you would not experience this >> overwrite issue. > > Until a change to the file in question was pushed, at which time you'd > probably get a conflict error? Not an error as much as question, incoming change on locally modified file, what do you want to do. The svn documentation can better explain what your options would be, theirs full, mine full, etc. >> `port sync` updates all sources that aren't marked "nosync" in sources.conf. > > The comments in sources.conf >> # To prevent a source from synchronizing when `port sync` is used, >> # append [nosync] at the end as shown in this example: >> # Example: file:///Users/landonf/misc/MacPorts/ports [nosync] > suggest that a local repo will also be synced if not marked that way, but > from what/where? > > So, should I change my current > > file:///opt/local/site-ports > rsync://rsync.macports.org/release/ports/ [default] > > into > > file:///opt/local/site-ports [default] [nosync] > rsync://rsync.macports.org/release/ports/ > > or will that prevent me from getting updates at all? I suggest switching to svn for syncing: https://trac.macports.org/wiki/howto/SyncingWithSVN and then in sources.conf: file:///opt/local/site-ports [nosync] file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ [default] or if you want to keep using rsync: file:///opt/local/site-ports [nosync] rsync://rsync.macports.org/release/ports/ [default] With svn there is less reason to use a local repo. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: scope of "local" PortGroup definition files
On Jan 9, 2015, at 4:32 AM, René J.V. Bertin wrote:
> Correction:
>
> This is not limited to the compiler blacklist portgroup, nor to Linux.
>
> Exactly as I feared, my changes to the qt4, qt5 and kde4 portgroups need to
> be copied to the portgroup directory in the default tree if they are to be
> visible to all ports and not just to the ports in the local repository.
Is your local tree in sources.conf?
grep -v -E "(^ *#|^$)" /opt/local/etc/macports/sources.conf
> Which means that every selfupdate will undo any changes you might have
> applied.
>
> Out of curiosity, what if I set my local repository to be the default? Will
> selfupdate update that tree, or will it continue to update the one under
> ${prefix}/var/macports/source/ ?
If you used svn instead of rsync port sync you would not experience this
overwrite issue.
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] Getting started on Mac OS X
On Jan 6, 2015, at 2:41 PM, René J.V. Bertin wrote:
> On Tuesday January 06 2015 14:08:44 Bradley Giesbrecht wrote:
>
>> It is usually easier to get patch reviews if the changes are as few as
>> possible.
>
> Heh, yes, I know I introduced a couple more variants, but they're actually
> intended to speed up things.
>
>> I have macports installed in a vm building qt4-mac based of René's work [1].
>
> Great, thanks!
>
>> The new variants have been removed but the effect of the +concurrent variant
>> has been incorporated along with the PortGroup changes to create a minimal
>> patch to test concurrency.
>
> Is that a summary of my work, or your version of it?
I moved your qt4-1.0.tcl changes around to create the smallest diff.
>> If having a non-local machine to test changes to qt4-mac would help Michael,
>> René or anyone else contact me off list and we can work out access to my
>> macports vm.
>
> Hmmm, makes us drool, how fast is it? :)
It's not fast (mac mini, core i5, 16gb memory) but not to busy either. There is
a kdeci vm on the same host.
I think the biggest advantage for you would be not having to worry about
borking your dev env while working with qt{4,5}-mac deconfliction.
I'm going to attach my patch to your ticket if for no other reason then allow
the use of the trac diff viewer to show interested parties how small the
changes really are.
Here is what I have built in the vm so far, and tested as far as launching apps
in /Applications/MacPorts/Qt4:
$ port installed requested
The following ports are currently installed:
qt4-creator-mac @2.8.1_0 (active)
qt4-mac @4.8.6_1 (active)
qt4-mac-mysql55-plugin @4.8.6_0 (active)
qt4-mac-sqlite3-plugin @4.8.6_0 (active)
qt5-mac @5.3.2_1 (active)
sqlitedbrowser @0_1 (active)
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] Getting started on Mac OS X
On Jan 6, 2015, at 9:52 AM, René J.V. Bertin wrote: > On Tuesday January 06 2015 11:48:46 Michael Dickens wrote: > >> There just isn't enough time in the day! Some day, I won't be so crazy >> busy! Some day, I really will address the Qt4 tickets. I really do like >> the idea of having Qt4 and Qt5 available at the same time & I know that >> Qt4 needs some attention (as does Qt5, but I haven't even found time for > > Do you use port:qt4-mac yourself? If so, it won't necessarily take a lot of > time to install it in concurrent mode, esp. if you've kept your work/build > tree around. Given the lack of feedback, I was actually planning to make > +concurrent the default (= remove the variant), and add a +exclusive variant > corresponding to the current default behaviour. That might make testing even > easier... It is usually easier to get patch reviews if the changes are as few as possible. I have macports installed in a vm building qt4-mac based of René's work [1]. The new variants have been removed but the effect of the +concurrent variant has been incorporated along with the PortGroup changes to create a minimal patch to test concurrency. If/when the qt4-mac build succeeds I plan to build "port echo depends:qt4-mac". If having a non-local machine to test changes to qt4-mac would help Michael, René or anyone else contact me off list and we can work out access to my macports vm. [1] http://trac.macports.org/ticket/46238 Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] Getting started on Mac OS X
On Jan 6, 2015, at 1:32 AM, René J.V. Bertin wrote: > Sadly he cannot force things. I think my work on the qt4-mac side is done and > available as a draft for testing on trac.macports.org; I'm waiting for > feedback from people. That in turn might motivate the port maintainer to make > a move... http://trac.macports.org/ticket/46238 Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
license for contrib
Does MacPorts have a preferred licensing practice for contrib? Examples? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: trac/wiki is DOWN AGAIN
On Dec 21, 2014, at 4:59 AM, Rainer Müller wrote: > On 2014-12-18 16:02, Shreeraj Karulkar wrote: >> It is up and in sync now. > > It happened again today, I cannot reach Trac right now. Trac appears to be down. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt4-mac concurrent update
On Jan 1, 2015, at 11:32 AM, René J.V. Bertin wrote: > Hi > > Trac appears to be down or is inaccessible to me, so here's a correction for > my port:qt4-mac modifications. > To be precise, this corrects an issue when building with the proposed > +noexceptions variant (which builds only the required Qt components with > compiler exceptions support): it removes the guessed and undesirable macro > definition of QT_EXCEPTIONS or QT_NO_EXCEPTIONS from QtCore/qconfig.h . > > BTW, is it possible to have local PortGroup definitions like one can have a > local port repository? Yes, if "local port repository" is found first in $prefix/etc/macports/sources.conf then "local port repository"/_resources/port1.0/group will be searched first for port group files. > It took me a while today to realise that a recent selfupdate had replaced my > qt4-1.0.tcl and kde4-1.1.tcl definition files ... Why not use svn instead of rsync so you can control local changes? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: dbus port notes are not correct
On Dec 19, 2014, at 3:09 AM, René J.V. Bertin wrote: > On Friday December 19 2014 07:50:38 Marko Käning wrote: > >> # sudo launchctl load -w >> /Library/LaunchDaemons/org.freedesktop.dbus-system.plist >> # launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist >> > >> isn’t needed anymore - already since quite some time! > > I think what Marko means is that there's no need to launch a system dbus, or > at least there appears to be none (never seen one on Linux either). > Right? I read somewhere years ago that the dbus system bus was no longer required and there should be a thread in the macports list archives regarding this subject. I don't maintain the port and cannot remember the conclusion of that list thread. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port activate ignores multiple installed versions and variants of inactive dependents
On Dec 11, 2014, at 1:46 PM, Clemens Lang wrote: > Hi, > > - On 11 Dec, 2014, at 22:31, Bradley Giesbrecht pixi...@macports.org > wrote: > >> If installation/activation of ports via dependency ignores installed inactive >> versions I think this a bug in base. >> >> Shouldn't dependency installation take into consideration multiple inactive >> versions as "port activate" does? > > No. There is a reason why we always upgrade dependencies first. Installing a > port always requires all dependencies to be at the latest state. If we didn't > do that we'd either need versioned dependencies, or rev-bumps would be > pointless. All ports were already at the current version, there was no upgrade. > Without checking active versions before and after activation this user > workflow >> could be dangerous: >> $ sudo port -q deactivate sqlgrey postfix >> $ sudo port -q activate sqlgrey > > Dangerous in that you might end up with a more recent version of postfix than > you > had before, yes. I don't think this is a very dangerous situation – in fact I > think the exact opposite situation might actually be more dangerous. There were two current versions of the same port with differing variants: ---> postfix @2.11.3_0 ---> postfix @2.11.3_0+dovecot_sasl+mariadb I was surprised that "port activate postfix" asked for a specific version+variant while "port activate sqlgrey" was happy to suck in the default postfix. This is an edge case, I accept the status quo. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port activate ignores multiple installed versions and variants of inactive dependents
On Dec 11, 2014, at 1:06 PM, Bradley Giesbrecht wrote: > > On Dec 11, 2014, at 12:41 PM, Joshua Root wrote: > >> On 2014-12-12 06:51 , Bradley Giesbrecht wrote: >>> >>> On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote: >>> >>>> >>>> On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote: >>>> >>>>> Is this behavior by design? >>>>> >>>>> $ sudo port -q deactivate sqlgrey postfix >>>>> ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >>>>> ---> Deactivating postfix @2.11.3_0 >>>>> $ sudo port -q activate sqlgrey postfix >>>>> ---> Computing dependencies for sqlgrey >>>>> ---> Dependencies to be installed: postfix >>>>> ---> Activating postfix @2.11.3_0 >>>>> ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >>>>> ---> The following versions of postfix are currently installed: >>>>> ---> postfix @2.11.2_0 >>>>> ---> postfix @2.11.3_0 (active) >>>>> ---> postfix @2.11.3_0+dovecot_sasl+mariadb >>>>> Error: port activate failed: Registry error: Please specify the full >>>>> version as recorded in the port registry. >>>> >>>> It looks expected, in so far as you have multiple versions of postfix >>>> installed, asked MacPorts to activate postfix, and did not specify which >>>> one you wanted to activate. >>> >>> Right, with sqlgrey and multiple postfix versions installed and inactive >>> why does port not ask me which postfix version to activate when activating >>> sqlgrey? >>> >>> If "port activate postfix" requires me to specify a version then why >>> wouldn't activation via dependency also ask? >> >> Same reason 'port install sqlgrey' doesn't ask which version of postfix >> to activate. >> >> - Josh > > Ok, and the reason is? If installation/activation of ports via dependency ignores installed inactive versions I think this a bug in base. Shouldn't dependency installation take into consideration multiple inactive versions as "port activate" does? $ port -q installed active and name:"sqlgrey|postfix" postfix @2.11.3_0+dovecot_sasl+mariadb (active) sqlgrey @1.8.0-rc2_2+mysql+perl5_20 (active) $ sudo port -q deactivate sqlgrey postfix ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 ---> Deactivating postfix @2.11.3_0+dovecot_sasl+mariadb $ sudo port -q activate sqlgrey ---> Computing dependencies for sqlgrey ---> Dependencies to be installed: postfix ---> Activating postfix @2.11.3_0 ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 $ port -q installed active and name:"sqlgrey|postfix" postfix @2.11.3_0 (active) sqlgrey @1.8.0-rc2_2+mysql+perl5_20 (active) Without checking active versions before and after activation this user workflow could be dangerous: $ sudo port -q deactivate sqlgrey postfix $ sudo port -q activate sqlgrey Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port activate ignores multiple installed versions and variants of inactive dependents
On Dec 11, 2014, at 12:41 PM, Joshua Root wrote: > On 2014-12-12 06:51 , Bradley Giesbrecht wrote: >> >> On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote: >> >>> >>> On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote: >>> >>>> Is this behavior by design? >>>> >>>> $ sudo port -q deactivate sqlgrey postfix >>>> ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >>>> ---> Deactivating postfix @2.11.3_0 >>>> $ sudo port -q activate sqlgrey postfix >>>> ---> Computing dependencies for sqlgrey >>>> ---> Dependencies to be installed: postfix >>>> ---> Activating postfix @2.11.3_0 >>>> ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >>>> ---> The following versions of postfix are currently installed: >>>> ---> postfix @2.11.2_0 >>>> ---> postfix @2.11.3_0 (active) >>>> ---> postfix @2.11.3_0+dovecot_sasl+mariadb >>>> Error: port activate failed: Registry error: Please specify the full >>>> version as recorded in the port registry. >>> >>> It looks expected, in so far as you have multiple versions of postfix >>> installed, asked MacPorts to activate postfix, and did not specify which >>> one you wanted to activate. >> >> Right, with sqlgrey and multiple postfix versions installed and inactive why >> does port not ask me which postfix version to activate when activating >> sqlgrey? >> >> If "port activate postfix" requires me to specify a version then why >> wouldn't activation via dependency also ask? > > Same reason 'port install sqlgrey' doesn't ask which version of postfix > to activate. > > - Josh Ok, and the reason is? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port activate ignores multiple installed versions and variants of inactive dependents
On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote: > > On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote: > >> Is this behavior by design? >> >> $ sudo port -q deactivate sqlgrey postfix >> ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >> ---> Deactivating postfix @2.11.3_0 >> $ sudo port -q activate sqlgrey postfix >> ---> Computing dependencies for sqlgrey >> ---> Dependencies to be installed: postfix >> ---> Activating postfix @2.11.3_0 >> ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 >> ---> The following versions of postfix are currently installed: >> ---> postfix @2.11.2_0 >> ---> postfix @2.11.3_0 (active) >> ---> postfix @2.11.3_0+dovecot_sasl+mariadb >> Error: port activate failed: Registry error: Please specify the full version >> as recorded in the port registry. > > It looks expected, in so far as you have multiple versions of postfix > installed, asked MacPorts to activate postfix, and did not specify which one > you wanted to activate. Right, with sqlgrey and multiple postfix versions installed and inactive why does port not ask me which postfix version to activate when activating sqlgrey? If "port activate postfix" requires me to specify a version then why wouldn't activation via dependency also ask? $ port installed postfix sqlgrey The following ports are currently installed: postfix @2.11.2_0 postfix @2.11.3_0 postfix @2.11.3_0+dovecot_sasl+mariadb sqlgrey @1.8.0-rc2_2+mysql+perl5_20 $ sudo port -q activate postfix ---> The following versions of postfix are currently installed: ---> postfix @2.11.2_0 ---> postfix @2.11.3_0 ---> postfix @2.11.3_0+dovecot_sasl+mariadb Error: port activate failed: Registry error: Please specify the full version as recorded in the port registry. $ sudo port -q activate sqlgrey ---> Computing dependencies for sqlgrey ---> Dependencies to be installed: postfix ---> Activating postfix @2.11.3_0 ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 $ port installed postfix sqlgrey The following ports are currently installed: postfix @2.11.2_0 postfix @2.11.3_0 (active) postfix @2.11.3_0+dovecot_sasl+mariadb sqlgrey @1.8.0-rc2_2+mysql+perl5_20 (active) Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
port activate ignores multiple installed versions and variants of inactive dependents
Is this behavior by design? $ sudo port -q deactivate sqlgrey postfix ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 ---> Deactivating postfix @2.11.3_0 $ sudo port -q activate sqlgrey postfix ---> Computing dependencies for sqlgrey ---> Dependencies to be installed: postfix ---> Activating postfix @2.11.3_0 ---> Activating sqlgrey @1.8.0-rc2_2+mysql+perl5_20 ---> The following versions of postfix are currently installed: ---> postfix @2.11.2_0 ---> postfix @2.11.3_0 (active) ---> postfix @2.11.3_0+dovecot_sasl+mariadb Error: port activate failed: Registry error: Please specify the full version as recorded in the port registry. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Building all ports when setting up a new buildbot builder
On Dec 2, 2014, at 6:40 AM, Daniel J. Luke wrote: >> On Dec 2, 2014, at 5:57 AM, Ryan Schmidt wrote: >> So after 99 hours, the Yosemite builder failed building "all" ports, with a >> memory error: >> >> https://build.macports.org/builders/buildports-yosemite-x86_64/builds/71/steps/compile/logs/err.text >> >> I think we should refrain from trying to build all 20,000 ports at once. It >> takes over a week anyway. We should instead build smaller sets of ports at a >> time. Since archives are not uploaded to the packages server until the >> entire set of ports has been built, building smaller sets of ports will let >> some packages become available sooner. > > this seems like a reasonable workaround, but it might be nice if we could > make building 'all' ports work (and maybe also set things up to upload > archives as they become available?) And possibly use mpstats to weight the order. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Open tickets
On Nov 18, 2014, at 7:28 AM, Thomas Lockhart wrote: > #43750 has been open for six months and fixes a hardcoded path problem in a > docbook-utils utility script. A patch is posted with the ticket. Build failed, I posted the log file to the ticket. > #44897 has been open for a couple of months which fixes a problem installing > pre-built binaries for the TAO port. It has a patch posted. Once that one is > applied I can go ahead and update to a newer version of TAO. > > #45860 has been open a week to update SUMO to version 0.22.0. A patch is > posted. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Nov 12, 2014, at 8:53 AM, Joshua Root wrote: > On 2014-11-12 17:14 , Lawrence Velázquez wrote: >> On Nov 10, 2014, at 3:02 PM, Bradley Giesbrecht wrote: >> >>> I don't know that I understand these variant checks, they seem to not >>> produce the same result in all cases: >>> >>> http://trac.macports.org/browser/tags/release_2_3_2/base/src/port/port.tcl#L289 >>> http://trac.macports.org/browser/tags/release_2_3_2/base/src/port/port.tcl#L1752 >>> http://trac.macports.org/browser/tags/release_2_3_2/base/src/macports1.0/macports.tcl#L730 >>> http://trac.macports.org/browser/tags/release_2_3_2/base/src/port1.0/portutil.tcl#L2289 >>> >>> Would a proc for testing variant name sanity be worth the effort? >> >> It would probably be a good idea to decide on an authoritative specification >> and consolidate verification in a single place. > > I think you mean validation? We don't actually do that anywhere at the > moment. All the places above are just parsing. If we did create authoritative validation service, would portutil.tcl be a good location? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote: > On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > >> The problem with dots in port names is that so far "port lint" has declared >> the dot an illegal character in a variant name. This has led the perl5 port >> for example to adopt variant names like perl5_16 which I've always found a >> little confusing. It has been nice that under the original naming scheme, >> one could assume that in many cases the variant name matches the name of the >> dependency that will be added. If you want to use the python27 port, you use >> a port's +python27 variant, etc. >> >> Leaving the dot in would remove the ambiguity, as demonstrated by the Perl >> ports, and "port lint" may be overly cautious in its prohibition of the dot >> in variant names. Someone should do some tests. Make variants with dots, >> like "mysql5.1", and see if they work correctly. Can you install the port? >> Can you upgrade the port? Can you uninstall the port? What if other variants >> are also selected? If everything works fine we can relax this lint >> restriction. > > A cursory glance at port.tcl suggests that periods are acceptable in variant > names. > > http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 I don't know that I understand these variant checks, they seem to not produce the same result in all cases: http://trac.macports.org/browser/tags/release_2_3_2/base/src/port/port.tcl#L289 http://trac.macports.org/browser/tags/release_2_3_2/base/src/port/port.tcl#L1752 http://trac.macports.org/browser/tags/release_2_3_2/base/src/macports1.0/macports.tcl#L730 http://trac.macports.org/browser/tags/release_2_3_2/base/src/port1.0/portutil.tcl#L2289 Would a proc for testing variant name sanity be worth the effort? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Database Browser 3.4.0 for SQLite
On Nov 3, 2014, at 6:10 AM, Andrea D'Amore wrote: > On Fri, Oct 31, 2014 at 9:01 PM, Ian Wadham wrote: >> On 01/11/2014, at 5:23 AM, Bradley Giesbrecht wrote: >>> A nice SQlite GUI app: >>> https://github.com/sqlitebrowser/sqlitebrowser/releases >> Don't we already have sqlitedbrowser in MacPorts? Apart from >> the "d", what is the difference? > > The one already in port is a different project and much less mature, > also it seems abandoned. I like that with Database Browser for SQLite I can view the table schema from the query editor. There is also a menu for loading extensions, MacPorts registry uses share/macports/sqlite/macports.sqlext. I cannot remember how I loaded extensions with sqlitedbrowser, probably the query editor. The GUI is the best I have found so far, clean and intuitive. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Database Browser 3.4.0 for SQLite
A nice SQlite GUI app: https://github.com/sqlitebrowser/sqlitebrowser/releases Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
how to avoid fetching from macports_distfiles mirrors
Is there an easier way to not fetch distfiles from macports_distfiles mirrors than editing _resources/port1.0/fetch/mirror_sites.tcl? Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bash 4.3.28 checksum failure
On Oct 2, 2014, at 10:56 AM, Juan Manuel Palacios wrote:
> Hey guys!
>
> I'm trying to update to bash 4.3.28 but I'm constantly (since yesterday)
> getting a checksum failure for the bash43-028 patchfile:
>
> Error: Checksum (sha1) mismatch for bash43-028
> Portfile checksum: bash43-028 sha1 1e05d95e4abd32b631d991fa374d030c1651645d
> Distfile checksum: bash43-028 sha1 0cb3ff195fb252ff4bd33f7562c4e1917b210edc
>
> Anyone else seen this? Or is it maybe something on my end? It may be
> completely unrelated, but with all the bash shellshock reports going around,
> I'm naturally a bit wary of such mismatch.
With:
for mirror in $(port distfiles bash | grep "^ .*bash43-028$");do echo
$mirror;curl -s ${mirror} -O;openssl sha1 bash43-028;done
These do not match:
http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/bash/bash43-028
SHA1(bash43-028)= 992fa55af8366819627e5fafa686ed956b24bc4f
http://svn.macports.org/repository/macports/distfiles/bash/bash43-028
SHA1(bash43-028)= 7d05360cf240509e210ac1f81e2cda75addb4b3e
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bash 4.3.28 checksum failure
On Oct 2, 2014, at 10:56 AM, Juan Manuel Palacios wrote: > Hey guys! > > I'm trying to update to bash 4.3.28 but I'm constantly (since yesterday) > getting a checksum failure for the bash43-028 patchfile: > > Error: Checksum (sha1) mismatch for bash43-028 > Portfile checksum: bash43-028 sha1 1e05d95e4abd32b631d991fa374d030c1651645d > Distfile checksum: bash43-028 sha1 0cb3ff195fb252ff4bd33f7562c4e1917b210edc > > Anyone else seen this? Or is it maybe something on my end? It may be > completely unrelated, but with all the bash shellshock reports going around, > I'm naturally a bit wary of such mismatch. Not here, just now fetched and file checksums matched Portfile. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Oct 1, 2014, at 1:59 PM, Bradley Giesbrecht wrote: > > On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote: > >> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: >> >>> The problem with dots in port names is that so far "port lint" has declared >>> the dot an illegal character in a variant name. This has led the perl5 port >>> for example to adopt variant names like perl5_16 which I've always found a >>> little confusing. It has been nice that under the original naming scheme, >>> one could assume that in many cases the variant name matches the name of >>> the dependency that will be added. If you want to use the python27 port, >>> you use a port's +python27 variant, etc. >>> >>> Leaving the dot in would remove the ambiguity, as demonstrated by the Perl >>> ports, and "port lint" may be overly cautious in its prohibition of the dot >>> in variant names. Someone should do some tests. Make variants with dots, >>> like "mysql5.1", and see if they work correctly. Can you install the port? >>> Can you upgrade the port? Can you uninstall the port? What if other >>> variants are also selected? If everything works fine we can relax this lint >>> restriction. >> >> A cursory glance at port.tcl suggests that periods are acceptable in variant >> names. >> >> http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 > > Lint warnings aside, after adding a mariadb10.0 variant to sphinx I have been > able to install, activate and deactivate sphinx with an assortment of > variants including mariadb10.0. Lint warning gone after adding a "." to the regex on variantname: http://trac.macports.org/browser/tags/release_2_3_1/base/src/port1.0/portlint.tcl#L411 Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote: > On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > >> The problem with dots in port names is that so far "port lint" has declared >> the dot an illegal character in a variant name. This has led the perl5 port >> for example to adopt variant names like perl5_16 which I've always found a >> little confusing. It has been nice that under the original naming scheme, >> one could assume that in many cases the variant name matches the name of the >> dependency that will be added. If you want to use the python27 port, you use >> a port's +python27 variant, etc. >> >> Leaving the dot in would remove the ambiguity, as demonstrated by the Perl >> ports, and "port lint" may be overly cautious in its prohibition of the dot >> in variant names. Someone should do some tests. Make variants with dots, >> like "mysql5.1", and see if they work correctly. Can you install the port? >> Can you upgrade the port? Can you uninstall the port? What if other variants >> are also selected? If everything works fine we can relax this lint >> restriction. > > A cursory glance at port.tcl suggests that periods are acceptable in variant > names. > > http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 Lint warnings aside, after adding a mariadb10.0 variant to sphinx I have been able to install, activate and deactivate sphinx with an assortment of variants including mariadb10.0. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Drop PPC support
On Oct 1, 2014, at 10:58 AM, Sean Farley wrote: > As discussed in the MPI thread, PPC is very old and is causing quite the > development burden. I would be in favor of discussing how much effort we > really want to spend supporting them (similar to supporting libstdc++ on > Mavericks). > > We could tag some known version of the MacPorts svn tree for PPC users > and be done with it. This would allow us to concentrate on other issues. > > We could also talk about how far of an OS back do we really want to > support. Tiger and Leopard are decrepit. We don't even have buildbots > for PPC nor OSes below Lion. There are buildbots for Snow Leopard. https://build.macports.org/buildslaves Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts-MySQL Dictator wanted, prefer benevolent
On Oct 1, 2014, at 6:45 AM, Craig Treleaven wrote:
> At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:
>> Currently, the latest stable version of MariaDB is 10.0.
>
> Really?
Yes, in that MariaDB 10.0 is the latest "release" version.
> Has MariaDB 10.0 really been sufficiently exercised in the
> OS X environment to become the default? Currently, not a single port
> that I've identified even offers mariadb-10.0 as a variant. Only 4
> ports in my list currently default to mariadb or mariadb55:
>
> PortDefault Variant
> akonadi mariadb55
> amarok mariadb55
> py24-mysql mariadb55
> py25-mysql mariadb55
> py26-mysql mariadb55
> py27-mysql mariadb55
> qore-mysql-module mariadb
As soon as the variant naming is settled there will be mariadb-10.{0,1}
variants.
>> The question is what to name the variants. This has also been
>> brought up for discussion before. My most recent thread on the topic
>> from 2 weeks ago got no replies on the list; perhaps I was too wordy.
>>
>> My suggestion was that using dots in version numbers, but no
>> underscores, would be the cleanest and most informative, which would
>> make the complete list of proposed MySQL variant today: +mariadb5.5,
>> +mariadb10.0, +mariadb10.1, +mysql5.1, +mysql5.5, +mysql5.6, and
>> +percona5.6.
>
> Adopting this format means renaming every variant of every affected port.
>
> This may also break the upgrade path for existing installs, no? We
> really should keep legacy-named variants for a period of time along
> with the new standard which leads to an explosion of variants for
> some ports.
I think it is common to add something like this for a time (1 year):
if [variant_isset ${legacy-variant}] {
default_variants-append +${replacement-variant}
}
> For example, apr-util currently has mariadb, mysql5,
> mysql51, mysql55, mysql56, and percona variants related to db
> selection. We'd have to keep those 6 and add at least 6 more (maybe
> 8 if maridb10.0 and mariadb10.1 are supported).
Similar to recent discussions regarding removing old versions of perl and
python, we should consider removing/replacing older versions of mysql like
mysql4 and mysql5 and probably mysql51.
I believe it would be an improvement if we settled on these ports for now and
removed/replace all others:
mariadb-5.5 // MariaDB has long term support contract with Redhat for this 5.5
mariadb-10.0 // Newest stable release
mariadb-10.1 // Alpha release
mysql-5.5
mysql-5.6 // Generally Available (GA) Release
mysql-5.7 // Development Release
percona-5.5
percona-5.6
https://downloads.mariadb.org/mariadb/+releases/
http://dev.mysql.com/downloads/mysql/
http://www.percona.com/downloads/
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts-MySQL Dictator wanted, prefer benevolent
On Sep 30, 2014, at 8:37 AM, Craig Treleaven wrote:
> By way of background, my MythTV ports depend on p5.16-dbd-mysql, py27-mysql
> and php-5-mysql. Previously, all of these defaulted to the now-obsolete
> mysql5 variant. Now, py-mysql defaults to mariadb55. p516-dbd-mysql offers
> a "mariadb" variant; not "mariadb55". php5-mysql defaults to mysqlind
> ("MySQL native driver") and offers a "mariadb" variant; again not
> "mariadb55". p5.16-dbd-mysql still defaults to mysql5.
>
> The subtle variance in naming the variants creates confusion. The range of
> defaults can lead to bloat and confusion.
>
> Initially, I found there was a ticket related to py-mysql database variants
> [1] and I filed additional tickets for php5-mysql [2] and p5-dbd-mysql [3].
> Since then, I thought to search for other ports that offer variants related
> to MySQL ('port echo variant:mysql*')--a total of 89 ports, of which about 20
> are subports.
>
> [1] https://trac.macports.org/ticket/39068
> [2] https://trac.macports.org/ticket/44481
> [3] https://trac.macports.org/ticket/44484
>
> The tickets have been open for 6 weeks or more with no movement. I've started
> to do some analysis on this (with another thread asking for help) to see if
> we can standardize on a list of MySQL-related variant names and maybe even
> agree on a common default.
>
> That's where the dictator comes in. At the moment, I would say the obvious
> choices for a default MySQL variant would be mysql55, mariadb55 or, maybe,
> mysql56. AFAICT there is no clear-cut, compelling reason to choose one over
> the others (technical, legal, religious, whatever).
Momentum appears to be on the side of MariaDB
MariaDB 10.0 is the current release branch and is tracked by the mariadb-10.0
port.
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
