Re: PR usage by people with commit access

On 5 November 2016 at 08:33, Ryan Schmidt wrote: > > Now that we've converted to GitHub, I am automatically receiving emails about > each pull request submitted to the MacPorts repositories, and each comment > that's made on them. I've tried to participate in some of those, providing > feedback

Re: How to keep uncommitted work in a git clone

On 5 November 2016 at 08:39, Ryan Schmidt wrote: > On Nov 4, 2016, at 12:39 AM, David Bariod wrote: > >> Personnally, I would just commit such change. It is cheap, can be reworked >> later and be ketp safe in a private remote repository in case of disaster. >> With git there are no reason to not

Re: Pull Requests for Work in Progress (WIP)

On 4 November 2016 at 18:55, Marko Käning wrote: > > Besides there is even a clearly visible RED "Work-In-Progress" label > available in the PR interface, which Mojca had spotted eventually. I didn't spot it. I though it was useful and made it after this discussion was started. Mojca

Properly merging pull requests

Hi, We have recently experienced problems with pull requests showing up as rejected on the web interface rather than merged (while the changes were in fact accepted, possibly with some modifications). I admit my sins. In one case I did a minor modification (squashed commits, removed the "Id"

Re: Removing "$Id$" lines

On 2 November 2016 at 05:07, David Evans wrote: > > Another reason for not canceling such a build would be to generate a record > of how many ports and which ones are > currently broken. I suspect there are a number that never get reported > because they are old or obscure or just not used >

Re: New build failure emails are difficult to act on

On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote: > I've been having a bit of difficulty dealing with the new buildbot emails. I > would really like links to the individual failing jobs. Instead, we're given > links to each job and a list of failed ports, but there is no indication

Re: GitHub usernames as maintainers

On 1 November 2016 at 19:57, Clemens Lang wrote: > On Tue, Nov 01, 2016 at 07:42:23PM +0100, Mojca Miklavec wrote: > >> At some point (rather sooner than later) we'll have to start adding >> GitHub usernames to Portfiles (we might have to extend the base to >> properly su

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

On 1 November 2016 at 19:23, Sean Farley wrote: > Lawrence Velázquez writes: > >> You should set your repository's user.email to your MacPorts email address. > > Is this really necessary? I've seen mention of a mailmap but that hardly > seems like a big enough reason to force us to change

Re: Removing "$Id$" lines

On 1 November 2016 at 18:07, Lawrence Velázquez wrote: >> On Nov 1, 2016, at 7:00 AM, Mojca Miklavec wrote: >> >> On 1 November 2016 at 01:03, Ryan Schmidt wrote: >>> On Oct 31, 2016, at 17:17, Dan Ports wrote: >>>> >>>> Any reason not to ju

Re: Removing "$Id$" lines

On 1 November 2016 at 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

Re: Working with Git

On 31 October 2016 at 16:35, Daniel J. Luke wrote: > On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote: >> >> One of the suggestions in this thread was to use the "hub" wrapper around >> git. Based on the fact that their homepage only mentions how to install hub >> with Homebrew, and that they

Re: Moving to GitHub: Status Update, Action Required

On 24 October 2016 at 20:08, Lawrence Velázquez wrote: >> On Oct 24, 2016, at 1:58 PM, Clemens Lang wrote: >>> On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote: >>> >>> (My preference would be to keep linear history for master and not to >>&g

Re: Moving to GitHub: Status Update, Action Required

On 24 October 2016 at 19:15, Lawrence Velázquez wrote: >> On Oct 24, 2016, at 12:50 PM, Mojca Miklavec wrote: >> >> (not?) related to the above question: One thing I'm confused about is >> that whenever I'm listed as a reporter or in CC, my name would be >> repl

Re: Moving to GitHub: Status Update, Action Required

Hi, On 21 October 2016 at 20:12, Clemens Lang wrote: > > Action Required: GitHub Accounts > > Our new Trac installation will use GitHub for login. If you do not have > a GitHub account yet, please create one now at > https://github.com/join > > To help us match

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

On 20 October 2016 at 10:41, Mojca Miklavec wrote: > On 20 October 2016 at 04:42, Joshua Root wrote: >> On 2016-10-20 13:23 , Ryan Schmidt wrote: >>> >>> >>>> On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote: >>>> >>>> Rev

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

On 20 October 2016 at 04:42, Joshua Root wrote: > On 2016-10-20 13:23 , Ryan Schmidt wrote: >> >> >>> On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote: >>> >>> Revision >>> 154081 >>> Author >>> mo...@macports.org >>> Date >>> 2016-10-19 19:04:20 -0700 (Wed, 19 Oct 2016)

Dependencies that depend on installed ports/variants

Hi, Trac seems to be down for me at the moment. I switched most of the ports to perl5.24, but there are some ports like - cpuid - docbook-utils - pcsc-tools that do just PortGroup perl5 1.0 depends_build port:p${perl5.major}-foo without specifying the perl version to use

Re: A new category of ports: purgatory

On 18 October 2016 at 10:42, Ryan Schmidt wrote: > On Oct 18, 2016, at 2:53 AM, Mojca Miklavec wrote: > >> I would like to ask once again for thoughts about the following suggestion. >> >> 1.) Create a new folder/category called "purgatory" (other suggest

A new category of ports: purgatory

Hi, I would like to ask once again for thoughts about the following suggestion. 1.) Create a new folder/category called "purgatory" (other suggestions for names welcome) 2.) We would put there any ports satisfying some of the following criteria: - don't build at all - abandoned upstream -

