Re: Issues with oudated ports / GitHub

>> On Oct 7, 2016, at 10:59 AM, Marcel Bischoff wrote: >> It pains me to say that Homebrew is running circles around MacPorts in the department of current available packages. >>> >>> [citation needed] ;-) >> >> Gladly. I have written a small script to check that. Here are a few of >>

Re: GSoC Project: Revitalizing Pallet

On 02 Jun 2015 René J.V. Bertin wrote: > Actually, MacPorts is a clone or descendant of BSD port, no? > Isn't there a BSD variant (FreeBSD, OpenBSD, PC-BSD, ...) that > already developed a GUI interface to the CLI command that could > be ported (and not necessarily to Cocoa). pkgng isn’t anymor

Re: GSoC Project: Revitalizing Pallet

On 02 Jun 2015, at 03:56, Kyle Samamons wrote: > It'll be a lot of work, and hopefully either myself, or some other fearless > developers, will be able to keep it up and maintain it after the summer is > over. How do you plan to publish your work in progress? Are you going to use exclusively M

Re: Friendly talk

On Aug 29,David Strubbe-2 wrote: > What the advantages and disadvantages does Homebrew have with respect to > MacPorts? If you are very passionate about Cocoa and dynamic languages, I think you can’t ignore Ruby and GitHub. There’s a very vibrant community growing around the CocoaPods, a new p

Re: Webkit-gtk3 or webkit-gtk-devel

On Apr 4, 2013, at 12:49 PM, Ryan Schmidt wrote: >> In summary, I think that MacPorts could simply limit to these three distinct >> ports: >> >> webkit-gtk >> webkit-gtk3 >> webkit2-gtk3 > > webkit-gtk was already updated to version 2. Is there a reason to keep > version 1 around? Webkit2

Re: Webkit-gtk3 or webkit-gtk-devel

Jeremy Huddleston Sequoia wrote: > I'm on the fence between subport and variant for gtk3. Thoughts? I think that providing two different ports, webkit-gtk and webkit-gtk3, is the unavoidable solution as FreeBSD and NetBSD's pkgsrc did. We could also follow strictly the naming conventions used

Re: Webkit-gtk3 or webkit-gtk-devel?s

On Fri Mar 29, I wrote: > WebKitGTK+ 2.0.0 has been released and many patches of the current > port aren't needed anymore. Gtk+3 and GObject Introspection are > well supported and I think that MacPorts shouldn't disable them > by default from now on. I tried to compile the updated port by Jerem

Webkit-gtk3 or webkit-gtk-devel?

WebKitGTK+ 2.0.0 has been released and many patches of the current port aren't needed anymore. Gtk+3 and GObject Introspection are well supported and I think that MacPorts shouldn't disable them by default from now on. Gtk-OSX, which is based on the official JHBuild scripts, offers two different m

Re: Is it worth persevering with Macports_Framework?

On 11/02/2013, Ian Wadham wrote: > I see that Cocoa has NSTask and NSPipe classes and that Guido's > Guigna app is using them in its GuignaAgent class. I also like this approach > because there is loose binding between the processes. A more canonical approach would require to implement a helper

Re: Is it worth persevering with Macports_Framework?

On 10/02/2013, Ian Wadham wrote: > Maybe there is scope for a simpler interface to Macports, such as > running scripts and intercepting the output, but I have not looked at > that. You can have a look at the sources of Guigna I published on GitHub: . It is at

Re: macports-dev Digest, Vol 66, Issue 52

On Feb 19, 2012, at 7:20 AM, macports-dev-requ...@lists.macosforge.org wrote: > We have the MacPorts.app GUI (also known as Pallet), where most of the > work was done in previous editions of Google Summer of Code. In my humble opinion, the use of the predicate editor at the top of the window is

Re: Hosting and reviving the Porticus source code

