Re: New project members: jonesc
> On 02 nov 2016, at 20:07, Lawrence Velázquez wrote: > >> Please join us in welcoming the following new MacPorts project member: >> >> - Chris Jones (jonesc) >> >> We look forward to continued excellent contributions! Welcome Chris! 😊 -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 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: 2nd MacPorts Meeting & Online Meeting
> On 10 ott 2016, at 07:53, Mojca Miklavec wrote: > > 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. I *may* have a place, we could meet at Mittelab’s new “home”, we have a B&B chain hotel *literally* on the other side of the road, and a bigger and nicer space to hack/discuss. As for the time, I think March would be good. > > > In addition to the face-to-face meeting, I would like to propose > trying out some online meeting some time in mid-November (or any other > time, according to your wishes). I would propose to discuss: > > - creating timeline(s) with most important features that we might want > to implement & get into next releases > > - how to improve the ticket system > > - and/or any other pressing topic (just not too much all at once) > > I'm not sure about the best format of the online meeting though > (IRC?). Any suggestions welcome. It would be nice to prepare proposals > / agenda for discussion in advance though. I would limit the meeting > to 2 hours max and repeat it if necessary. Yes, that makes sense for me. Discussing on IRC is going to be a pain, though. Maybe a video conference using Google Hangouts? -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [153697] trunk/dports/sysutils/bacula
> On 08 ott 2016, at 15:46, Ryan Schmidt wrote: > > I suppose it's possible someone managed to install it in a secondary > non-standard prefix, if they also had the dependencies installed in the > standard prefix. Yeah, that is indeed possible. I commited r153706 with a fixed patch and revbump. -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [153697] trunk/dports/sysutils/bacula
> On 08 ott 2016, at 11:40, Ryan Schmidt wrote: > > /opt/local should not be hardcoded. Of course. Should I revbump it just to be sure? It wouldn’t build in a non-standard prefix anyway. -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bacula Ticket 49203
> On 07 ott 2016, at 15:31, Oschwald Robert wrote: > > Hi all, > > 6 months ago, I supplied patches to fix > https://trac.macports.org/ticket/49203 > <https://trac.macports.org/ticket/49203>. > None of the committers applied the fixes, therefore may someone please apply > them? > > Also, please remove me as maintainer from Bacula port file, as it is of no > fun for me anymore to maintain ports which do not get committed for a long > time. Hello Robert! I went ahead and committed your patch (with small modifications) in r153697. I also removed you from the maintainer list. I’m really sorry you feel that way, I can assure you it’s frustrating for us too sometimes (having a *big* backlog of tickets is no fun at all). This will be hopefully solved in the future. Thank you for your contributions, Aljaž -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 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: request review #52453
> On 02 ott 2016, at 19:38, Björn Ketelaars > wrote: > > Would someone be so kind to review (and commit) > https://trac.macports.org/ticket/52453 ? > > Thank you! Commited in r153557. Thanks for your contribution! -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Libpointing
> On 03 ago 2016, at 16:17, Izzat Mukhanov wrote: > > Hello, > > I submitted a new Portfile which compiles and installs libpointing a few > weeks ago. Could you please verify it and tell me what's wrong. Nello Izzat and welcome! In the future, please link add a link to the ticket in question (https://trac.macports.org/ticket/51737). I’ll review your portfile and comment on the ticket. -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 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: Gnucash Port Question
> On 19 lug 2016, at 18:07, David Spreen wrote:
>
> Hi All,
>
> Thanks for all the awesome work! About a week ago, I submitted a ticket +
> patch to upgrade Gnucash to the newest version (2.6.13). Since Gnucash has
> the openmaintainer address set, would it be possible for someone to have a
> look at the ticket (#51833) and perhaps commit it?[1]
>
> I also have a question about #43254.[2] The patch that is attached to that
> bug report works flawlessly and I have been using it for many months. I’ll
> happily attach a patched Portfile to that ticket once the port is updated to
> 2.6.13 (so I don’t have to go back and patch the old version). The working
> patch has been attached to the ticket for 17 months, so I am wondering if it
> has just been overlooked or if other concerns have kept this from making it
> into the port? The gnucash website still recommends the macports port to get
> python bindings on macs as they are excluded from binary distributions.
>
> Best Wishes,
> David
>
> [1] https://trac.macports.org/ticket/51833
> [2] https://trac.macports.org/ticket/43254
Hello David!
thanks for bringing this up to our attention, from time to time we need a
little reminder on the stuff that still needs work 😊
I remember looking at #43254 some time ago and I can’t remember why I discarded
it. Does it install the python packages in the correct location? I remember
having to fight the build system to put the python module in
${frameworks_dir}/Python.framework/Versions/2.7/lib/python2.7/… instead of
${prefix}/lib/python2.7/…
--
Aljaž Srebrnič a.k.a g5pw
My public key: https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677
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: New Port for osxfuse
> On 12 giu 2016, at 10:25, Alexey Kuznetsov wrote: > > Hello! > > I'm using encfs/osxfuse to enctying my home folder on mac. Recently (about > year :) ago) I notice sycing issues when I unable to remove folder because > some internal error in osxfuse/encfs. Recent investigation shows it is some > problems with source code. In short: when you do a lot of files operations > (fast create files) encfs breaks. git clone always fail on big repos for > example. > > You can find more details in: > > https://github.com/vgough/encfs/issues/109 > <https://github.com/vgough/encfs/issues/109> > > I'm trying to build recent osxfuse libraries on my mac @3.3.3 but I have lack > of knowladge how macport build system works. I wrote new Portfiles but it > fail with strange library conflict error. This is conflict between mac system > libraries (ncurses) and macport one. > > https://github.com/axet/macports_custom/issues/1 > <https://github.com/axet/macports_custom/issues/1> > > Can you help me write proper Portfile? > > You can find my work here: > > https://github.com/axet/macports_custom/tree/master/fuse/osxfuse > <https://github.com/axet/macports_custom/tree/master/fuse/osxfuse> Hello Alexey, Thanks for your contribution. Note however that osxfuse 3.x versions are “developer previews” and not really ready for the general public [1]. We could however have a osxfuse-devel port. [1]: https://trac.macports.org/ticket/49597 -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Thank you all for the wonderful MacPorts Meeting in Slovenia (and see you again soon ...)
> On 18 mar 2016, at 11:29, Mojca Miklavec wrote: > > Hi, > > All good things come to an end and so did the wonderful week that we > spent together in Gozd Martuljek. > > While I was initially hoping to see a larger group of people come > together, the relatively small group of hackers eventually turned out > to be the perfect recipe for boosting up the motivation, allowing us > for very productive one-to-one learning experience and hacking > sessions, resulting in quite satisfactory amount of work being done, > new people getting confidence in hacking the core of MacPorts, new > people joining the project, ... > > The spirit was so motivating that our "chef" nearly had to tear us > apart from the notebooks to make us come to the lunch and dinner. > Nevertheless we still managed to find some time to enjoy the wonderful > weather playing snowleyball on fresh air. > > Special thanks to Ryan for joining us in a remote session, to Rainer > for representing the PortMgr, to Clemens for convincing us that > hacking the base might not be as scary as it sounds, for attracting > and mentoring new developers, to Dagobert for bringing in a fresh > perspective from a different package manager and helping us with the > buildbot setup, to Jackson for flying in from the other side of the > globe, to Peter for keeping us awake with Italian coffee and not > minding to completely change his meeting agenda, to our cook Darko. > And finally to Aljaž who set up all the infrastructure for the > conference and helped a lot with preparation work. And a big thanks goes to Mojca, who found the hotel in the first place, negotiated a better internet connection, prepared and handled the payments, wrote mails, and generally did everything so that the meeting was successful! > > Some moments have been captured in https://twitter.com/macports, but > during the week we are all too busy to document everything we have > done and everything that we discussed. You may expect the minutes from > the meeting arriving in not too distant future though. > > We all agreed that we have to meet again. So stay tuned. Oh yeah! Judging from the quantity of food we ate, i’ll have to start fasting :P -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Python PortGroup resets depends_lib ?
> On 05 ott 2015, at 23:38, René J.V. Bertin wrote:
>
> Hi,
>
> Is it "normal" that the Python PortGroup resets `depends_lib` in the code
> called through
>
> python.versions X Y [Z]
>
> ?
>
> This may work fine for pure Python ports, but it introduces annoying
> side-effects with the dependencies that may have been set by other PortGroups
> (cf. port:py-pyqt4).
> It turns out to be perfectly possible to cache and restore the settings, e.g.
>
> PortGroup qt4 1.0
> set depends_lib_backup ${depends_lib}
> PortGroup python 1.0
>
> # ...
> python.versions 27 34
>
> depends_lib-append ${depends_lib_backup}
>
> Why does the PortGroup not do this, or have I missed a trick to achieve the
> same thing?
Hm, that’s interesting. Indeed on lines 110 and 187 of python-1.0.tcl
depends_lib is used directly, but on lines 100 and 191 depends_lib-append is
used.
In the qt4 PortGroup only depends_lib-append is used though. I wonder what
happens if you call the python PortGroup first, and the qt4 one below it?
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Article: Basic code completion for Rust in KDE's Kate (and later KDevelop) | blogs.kde.org
> On 18/mag/2015, at 17:53, René J.V. Bertin wrote: > > I haven't checked, but it seems port:rust may not be as well uptodate as it > could be? Yes, I’m working on the 1.0 release port. It should be done sometime this week. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125609] users/g5pw/pypi2port/pypi2port.py
> On 24/set/2014, at 02:47, Lawrence Velázquez wrote: > >> On Sep 23, 2014, at 3:54 AM, Aljaž Srebrnič wrote: >> >> Well, yes, but I’m assuming that if either one of xmlrpclib or >> urllib2.urlopen fails importing, the script is run under python3 since both >> modules are in core python. > > A decent assumption. Hope they never fail for any other reasons :) Well, the only reason it would fail is because the package was somehow damaged. In that case even if there were two separate try blocks, the script would fail because it would try to import a nonexistent package. We can always split it in two if we see strange issues :) -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125609] users/g5pw/pypi2port/pypi2port.py
On 22/set/2014, at 22:11, Lawrence Velázquez wrote: > With this change, an failure importing either xmlrpclib or urllib2.urlopen > will result in the fallback behavior for both. You should use two separate > try blocks. Well, yes, but I’m assuming that if either one of xmlrpclib or urllib2.urlopen fails importing, the script is run under python3 since both modules are in core python. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125415] trunk/dports/sysutils/rcm/Portfile
On 18/set/2014, at 11:54, Ryan Schmidt wrote: > > On Sep 18, 2014, at 4:50 AM, Aljaž Srebrnič wrote: >> >> On 18/set/2014, at 03:58, Ryan Schmidt wrote: >> >>> >>> >>> Checksum mismatch, unsurprisingly: >>> […] >>> >> >> Yeah, I figured, but a port clean —all && port checksum didn’t show any >> errors. It must have fetched from already cached tarballs. > > Yes, this just means github.com is not the closest server to where you are > currently located. > > >> Anyway, I updated checksums and applied the “stealth update” procedure in >> 125458. >> > > The build now fails: > > sh: ./configure: No such file or directory Well, I guess we found the reason why they hosted their tarball. I’ll roll back my last two commits and fix livecheck. > > >>> >>> It would be unlikely for a project to have hosted on their own web site a >>> tarball that was identical to the automatically-generated tarball provided >>> by github. >> >> Well, could be unlikely, but not so unreasonable: one could just re-use the >> generated tarball from github. > > In this case, they didn't. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125415] trunk/dports/sysutils/rcm/Portfile
On 18/set/2014, at 03:58, Ryan Schmidt wrote: > >> On Sep 17, 2014, at 5:17 AM, g...@macports.org wrote: >> >> Revision >> 125415 >> Author >> g...@macports.org >> Date >> 2014-09-17 03:17:24 -0700 (Wed, 17 Sep 2014) >> Log Message >> >> sysutils/rcm >> move upstream to github >> > > Checksum mismatch, unsurprisingly: > […] > Yeah, I figured, but a port clean —all && port checksum didn’t show any errors. It must have fetched from already cached tarballs. Anyway, I updated checksums and applied the “stealth update” procedure in 125458. > > It would be unlikely for a project to have hosted on their own web site a > tarball that was identical to the automatically-generated tarball provided by > github. Well, could be unlikely, but not so unreasonable: one could just re-use the generated tarball from github. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125429] trunk/dports/textproc/colout/Portfile
Thanks, 125454.
On 18/set/2014, at 04:11, Ryan Schmidt wrote:
>
>> On Sep 17, 2014, at 8:40 AM, g...@macports.org wrote:
>>
>> Revision
>> 125429
>> Author
>> g...@macports.org
>> Date
>> 2014-09-17 06:40:55 -0700 (Wed, 17 Sep 2014)
>> Log Message
>>
>> textproc/colout:
>> use python34
>> add license
>> disable livecheck (upstream tagged 0.11 instead of 0.1.1, so version check
>> fails)
>>
>> Modified Paths
>>
>> • trunk/dports/textproc/colout/Portfile
>> Diff
>>
>> Modified: trunk/dports/textproc/colout/Portfile (125428 => 125429)
>>
>
>> -python.default_version 33
>> +python.default_version 34
>
> This changes the files that the port installs, so the port's revision must be
> increased.
>
>> patch {
>> -reinplace s/python3/python3.3/ bin/colout \
>> +reinplace s/python3/python${python.branch}/ bin/colout \
>> colout/colout.py \
>> setup.py \
>> README.md
>> }
>
> These paths must be absolute; you cannot assume what the current working
> directory will be when the patch phase (or any other phase) runs. You could
> do this by using "reinplace -W ${worksrcpath} ..."
>
>
>
>
> Index: Portfile
> ===
> --- Portfile (revision 125443)
> +++ Portfile (working copy)
> @@ -6,6 +6,7 @@
> PortGroup python 1.0
>
> github.setupnojhan colout 0.4 v
> +revision1
> maintainers g5pw openmaintainer
>
> categories textproc python
> @@ -23,7 +24,7 @@
> python.default_version 34
>
> patch {
> -reinplace s/python3/python${python.branch}/ bin/colout \
> +reinplace -W ${worksrcpath} s/python3/python${python.branch}/ bin/colout
> \
> colout/colout.py \
> setup.py \
> README.md
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
About pypi2port
Hello everyone! I managed to finally take a look and use pypi2port. I can’t help but notice two things: 1) No Portfile. I think it would be nice to have portfiles for our tools. A basic porfile would be easy, but a more “pythonic” solution would be write a setup.py with distutils. Moreover, I see that the shabang is for bash and python is subsequently invoked… Couldn’t we use "#!/usr/bin/env python” ? 2) Pypi2port does not support python3. Moreover, it fails to select the correct python version, failing when the user has python3 as python default. I think it’s a real shame, as a quick pass through 2to3 yields a solution that, on a quick look, should work for python3 too. That said, I’m prepared to “pythonize” it a bit more and make a portfile so it’s easy to install. What do you think? -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Retiring Python 2.4 and 2.5
On 16/set/2014, at 03:56, Lawrence Velázquez wrote: > I'm trying to adapt Ned Deily's patches for Yosemite[1] to the Python ports. > Adapting them to all the Python 3.x ports was tedious enough, but now I've > made it to Python 2.4 and 2.5. I feel like I'm slapping bandages onto > patients who have been brain-dead for 5.74 and 3.31 years, respectively. > > Is there some overwhelmingly good reason we still provide these, given that > 2.7 is still alive and kicking? Can we please stop providing them? > >[1] http://bugs.python.org/issue21811 > > vq > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev +1 to remove python 2.4 and 2.5, it’s really been too long. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: doxygen dependencies
On 06/set/2014, at 17:06, Jeremy Lavergne wrote: > Also seems that it needs wasysym from: > texlive-fonts-recommended > > On Sep 6, 2014, at 11:02, Jeremy Lavergne wrote: > >> I’ve found that doxygen tries to use texlive-fontutils during build, and >> gnumake will segfault out if it cannot access it. >> >> Should this be added as a build dependency? > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev There are some troubles with tex dependencies, I believe they are tracked here: https://trac.macports.org/ticket/43894 -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [122078] trunk/dports/net/impacket/Portfile
On 14/lug/2014, at 10:47, Ryan Schmidt wrote: > It is syntactically acceptable to not list a license version, but that means > that any license version is acceptable. The LICENSE file in the impacket > 0.9.11 tarball described the Apache license version 1.1 so I assumed that was > the version it's actually licensed under. Aha, so I can add version numbers to all licenses that have it? I was under impression that we were using it for GPL only. > > The only list of licenses I know of is in the port_binary_distributable.tcl > script but it doesn't include license version numbers. I see, thanks! > > On Jul 14, 2014, at 3:44 AM, Aljaž @ HackerSpace_GO wrote: > >> Ah, thanks. I wasn't sure about the version number, but the portfile passed >> lint --nitpick, so I guessed it was ok. >> >> Do we have a list with all "supported" licenses? >> >> Aljaž Srebrnič >> >> Sent from mobile >> -- -- >> My public key: http://bit.ly/81qoyC >> >> On 14/lug/2014, at 10:34, ryandes...@macports.org wrote: >> >>> Revision >>> 122078 >>> Author >>> ryandes...@macports.org >>> Date >>> 2014-07-14 01:34:57 -0700 (Mon, 14 Jul 2014) >>> Log Message >>> >>> impacket: add Apache license version number >>> Modified Paths >>> >>> • trunk/dports/net/impacket/Portfile >>> Diff >>> >>> Modified: trunk/dports/net/impacket/Portfile (122077 => 122078) >>> >>> >>> --- trunk/dports/net/impacket/Portfile 2014-07-14 08:30:09 UTC (rev >>> 122077) >>> +++ trunk/dports/net/impacket/Portfile 2014-07-14 08:34:57 UTC (rev >>> 122078) >>> @@ -23,7 +23,7 @@ >>> it simple to work with deep protocol hierarchies. >>> >>> platforms darwin >>> -license Apache >>> +license Apache-1.1 >>> >>> homepage >>> http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=Impacket -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [121692] trunk/dports/sysutils
On 07/lug/2014, at 21:51, Ryan Schmidt wrote:
>
> On Jul 4, 2014, at 9:14 AM, kimu...@macports.org wrote:
>
>> Revision
>> 121692
>> Author
>> kimu...@macports.org
>> Date
>> 2014-07-04 07:14:30 -0700 (Fri, 04 Jul 2014)
>> Log Message
>>
>> sysutils/peco: new port "peco" - http://peco.github.io
>>
>>
>> peco can be a great tool to filter stuff like logs, process stats,
>> find files, because unlike grep, you can type as you think and look
>> through the current results.
>>
>> Added Paths
>>
>> • trunk/dports/sysutils/peco/
>> • trunk/dports/sysutils/peco/Portfile
>> Diff
>>
>> Added: trunk/dports/sysutils/peco/Portfile (0 => 121692)
>>
>> --- trunk/dports/sysutils/peco/Portfile (rev 0)
>> +++ trunk/dports/sysutils/peco/Portfile 2014-07-04 14:14:30 UTC (rev
>> 121692)
>>
>> @@ -0,0 +1,82 @@
>>
>> +# $Id$
>
> The modeline is missing, and there should be a blank line after the $Id$ line.
>
>
>> +master_siteshttps://github.com/peco/peco/tarball/v${version}:peco
>
> Since this project is hosted at github, consider using the github 1.0
> portgroup. The multiple distfiles might however be a complication.
>
>
>> +destroot {
>> +xinstall "${worksrcpath}/peco" "${destroot}/${prefix}/bin"
>> +}
>
> There's no need for quotes around those variables; this isn't a shell script.
>
> There should be no "/" before "${prefix}" because ${prefix} already begins
> with a slash.
Also, it looks like the port install multiple programs/libraries. Perhaps it
would be easier to separate them in multiple ports.
Should we start thinking about a golang PortGroup?
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mid-Term Report
On 28/giu/2014, at 10:22, Joshua Root wrote: > On 2014-6-28 02:48 , Rainer Müller wrote: >> On 2014-06-27 07:47, Joshua Root wrote: >>> On 2014-6-27 05:29 , Shashwat Pandey wrote: >>> >>> Sounds like good work for the most part. One note: >>> >>> >>> This will break people's scripts. If users don't do anything different, >>> the behaviour should stay the same. I would provide a different >>> executable name for interactive use, but I guess a command line and/or >>> config option to make port(1) behave that way would be OK too. >> >> We have broken the backwards compatibility of the port command multiple >> times already by changing strings and its output formats. We don't make >> any guarantees for that, do we? > > No, but changing a command that never asked for user input to now do so > is a much bigger change. You can't even just run something and check the > exit code then. Well, yes you can, it will just ask for user input. Also, I think the majority of situations described in the [wiki](https://trac.macports.org/wiki/SummerOfCode2014_interactive) are not actions usually done in scripts IMO. > >> If you redirect the command output or it is not connected to a terminal, >> port(1) will automatically behave non-interactively as it did before. > > OK, that's not as bad. But does that prevent the use of tools like expect? If that’s implemented, I think it’s fine. > >> Maybe we should also have an option in macports.conf to force >> non-interactive mode? > > A different executable name for interactive operation is simpler. Yeah, but that way the user will have to learn and use a new command name and update his/her aliases to use the interactive command. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
port wrapper, take 2
Hello everyone! I created a port wrapper for my use, this time in ZSH. Feel free to check it out, I think it has some nice things and should ease the menial tasks like updating a port, diffing, commiting and so on. You can find it here: https://github.com/g5pw/port-wrapper Once it stabilizes a bit, I could even write a port for it :D -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New committers: petr, ctreleaven, juanrgar
On 25/giu/2014, at 17:03, Bradley Giesbrecht wrote: >> Please join us in welcoming the following new MacPorts committers: >> >> - Peter Danecek (petr) >> - Craig Treleaven (ctreleaven) >> - Juan R. Garcia Blanco (juanrgar) Welcome everyone! I’m sure you’ll have fun :) -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: "ticket" port command?!
On 13/mag/2014, at 06:10, Ryan Schmidt wrote: > > On May 11, 2014, at 13:49, mk-macpo...@techno.ms wrote: > >> 1) Something like >> — >> $ port ticket foo >> — >> could open up the web browser and show all trac tickets for port foo. > > I've been using a shell function to do this for years. Is it in contrib/? I’d like to take a look at it! -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [111229] trunk/dports/net/prosody/Portfile
On 17/set/2013, at 20:17, Ryan Schmidt wrote:
>
> On Sep 17, 2013, at 08:09, g...@macports.org wrote:
>
>> Revision: 111229
>> https://trac.macports.org/changeset/111229
>> Author: g...@macports.org
>> Date: 2013-09-17 06:09:12 -0700 (Tue, 17 Sep 2013)
>> Log Message:
>> ---
>> net/prosody:
>> ensure we are UsingTheRightCompiler and actually support universal build
>>
>> Modified Paths:
>> --
>> trunk/dports/net/prosody/Portfile
>>
>> Modified: trunk/dports/net/prosody/Portfile
>> ===
>> --- trunk/dports/net/prosody/Portfile2013-09-17 06:23:52 UTC (rev
>> 111228)
>> +++ trunk/dports/net/prosody/Portfile2013-09-17 13:09:12 UTC (rev
>> 111229)
>> @@ -5,6 +5,7 @@
>>
>> nameprosody
>> version 0.9.1
>> +revision1
>> maintainers g5pw openmaintainer
>>
>> categories net chat
>> @@ -30,9 +31,18 @@
>> checksums rmd160 95d5e12c4ca2a2e292a2baa7271f949f1743c02b \
>>sha256
>> 6cdea6fd6027bec621f7995709ca825a29aa5e066b321bfbb7785925c9f32cd5
>>
>> +configure.cflags-append -fPIC
>> +configure.ldflags-append -bundle -undefined dynamic_lookup
>> +
>> configure.args-append \
>>--ostype=macosx \
>> ---with-lua-include=${prefix}/include
>> +--with-lua=${prefix} \
>> +--with-lua-include=${prefix}/include \
>> +--with-lua-lib=${prefix}/lib \
>> +--c-compiler=${configure.cc} \
>> +--linker=${configure.cc} \
>> +--cflags=\"${configure.cflags}\" \
>> +--ldflags=\"${configure.ldflags}\"
>
> These changes don't appear to relate to supporting a universal build. And:
>
Thanks, I forgot to add archflags.
>
> $ sudo port install prosody +universal
> ---> Computing dependencies for prosody
> Error: Cannot install prosody for the arch(s) 'i386 x86_64' because
> Error: its dependency lua-luasocket does not build for the required arch(s)
> by default
> Error: and does not have a universal variant.
> Error: Unable to execute port: architecture mismatch
I see. Then what should I do?
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [107726] trunk/dports/sysutils/john/Portfile
On 04/lug/2013, at 20:39, Ryan Schmidt wrote:
>
> On Jul 4, 2013, at 12:59, g...@macports.org wrote:
>
>> Revision: 107726
>> https://trac.macports.org/changeset/107726
>> Author: g...@macports.org
>> Date: 2013-07-04 10:59:51 -0700 (Thu, 04 Jul 2013)
>> Log Message:
>> ---
>> sysutils/john:
>> use xz instead of gz
>>
>> Modified Paths:
>> --
>> trunk/dports/sysutils/john/Portfile
>>
>> Modified: trunk/dports/sysutils/john/Portfile
>> ===
>> --- trunk/dports/sysutils/john/Portfile 2013-07-04 17:56:33 UTC (rev
>> 107725)
>> +++ trunk/dports/sysutils/john/Portfile 2013-07-04 17:59:51 UTC (rev
>> 107726)
>> @@ -19,6 +19,8 @@
>> platforms darwin
>> master_siteshttp://www.openwall.com/${name}/j/
>>
>> +use_xz yes
>> +
>> checksums rmd160 5c0f8b90a5567321d263c4fcbf24447142c7b89d \
>>sha256
>> 1222738c7829ce3014177ca9bd26c41573426f883c6b22527ee9bde363d84bda
>
> But surely then the checksums have to change?
Yes, of course, what was I thinking. Done in r107736.
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [107714] trunk/dports/sysutils/john/Portfile
On 04/lug/2013, at 19:49, Ryan Schmidt wrote: > On Jul 4, 2013, at 12:46, Aljaž Srebrnič wrote: > >> On 04/lug/2013, at 19:29, Ryan Schmidt wrote: >> >>> >>> On Jul 4, 2013, at 10:53, g...@macports.org wrote: >>> >>> >>> Why switch from bz2 to gz (which is larger) and not to xz (which is >>> smaller)? >> >> Looks like upstream switched (see homepage http://www.openwall.com/john/). > > …Right, upstream switched from providing gz and bz2 to providing gz and xz, > and I'm wondering why you switched from bz2 to gz instead of to xz. Heh, brain went into default mode :) Fixed in r107726, thanks. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [107714] trunk/dports/sysutils/john/Portfile
On 04/lug/2013, at 19:29, Ryan Schmidt wrote: > > On Jul 4, 2013, at 10:53, g...@macports.org wrote: > >> Revision: 107714 >> https://trac.macports.org/changeset/107714 >> Author: g...@macports.org >> Date: 2013-07-04 08:53:27 -0700 (Thu, 04 Jul 2013) >> Log Message: >> --- >> sysutils/john: >> bump to 1.8.0 >> update master_sites (the mirrors didn't have john 1.8.0) >> use .tar.gz >> add john-jumbo subport to compile the jumbo version >> >> Modified Paths: >> -- >> trunk/dports/sysutils/john/Portfile > > Why switch from bz2 to gz (which is larger) and not to xz (which is smaller)? Looks like upstream switched (see homepage http://www.openwall.com/john/). -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [107347] trunk/dports/finance
On 26/giu/2013, at 22:24, mk-macpo...@techno.ms wrote: > On Jun 26, 2013, at 10:01 AM, Aljaž Srebrnič wrote: >> You probably need to do a :retab in vim. See :h retab. > > Thanks, Aljaž, for the hint. I did so and committed the changes. > :-) > > Wasn't aware of that command, although I use vi since 20 years every now and > then. ;-) I actually stumbled upon it for just the same reason (vim was not adhering to the modeline) Another hint, if you are using mpvim: setting let g:portfile_highlight_space_errors=1 in your vimrc will highlight mixed tab/space (or just all tabs? I usually use spaces) and trailing whitespace. > Greets, > Marko > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [107347] trunk/dports/finance
On 26/giu/2013, at 18:21, Lawrence Velázquez wrote: > On Jun 26, 2013, at 3:14 AM, Ryan Schmidt wrote: > >> On Jun 26, 2013, at 01:42, mk-macpo...@techno.ms wrote: >> >>> On Jun 26, 2013, at 5:53 AM, Ryan Schmidt wrote: >>> That is strange, since I was using vi to edit this port file. >>> Any idea what I could to force vi to conform to these settings when saving >>> the file? >> >> I am not sure! I don't know how vi handles modelines or whitespace. I just >> noticed that the formatting of the commit email was strange, and when I >> opened the Portfile in my editor, I saw the mix of tabs and spaces. > > I think modelines are only checked when you open a file. The easiest thing to > do when creating a new port is probably to save it with just the modeline and > then reopen it. That is correct. However, you just need to do a :e % to reread the file, no need to relaunch vim! Also, modeline is not automatically applied (vim won't convert tabs to spaces to adhere to the modeline by itself); you need to issue a :retab command. > > vq > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [106691] trunk/dports/devel/coccinelle/Portfile
On 06/giu/2013, at 08:19, Ryan Schmidt wrote:
> On Jun 5, 2013, at 02:55, g...@macports.org wrote:
>
>> Revision: 106691
>> https://trac.macports.org/changeset/106691
>> Author: g...@macports.org
>> Date: 2013-06-05 00:55:54 -0700 (Wed, 05 Jun 2013)
>> Log Message:
>> ---
>> devel/coccinelle:
>> fix homepage (I like it better without the slash at the end)
>> add some dependencies and explicitly enable them
>> add variant for pcre
>> fix python variants
>>
>> Modified Paths:
>> --
>> trunk/dports/devel/coccinelle/Portfile
>>
>> Modified: trunk/dports/devel/coccinelle/Portfile
>> ===
>> --- trunk/dports/devel/coccinelle/Portfile 2013-06-05 07:17:42 UTC (rev
>> 106690)
>> +++ trunk/dports/devel/coccinelle/Portfile 2013-06-05 07:55:54 UTC (rev
>> 106691)
>> @@ -5,6 +5,7 @@
>>
>> namecoccinelle
>> version 1.0.0-rc17
>> +revision1
>> license GPL-2
>> maintainers g5pw openmaintainer
>>
>> @@ -16,12 +17,14 @@
>>
>> platforms darwin
>>
>> -homepagehttp://coccinelle.lip6.fr/
>> +homepagehttp://coccinelle.lip6.fr
>>
>> depends_lib port:ocaml \
>>port:ocaml-findlib \
>> +port:ocaml-menhir \
>> +port:ocaml-pcre
>
>
>> +variant pcre description {Enable PCRE support} {
>> +configure.args-delete --disable-pcre
>> +configure.args-append --enable-pcre
>> +
>> +depends_lib port:pcre
>> +}
>
> You should append to depends_lib, not overwrite it.
>
> However, ocaml-pcre already depends on pcre, so why not enable pcre support
> always, since it wouldn't add any additional dependencies?
Good catch, I actually got a little mixed up… fixed in r106724!
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [104039] trunk/dports/python/py-scikit-image
I saw the build failure and just found the bug when I saw your commit. Also,
nice catch about the py33-scipy. Is there any reason python33 is not supported
for scipy?
On 13/mar/2013, at 18:35, strom...@macports.org wrote:
> Revision
> 104039
> Author
> strom...@macports.org
> Date
> 2013-03-13 10:35:41 -0700 (Wed, 13 Mar 2013)
> Log Message
>
> py-scikit-image: add cython support, drop py33 variant (py33-scipy not
> available for now), bump revision
> Modified Paths
>
> trunk/dports/python/py-scikit-image/Portfile
> Added Paths
>
> trunk/dports/python/py-scikit-image/files/
> trunk/dports/python/py-scikit-image/files/patch-skimage__build.py.diff
> Diff
>
> Modified: trunk/dports/python/py-scikit-image/Portfile (104038 => 104039)
>
> --- trunk/dports/python/py-scikit-image/Portfile 2013-03-13 16:22:16 UTC
> (rev 104038)
> +++ trunk/dports/python/py-scikit-image/Portfile 2013-03-13 17:35:41 UTC
> (rev 104039)
> @@ -1,4 +1,4 @@
> -# -*- coding: utf-8; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4
> -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> # $Id$
>
> PortSystem 1.0
> @@ -7,10 +7,13 @@
>
> github.setupscikit-image scikit-image 0.8.2 v
> namepy-${name}
> +revision1
> categories-append science
> +platforms darwin
> license BSD
> -platforms darwin
>
> +python.versions 26 27 32
> +
> maintainers stromnov openmaintainer
>
> description Image processing algorithms for SciPy.
> @@ -24,15 +27,21 @@
> checksums rmd160 a759f6a55c8556f9677b7d67d0bad3c69a385c4e \
> sha256
> 158e77a2f1169caf8ee48c0b8f0e0263a3a3e93636a7805dda5457e6006ea42d
>
> -python.default_version 27
> -python.versions 26 27 32 33
> +if {$subport != $name} {
> +patchfiles patch-skimage__build.py.diff
>
> -if {$subport != $name} {
> +depends_build-append \
> +port:py${python.version}-cython
> +
> depends_lib-append port:py${python.version}-distribute \
> -port:py${python.version}-cython \
> port:py${python.version}-numpy
>
> -depends_run port:py${python.version}-scipy
> +depends_run-append port:py${python.version}-scipy
>
> +post-patch {
> +reinplace "s|@prefix@|${prefix}|g" ${worksrcpath}/skimage/_build.py
> +reinplace "s|@python.branch@|${python.branch}|g"
> ${worksrcpath}/skimage/_build.py
> +}
> +
> livecheck.type none
> }
> Added: trunk/dports/python/py-scikit-image/files/patch-skimage__build.py.diff
> (0 => 104039)
>
> --- trunk/dports/python/py-scikit-image/files/patch-skimage__build.py.diff
> (rev 0)
> +++ trunk/dports/python/py-scikit-image/files/patch-skimage__build.py.diff
> 2013-03-13 17:35:41 UTC (rev 104039)
> @@ -0,0 +1,16 @@
> +--- skimage/_build.py.orig 2013-03-07 02:12:35.0 +0400
> skimage/_build.py2013-03-13 21:18:21.0 +0400
> +@@ -41,11 +41,11 @@
> + c_file = pyxfile[:-4] + '.c'
> +
> + # run cython compiler
> +-cmd = 'cython -o %s %s' % (c_file, pyxfile)
> ++cmd = '@prefix@/bin/cython-@python.branch@ -o %s %s' % (c_file,
> pyxfile)
> + print(cmd)
> +
> + try:
> +-subprocess.call(['cython', '-o', c_file, pyxfile])
> ++subprocess.call(['@prefix@/bin/cython-@python.branch@',
> '-o', c_file, pyxfile])
> + except WindowsError:
> + # On Windows cython.exe may be missing if Cython was
> installed
> + # via distutils. Run the cython.py script instead.
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Conflict between gtk2 and pangox-compat
Hello!
I recently tried to update gtk2, but it gave the error that pango must be
installed with -x11. The thing is, I did install pango without the x11 variant.
Going through the gtk2 portfile I noticed that it checks on a lib file to
determine installed variants. The file ($prefix/lib/libpangox-1.0.0.dylib) is
provided by pangox-compat!
I refactored the gtk2 portfile to use active_variants instead, but, learning
from my mistakes, I'm inlining the diff. If it's OK to you I'll commit it.
Here it is:
Index: Portfile
===
--- Portfile(revision 102964)
+++ Portfile(working copy)
@@ -4,6 +4,7 @@
PortSystem 1.0
PortGroup muniversal 1.0
PortGroup xcodeversion 1.0
+PortGroup active_variants 1.1
namegtk2
version 2.24.15
@@ -73,11 +74,7 @@
}
if {[variant_isset quartz]} {
-if {![file exists ${prefix}/include/cairo/cairo-quartz.h]} {
-error "cairo must be built with the +quartz variant enabled."
-}
-} elseif {![file exists ${prefix}/include/cairo/cairo-xlib.h]} {
-error "cairo must be built without the +no_x11 variant."
+require_active_variants cairo quartz x11
}
}
@@ -193,12 +190,7 @@
}
variant no_x11 description {Disable X11 support} {
-pre-fetch {
-if {[file exists ${prefix}/lib/libpangox-1.0.dylib]} {
-ui_error "Please install pango without the x11 variant, by running
'port install pango -x11'."
-error "pango must be installed with the x11 variant disabled"
-}
-}
+require_active_variants pango "" x11
}
variant quartz requires no_x11 conflicts x11 {
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [102707] trunk/dports/graphics
On 07/feb/2013, at 19:23, Ryan Schmidt wrote:
> On Feb 7, 2013, at 07:32, g...@macports.org wrote:
>
>> Revision: 102707
>> https://trac.macports.org/changeset/102707
>> Author: g...@macports.org
>> Date: 2013-02-07 05:32:37 -0800 (Thu, 07 Feb 2013)
>> Log Message:
>> ---
>> graphics/tiv:
>> new port, Terminal Image Viewer
>>
>> Added Paths:
>> ---
>> trunk/dports/graphics/tiv/
>> trunk/dports/graphics/tiv/Portfile
>
>
>> +use_configure no
>> +
>> +pre-build {
>> +build.args CC=${configure.cc} \
>> +CXX=${configure.cxx}
>> +}
>
> FYI this doesn't need to be in a pre-build block, since these variables
> aren't being affected by variants elsewhere in the port.
I thought so, too, but I found that snippet somewhere in the wiki… :/
>
> But you should use [get_canonical_archflags]. And you might be able to set a
> universal variant before that.
Aha, I'll try!
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [102708] trunk/dports/databases/tcl-sqlite3/Portfile
On 07/feb/2013, at 18:57, Ryan Schmidt wrote:
>
> On Feb 7, 2013, at 07:37, g...@macports.org wrote:
>
>> Revision: 102708
>> https://trac.macports.org/changeset/102708
>> Author: g...@macports.org
>> Date: 2013-02-07 05:37:31 -0800 (Thu, 07 Feb 2013)
>> Log Message:
>> ---
>> databases/tcl-sqlite3:
>> Fix port-destroot failure. Not revbumping since port didn't build correctly.
>>
>> Modified Paths:
>> --
>> trunk/dports/databases/tcl-sqlite3/Portfile
>>
>> Modified: trunk/dports/databases/tcl-sqlite3/Portfile
>> ===
>> --- trunk/dports/databases/tcl-sqlite3/Portfile 2013-02-07 13:32:37 UTC
>> (rev 102707)
>> +++ trunk/dports/databases/tcl-sqlite3/Portfile 2013-02-07 13:37:31 UTC
>> (rev 102708)
>> @@ -51,7 +51,7 @@
>> post-destroot {
>># Make sure the correct version is used, not sure why this is
>># necessary.
>> -reinplace "s|3.6|${version}|g"
>> ${destroot}${prefix}/lib/tcl8.5/sqlite3/pkgIndex.tcl
>> +reinplace "s|3.6|${version}|g"
>> ${destroot}${prefix}/lib/tcl8.6/sqlite3/pkgIndex.tcl
>># Delete all normal SQLite 3 files, they are installed by the sqlite3
>># port.
>>file delete -force ${destroot}${prefix}/bin
>
> You should revbump, because the port probably did build correctly the last
> time it was modified, when we actually did have tcl 8.5 in MacPorts. This
> port has not yet received a revbump since tcl 8.6 was updated; probably most
> ports that depend on tcl will need one.
Aha, you're right!
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Double port: scapy
On 16/gen/2013, at 16:48, Rainer Müller wrote:
> On 2013-01-16 16:20, Aljaž Srebrnič wrote:
>> Hello list,
>> I just noticed that we have two ports for scapy, one named scapy and the
>> other named py26-scapy. Should we:
>> - create a unified portfile named py-scapy
>> - delete py26-scapy
>> - mark scapy replaced_by py27-scapy (since scapy is based on python27 at
>> the moment)
>> or:
>> -mark py26-scapy replaced_by scapy
>>
>> I personally like the second alternative, since it's an application and
>> not just a module (it installs a script in ${prefix}/bin), but looking
>> at ports like ipython and simpy, maybe the first is preferable.
>
> I'm with you and would prefer the second alternative for such tools.
Great! :)
>
> ipython is a little bit different since you might want to use the
> interactive shell for a specific version of python and there is a
> benefit of having these different versions installed in parallel.
> py*-ipython also supports 'port select'.
>
> I don't know simpy, but it does not look like there is any tool in this
> port – at least no files ends up at bin/*. The included SimGUI.py seems
> to be a basic example only and is marked deprecated. So that's okay to
> be ported as py*-simpy.
Hah, sorry, I meant sympy, I always mistype that!
Ok, so, if no one disagrees, I'm obsoleting py26-scapy in favor of scapy.
>
> Rainer
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ROOT Update Ticket
On 15/gen/2013, at 21:18, Chris Jones wrote: > Hi, > > On 15 Jan 2013, at 8:01pm, Aljaž Srebrnič wrote: > >> On 15/gen/2013, at 20:55, Chris Jones wrote: >> >> Yeah, honestly I don't even remember why I enabled all of them. :D I enabled >> qt4_mac to test it out, so I wouldn't have x11 start up all the time… > > Yeah… that doesn't quite work as expected - you still use the X11 backend > even with qt4_mac support (go figure… partly why I don't really place much > hold in this variant). The cocoa variant on the other hand is newer and gives > real native OSX GUI support, and does work well for me. X11 is really not > used (although again for perverse reasons the build/install dependency is > still there at the moment. Hopefully will be fixed some time …). > > I cannot though reproduce your failure. The variant combination > > macmini ~ > sudo port install root +avahi +cocoa +fftw3 +fitsio +mysql55 > +postgresql92 +pythia +python32 +qt_mac +ruby +clang31 > > giving > >> --> Activating root >> @5.34.04_0+avahi+clang31+cocoa+fftw3+fitsio+graphviz+gsl+minuit2+mysql55+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+ssl+tmva+xml > > just worked find for me…. > > Can you reproduce the failure you had ? Pah, go figure! I just now successfully compiled with default variants. Will re-test with old variants, and if it checks out I'll commit it right away :) >> >> I really hope +cocoa works! By the way, do you know when will be added the >> support for cling? > > cocoa works fine for me…. > > I also am keen to get cling working, but this is still very very experimental > and I haven't managed it yet. I test the variant each time but so far it > still fails …. I suspect this may not be a viable alternative until ROOT 6 is > released, but we can hope… Let's hope, I was super hyped when I read the announcement! > > cheers Chris >> -- >> Aljaž Srebrnič a.k.a g5pw >> My public key: http://bit.ly/g5pw_pubkey -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ROOT Update Ticket
On 15/gen/2013, at 20:55, Chris Jones wrote: > > On 15 Jan 2013, at 7:46pm, Aljaž Srebrnič wrote: > >> On 15/gen/2013, at 20:45, Chris Jones wrote: >> >>> Hi, >>> >>> >>> OK… so is that all of them ;) >> >> When I build, I build all-in ;) > > Fair enough in general. ROOT though has a hell of a lot of variants, and some > are provide as is, in that I know they give troubles in some cases but I keep > them neverless. qt4_mac is one in particular. It has never worked that well > for me, and I tried to remove it a while back, but added it back when I found > some users actually found it OK…. Yeah, honestly I don't even remember why I enabled all of them. :D I enabled qt4_mac to test it out, so I wouldn't have x11 start up all the time... > >> >>> >>> Please first try the default set of variants, then add them back. In >>> particular try without using clang31 which forces the use of MacPorts clang >>> 3.1 compiler… >> >> will try the default set first! Let's see which variant fails. > > I will test things myself. My bet is it is one of cocoa, clang31 or qt4_mac > that is causing the issue… I really hope +cocoa works! By the way, do you know when will be added the support for cling? > > Chris > >> >>> >>> I'll try myself, as I may not have tried that particular combinations of >>> variants …. >>> >>> cheers Chris >>> >> >> >> >> -- >> Aljaž Srebrnič a.k.a g5pw >> My public key: http://bit.ly/g5pw_pubkey -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ROOT Update Ticket
On 15/gen/2013, at 20:39, Chris Jones wrote: > > On 15 Jan 2013, at 7:32pm, Aljaž Srebrnič wrote: > >> On 15/gen/2013, at 18:56, Chris Jones wrote: >> >>> Hi, >>> >>> Could a commuter take a look at >>> >>> https://trac.macports.org/ticket/37643 >>> >>> ? Normally I wouldn't send an email so soon after committing, but it turns >>> out this update fixes a 'seg. fault on quit' bug 5.34.03 suffered from, so >>> it would be good to get it out. >> >> I tested it, however the build failed, I'll attach the logs to the ticket. > > I don't see any new comments on trace ? Could you check you actually attached > them ? Nope, I built root this morning but I deleted the logs; I'm building now, will attach as soon as it finishes. > Builds fine for me on 10.8 + Xcode 4.5.2 …. What platform / variants / Xcode > did you use ? I'm on Mountain Lion, Xcode 4.5.2, variants are +avahi+clang31+cocoa+fftw3+fitsio+graphviz+gsl+ldap+minuit2+mysql55+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+ssl+tmva+xml > > Chris -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101588] trunk/dports/devel/pcre/Portfile
But I like mpvim! :( On 14/gen/2013, at 10:50, lar...@macports.org wrote: > Revision > 101588 > Author > lar...@macports.org > Date > 2013-01-14 01:50:22 -0800 (Mon, 14 Jan 2013) > Log Message > > pcre: Take maintainership; fix modeline, which required mpvim. > Modified Paths > > trunk/dports/devel/pcre/Portfile > Diff > > Modified: trunk/dports/devel/pcre/Portfile (101587 => 101588) > > --- trunk/dports/devel/pcre/Portfile 2013-01-14 09:23:29 UTC (rev 101587) > +++ trunk/dports/devel/pcre/Portfile 2013-01-14 09:50:22 UTC (rev 101588) > @@ -1,4 +1,4 @@ > -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; > c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=portfile:et:sw=4:ts=4:sts=4 > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; > c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > PortSystem 1.0 > @@ -8,7 +8,7 @@ > categories devel > license BSD > platforms darwin freebsd > -maintainers nomaintainer > +maintainers larryv > description Perl Compatible Regular Expressions Library > > long_description \ > ___ > macports-changes mailing list > macports-chan...@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mass rebuild for tcl/tk 8.6
On 11/gen/2013, at 15:25, Jack Howarth wrote: > I don't recall seeing a discussion in macports-dev regarding the transition > from the tcl/tk 8.5 to 8.6 series. Also are there any plans for a coordinated > rebuild of all of the packages that require tcl or tk? Do we know of any linux > distributions which have migrated to the new tcl/tk release yet? We should try > to identify one if possible in order to avoid duplicating efforts in porting > packages to the new tcl/tk. > Jack Hello! I'm afraid I am responsible for this, I updated the tcl port without weighting all the consequences. So we decided to stick to 8.6 and fix problems as they present. I've sen that in most cases a -DUSE_INTERP_RESULT solves the majority of problems. Ports still need to be revbumped though. > ps So far the main blocker in my packages is ccpnmr. It rebuilds without error > under the new tcl/tk but crashes with an X windows rendering error (which I'll > have to repost later). However I am unclear if this bug is in tcl/tk or due to > recent mesa changes. The ccpnmr crash in the analysis program only occurs when > a NMR spectrum is displayed. Post the bug and I'll gladly take a look! > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Unified Python portgroup
On 10/gen/2013, at 09:57, Freek Dijkstra wrote:
> Hi all,
>
> Is there any documentation for the unified Python portgroup? The guide
> does not yet mention it, and searching the mailing list only resulted in
> one thread.
I don't think there's a guide other than peering through the portgroup, located
(usually) in
${prefix}/var/macports/sources/rsync.macports.org/dports/_resources/port1.0/group/
>
> I submitted a Portfile for py27-pdfrw, and was asked to modify it to use
> the unified python 1.0 portgroup. I'm happy to do so, but when I tried I
> got the following error:
>
>> [root@lampje] Code/macports/py-pdfrw# port -d install
>> DEBUG: Copying /Users/freek/Library/Preferences/com.apple.dt.Xcode.plist to
>> /opt/local/var/macports/home/Library/Preferences
>> DEBUG: Changing to port directory: /Users/freek/Code/macports/py-pdfrw
>> DEBUG: OS darwin/11.4.2 (Mac OS X 10.7) arch i386
>> [...]
>> DEBUG: Searching for dependency: py27-pdfrw
>> DEBUG: Didn't find receipt, going to depspec regex for: py27-pdfrw
>> Error: Dependency 'py27-pdfrw' not found.
That is actually not a bug! You're trying to install it directly from the
directory, which is equivalent to running `port -d install py-pdfrw`. Now,
since you didn't provide a py24-* subport, the behaviour defined in the python
portgroup for running install without specifying a version (as opposed to
specifying it, like `port install py26-pdfrw`) is to specify a dependency on
the 27 version of the port (py27-pdfrw).
Since you run it from the directory I think you either don't have another port
index or it is not updated, so MacPorts doesn't know where to find py27-pdfrw!
>
> The Portgroup can be found at
> http://trac.macports.org/attachment/ticket/37570/Portfile-unified-attempt
>
> I have the distinct feeling I'm overlooking something really obvious here.
>
> If anyone cares to point me at my silliness, I surely appreciate that :)
>
> Thanks,
> Freek
> _______
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101250] users/g5pw/dports/python
On 08/gen/2013, at 02:06, Ryan Schmidt wrote:
>
> On Jan 7, 2013, at 04:47, g...@macports.org wrote:
>
>> Revision: 101250
>> https://trac.macports.org/changeset/101250
>> Author: g...@macports.org
>> Date: 2013-01-07 02:47:53 -0800 (Mon, 07 Jan 2013)
>> Log Message:
>> ---
>> python/py-pyobjc{,-core}:
>> rename py-pyobjc to py-pyobjc-core, unify both ports
>> update to 2.4
>
>
>> --- users/g5pw/dports/python/py-pyobjc/Portfile 2013-01-07 07:06:23 UTC
>> (rev 101249)
>> +++ users/g5pw/dports/python/py-pyobjc/Portfile 2013-01-07 10:47:53 UTC
>> (rev 101250)
>> @@ -2,16 +2,19 @@
>> # $Id$
>>
>> PortSystem 1.0
>> -PortGroup python24 1.0
>> +PortGroup python 1.0
>>
>> namepy-pyobjc
>> +replaced_by py-pyobjc-core
>> version 1.4
>> +revision1
>> +python.versions 25 26 27 32
>
> You will need to manually and individually handle replacement of each of the
> old ports. For an example see the py-scikits-umfpack port. There's probably
> no need to include the python portgroup (or any portgroup other than the
> "obsolete" portgroup if desired) in replaced ports.
Yeah, I thought it won't work...
>
>
>> --- users/g5pw/dports/python/py-pyobjc-core/Portfile
>> (rev 0)
>> +++ users/g5pw/dports/python/py-pyobjc-core/Portfile 2013-01-07 10:47:53 UTC
>> (rev 101250)
>> @@ -0,0 +1,50 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +PortGroup python 1.0
>> +
>> +set my_name pyobjc-core
>> +name py-${my_name}
>> +version 2.4
>> +python.versions 26 27 32 33
>
> So there is no upgrade path for py-pyobjc (the current python 2.4 port) or
> py25-pyobjc?
Well, what about rendering the py24- (and maybe the py25-,too) completely
obsolete...
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100560] trunk/dports/devel/class-dump/Portfile
Thanks landonf, that got buried in my todo list!
On 15/dic/2012, at 16:13, land...@macports.org wrote:
> Revision
> 100560
> Author
> land...@macports.org
> Date
> 2012-12-15 07:13:02 -0800 (Sat, 15 Dec 2012)
> Log Message
>
> Fix build on Mac OS X 10.7; the build must be done against the 10.8 SDK. The
> 3.4 release of class-dump also bumps the minimum supported OS version to 10.7.
> Modified Paths
>
> trunk/dports/devel/class-dump/Portfile
> Diff
>
> Modified: trunk/dports/devel/class-dump/Portfile (100559 => 100560)
>
> --- trunk/dports/devel/class-dump/Portfile2012-12-15 14:10:44 UTC (rev
> 100559)
> +++ trunk/dports/devel/class-dump/Portfile2012-12-15 15:13:02 UTC (rev
> 100560)
> @@ -23,14 +23,18 @@
>
> worksrcdir ${distname}/src
>
> +# 3.4+ must be built against the 10.8 SDK, as it requires LC_* constants
> +# and other definitions unavailable in earlier SDKs. It will, however,
> +# run against 10.7+.
> +configure.sdkroot "[exec xcode-select
> -print-path]/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk"
> xcode.targetall
>
> xcode.configuration Release
> xcode.destroot.path ${prefix}/bin
>
> -if {${os.major} < 9} {
> +if {${os.major} < 11} {
> pre-fetch {
> -return -code error "$name requires Mac OS X 10.5 or later."
> +return -code error "$name requires Mac OS X 10.7 or later."
> }
> }
>
> _______
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: python24-26 policy
On 09/dic/2012, at 16:09, Rainer Müller wrote: > On 2012-12-09 05:12, Ryan Schmidt wrote: >> On Dec 8, 2012, at 17:53, Joshua Root wrote: >>> With the unified portgroup there's almost no extra effort involved >>> in having them. I don't think there's any reason to drop them >>> until upstream does. >> >> Users unfamiliar with the intricacies of the python ports in MacPorts >> may (and do) install "py-foo" and receive "py24-foo", and either >> assume that's the best we have to offer, or just run into problems >> because python 2.4 is old. We should be encouraging the use of python >> 2.7. Removing the python 24 subports from unified ports would >> facilitate that. > > +1 > > Fewer versions reduce confusion for users. I like the idea of reducing ports, too. > > This is especially a problem as other ports implement a different way to > select the version for modules/libraries. For python, the default for > py-foo is always py24-foo. For perl, requesting p5-foo installs the > p5.XY-foo depending on the +perl5.XY variant of the perl5 port. With > ruby, rb-foo refers to ruby 1.8 and rb19-foo to ruby 1.9, while no > rb18-foo exists at all. > > I am not saying that the ways perl or ruby handle this are any better, > but it's confusing that this there is not one unique way to handle all this. we should just discuss and decide what's the better option for this. It _is_ quite confusing! > >> If all the python modules were using the unified portgroup and had >> been doing so for awhile, we could just remove the py24 default in >> the portgroup, which was only there to help users upgrade from the >> pre-unified ports. But we still have many ports that are not >> unified. > > While we have some ports that still depend on py-*, these are mostly > other non-unified python modules targeting python24. There are also > dependencies on ports that provide support for features merged into > later versions of python (for example py-bsddb, py-ctypes), these would > no longer be necessary when getting rid of python24. I'd like to start gradually removing at least py24-* ports from the repo. I highly doubt there's any demand for older versions, and even if there is some demand, those users should create their repository, checking out the older ports from svn. > > Rainer > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: py-gtk unified
On 08/dic/2012, at 02:30, Ryan Schmidt wrote:
> On Dec 7, 2012, at 18:08, Aljaž Srebrnič wrote:
>
>> On 08/dic/2012, at 00:32, Ryan Schmidt wrote:
>>
>>> On Dec 7, 2012, at 09:23, Aljaž Srebrnič wrote:
>>>
>>>
>>> Bear in mind that we also have a gtk3 port already. Does pygtk support
>>> gtk3, or will it? If so, we should think about how we plan to handle that.
>>> (Separate py-gtk3 port? Subports? Variants?)
>>
>> Fortunately, py-gtk won't support gtk3, there is another module for gtk3
>> named pyGObject [1].
>>
>> [1] -
>> http://stackoverflow.com/questions/5920049/learning-gui-programming-with-gtk2-or-gtk3
>
> Ok, that's good to know.
>
> I assume the reason why the py25 thru py27 ports are called gtk not gtk2 is
> that the module name is pygtk not pygtk2. There was a recent push to make
> sure the entire module name appears in the port name; under that theory, the
> port should be called py-pygtk.
Fine by me!
>
> Whatever you change the name to, all ports depending on pygtk will have to
> have their dependencies updated and their revisions increased.
>
>
>> I'm attaching the actial diff, if anyone want to take a look before I commit.
>>
>
> You can leave out "python.default_version 27"; that is the default, when "24"
> is not in python.versions.
>
> The dependencies should go inside the "if {${name} != ${subport}}" block,
> since the stub port does not actually depend on those other ports. The
> "use_configure yes" command also needs to go in that block, since its
> presence globally will cause the stub port to fail. The build and destroot
> changes could also go in that block since the stub port does not actually
> build or destroot anything, though having them set globally does not seem to
> cause problems, and there is precedent for keeping them global, since we
> habitually set master_sites and checksums outside that block, even though the
> stub port does not fetch any files.
>
> The active_variants 1.1 portgroup should be used, with which you no longer
> need to put the require_active_variants in a pre-configure block manually.
Yes, I wrote that portfile before the active_variants update :)
Great! so I'll commit everything and edit+revbump the dependencies :)
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100265] trunk/dports/python
On 06/dic/2012, at 13:39, Ryan Schmidt wrote: > > On Dec 6, 2012, at 06:06, Aljaž Srebrnič wrote: > >> On 06/dic/2012, at 12:11, Ryan Schmidt wrote: >> >>> On Dec 6, 2012, at 05:06, Ryan Schmidt wrote: >>> >>> >>> Actually there is something that depends on py-cairo: py-gtk2. So that port >>> will have to be deleted. >>> >>> And py-gtkmvc depends on py-gtk2. So that'll have to be deleted. Nothing >>> depends on py-gtkmvc. >>> >>> And diffuse has a python24 variant which depends on py-gtk2. So that >>> variant will have to be deleted. >>> >>> Unless you want to add "24" to python.versions in py-cairo and delete >>> "python.default_version 27", and then change the aforementioned >>> dependencies from py-cairo to py24-cairo. But I'd rather proceed with >>> getting rid of python 2.4 things wherever we can. >> >> By the way, should I just svn rm it or deprecate it? > > "deprecated" means usable but not recommended, but because a python 2.4 > version of py-cairo does not exist anymore, they're not actually usable > anymore. Understood. > > For py-gtk2, the most helpful would be if it could be turned into a unified > port too. It's a bit unusual in that the other ports in the set are py25-gtk, > py26-gtk and py27-gtk (not *-gtk2). So the new unified port would be py-gtk2. > And in that case you might leave py-gtk2 around, marked as replaced_by > py27-gtk. I'll give it a try! I like the py-gtk2 port name, but that would mean marking all the py2*-gtk ports replaced_by py2-*gtk2... > > You could try unifying py-gtkmvc too and updating it to the newest version, > but since only a Python 2.4 version exists now, and nothing depends on it, > and the port hasn't been updated since January 2005, that suggests nobody > uses this port, so you could also just "svn rm" it. Agreed. > > After you delete the python24 variant of diffuse, anyone requesting that > variant will instead get the default python27 variant. Anyone already having > the port installed with +python24 will keep it, and it won't work anymore > since the python 2.4 versions of the dependencies won't exist anymore. To > avoid that you could increase the port's revision. But that would be an > unnecessary rebuild for anyone with any of the other variants. So I'm > inclined to recommend not increasing the revision, and just leaving any > python24 stragglers to find out that they need to rebuild; it'll fix itself > when the next version of diffuse is released and the port is updated. I agree with you, if something happenes we can always file a bug with the instructions to rebuild the port... -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: automatically put require_active_variants in pre-configure Was: Re: [100265] trunk/dports/python
On 06/dic/2012, at 14:25, Clemens Lang wrote: > On Thu, Dec 06, 2012 at 04:13:20AM -0600, Ryan Schmidt wrote: >> On Dec 6, 2012, at 03:05, Aljaž Srebrnič wrote: >>> well, the only difference between putting the code in pre-configure >>> and post-configure is, well, that configure gets executed, so >>> pre-configure should save some time. > >>> but we can always change the portgroup... >> Yes, I suppose I should be asking Clemens (Cc'd now) about this since >> he wrote the portgroup. > > Yes, require_active_variants could certainly be put in a pre-configure > block automatically. I didn't omit this for any specific reasons, I just > didn't think of doing it automatically. > > I probably won't be able to do this before the weekend, so feel free to > do the change yourself if you want. Remember this is an API change for > the portgroup and needs to go into a new active_variants 1.1 group to > avoid breaking Portfiles executed from registry during the uninstall > and/or deactivate phases. Well, I'm not so skilled with portgroups, so I'll leave the change to you and try to learn from your code, if you don't mind! :) -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100265] trunk/dports/python
On 06/dic/2012, at 12:11, Ryan Schmidt wrote: > > On Dec 6, 2012, at 05:06, Ryan Schmidt wrote: > >> py24-cairo would be the python 2.4 version of the port if "24" were in >> python.versions, but since it's not, no python 2.4 version is available >> anymore. Which is fine by me if nothing depended on it since we're trying to >> get rid of python 2.4 in MacPorts. > > Actually there is something that depends on py-cairo: py-gtk2. So that port > will have to be deleted. > > And py-gtkmvc depends on py-gtk2. So that'll have to be deleted. Nothing > depends on py-gtkmvc. > > And diffuse has a python24 variant which depends on py-gtk2. So that variant > will have to be deleted. > > Unless you want to add "24" to python.versions in py-cairo and delete > "python.default_version 27", and then change the aforementioned dependencies > from py-cairo to py24-cairo. But I'd rather proceed with getting rid of > python 2.4 things wherever we can. By the way, should I just svn rm it or deprecate it? -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100265] trunk/dports/python
On 06/dic/2012, at 12:11, Ryan Schmidt wrote: > > On Dec 6, 2012, at 05:06, Ryan Schmidt wrote: > >> py24-cairo would be the python 2.4 version of the port if "24" were in >> python.versions, but since it's not, no python 2.4 version is available >> anymore. Which is fine by me if nothing depended on it since we're trying to >> get rid of python 2.4 in MacPorts. > > Actually there is something that depends on py-cairo: py-gtk2. So that port > will have to be deleted. > > And py-gtkmvc depends on py-gtk2. So that'll have to be deleted. Nothing > depends on py-gtkmvc. > > And diffuse has a python24 variant which depends on py-gtk2. So that variant > will have to be deleted. > > Unless you want to add "24" to python.versions in py-cairo and delete > "python.default_version 27", and then change the aforementioned dependencies > from py-cairo to py24-cairo. But I'd rather proceed with getting rid of > python 2.4 things wherever we can. OK, I get it, now. Thanks for explaining it to me! I'll delete the py-gtk and py-gtkmvc ports and the diffuse variant. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100265] trunk/dports/python
On 06/dic/2012, at 11:13, Ryan Schmidt wrote: > > On Dec 6, 2012, at 03:05, Aljaž Srebrnič wrote: > >>> On a side note, why does the active_variants portgroup require the consumer >>> to enclose the require_active_variants invocation in a post-configure >>> block? Why can't the portgroup do that on its own, like the conflicts_build >>> portgroup does? Anyway shouldn't it be pre-configure not post-configure? >> >> well, the only difference between putting the code in pre-configure and >> post-configure is, well, that configure gets executed, so pre-configure >> should save some time. > > My thought was that it was not only time savings, but also possible error > avoidance. The way it is now, assume cairo is not installed with the quartz > variant. py27-cairo's configure will run (which will find out about the > currently-installed cairo without quartz support), and afterward, the > active_variants portgroup will display the error to the user and exit. The > user will follow the instructions and reinstall cairo with the quartz variant > and will then retry the py27-cairo installation, which, assuming the user > does not clean py27-cairo first, will pick up where it left off. The > configure phase hadn't completed, so it will run again, but I don't know > whether configure will re-check everything again or whether it caches the > results of prior runs somewhere. good catch! I'll commit the new version now. > >> I don't know why it has to be put in *-configure, > > The comments in the portgroup explain that. Before the configure phase, you > can't be sure that the dependencies have been installed at all. For example > if you just run "port info py27-cairo" MacPorts won't install any > dependencies for you. Or if you run "sudo port extract py27-cairo" MacPorts > will only install fetch and extract dependencies, but not build, lib or run > dependencies. Yeah, I meant why do you have to put it in the configure and not directly in the portfile :) > >> but we can always change the portgroup... > > Yes, I suppose I should be asking Clemens (Cc'd now) about this since he > wrote the portgroup. Great, I see not many port use the portgroup so changing it won't be a problem IMHO. -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [100265] trunk/dports/python
On 06/dic/2012, at 09:42, Ryan Schmidt wrote:
> On Dec 6, 2012, at 00:45, g...@macports.org wrote:
>
>> Revision: 100265
>> https://trac.macports.org/changeset/100265
>> Author: g...@macports.org
>> Date: 2012-12-05 22:45:07 -0800 (Wed, 05 Dec 2012)
>> Log Message:
>> ---
>> python/py-cairo:
>> - unified using python portgroup
>> - check for cairo variant using active_variants
>> - use setup.py install method
>> - new maintainer
>>
>> Modified Paths:
>> --
>> trunk/dports/python/py-cairo/Portfile
>
>
>> +post-configure {
>> +if {[variant_isset x11]} {
>> +require_active_variants cairo x11
>> +}
>> +}
>
>
>> +variant x11 {}
>
> I think it would be clearer if you placed the code relating to the x11
> variant into the x11 variant. Otherwise it looks, at quick glance, as if an
> empty variant is being declared.
>
>
> variant x11 {
>post-configure {
> require_active_variants cairo x11
>}
> }
>
Yeah, silly me! :D
>
> On a side note, why does the active_variants portgroup require the consumer
> to enclose the require_active_variants invocation in a post-configure block?
> Why can't the portgroup do that on its own, like the conflicts_build
> portgroup does? Anyway shouldn't it be pre-configure not post-configure?
well, the only difference between putting the code in pre-configure and
post-configure is, well, that configure gets executed, so pre-configure should
save some time.
I don't know why it has to be put in *-configure, but we can always change the
portgroup...
--
Aljaž Srebrnič a.k.a g5pw
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [99234] trunk/dports/sysutils
Hi Ryan!
This wakes up a sleeping beast: ruby. I have ruby and ruby19 installed, so I
can't install ruby19 with nosuffix. So, the install of vcsh fails because the
ronn gem is not found, of course, as it's installed for ruby 1.9 and the script
calls for ruby (which is the 1.8 version).
I started working on a ruby-select portfile, but my knowledge is not so deep,
and furthermore, ruby 1.9 installs rake too, which is usually provided by the
rb-rake.
So, anyone willing to lend me a hand to resolve the ruby issue?
On 30/ott/2012, at 01:21, ryandes...@macports.org wrote:
> Revision
> 99234
> Author
> ryandes...@macports.org
> Date
> 2012-10-29 17:21:08 -0700 (Mon, 29 Oct 2012)
> Log Message
>
> vcsh: new port, version 1.0 (#36758)
> Added Paths
>
> trunk/dports/sysutils/vcsh/
> trunk/dports/sysutils/vcsh/Portfile
> Diff
>
> Added: trunk/dports/sysutils/vcsh/Portfile (0 => 99234)
>
> --- trunk/dports/sysutils/vcsh/Portfile (rev 0)
> +++ trunk/dports/sysutils/vcsh/Portfile 2012-10-30 00:21:08 UTC (rev
> 99234)
> @@ -0,0 +1,30 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
> c-basic-offset: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem 1.0
> +PortGroup github 1.0
> +
> +github.setupRichiH vcsh 1.0 v
> +categories sysutils
> +platforms darwin
> +maintainers googlemail.com:gjasny openmaintainer
> +license GPL-2+
> +
> +description manage config files in HOME via fake bare git
> repositories
> +
> +long_descriptionvcsh allows you to have several git repositories, all
> maintaining their working \
> +trees in HOME without clobbering each other. That, in
> turn, means you can have \
> +one repository per config set (zsh, vim, ssh, etc),
> picking and choosing which \
> +configs you want to use on which machine.
> +
> +checksums rmd160 a104701eb1cbf4c4c7137ef8f93e419136248413 \
> +sha256
> d4776bd501ded81b2e50035bbe7ddd13990ee58110413e9164960bc6b1293c2c
> +
> +supported_archs noarch
> +use_configure no
> +
> +depends_build port:rb19-ronn
> +depends_lib port:git-core
> +depends_run port:mr
> +
> +destroot.post_args-append PREFIX=${prefix}
> Property changes on: trunk/dports/sysutils/vcsh/Portfile
> ___
> Added: svn:keywords
> Added: svn:eol-style
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [97362] trunk/dports/python/py-argparse/Portfile
On 04/set/2012, at 11:51, Joshua Root wrote: >> Revision: 97362 >> https://trac.macports.org/changeset/97362 >> Author: g5pw at macports.org >> Date: 2012-09-04 01:09:14 -0700 (Tue, 04 Sep 2012) >> Log Message: >> --- >> python/py-argparse: >> argparse is compatible with python3, too. >> >> Modified Paths: >> -- >>trunk/dports/python/py-argparse/Portfile >> >> Modified: trunk/dports/python/py-argparse/Portfile >> === >> --- trunk/dports/python/py-argparse/Portfile 2012-09-04 08:05:49 UTC (rev >> 97361) >> +++ trunk/dports/python/py-argparse/Portfile 2012-09-04 08:09:14 UTC (rev >> 97362) >> @@ -24,7 +24,7 @@ >> checksums rmd160 4ba4f413fab2a5f566b9b9bf1572714cd762fc66 \ >> sha256 >> ddaf4b0a618335a32b6664d4ae038a1de8fbada3b25033f9021510ed2b3941a4 >> >> -python.versions 24 25 26 >> +python.versions 24 25 26 27 31 32 > > But as it says in the description, this is a backport from the Python > 2.7 standard library. There is literally no point having this as a port > for python >= 2.7. (Actually I'm not sure about 3.1, but certainly > 2.7/3.2+.) Ah, you're right! actually, i modified it as a dependency of skypipe, but now I see that it's completely unnecessary. Feel free to rollback, I'll patch the skypipe requirements to ignore argparse. > > - Josh Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [97100] users/g5pw/dports/devel
Dammit, I screw up again. I'm sorry, the commits for bokken and octogit were
unintentional.
On 27/ago/2012, at 15:34, g...@macports.org wrote:
> Revision
> 97100
> Author
> g...@macports.org
> Date
> 2012-08-27 06:34:36 -0700 (Mon, 27 Aug 2012)
> Log Message
>
> Done with sandbox for radare2
> Modified Paths
>
> users/g5pw/dports/devel/bokken/Portfile
> users/g5pw/dports/devel/octogit/Portfile
> Removed Paths
>
> users/g5pw/dports/devel/radare2/
> Diff
>
> Modified: users/g5pw/dports/devel/bokken/Portfile (97099 => 97100)
>
> --- users/g5pw/dports/devel/bokken/Portfile 2012-08-27 13:33:57 UTC (rev
> 97099)
> +++ users/g5pw/dports/devel/bokken/Portfile 2012-08-27 13:34:36 UTC (rev
> 97100)
> @@ -5,7 +5,7 @@
> PortGroup python27 1.0
>
> namebokken
> -version 1.5
> +version 1.6
> categories devel
> platforms darwin
> license GPL-3
> @@ -15,7 +15,7 @@
> some of the Radares ones. It is intended to be a basic
> disassembler, mainly, \
> to analyze malware and vulnerabilities.
> homepagehttp://inguma.eu/projects/bokken
> -master_siteshttp://inguma.eu/attachments/download/188/
> +master_siteshttp://inguma.eu/attachments/download/197/
>
> checksums rmd160 4efed8f5d186ee5d957198fc1973b322b2000a32 \
> sha256
> 7dfb24b4283494db971d5a907dd52bb55455d4b62bfd907c50d125027ff80826
> Modified: users/g5pw/dports/devel/octogit/Portfile (97099 => 97100)
>
> --- users/g5pw/dports/devel/octogit/Portfile 2012-08-27 13:33:57 UTC (rev
> 97099)
> +++ users/g5pw/dports/devel/octogit/Portfile 2012-08-27 13:34:36 UTC (rev
> 97100)
> @@ -5,7 +5,7 @@
> PortGroup github 1.0
> PortGroup python 1.0
>
> -github.setupmyusuf3 octogit 0.3.1 v
> +github.setupmyusuf3 octogit 0.3.3 v
>
> python.default_version 27
> categories devel
> @@ -18,8 +18,8 @@
>
> platforms darwin
>
> -checksums rmd160 40486470c2ad35da17fba41aa29b260f39a3320b \
> -sha256
> b61f3c19a07feaf5c7db67788a7ba242bb389bf51037ed9929388b28540a5e29
> +checksums rmd160 058cce4b0815ad6cad6db4832acde6c936ea141a \
> +sha256
> 888d09e46a5d7118b23c276d76a91a68fa26695afeca4a3aed072880f60151c8
>
> depends_lib port:py${python.version}-virtualenv \
> port:py${python.version}-clint
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New AquaTerm & gnuplot patches
On 21/ago/2012, at 01:23, Mojca Miklavec wrote: > On Mon, Aug 20, 2012 at 5:39 PM, Aljaž Srebrnič wrote: >> On 31/lug/2012, at 00:30, Mojca Miklavec wrote: >> >> Hi Mojca, Sorry I'm late, i was "out of the civilization" until some days >> ago ;) > > I hope that details follow off-list ;) > >>> AquaTerm has moved to GitHub and new version has been released. I >>> attached the revised Portfile here: >>> http://trac.macports.org/ticket/34346 >>> >>> However, it would be very helpful to patch gnuplot before upgrading >>> AquaTerm. I uploaded this patch about three months ago (today I only >>> refreshed it to reflect the latest change in gnuplot) and I would be >>> really grateful for any kind of feedback: >>> >>> http://trac.macports.org/attachment/ticket/34423/gnuplot-use-aqt-framework-extra-option.patch >> >> I am no autoconf expert, however I know it a little, all your patches make >> sense to me. >> >>> The patch is needed in order to be able to get rid of >>> libaquaterm.dylib & header files (replaced by AquaTerm.framework) >>> >>> I'm the maintainer of gnuplot port (without commit rights) and from my >>> perspective I consider the patch ready to be committed (there is no >>> need for rebuild gnuplot since gnuplot already links against >>> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm), >>> so if any developer with commit rights is comfortable with the patch, >>> I would like to request commiting it. >> >> I'll commit it then, with your approval. > > Then please do. Thank you. Committed in r96897. > >>> >>> -- >>> >>> The new version of AquaTerm might be interested for the following reasons: >>> - support for transparency >>> - universal binaries (like running i386 gnuplot with x86_64 AquaTerm) >>> don't have problems any more >>> - in 1.1.0 (which never made it into MacPorts) the first plot >>> following "set term aqua size x,y" would be typeset with transparent >>> (=invisible) labels and sometimes plot wouldn't be cleared >>> - no need to patch xcodeproject >> >> Since AquaTerm is under maintainership of mcalhoun, let's see what he/she >> thinks of it! > > I first tried to reach him in March 2011. I wrote him emails in 16 > different threads (one to several emails per thread) and never > received any single response from him. Not even a single sign of life. > I guess that other developers who have been following development > longer must know more. Oh, well, that does it :P > > I believe the patches are way beyond the 72 hours of "maintainer > timeout" limit, so they should be legally safe to commit ;). There has > been no single response to >http://trac.macports.org/ticket/34346 > for approximately four months. I was actually thinking of filing a > port abandonment ticket for AquaTerm eventually. Well, do you want to maintain it? We could co-maintain it if you want! > >> Also, I see that your commits were pulled in, does that mean that the >> patches to AquaTerm are now obsolete? > > Which commits do you have in mind? Any patches under "files" can go if > that is what you are asking. Sorry, I was referring to the commits in the aquaterm repository! > > Thanks a lot for taking the time to look at all the patches, You kidding me?:) Thanks to _you_ for writing them! >Mojca > > (un)related: I'm fighting with another issue which I believe must be > some PackageMaker's bug. If someone would install AquaTerm with > MacPorts first and then with an official installer, the installed > AquaTerm.app would end up overwriting > /Applications/MacPorts/AquaTerm.app instead of being placed under > /Applications/AquaTerm.app. Here's an exact description from 2007: > http://lists.apple.com/archives/installer-dev/2007/Dec/msg00040.html That is because the installer searches by bundle identifiers. We could change the bundle ID when installing via MacPorts. Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: New AquaTerm & gnuplot patches
On 31/lug/2012, at 00:30, Mojca Miklavec wrote: > Hello, Hi Mojca, Sorry I'm late, i was "out of the civilization" until some days ago ;) > > AquaTerm has moved to GitHub and new version has been released. I > attached the revised Portfile here: > http://trac.macports.org/ticket/34346 > > However, it would be very helpful to patch gnuplot before upgrading > AquaTerm. I uploaded this patch about three months ago (today I only > refreshed it to reflect the latest change in gnuplot) and I would be > really grateful for any kind of feedback: > > http://trac.macports.org/attachment/ticket/34423/gnuplot-use-aqt-framework-extra-option.patch I am no autoconf expert, however I know it a little, all your patches make sense to me. > > The patch is needed in order to be able to get rid of > libaquaterm.dylib & header files (replaced by AquaTerm.framework) > > I'm the maintainer of gnuplot port (without commit rights) and from my > perspective I consider the patch ready to be committed (there is no > need for rebuild gnuplot since gnuplot already links against > /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm), > so if any developer with commit rights is comfortable with the patch, > I would like to request commiting it. I'll commit it then, with your approval. > > -- > > The new version of AquaTerm might be interested for the following reasons: > - support for transparency > - universal binaries (like running i386 gnuplot with x86_64 AquaTerm) > don't have problems any more > - in 1.1.0 (which never made it into MacPorts) the first plot > following "set term aqua size x,y" would be typeset with transparent > (=invisible) labels and sometimes plot wouldn't be cleared > - no need to patch xcodeproject Since AquaTerm is under maintainership of mcalhoun, let's see what he/she thinks of it! Also, I see that your commits were pulled in, does that mean that the patches to AquaTerm are now obsolete? > > In addition to that, I added a trivial patch which now tries to start > /Applications/MacPorts/AquaTerm.app instead of > /Applications/AquaTerm.app. The second one breaks functionality in > case that a different version of AquaTerm is installed in > /Applications. > > On the other hand it might not work on 10.4, but I'm not exactly sure > about that. There is no reason why it wouldn't work (there are no > Lion-specific functions in there :) except that it was way too painful > to set up the old XCode to compile fat binaries including x86_64 that > would also work on Tiger. > > Thank you, > Mojca > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [94725] users/g5pw/dports/devel
On 28/giu/2012, at 00:01, Ryan Schmidt wrote:
>
> On Jun 27, 2012, at 13:55, g...@macports.org wrote:
>
>> Revision: 94725
>> https://trac.macports.org/changeset/94725
>> Author: g...@macports.org
>> Date: 2012-06-27 11:55:15 -0700 (Wed, 27 Jun 2012)
>> Log Message:
>> ---
>> devel/pev: new port
>>
>> Added Paths:
>> ---
>> users/g5pw/dports/devel/pev/
>> users/g5pw/dports/devel/pev/Portfile
>
>
>> +master_sitessourceforge
>
> Please write sourceforge master_sites entries so that redirects are avoided.
> In this case:
>
> master_sitessourceforge:project/pev/pev-${version}
>
>
>> +use_configure no
>> +
>> +build.args-append CC=${configure.cc} \
>> +CXX=${configure.cxx} \
>> +CPP=${configure.cpp}
>
> Because you are using "use_configure no", please consider the need of
> specifying the -arch flags. You may need to add [get_canonical_archflags] to
> CFLAGS / CXXFLAGS / LDFLAGS, or to CC / CXX. If possible, also please add a
> universal variant, by adding the line "variant universal {}" before you call
> get_canonical_archflags.
i knew I was missing something… :D thanks, will change before copying in the
main tree!
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [93402] users/g5pw/dports/devel/radare2/Portfile
On 21/mag/2012, at 23:09, Ryan Schmidt wrote:
>
> On May 21, 2012, at 15:46, g...@macports.org wrote:
>
>> Revision: 93402
>> https://trac.macports.org/changeset/93402
>> Author: g...@macports.org
>> Date: 2012-05-21 13:46:00 -0700 (Mon, 21 May 2012)
>> Log Message:
>> ---
>> devel/radare2:
>> fixed whitespace mess, added livecheck, using system -W
>> and removed a patch whose sole purpose was to create a file.
>> Just created the file instead.
>
> In addition it looks like you added a pre-patch block and some build.args
> that weren't there before, but it's hard to clearly see these functional
> changes because of the concurrent whitespace changes. In the future please
> make whitespace changes in a separate commit.
Yeah, it was full of old changes, it won't happen again. :)
>
> More below:
>
>
>> Modified: users/g5pw/dports/devel/radare2/Portfile
>> ===
>> --- users/g5pw/dports/devel/radare2/Portfile 2012-05-21 20:39:13 UTC (rev
>> 93401)
>> +++ users/g5pw/dports/devel/radare2/Portfile 2012-05-21 20:46:00 UTC (rev
>> 93402)
>> @@ -3,31 +3,38 @@
>>
>> PortSystem 1.0
>>
>> -nameradare2
>> -version 0.9
>> -categories devel
>> +nameradare2
>> +version 0.9
>> +categories devel
>> platforms darwin
>> -license GPL-3
>> -maintainers g5pw pixilla openmaintainer
>> -description Opensource tools to disasm, debug, analyze and
>> manipulate binary files.
>> -long_description${description}
>> -homepagehttp://radare.org/
>> -master_sites${homepage}get/
>> +license LGPL-3+
>> +maintainers g5pw pixilla openmaintainer
>> +description Opensource tools to disasm, debug, analyze and
>> manipulate binary files.
>> +long_description${name} provides ${description}.
>> +homepagehttp://radare.org
>> +master_sites${homepage}/get/
>>
>> -checksums ${distname}${extract.suffix} \
>> -rmd160
>> f68ebf07ec62e907980e8f8bc195754bf993b466 \
>> -sha256
>> e12feea3b776601d7b680e64250897110cf4fca2f1214b4c527e13b7abe900e0
>> +checksums rmd160 f68ebf07ec62e907980e8f8bc195754bf993b466 \
>> +sha256
>> e12feea3b776601d7b680e64250897110cf4fca2f1214b4c527e13b7abe900e0
>>
>> patch.pre_args -p1
>> -patchfiles patch-change_install_names.diff \
>> -patch-libr-Makefile.diff \
>> +patchfiles patch-libr-Makefile.diff \
>>patch-libr-config.mk.tail.diff \
>>patch-libr-rules.mk.diff \
>>patch-mk-gcc.mk.diff
>>
>> -build.env-append "LDFLAGS=-L${prefix}/lib"
>> -
>> +pre-patch {
>> +reinplace "s/\"main(){}\"/\"int main(){}\"/" ${worksrcpath}/configure
>> +}
>
> Since this reinplace affects only a single line, and doesn't involve any
> portfile variables, it would be better to make a patchfile.
Will do!
>
>
>> +build.env-appendLDFLAGS="-L${prefix}/lib"
>> +build.args CC="${configure.cc} [get_canonical_archflags]"
>
> It's indeed necessary to specify the compiler and arch flags for this port,
> however calling get_canonical_archflags will not work as you want unless you
> define the universal variant before calling it. Meaning: on a line before you
> call get_canonical_archflags, write:
>
> variant universal {}
>
> Since this changes how the files are built (previously, the universal variant
> would install non-universal software), the revision should be increased.
Understood. Thanks for your corrections!
>
>
>> post-destroot {
>># Fix link lib paths
>> -system "cd ${worksrcpath} && sh change_install_names ${destroot}"
>> +system -W ${filespath} "sh change_install_names ${destroot}"
>> }
>> +
>> +livecheck.type regex
>> +livecheck.url ${homepage}/y/?p=download
>> +livecheck.regex "${name}-(\\d\\.\\d)"
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [93406] trunk/dports/devel
On 21/mag/2012, at 23:11, Ryan Schmidt wrote:
> On May 21, 2012, at 16:08, g...@macports.org wrote:
>
>> Revision: 93406
>> https://trac.macports.org/changeset/93406
>> Author: g...@macports.org
>> Date: 2012-05-21 14:08:03 -0700 (Mon, 21 May 2012)
>> Log Message:
>> ---
>> devel/plumbum:
>> new port: small yet feature-rich library for shell script-like programs in
>> Python.
>>
>> Added Paths:
>> ---
>> trunk/dports/devel/plumbum/
>> trunk/dports/devel/plumbum/Portfile
>>
>> Added: trunk/dports/devel/plumbum/Portfile
>> ===
>> --- trunk/dports/devel/plumbum/Portfile (rev 0)
>> +++ trunk/dports/devel/plumbum/Portfile 2012-05-21 21:08:03 UTC (rev
>> 93406)
>> @@ -0,0 +1,27 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +PortGroup github 1.0
>> +PortGroup python 1.0
>> +
>> +github.setuptomerfiliba plumbum 0.9 v
>> +
>> +maintainers g5pw
>> +
>> +categories devel python
>> +description Plumbum (Latin for lead, which was used to create pipes
>> \
>> +back in the day) is a small yet feature-rich library
>> for \
>> +shell script-like programs in Python.
>> +long_description${description} The motto of the library is \"Never
>> write \
>> +shell scripts again\", and thus it attempts to mimic
>> the \
>> +shell syntax (\"shell combinators\") where it makes
>> sense, \
>> +while keeping it all pythonic and cross-platform.
>> +
>> +platforms darwin
>> +license ?
>
> If you can't figure out what the license is, don't put a license line.
>
>
>> +checksums rmd160 d385af17e9b3234c18b80b7bb52488f582c39914 \
>> +sha256
>> f970e7a91661e9d8ef586ed7f5a84b554f691bc4f904fcb6b16e4e6d7db849a3
>> +
>> +python.default_version 27
Oh, yeah, sorry :/
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts 2.1.0 has been released
On 15/mag/2012, at 17:36, Bradley Giesbrecht wrote: > Nice! > Thanks Joshua! > > > On May 15, 2012, at 8:29 AM, Joshua Root wrote: > >> The MacPorts Project is happy to announce that the 2.1.0 version has now >> been released. It is available via the usual methods: >> >> - selfupdate if you already have MacPorts installed >> - package installers for 10.5 [1], 10.6 [2], and 10.7 [3] (all >> universal builds, the first i386/ppc and the latter two i386/x86_64) >> - source tarballs, both .tar.bz2 [4] and .tar.gz [5] >> - subversion tag [6] >> >> The list of what's new in 2.1.0 is quite extensive (so I won't list it >> here), the details can be found in the NEWS [7] file or the somewhat >> more exhaustive ChangeLog [8]. >> >> A big thanks to the developers for their hard work with all of the >> various features and bug fixes in 2.1.0, and to all those who helped out >> by reporting bugs or testing. >> >> Detached PGP signatures for the pkg/dmgs and source tarballs have been >> made with my key, which is available on the keyservers and my MacPorts >> wiki page [9]. >> >> - Josh >> >> [1] >> <https://distfiles.macports.org/MacPorts/MacPorts-2.1.0-10.5-Leopard.dmg> >> [2] >> <https://distfiles.macports.org/MacPorts/MacPorts-2.1.0-10.6-SnowLeopard.pkg> >> [3] >> <https://distfiles.macports.org/MacPorts/MacPorts-2.1.0-10.7-Lion.pkg> >> [4] <https://distfiles.macports.org/MacPorts/MacPorts-2.1.0.tar.bz2> >> [5] <https://distfiles.macports.org/MacPorts/MacPorts-2.1.0.tar.gz> >> [6] <https://svn.macports.org/repository/macports/tags/release_2_1_0> >> [7] >> <http://svn.macports.org/repository/macports/branches/release_2_1/base/NEWS> >> [8] >> <http://svn.macports.org/repository/macports/branches/release_2_1/base/ChangeLog> >> [9] <https://trac.macports.org/wiki/jmr> >> >> PS, my PGP key ID is 63BAD8CF2A10D5EE, >> fingerprint 5F83 E16B D885 0601 5084 63C2 63BA D8CF 2A10 D5EE >> ___ >> macports-users mailing list >> macports-us...@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Hooray for you devs! :) Cannot thank you enough for your work! Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [92519] users/g5pw/dports/devel
On 30/apr/2012, at 22:25, Ryan Schmidt wrote: > > On Apr 30, 2012, at 14:10, g...@macports.org wrote: > >> Revision: 92519 >> https://trac.macports.org/changeset/92519 >> Author: g...@macports.org >> Date: 2012-04-30 12:10:33 -0700 (Mon, 30 Apr 2012) >> Log Message: >> --- >> devel/zshdb: >> New Port, should be OK for inclusion. >> >> Added Paths: >> --- >> users/g5pw/dports/devel/zshdb/ >> users/g5pw/dports/devel/zshdb/Portfile >> >> Added: users/g5pw/dports/devel/zshdb/Portfile >> === >> --- users/g5pw/dports/devel/zshdb/Portfile (rev 0) >> +++ users/g5pw/dports/devel/zshdb/Portfile 2012-04-30 19:10:33 UTC (rev >> 92519) >> @@ -0,0 +1,22 @@ >> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; >> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4 >> +# $Id$ >> + >> +PortSystem 1.0 >> +PortGroup github 1.0 >> + >> +github.setuprocky zshdb 0.08 "release-" >> + >> +maintainers g5pw openmaintainer >> + >> +categories devel >> + >> +description GDB-like debugger for zsh scripts. >> + >> +platforms darwin >> + >> +depends_lib port:zsh-devel >> + >> +checksums rmd160 4d266c534cb39f000fceb929c087597c85bb6437 \ >> +sha256 >> 9d49597819af9f6b1661fa67727fca987ace6bab982d41d2f91242dd6f5be3c0 >> + >> +configure.cmd ./autogen.sh > > Scripts called "autogen" typically run automake, autoconf, and/or > glibtoolize; if so you'd need build deps on the automake, autoconf and/or > libtool ports, respectively. aha, thanks! Will correct… ;) Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [91911] users/g5pw
On 13/apr/2012, at 10:37, Ryan Schmidt wrote:
> On Apr 13, 2012, at 02:06, g...@macports.org wrote:
>
>> Revision: 91911
>> https://trac.macports.org/changeset/91911
>> Author: g...@macports.org
>> Date: 2012-04-13 00:06:41 -0700 (Fri, 13 Apr 2012)
>> Log Message:
>> ---
>> devel/wemux:
>> new port
>>
>> Added Paths:
>> ---
>> users/g5pw/dports/
>> users/g5pw/dports/devel/
>> users/g5pw/dports/devel/wemux/
>> users/g5pw/dports/devel/wemux/Portfile
>
>
>> +use_configure no
>> +
>> +build {}
>> +
>> +destroot {
>> +xinstall -m 775 ${worksrcpath}/wemux ${destroot}${prefix}/bin
>> +xinstall -m 664 ${worksrcpath}/wemux.conf.example
>> ${destroot}${prefix}/etc
>> +}
>
>
>
> I realize this is still a work in progress and in your users directory, but
> disabling the configure ("use_configure no") and build ("build {}") phases is
> a pretty good hint that this port probably doesn't install any
> architecture-specific files and should therefore use "supported_archs noarch".
Yes, in fact this is true. Where can I read something about platforms and
architectures in macports? It seems it's still not clear to me… :/
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: ruby question
On 02/apr/2012, at 19:20, Ryan Schmidt wrote: > > On Apr 1, 2012, at 16:16, Aljaž Srebrnič wrote: > >> I was trying to craft a port for the earthquake ruby gem (a CLI for >> twitter), but I stumbled on some puzzling things: apparently, earthquake >> needs ruby 1.9, why is ruby available as ruby19 and not simply ruby (whih >> installs the 1.8 version)? And if we go the python way, why there's no >> ruby-select? > > The ruby port should probably be renamed to / replaced_by ruby18. > > There should probably be a ruby-select port. > > The ruby portgroup would then need to be overhauled as well. > > I don't think anybody's worked on the ruby ports in awhile; if you're > interested you should coordinate with the ruby maintainer. I pinged him/her, but no response… The select stuff is quite obscure to me, however, Is there some documentation about it? I couldn't find anything in the guide or wiki… :/ > > >> Slightly related: I wanna install earthquake, but get the source using >> github. Just add both PortGroups and then ruby.setup first and then >> github.setup? > > Yes, the github portgroup should be able to coexist with other portgroups. Thanks for the info ;) However, I took a peek in the python_select port and tried to emulate it, and quickly noticed an issue: ruby 1.8 does not provide the rake command (available as rb-rake port) but it is bundled with ruby19! I haven't the foggiest on how to implement that :/ Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [91398] trunk/dports
Id: Portfile 86877 2011-11-06 17:56:12Z r...@macports.org $
> +
> +PortSystem1.0
> +PortGroup python 1.0
> +
> +name py-gitdb
> +version 0.5.4
> +maintainers landonf openmaintainer
> +platforms darwin
> +license BSD
> +
> +description GitDB is a pure-Python git object database
> +long_description ${description}
> +
> +homepage http://packages.python.org/gitdb/
> +master_sites http://pypi.python.org/packages/source/g/gitdb/
> +distname gitdb-${version}
> +
> +python.versions 26 27
> +python.default_version 27
> +
> +depends_run port:py-async-task \
> + port:py-smmap
> +
> +checksums md5 25353bb8d3ea527ba443dd88cd4e8a1c \
> + sha12e01b48f53f1716e59291b4183449e7fe3e574ea \
> + rmd160 21961026cb560f85450c356464a7d1018000902a
> Added: trunk/dports/python/py-gitpython/Portfile (0 => 91398)
>
> --- trunk/dports/python/py-gitpython/Portfile (rev 0)
> +++ trunk/dports/python/py-gitpython/Portfile 2012-03-31 18:00:42 UTC (rev
> 91398)
> @@ -0,0 +1,26 @@
> +# $Id$
> +
> +PortSystem1.0
> +PortGroup python 1.0
> +
> +name py-gitpython
> +version 0.3.2.RC1
> +maintainers landonf openmaintainer
> +platforms darwin
> +license BSD
> +
> +description A python library used to interact with Git repositories.
> +long_description GitPython provides object model access to your git \
> + repository. Once you have created a repository object, you
> \
> + can traverse it to find parent commit(s), trees, blobs, etc.
> +
> +homepage http://gitorious.org/projects/git-python/
> +master_sites http://pypi.python.org/packages/source/G/GitPython/
> +distname GitPython-${version}
> +
> +python.versions 26 27
> +python.default_version 27
> +
> +checksums md5 849082fe29adc653a3621465213cab96 \
> + sha1b9f43c91452f3fe7e105ac54ce878ff20ea44f44 \
> + rmd160 75488dcfe0be35066cd39eb63f909f999f17cdda
> Property changes on: trunk/dports/python/py-gitpython/Portfile
> ___
> Added: svn:keywords
> Added: svn:eol-style
> Added: trunk/dports/python/py-smmap/Portfile (0 => 91398)
>
> --- trunk/dports/python/py-smmap/Portfile (rev 0)
> +++ trunk/dports/python/py-smmap/Portfile 2012-03-31 18:00:42 UTC (rev
> 91398)
> @@ -0,0 +1,24 @@
> +# $Id$
> +
> +PortSystem1.0
> +PortGroup python 1.0
> +
> +name py-smmap
> +version 0.8.2
> +maintainers landonf openmaintainer
> +platforms darwin
> +license BSD
> +
> +description Pure python sliding memory map manager
> +long_description ${description}
> +
> +homepage https://github.com/Byron/smmap
> +master_sites http://pypi.python.org/packages/source/s/smmap/
> +distname smmap-${version}
> +
> +python.versions 26 27
> +python.default_version 27
> +
> +checksums md5 f5426b7626ddcf5e447253fae0396b0c \
> + sha1d2d2e1b4726e8c6616d0a5f01146dd45fd94808b \
> + rmd160 a030840a5821bf60160fecd3ed1d28d08a075614
> Property changes on: trunk/dports/python/py-smmap/Portfile
> ___
> Added: svn:keywords
> Added: svn:eol-style
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90923] trunk/dports/cross/msp430-binutils/Portfile
On 19/mar/2012, at 02:22, Ryan Schmidt wrote:
> On Mar 18, 2012, at 07:28, g...@macports.org wrote:
>
>> Revision: 90923
>> https://trac.macports.org/changeset/90923
>> Author: g...@macports.org
>> Date: 2012-03-18 05:28:54 -0700 (Sun, 18 Mar 2012)
>> Log Message:
>> ---
>> cross/msp430-binutils:
>> Updated to use better patch URLs
>>
>> Modified Paths:
>> --
>> trunk/dports/cross/msp430-binutils/Portfile
>>
>> Modified: trunk/dports/cross/msp430-binutils/Portfile
>> ===
>> --- trunk/dports/cross/msp430-binutils/Portfile 2012-03-18 12:25:56 UTC
>> (rev 90922)
>> +++ trunk/dports/cross/msp430-binutils/Portfile 2012-03-18 12:28:54 UTC
>> (rev 90923)
>> @@ -12,8 +12,8 @@
>> conflicts ${name}-devel
>> maintainers g5pw
>>
>> -patch_sites
>> http://downloads.sourceforge.net/project/mspgcc/Patches/${distname}/ \
>> -
>> http://downloads.sourceforge.net/project/mspgcc/Patches/LTS/${lts_date}/ \
>> +patch_sites sourceforge:project/mspgcc/Patches/${distname}/ \
>> +sourceforge:project/mspgcc/Patches/LTS/${lts_date}/ \
>>
>> patchfiles ${name}-${version}.patch \
>>${name}-${version}-sf3143071.patch \
>
> Unless *all* of the patchfiles are available from *all* of the patch_sites,
> you should use tags to indicate which patchfiles are available at which
> patch_sites; that way MacPorts doesn't unnecessarily try downloading files
> from locations where we already know they won't be found. See attached patch.
> (If you can come up with better descriptions for these two patch_sites than
> "patch1" and "patch2" by all means do so.)
>
Didn't know I could do that, thanks!
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90862] trunk/dports/devel
On 16/mar/2012, at 16:04, Ryan Schmidt wrote:
>
> On Mar 16, 2012, at 04:35, g...@macports.org wrote:
>
>> Revision: 90862
>> https://trac.macports.org/changeset/90862
>> Author: g...@macports.org
>> Date: 2012-03-16 02:35:56 -0700 (Fri, 16 Mar 2012)
>> Log Message:
>> ---
>> devel/radare2:
>> New port
>
> https://trac.macports.org/ticket/32560 had been filed for this. Does this
> commit address all the issues discussed there? / Can the ticket be closed?
It was me who filed this ticket. It can be safely closed.
>
>
>> Added Paths:
>> ---
>> trunk/dports/devel/radare2/
>> trunk/dports/devel/radare2/Portfile
>> trunk/dports/devel/radare2/change_install_names
>
> This file does not appear to be used.
>
>
>> trunk/dports/devel/radare2/files/
>> trunk/dports/devel/radare2/files/patch-change_install_names.diff
>
> This patch appears to create the above script in the worksrcpath.
>
> We usually just put the script itself into the files directory, and either
> call it from there or copy it into the worksrcpath, rather than writing a
> patch that creates a file, since it's easier to edit a script itself than to
> edit a patch that creates a script.
Done! Will commit as soon as I fix some things with the developers.
>
>
>> trunk/dports/devel/radare2/files/patch-libr-Makefile.diff
>> trunk/dports/devel/radare2/files/patch-libr-config.mk.tail.diff
>> trunk/dports/devel/radare2/files/patch-libr-rules.mk.diff
>> trunk/dports/devel/radare2/files/patch-mk-gcc.mk.diff
>>
>> Added: trunk/dports/devel/radare2/Portfile
>> ===
>> --- trunk/dports/devel/radare2/Portfile (rev 0)
>> +++ trunk/dports/devel/radare2/Portfile 2012-03-16 09:35:56 UTC (rev
>> 90862)
>> @@ -0,0 +1,33 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +
>> +nameradare2
>> +version 0.9
>> +categories devel
>> +platforms darwin
>> +license GPL-3
>
> According to my notes in #32560 the license is actually "LGPL-3+".
You're right. Corrected!
>
>
>> +maintainers g5pw pixilla openmaintainer
>> +description Opensource tools to disasm, debug, analyze and
>> manipulate binary files.
>> +long_description${description}
>> +homepagehttp://radare.org/
>> +master_sites${homepage}get/
>> +
>> +checksums ${distname}${extract.suffix} \
>
> Note that you don't have to list the distfile name when there's only one.
Just being explicit :) But yeah, it's redundant.
>
>
>> +rmd160
>> f68ebf07ec62e907980e8f8bc195754bf993b466 \
>> +sha256
>> e12feea3b776601d7b680e64250897110cf4fca2f1214b4c527e13b7abe900e0
>> +
>> +patch.pre_args -p1
>> +patchfiles patch-change_install_names.diff \
>
>> +patch-libr-Makefile.diff \
>> +patch-libr-config.mk.tail.diff \
>> +patch-libr-rules.mk.diff \
>> +patch-mk-gcc.mk.diff
>> +
>> +build.env-append "LDFLAGS=-L${prefix}/lib"
>
> Note that you don't need to quote this, and also that -L${prefix}/lib is
> known in MacPorts as ${configure.ldflags}. The fact that you're having to
> manually add this to LDFLAGS makes me wonder what else (-arch flags?) you
> might have to manually deal with (see #32560).
Actually I have a valid reason to do that, the makefile looks a little bugged.
I will contact the devs and see if they can fix it upstream.
>
>
>> +post-destroot {
>> +# Fix link lib paths
>> +system "cd ${worksrcpath} && sh change_install_names ${destroot}"
>
> Note that "system" has a "-W" argument that should be used instead of
> manually "cd"ing somewhere.
>
> system -W ${worksrcpath} "sh change_install_names ${destroot}"
>
> Or, if you decide to move the actual script into the files directory and call
> it from there, as I suggested above, perhaps just:
>
> system "sh ${filespath}/change_install_names ${destroot}"
Corrected!
>
Re: [90772] trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl
Ok, few things:
1) thanks for fixing whitespace. I have to remember to check indentation and
whitespace before committing.
2) The problem with the extract.only keyword is that my msp430-gcc[-devel]
ports download the full gcc archive (gcc-4.5.6, for example) and that breaks if
extract.only is set like that.
Should I just override extract.only in my portfiles?
On 14/mar/2012, at 10:29, rai...@macports.org wrote:
> Revision
> 90772
> Author
> rai...@macports.org
> Date
> 2012-03-14 02:29:30 -0700 (Wed, 14 Mar 2012)
> Log Message
>
> group/crossgcc:
> Explain why extract.only is required here
> Modified Paths
>
> trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl
> Diff
>
> Modified: trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl (90771 =>
> 90772)
>
> --- trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl2012-03-14
> 09:21:48 UTC (rev 90771)
> +++ trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl2012-03-14
> 09:29:30 UTC (rev 90772)
> @@ -84,11 +84,10 @@
>
> depends_build port:gettext
>
> -# I don't know why is this here, it looks redundant.
> -# macports should already extract all the distfiles!
> -#extract.only${dcore} ${dcxx} ${dobjc}
> +# Extract gcc distfiles only. newlib tarball is available as gzip
> only;
> +# handled below in post-extract in the variant.
> +extract.only${dcore} ${dcxx} ${dobjc}
>
> -
> # Build in a different directory, as advised in the README file.
> post-extract {
> file mkdir "${workpath}/build"
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90767] trunk/dports/cross/msp430-gdb/Portfile
On 14/mar/2012, at 09:32, Ryan Schmidt wrote:
>
> On Mar 14, 2012, at 03:14, g...@macports.org wrote:
>
>> Revision: 90767
>> http://trac.macports.org/changeset/90767
>> Author: g...@macports.org
>> Date: 2012-03-14 01:14:28 -0700 (Wed, 14 Mar 2012)
>> Log Message:
>> ---
>> msp430-gdb:
>> - Updated maintainer address
>> - Eliminated the use of the epoch keyword
>
> It looks like you did several things in this changeset, but the word "epoch"
> does not appear anywhere in this changeset, so removing it wasn't one of the
> changes.
Hmm… Looks like i diffed agains the wrong file :P
>
> Do be aware however that if there is an epoch line in a portfile, it can
> never be removed, nor can its value ever be decreased.
Ah ok. Yes, using it was a mistake in the first place.
>
>
>> Modified Paths:
>> --
>> trunk/dports/cross/msp430-gdb/Portfile
>>
>> Modified: trunk/dports/cross/msp430-gdb/Portfile
>> ===
>> --- trunk/dports/cross/msp430-gdb/Portfile 2012-03-14 07:46:16 UTC (rev
>> 90766)
>> +++ trunk/dports/cross/msp430-gdb/Portfile 2012-03-14 08:14:28 UTC (rev
>> 90767)
>> @@ -4,14 +4,17 @@
>> PortSystem 1.0
>>
>> namemsp430-gdb
>> -version 7.2
>> +set name_target [lindex [split ${name} -] 0]
>> +set name_package[lindex [split ${name} -] 1]
>> +set version_base7.2
>> +set lts_date20110103
>
> A tab character snuck in on this line, but per our preferred style, and per
> the modeline in this portfile, there should be no tabs, only spaces. You may
> wish to configure your editor to insert spaces instead of tab characters when
> you press the tab key.
Ah! good find. I usually use vim, but it looks like that tab snuck in whan I
was (briefly) using another editor.
>
>
>> +version ${version_base}-${lts_date}
>> +conflicts ${name}-devel
>>
>> -distnamegdb-${version}
>> -set crossgcc-target msp430
>> -set version_date20110103
>> +distname${name_package}-${version_base}
>>
>> categories cross
>> -maintainers gmail.com:a2piratesoft nomaintainer
>> +maintainers g5pw
>> description GDB for the MSP430 processors
>> long_descriptionmsp430-gdb is a version of the GNU Debugger that \
>>through the mspdebug program can be used to debug \
>> @@ -22,7 +25,7 @@
>> master_sitesgnu:gdb
>> patch_sites
>> http://downloads.sourceforge.net/project/mspgcc/Patches/${distname}/
>> use_bzip2 yes
>> -checksums ${name}-${version}-${version_date}.patch \
>> +checksums ${name}-${version}.patch \
>>rmd160 09d8427721b0a54ecddda373fcd5af6f9496e55c \
>>sha256
>> 5631fce178ed3bf05b6c60957e56501ea22b3618febc2fa790249a1b86447aa0 \
>>${distname}${extract.suffix} \
>> @@ -30,11 +33,11 @@
>>sha256
>> bf444b88ab845243364c3d410be9e3f43a57f96ff594d65a37842ea03c3410f0
>> depends_run port:mspdebug
>>
>> -patchfiles ${name}-${version}-${version_date}.patch
>> +patchfiles ${name}-${version}.patch
>>
>> -worksrcdir gdb-[string trimright ${version} a-zA-Z]
>> +worksrcdir ${distname}
>
> You can remove the line "worksrcdir ${distname}"; that's the default.
Will do, thanks!
Aljaž Srebrnič
-- --
My public key: http://bit.ly/g5pw_pubkey
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: SVN tree not updating
On 10/mar/2012, at 07:56, Ryan Schmidt wrote: > > On Mar 10, 2012, at 00:35, Aljaž Srebrnič wrote: > >> Hey! I'm Aljaž, the noob ;) >> it looks like I'm having some difficulties setting up the svn tree, I >> decided to check out the entire trunk, so i created >> /opt/local/var/macports/sources/svn.macports.org/ and checked out trunk in >> /opt/local/var/macports/sources/svn.macports.org/trunk. >> >> Now i have Makefile,base,doc,doc-new,dports,www under the trunk directory. >> If I run svn up in >> /opt/local/var/macports/sources/svn.macports.org/trunk/dports, it refreshes >> correctly from svn. >> >> I've modified /opt/local/etc/macports/sources.conf, adding >> file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ >> [default] >> and commenting away the rsync:// >> >> I've run port selfupdate multiple times. However, it won't update the dports >> tree. if I run port -d sync, i get the following output: >> $ port -d sync >> DEBUG: Synchronizing ports tree(s) >> Synchronizing local ports tree from >> file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ >> Creating port index in >> /opt/local/var/macports/sources/svn.macports.org/trunk/dports >> >> Total number of ports parsed:0 >> Ports successfully parsed: 0 >> Ports failed:0 >> >> So, where did I do wrong? > > MacPorts has not yet been updated to properly handle subdirectories of > Subversion 1.7+ working copies. In Subversion 1.6.x and earlier, every > directory in a working copy contained a directory called ".svn" where > Subversion stored metadata. Before allowing a directory to be used as a sync > directory, MacPorts checks whether the directory contains a ".svn" directory: > > https://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=90368#L2190 > > As of Subversion 1.7, only the root directory of the working copy contains a > ".svn" directory, and since trunk is the root of your working copy, but > you're pointing MacPorts at the dports subdirectory of that, it won't work. > > I myself have not yet upgraded to Subversion 1.7 so I have not run into this > yet. But you should be able to work around it by checking out a separate > working copy of dports and pointing your sources.conf at that. It doesn't > have to be in /opt/local/var/macports/sources if you don't want it to; > personally, I have mine in $HOME/macports/dports. Aha, this is indeed the case. Thanks! And sorry for the double posting, I had some issues on send, but they are now resolved. Thanks again! Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
SVN tree not updating
Hey! I'm Aljaž, the noob ;) it looks like I'm having some difficulties setting up the svn tree, I decided to check out the entire trunk, so i created /opt/local/var/macports/sources/svn.macports.org/ and checked out trunk in /opt/local/var/macports/sources/svn.macports.org/trunk. Now i have Makefile,base,doc,doc-new,dports,www under the trunk directory. If I run svn up in /opt/local/var/macports/sources/svn.macports.org/trunk/dports, it refreshes correctly from svn. I've modified /opt/local/etc/macports/sources.conf, adding file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ [default] and commenting away the rsync:// I've run port selfupdate multiple times. However, it won't update the dports tree. if I run port -d sync, i get the following output: $ port -d sync DEBUG: Synchronizing ports tree(s) Synchronizing local ports tree from file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ Creating port index in /opt/local/var/macports/sources/svn.macports.org/trunk/dports Total number of ports parsed: 0 Ports successfully parsed: 0 Ports failed: 0 So, where did I do wrong? Thanks, Aljaž Srebrnič -- -- My public key: http://bit.ly/g5pw_pubkey ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