Building for 10.5 i386+ppc on 10.6 x86_64

Hi, A while ago we got a bug report about problems building Perl on 10.6 x86_64 for 10.5 i386+ppc https://trac.macports.org/ticket/52290 To what extent is (or should be) this supported? I remember that I tried to cross-compile clang/libc++ on 10.6 x86_64 for 10.5 ppc, but I gave up at some

2nd MacPorts Meeting & Online Meeting

Hi, Me and Aljaž would be willing to host the MacPorts meeting in 2017 again. If you have any particular requests about the desired time / place / or anything else, we can discuss it before we fix the dates, but we should probably fix it some time soon. In addition to the face-to-face meeting,

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

On 8 October 2016 at 12:09, Clemens Lang wrote: > - On 4 Oct, 2016, at 00:51, Mojca Miklavec wrote: > >>-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE > > I think this flag only affects installation (i.e. what happens on > make install), so you may want to check its

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 16:23, René J.V. Bertin wrote: > > Ken: apologies for not having thought of this, but myself when I was still > running 10.6 I've had sufficient success with building C++11 code using a > (then) recent gcc port. It's possible that things have evolved so much > nowadays

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 15:08, Ryan Schmidt wrote: > > Let's take the qt5-qtbase port as an example. It depends on the icu port. Its > library /opt/local/libexec/qt5/lib/QtCore.framework/QtCore links with icu's > libraries /opt/local/lib/libicui18n.55.dylib, > /opt/local/lib/libicuuc.55.dylib,

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 14:40, René J.V. Bertin wrote: > On Thursday October 06 2016 07:17:18 Ryan Schmidt wrote: > >> I don't understand... Those two paragraphs seem contradictory. You say it >> works without libc++, and that forcing libc++ would cause the ports to fail >> (on vanilla OS X <

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 14:43, Ryan Schmidt wrote: >> On Oct 6, 2016, at 7:35 AM, Mojca Miklavec wrote: >> >> It works without https://trac.macports.org/wiki/LibcxxOnOlderSystems >> (= setting libc++ to become your default stdlib globally). But the >> port in questio

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 14:17, Ryan Schmidt wrote: >> On Oct 6, 2016, at 6:26 AM, Mojca Miklavec wrote: >> On 6 October 2016 at 12:06, René J.V. Bertin wrote: >>> On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote: >>> >>>> If a port requires C++11