On Feb 19, 2012, at 4:30 AM, Joshua Root wrote: > (Even a note from the author saying "Consider the Porticus > source code to be under license X" would be fine Richard Laing has updated the project's home page and now he states: "If someone wants to put it up on GitHub feel free, BSD license"

Re: Xcode 4.3 missing X1SDK?

On Feb 17, 2012, at 11:01 PM, Ryan Schmidt wrote: >> >> "Yep, Apple has depreciated it. They give you a link to download quartz >> when you launch X11.app in /Applications/Utilities" >> >> () > > *X*Quartz, please. Quartz is a graphics techno

Re: [MacPorts] #12966: BUG: avahi cannot find Python module gtk

On Apr 8, 2008, at 10:53 AM, Randall Wood wrote: Does someone want to reach out to this person? This problem has been solved some months ago and it is due to the new Apple's libtool in Leopard. I applied a simple workaround to many python ports whose makefiles make use of the flag "-export-sy

Re: scrollkeeper

On Apr 7, 2008, at 9:10 AM, William Davis wrote: As I previously reported: I did (and still do) have rarian installed. Have you already tried to reinstall it with "sudo port -f uninstall rarian ; sudo port install rarian" ? -Guido ___ macports-d

Re: scrollkeeper

On Apr 7, 2008, at 8:20 AM, William Davis wrote: macintosh:~ frstan$ port installed rarian The following ports are currently installed: rarian @0.8.0_0 (active) macintosh:~ frstan$ OF COURSE I HAD PREVIOUSLY INSTALLED RARIAN! Then "port contents rarian" should provide: Port rarian contains

Re: Port sqlite build error:

Error: The following dependencies failed to build: apache2 apr-util sqlite3 Error: Status 1 encountered during processing. See http://trac.macosforge.org/projects/macports/ticket/14938 A simple "sudo port clean sqlite3 ; sudo port install sqlite3" should work. This trick always work in MacP

Re: Ticket #14796 (pike): please commit

Jordan K. Hubbard wrote: > You need to read my entire message again, making a more > sincere attempt to understand it this time. Everything you're > asking for comes from creating that infrastructure. I have already expressed my specific current efforts: I am not interested in the integrity of hu

Re: Ticket #14796 (pike): please commit

On Apr 1, 2008, at 6:46 AM, Jordan K. Hubbard wrote: Well, let's also be careful not to conflate multiple, desirable goals here - that only increases the size of the task and the attendant risk of seeing nothing happen. My initial propose was very simple and pragmatic, indeed. We don't ha

Re: Ticket #14796 (pike): please commit

On Mar 31, 2008, at 6:53 PM, Rainer Müller wrote: On trunk several pieces of Gnome 2.22 have been already committed sparsely without coordination: almost a nightmare. Why is this a nightmare? Gnome ports got no maintainer, so others did what they could. So did I: as I said, I am trying to

Re: Ticket #14796 (pike): please commit

On Mar 31, 2008, at 6:53 PM, Rainer Müller wrote: Step up and provide ports for them if you think they are valuable. Done: I have proposed the first WebKit's portfile, I have fixed it and I have patched the makefiles for all the ports depending on PyGTK: I asked for commit privileges to PortMg

Re: Ticket #14796 (pike): please commit

On Mar 31, 2008, at 4:03 PM, Rainer Müller wrote: Sure, but it doesn't integrate with MacPorts and installs outside the registry. So it will rather screw up your existing installation. Let's talk on more practical terms. On trunk several pieces of Gnome 2.22 have been already committed spars

Re: Ticket #14796 (pike): please commit

On Mar 31, 2008, at 3:16 PM, Rainer Müller wrote: 1. An open repository where to exchange precompiled archives in order to avoid the lengthy compilations of the dependencies. Which requires 2. I meant a simple hosting infrastructure outside of the subversion repository where the submitter

Re: Ticket #14796 (pike): please commit

On Mar 31, 2008, at 12:42 PM, Florian Ebeling wrote: I come to the impression that there are too few committers. What do others think on this? We are in serious need of: 1. An open repository where to exchange precompiled archives in order to avoid the lengthy compilations of the depende

Re: rarian and scrollkeeper

On Mar 30, 2008, at 11:33 AM, Randall Wood wrote: I know that rarian is supposed to be a drop-in replacement for scrollkeeper. but is it really? Yes, scrollkeeper has been deprecated in Gnome 2.22: rarian provides its own substitutes of the "scrollkeeper-*" commands required for backward comp

Re: Trying porting back WebKit

On Jan 25, 2008, at 8:23 AM, Randall Wood wrote: I am getting the same error and have reported it at http://bugs.webkit.org/show_bug.cgi?id=17001 if you wish to follow it. Thanks. I have applied the patch by Mark Raw in the attached updated portfile. Now the compilation fails towards the en

Re: Trying porting back WebKit

On Jan 25, 2008, at 7:24 AM, Randall Wood wrote: Your best bet maybe to work with the WebKit developers, as WebKit is not Apple (its mostly Apple, but not just Apple). Indeed, the problem is that the includes of AplicationServices.framework are evaluated even when PLATFORM(GTK) is defined.

Trying porting back WebKit

The GTK port of WebKit is being used by more and more Gnome programs as an alternative to the Gecko engine, so I have tried to create the attached minimal portfile for "webkitgtk", but the compilation fails with the following error: /opt/local/include/X11/X.h:108: error: conflicting declaration

/opt/local/bin/python2.5 as default MacPorts' "python" interpreter

Currently there is no official "python" interpreter for MacPorts (in the past there was a link to python2.3 even when python24 was installed, IIRC) but many Python programs (or their shebang lines) expect a "python" command in the PATH, otherwise Leopard's python2.5 is picked from its symbolic lin

32937] trunk/dports/gnome/evince/Portfile