Re: Patch naming policy (was: Re: [153574] trunk/dports/sysutils/skey)

Hi, I don't care if we use *.diff or *.patch. Either is fine, but I would prefer if we would stick to one ending and try to be as consistent as we can be. The "patch-" prefix is a bit redundant indeed, but then again I don't care that much. I would be OK with removal, but again I would like to

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On 6 October 2016 at 12:06, René J.V. Bertin wrote: > On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote: > >> If a port requires C++11 / libc++, include the cxx11 1.0 portgroup. > > I wonder if that shouldn't simply be done by the Qt5 PortGroup then ... > > I don't

Looking for help with MinGW-w64 cross-compiler

Hi, I would like to ask for some help with finalizing the packages for MinGW-w64. I have a working cross-compiler in my user tree https://trac.macports.org/browser/users/mojca/ports/cross but it's not yet in a state where I would be happy to move it to trunk. The ticket is here:

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

Dear Clemens, On 30 September 2016 at 10:35, Clemens Lang wrote: > Hi Mojca, > > - On 30 Sep, 2016, at 03:30, Mojca Miklavec wrote: > >> Does anyone with a deeper understanding of CMake build system have any >> idea what to fix? > > CMake should get this right

CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

Hi, Under https://svn.macports.org/repository/macports/users/mojca/ports/tex/miktex I have a preliminary port for MikTeX with the following problem: https://sourceforge.net/p/miktex/bugs/2485/ The developer was fast in fixing many issues, but this one is something that probably doesn't

Re: I'm a newbie mantainer and I'm confused about the buildbot

On 30 September 2016 at 01:29, Ken Cunningham wrote: > > I for one am very happy that patches are accepted for older systems, unlike > homebrew and fink. Just curious: where did you get that information? I'm not too familiar with homebrew, but

Re: I'm a newbie mantainer and I'm confused about the buildbot

On 29 September 2016 at 22:10, Leonardo Brondani Schenkel wrote: > On 2016-09-29 21:51, Lawrence Velázquez wrote: >> >> If the problem occurs on an earlier OS (as yours did), then it's up to >> you. We'd like to keep ports working on as many systems as possible, but >> you are not obligated to

Re: Buildbot now building Python modules

On 15 September 2016 at 15:51, Ryan Schmidt wrote: > In the interest of getting more packages built on our "new" builders, without > trying to build all ports just yet, I started builds of all the Python > modules we hadn't built yet on the 10.12_x86_64, 10.7_x86_64_legacy, > 10.6_i386_legacy

Re: [152630] contrib/buildbot-test

On 14 September 2016 at 21:15, Ryan Schmidt wrote: >> On Sep 14, 2016, at 2:01 PM, Rainer Müller wrote: >> On 2016-09-14 16:10, Ryan Schmidt wrote: >>> >>> I had to remove these lines when deploying because I don't have a "docs" >>> worker set up yet. >>> >>> Configuration Errors: >>> builder

Re: RFC: mp-buildbot failcache

> We should put the buildername/buildnumber/URL of the failing build into > the failcache to be reported back on a match. The current output would > not be helpful to find the reason why it failed. I added this > information to the build environment [1]. Just curious. Given that you already

Re: RFC: mp-buildbot failcache

On 14 September 2016 at 06:25, Ryan Schmidt wrote: > Now that we have the failcache (thanks!) what would be involved in getting a > successcache? - Before listing or installing any dependencies, ask MacPorts for the name (full path) of the resulting binary tarball like

Re: [152162] contrib

On 12 September 2016 at 06:30, Ryan Schmidt wrote: > > The updated master.cfg is live. Wonderful, thank you! Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Binary archives are never fetched for files in my local port repository

On 7 September 2016 at 09:25, Joshua Root wrote: > On 2016-9-6 23:58 , Brandon Allbery wrote: >> On Tue, Sep 6, 2016 at 5:56 AM, Mojca Miklavec wrote: >> >> I recently figured out that ports that I have in my local repository >> are *never* updated from the