Randall Wood wrote: > You might want to note that for the GNOME project, packages > with a version x.y.z where y is an odd number are normally > considered unstable, not fit for daily use. When I submitted the patch to make djvulibre compile again by adding the -dylib_file option to the linker (a

Re: [32932] trunk/dports/news/xpn/Portfile

On Jan 15, 2008, at 10:58 AM, Ryan Schmidt wrote: Coincidentally, could you please use "use_configure no" instead of "configure {}"? You might also want to add "universal_variant no". Thanks: I have corrected the Portfile with -

Workaround for PyGTK missing symbols under Leopard

I tried to compile the latest Deluge (a BitTorrent client) and XPN (an experimental Python newsreader) after applying a workaround to py25-gobject, py25-cairo, py25-gtk and dbus-python25, all of which were reporting missing symbols under Leopard: the patches simply exclude the option "-export-symb

Re: New "file delete" implementation breaks ncurses

On May 8, 2007, at 9:16 PM, Kevin Ballard wrote: That's not actually a fix. You should revert it, then change it to two different commands a - delete for the real folder, and a 'file delete' for the symlink. The reason this isn't a fix is it will not delete the symlink this way. My worka

Re: New "file delete" implementation breaks ncurses

On May 8, 2007, at 2:47 PM, James Berry wrote: If I understand Guido's suggestion, the workaround is to the Portfile, not to trunk, right? The problem is that "delete" now tries to follow the orphan symbolic links. IMHO, the "can't find" message is confusing: the orphan links should simp

New "file delete" implementation breaks ncurses

After the changes to the "file delete" implementation, the installation of ncurses fails because it tries to follow the target of a symbolic link. By reversing the order of the arguments from delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo into delete ${destroot}${prefix

Re: Archive mode broken after the latest updates

On Apr 20, 2007, at 4:12 PM, James Berry wrote: Hopefully we'll get this cleaned up soon. In the mean time, you can turn off archive mode in your ports.conf file. I have solved temporarily with another one-liner, by changing set unarchive.env "$gzip -d -c ${unarchive.path} |" into set un

Re: Pallet

On Mar 16, 2007, at 2:38 AM, Randall Wood wrote: You can still download it from here: Thank you. Hi Randall. Your code to parse the PortIndex has illuminated me! (There are however some memory leaks since you're not releasing enough). Two year

Re: Pallet

Randall Wood <[EMAIL PROTECTED]> wrote: Is the old dp_cocoa code available anywhere? You can still download it from here: ___ macports-dev mailing list macpo