Re: Do I want subports?

On 8 September 2016 at 19:33, Ken Cunningham wrote: > Working on the optimal way to do this emulator + GUI program. > > The emulator itself is best built with i386, for the JIT. This requires > libSDL to be available in i386 (so presumably +universal). You can monkey > around with a no-JIT

Binary archives are never fetched for files in my local port repository

Hi, I use a combination of of full macports repository plus a small local repository with just a few ports I'm interested in (mostly ones I'm maintaining, but also some ports where I committed things or was playing around with them). I recently figured out that ports that I have in my local

Re: A separate PortIndex for libc++ on older systems

Hi, I wrote this quite a while ago and then forgot to send it out. In short: yes, I believe that we should start distributing a separate PortIndex for libc++-based systems and that we should make final decisions rather sooner than later. (Maybe time to schedule an "online/irc meeting" to push

r151951: Wrong compiler dependencies of llvmlite

Hi, The changes from http://trac.macports.org/changeset/151951 don't work to well. I guess that the same compiler should be used to build the ports as the one you are linking against. See an example of the failed build:

Re: Updating tk +quartz failed on Snow Leopard

On 25 August 2016 at 12:44, Mojca Miklavec wrote: > > and tried to replace > scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2 : 1; > with > scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1; ... The other way

Re: Updating tk +quartz failed on Snow Leopard

Hi, I'm moving the discussion from the user mailing list to the developer one, hoping to catch attention of more experienced developers there. To summarize. Tk fails to compile on Snow Lepard due to the following chunk of code: MacDrawable *macDraw = (MacDrawable *) d; NSWindow *win =

Re: [151794] trunk/dports/graphics/fntsample

On 22 August 2016 at 20:15, Ryan Schmidt wrote: > >> +@@ -944,7 +944,7 @@ int main(int argc, char **argv) >> + exit(1); >> + } >> + >> +-cairo_set_source_rgb(cr, 0.0, 0.0, 0.0); >> ++cairo_set_source_rgb(cr, 0.0, 0.0, 0.0); >> + draw_glyphs(cr, cr_font, face, fontname,

Re: How to use git

On 20 August 2016 at 02:19, Ryan Schmidt wrote: > > https://trac.macports.org/wiki/WorkingWithGit We should add this: http://stackoverflow.com/questions/927358/how-to-undo-last-commits-in-git#927386 to: https://trac.macports.org/wiki/WorkingWithGit#revert Currently the third paragraph

Re: How to use git

On 21 August 2016 at 22:47, Fred Wright wrote: > On Sat, 20 Aug 2016, Brandon Allbery wrote: >> On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham wrote: >> >> > Fork the repo?? >> >> github expects you to do this, yes. I don't actually recommend it because >> keeping up to date with the original repo's

Re: Need to know what actions I need to take to get the following tickets resolved ...

Hi, On 14 August 2016 at 00:48, Edward Maros wrote: > https://trac.macports.org/ticket/51625 /.../ I see that the ports have already been committed. But given that you are installing the same version from the same master_sites, same homepage, same maintainer, similar configuration options ...

Re: [151265] contrib/mp-buildbot/mpbb-install-dependencies

On 14 August 2016 at 14:02, Ryan Schmidt wrote: > >> -echo "Installing $dependencies_count dependencies:" >> -echo "Installing $dependencies_count dependencies:" >> >> "$log_status_dependencies" >> -echo "$dependencies" | sed -E 's/^/ - /' >> -echo "$dependencies" | sed -E 's/^/ -

Re: How to discontinue ports completely (py26 deprecation) ...

On 15 August 2016 at 03:52, Fred Wright wrote: > On Sat, 13 Aug 2016, Christopher Jones wrote: >> >> I agree there is no way to migrate completely to 3.x, but I am still not >> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is >> worth the effort. 2.6 needs to be dropped

Re: Something broke wine

On 16 August 2016 at 15:29, wrote: > > I looked at the fontconfig website and I don’t see an obvious link to their > bug tracker. I will file a bug report there if you can tell me where it is? https://bugs.freedesktop.org/describecomponents.cgi?product=fontconfig Mojca

Re: [151267] contrib/mp-buildbot

Hi, On 11 August 2016 at 22:04, Clemens Lang wrote: > On Thu, Aug 11, 2016 at 01:03:06AM -0700, mo...@macports.org wrote: >> Revision: 151267 >> https://trac.macports.org/changeset/151267 >> Author: mo...@macports.org >> Date: 2016-08-11 01:03:06 -0700 (Thu, 11

Re: A separate PortIndex for libc++ on older systems

On 10 August 2016 at 10:37, Ryan Schmidt wrote: > > Currently, there is only one PortIndex file generated on the server, and > published to the rsync server, for each OS name/version/endianness > combination. So for example, there is one PortIndex for Darwin 12 Intel. > There is not currently a

Re: [151216] contrib/buildbot-test/master.cfg

On 11 August 2016 at 08:20, Lawrence Velázquez wrote: >> On Aug 11, 2016, at 2:07 AM, Ryan Schmidt wrote: >>> On Aug 10, 2016, at 11:56 PM, Mojca Miklavec wrote: >>> >>> I changed that in r151249 and 151258. I don't know any "official" way >&g

Re: [151215] contrib/mp-buildbot

On 11 August 2016 at 05:56, Ryan Schmidt wrote: >> On Aug 10, 2016, at 1:25 PM, Mojca Miklavec wrote: >> >> Alternatively logdir could simply remain hardcoded as >> ${option_workdir}/logs. There's no need for an extra layer of >> complexity that doesn't really

Re: [151216] contrib/buildbot-test/master.cfg

On 11 August 2016 at 03:45, Ryan Schmidt wrote: >> On Aug 10, 2016, at 8:44 PM, Lawrence Velázquez wrote: >>> On Aug 10, 2016, at 9:37 PM, Ryan Schmidt wrote: >>> On Aug 10, 2016, at 1:13 PM, mo...@macports.org wrote: --- contrib/buildbot-test/master.cfg2016-08-10 18:09:29

Re: [151215] contrib/mp-buildbot

On 10 August 2016 at 20:17, Lawrence Velázquez wrote: > > --- contrib/mp-buildbot/mpbb 2016-08-10 16:13:48 UTC (rev 151214) > +++ contrib/mp-buildbot/mpbb 2016-08-10 18:09:29 UTC (rev 151215) > @@ -77,6 +79,10 @@between builds. Your MacPorts installation in --prefix > needs to be able to >

Re: Determine before installation whether a port can be installed

On 27 July 2016 at 06:09, Ryan Schmidt wrote: > > One solution that occurs to me is to define a new "preflight" phase, to be > run before dependencies are computed. Ports can override that phase and do > whatever checks they need and exit with "return -code error" if needed. This > seems like

Re: New build system

On 10 August 2016 at 08:02, Ryan Schmidt wrote: > > On Aug 10, 2016, at 1:00 AM, Marko Käning wrote: > >> The waterfall view is - horizontally - pretty full these days... It would be >> neat if at least a logged on user could customise the view a little, like >> e.g. being able to only display

Re: [150874] trunk/dports/lang/python32

On 1 August 2016 at 20:49, Daniel J. Luke wrote: > On Aug 1, 2016, at 2:39 PM, Lawrence Velázquez wrote: >> Not to pick on you, Mihai, but have we ever considered getting rid of (or at >> least revising) the guideline that implies that these new, sprawling, >>

Sound Fonts

Hi, This is mostly meant for Davide who is a maintainer for Frescobaldi[-devel], but I wanted to raise the topic on this mailing list. Today I noticed this: > port notes frescobaldi-devel frescobaldi-devel has the following notes: You may want to install FluidSynth and obtain a SoundFont in

Re: pypi2port broken

On 22 July 2016 at 11:39, Joshua Root wrote: > On 2016-7-22 19:08 , Mojca Miklavec wrote: >> >> Hello, >> >> It seems that pypi2port has some problems (most likely after the >> changes done at pypi infrastructure): >> >> xmlrpclib.ProtocolErr

pypi2port broken

Hello, It seems that pypi2port has some problems (most likely after the changes done at pypi infrastructure): xmlrpclib.ProtocolError: Is anyone willing to look at it? Thank you, Mojca ___ macports-dev mailing list

Re: Choice of compiler from compiler.whitelist

One more question: does compiler.whitelist macports-gcc-6 macports-gcc-5 macports-gcc-4.9 ... automatically add a runtime dependency on libgcc? I just started wondering how building a port on a builtbot might influence the user that just happens to have no gcc installed. Mojca

Re: Compiler bug?

Reposting the question ... On 17 July 2016 at 14:18, Mojca Miklavec wrote: > Hi, > > I am unable to compile lilypond 2.19.45 (the problem must have started > at around 2.19.42 or 43). > > One of the developers came up with the following minimal example (from > the sour

Re: portfile test for macosx 10.6.8 + libc++

On 19 July 2016 at 04:38, Ken Cunningham wrote: > Hello everyone, > > I'd like to help with minor porfile adjustments to allow compiling on the > above system, within my limited skill set. > > To allow for an accurate method of specifying a system running 10.6..8 + > libc++, can anyone help me

Compiler bug?

Hi, I am unable to compile lilypond 2.19.45 (the problem must have started at around 2.19.42 or 43). One of the developers came up with the following minimal example (from the source code that Lilypond is using) that works with g++, but fails with clang++: class A { public: template void

'\0' not accepted as an empty "const char *": is this a compiler problem or not?

Hi, When I tried porting some software (originally written for Windows and now asking for C++14) to MacPorts I was stuck with an external piece of a code written in C, compiled with C++ (I don't fully understand why it is compiled with C++, but I cannot change that). This is a minimal example

Re: snapd

On 20 June 2016 at 11:43, Rainer Müller wrote: > > Furthermore, back to the topic of Snappy packages, I recommend to read > this post by Kyle Keen. He describes how distributions adapt software to > the needs of their users. This mostly also applies to MacPorts, as we > often have to patch

Re: PortGroup python 1.0 guidance

On 18 June 2016 at 00:40, Sterling Smith wrote: > Ed, > > Could it make sense to divide up the project into a python part, and a > non-python part as two ports? Just a thought. I cannot answer for this particular case, but this is indeed a problem that many Portfiles circumvent by hardcoding or

Re: snapd

On 17 June 2016 at 18:32, Ryan Schmidt wrote: > > On Jun 17, 2016, at 11:24 AM, Alexey Kuznetsov wrote: > >> Universal “snap” packages launch on multiple Linux distros >> >> https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/ >> >> Even OpenWRT on the

Livecheck for Perl

On 10 June 2016 at 14:51, Rainer Müller wrote: > On 2016-06-10 12:55, Mojca Miklavec wrote: >> But why >> >>> port -v livecheck p5-config-simple >> p5-config-simple seems to have been updated (port version: 4.59, new >> version: 4.58) >> >> then?

Re: Weird situation after updating paho-mqtt

On 10 June 2016 at 12:17, Rainer Müller wrote: > On 2016-06-10 11:42, Mojca Miklavec wrote: >> I wonder whether this livecheck error was perhaps a consequence of >> https://trac.macports.org/changeset/148976 >> or some related change around that. It's quite possible th

Weird situation after updating paho-mqtt

Hi, Some time ago (I made the commit on 2016-06-07, I don't remember when I actually did things) I ran port livecheck maintainer: which listed py-paho-mqtt as updated to version 1.2 So I went ahead and upgraded the port. Then I suddenly realized yesterday that livecheck now returns

Re: Snow Leopard compilers

On 9 June 2016 at 19:07, Mojca Miklavec wrote: > > There is probably not much interest in this issue and there is an easy > workaround, but I would also kind of agree that blacklisting "*gcc*" > should probably also blacklist clang/llvm-gcc on 10.6. Once again me

Re: Snow Leopard compilers

On 9 June 2016 at 19:03, Mojca Miklavec wrote: > On 9 June 2016 at 18:51, David Strubbe wrote: >> Hi all, >> >> I am a bit confused about what is going on with selection of compiler on >> Snow Leopard for the apbs port. It is taking clang for C but llvm-g++-4.2 >

Re: Snow Leopard compilers

On 9 June 2016 at 18:51, David Strubbe wrote: > Hi all, > > I am a bit confused about what is going on with selection of compiler on > Snow Leopard for the apbs port. It is taking clang for C but llvm-g++-4.2 > for C++, and the latter does not work for this port. If clang++ were used I > think it

Re: PortGroup directory hierarchy/priority

On 27 March 2016 at 17:33, Rainer Müller wrote: > On 2016-03-27 16:57, René J.V. Bertin wrote: >> Can someone please summarise the exact priority rules used in >> resolving the file to be included when using a PortGroup statement in >> a port? > > 1. _resources/port1.0/group/*.tcl in ports tree of

Re: Help with py-tz download location

On 29 May 2016 at 21:42, Joshua Root wrote: > On 2016-5-30 04:44 , Adam Mercer wrote: >> >> Hi >> >> py-tz has been updated, to version 2016.4) and it seems that the >> download location for the source has changed, it now seems to include >> some kind of hash in the URL and I can't workout how to

Re: Howto inspect Portfile variables to debug install

On 29 May 2016 at 20:19, Chris Gorman wrote: > Hello, > > I was wondering how to inspect variables in a port file. Specifically, I > want to apply a patch conditionally if perl is version 5.10.0. > > I'm trying something like > > if { ${configure.perl} eq "/usr/bin/perl" && [vercmp

Re: support for older HardWare and Mac OS X

On 23 May 2016 at 09:17, Bjarne D Mathiesen wrote: > I've got 2 older Mac Mini systems I'm using as headless servers: > > System Version : Mac OS X 10.6.8 (10K549) Mac OS X 10.6.8 (10K549) > > How much interest is there in still holding such old stuff supported in > MacPorts ??? 10.6 mostly

Re: Debian/Ubuntu-style -dev ports

(I used the wrong email address earlier) On 19 May 2016 at 11:58, René J.V. wrote: > On Thursday May 19 2016 01:14:19 Clemens Lang wrote: > >>This is really something that should either be done completely and >>correctly, or not. In theory, it's actually not all that hard. You only >>need the

Perl 5.24

Hi, I would like to ask the maintainers to start looking into Perl 5.24. Either by adding variants, switching to 5.24 exclusively ... or perhaps just testing in case that ports don't need any special switch. Please file bug reports for problems you discover. We should hopefully be done with

Re: [148570] trunk/dports/devel/subversion-perlbindings/Portfile

On 12 May 2016 at 14:44, Daniel J. Luke wrote: > On May 11, 2016, at 2:16 PM, mo...@macports.org wrote: >> subversion-perlbindings: add new subport subversion-perlbindings-5.24 > > While this change is fine - it's not an openmaintainer port (and this wasn't > a "broken port" issue), so I would

Runtime dependencies on Perl

Hi, I noticed that some ports like git strictly have just runtime dependencies on ${perl5.major}-whatever What's currently the best way to avoid the need to recompile a port like that? Using p5-whatever instead? Mojca ___ macports-dev mailing

Re: Weird version comparison in livecheck

On 26 April 2016 at 01:04, Rainer Müller wrote: > On 2016-04-25 18:29, Mojca Miklavec wrote: >> The problem is that in the second case the livecheck breaks. I tried >> to work around the issue by specifying >> >> livecheck.url ${github.homepage}/tags >>

Weird version comparison in livecheck

Hello, I'm fighting with the livecheck for root6. The thing is ... it works perfectly as long as we use github.setup root-mirror root 6-06-02 v version [string map {- .} ${github.version}] But occasionally the developers fix a problem that prevents us to build the latest version on

Signing packages without violating restrictions/laws

Hi, I have a weird question. I know that MacPorts has been signing all the packages for a long time already. I'm currently involved with a project where one developer recently implemented package signing. On the client level it uses the "gpg" or "gpg2" binary to verify packages. It works

Re: Errors should probably come after notes?

On 15 April 2016 at 19:47, Ryan Schmidt wrote: >> On Apr 8, 2016, at 4:23 PM, Mojca Miklavec wrote: >> >>> That's a tough question -- you wouldn't want users to miss the notes, >>> either. >> >> Sure. But notes can get pages long and when doing a mere upg

Re: variants

On 12 April 2016 at 20:49, Daniel J. Luke wrote: > On Apr 12, 2016, at 1:34 PM, Christopher Jones wrote: >> Take if you want, as a real world case, ROOT6, which I know well. It has a >> large number of variants, because upstream’s build system offers all these >> as optional extras. Many of them

Re: Errors should probably come after notes?

On 9 April 2016 at 16:25, Rainer Müller wrote: > On 04/08/2016 11:23 PM, Mojca Miklavec wrote: >> On 8 April 2016 at 22:24, Clemens Lang wrote: >>> On Fri, Apr 08, 2016 at 09:29:35PM +0200, Mojca Miklavec wrote: >>>> Shouldn't the order be reversed? (I'm not sure how

Re: Errors should probably come after notes?

On 8 April 2016 at 22:24, Clemens Lang wrote: > On Fri, Apr 08, 2016 at 09:29:35PM +0200, Mojca Miklavec wrote: >> What I don't like so much is that the notes come *after* the error >> report. I ended up with about 10 notes following the error, so I could >> easily

Errors should probably come after notes?

Hi, I like the new functionality (in trunk) that now the notes are printed at the end. What I don't like so much is that the notes come *after* the error report. I ended up with about 10 notes following the error, so I could easily have missed the fact that there was an error at all (I had to

Re: [147562] branches/portgroups-selector/base/src/port/port.tcl

On 8 April 2016 at 13:00, Rainer Müller wrote: > === >> --- branches/portgroups-selector/base/src/port/port.tcl 2016-04-08 >> 00:01:31 UTC (rev 147561) >> +++ branches/portgroups-selector/base/src/port/port.tcl 2016-04-08

Re: Post-destroot - How to copy folder

On 8 April 2016 at 02:53, Abdulrahman Alshammari wrote: > Hey, > I have a library that contains many folders, each one with many examples. How > can I copy the whole folder in Post-destroot? Just use "copy": copy ${worksrcpath}/somewhere/examples ${destroot}${prefix}/share/doc/${name}/

Re: PortGroup directory hierarchy/priority

Hi, I didn't follow every single detail of the thread, but here are some random notes from me: (0) Complaining that subversion is slow is highly unjustified. "sudo port selfupdate" on an rsync-based installation seems like it is taking forever (on a slow machine) as well. I might be biased

Re: WebKit2-GTK: quartz VS XQuartz

Hi, I'm sorry for posting the reply to the developer mailing list rather than the user mailing list where this was originally posted, but I had a feeling that the dirty details don't interest regular users so much. On 5 April 2016 at 01:10, David Evans wrote: > On 4/4/16 1:21 AM, Andrea

Re: variants

On 3 April 2016 at 09:40, Takeshi Enomoto wrote: > Hi, > > It seems that variants in default_variants are not proliferated as > those specified in the command-line. > I have this problem with some ports that I maintain and > cause build failures with the buildbots. > > I would be helpful if you

  1   2   3   4   5   6   7   >