Re: How to use git
On 20/08/2016, at 11:51 PM, Ryan Schmidt wrote: > > On Aug 19, 2016, at 10:24 PM, Lawrence Velázquez wrote: > >> Any documentation we write should be written specifically for developers >> >> 1. who are accustomed to using Subversion, and >> 2. want to translate *their MacPorts workflow* to Git. >> >> We shouldn't expend effort rewriting a sloppier version of every generic >> "this is how version control works" Git tutorial on the Web. There's quite >> enough of that. > > Maybe what we really need is documentation for MacPorts developers that just > covers how to do whatever they need to do, using git. (I don't know if we had > such a document for Subversion.) Things like... When first starting to > contribute, fork the repo, clone the fork to your Mac; if you already have a > fork, update it with the latest changes (how?). Create a branch for your > changes. Make your changes in your text editor. Use "git diff" to see the > changes. Use "git commit" to commit them. Use "git push" something to push > them to GitHub. Submit a pull request on GitHub. When the pull request is > accepted, delete your branch. Fork the repo?? The command for first use is just "git clone". This gets you a local working copy of the entire repository and its change history at the current time. For small changes, edit, test and "git commit -a" (all) or "git commit filename(s)" --- locally. For large changes, start a local branch and later merge it with your local master branch. The commands "git status", "git log" and "git diff" help you keep track of changes in progress and what is committed or uncommitted. To publish your local commits, first use "git pull --rebase origin master" to fetch the latest central changes and merge them into your local repository, then use "git push origin master". The --rebase option gets your changes and the central ones into a reasonably logical and readable sequence. Use "git pull --rebase origin master" on its own if you just wish to get up to date with changes to the central repo. And that is (almost) all the "gittery" I have needed and used on KDE development work in the last 4 years. The one exception is that, during the run-up to a KDE Applications release, the release guy makes a branch on the central repository for the new release and development can then continue on the master branch. If you are going to fix a bug, you need to retrieve the new branch from central and make the same fix in two branches. I can never remember exactly how to do that… ;-) … but I have the recipe in an email somewhere... Cheers, Ian W. > At various step along the way, we could add "historical note" boxes showing > how those step were done with Subversion. At some point in the future we'll > probably want to remove the Subversion historical information, but still have > the git instructions. > > ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to use git
On 20/08/2016, at 1:24 PM, Lawrence Velázquez wrote: >> On Aug 19, 2016, at 11:16 PM, Ian Wadham <iandw...@gmail.com> wrote: >> As a KDE developer (and spectator of the changeover from svn to git) I have >> found >> this cheat sheet very useful, but not quite covering all situations I have >> encountered. >> http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf > Any documentation we write should be written specifically for developers > > 1. who are accustomed to using Subversion, and > 2. want to translate *their MacPorts workflow* to Git. > > We shouldn't expend effort rewriting a sloppier version of every generic > "this is how version control works" Git tutorial on the Web. There's quite > enough of that. I can thoroughly recommend the cheat-sheet I referred to. It is a good start. It was put together by Zack Rusin, a prominent KDE and Qt developer, and originally appeared on his blog. It is just one page. I quoted the PDF version above because it is high-res and easily readable, although the web address sounds unpromising. When coding I keep a copy in a folder on my desktop at all times. I wish more Open Source software had such summaries. So please have a look. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to use git
Hi Lawrence, On 20/08/2016, at 1:24 PM, Lawrence Velázquez wrote: >> On Aug 19, 2016, at 11:16 PM, Ian Wadham <iandw...@gmail.com> wrote: >> >> Qt and KDE moved from svn to git a while back. IIRC it was quite an effort >> for a >> few individuals to port all the repositories across and preserve all the >> history. >> They had to write lots of scripts and check all the results. I hope it is >> easier now. > > We'll actually be using svn2git for the migration, so in a very real sense we > have you (collectively) to thank :) > > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git I don't know if this applies to Macports, but KDE did a lot of splitting of SVN "module" repositories into individual project repositories on git. For example, the KDE Games module on SVN went from one repository to about 40 repositories: one for each game and library. This was to limit the overheads, for developers, of cloning git repositories in their local machines, but it made building "everything" (i.e. collections of repositories) a little harder. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to use git
On 20/08/2016, at 11:49 AM, Mark Anderson wrote: > I use git (and Github Enterprise) in my day to day work. I can help out. > > Another good (free (as in beer)) client is SourceTree > https://www.sourcetreeapp.com/ Qt and KDE moved from svn to git a while back. IIRC it was quite an effort for a few individuals to port all the repositories across and preserve all the history. They had to write lots of scripts and check all the results. I hope it is easier now. As a KDE developer (and spectator of the changeover from svn to git) I have found this cheat sheet very useful, but not quite covering all situations I have encountered. http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf Also there are web pages on svn v. git "equivalence" (as far as it goes, which is not very far IIRC). I don't know how Github works, but in raw git you have your own local copy of the repository at all times, so it does not matter so much to a single developer if his/her central copy is down for a few days. Multiple developers on the same repository would feel more pain or less, depending on the degree of overlap of their work on particular files. In principle, developers can commit to each others' local git repositories, rather than via central, but I do not know how much that is done in practice. In KDE and Qt people always go via central AFAIK. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
Hi René and Nicolas and everybody,
On 07/01/2016, at 1:44 AM, René J.V. Bertin wrote:
> I'm sure you've noticed that I'm making progress with ports for KF5.
Yep. Good on yer, René!
And it is nice to see that David Faure and other KDE core developers are taking
an interest at last...
> KF5 is designed to allow for step-by-step migration of applications from KDE4
> to KDE5, but with the underlying idea that once an application has been
> migrated it's the better version
For KDE applications, "better version" = "only officially released version".
There is only one
'master' branch in each KDE repository and that is the branch from which
releases are made.
It is the branch where new features are developed and bugs are fixed. A
release is "maintained"
for a few months and, during that time, bug-fixes are supposed to be backported
into the release.
> and users are not supposed to feel the need to keep the older version around.
In principle, a KF5 application, when first released, should have the same
functionality as
the KDE4 application it replaces. IIUC, the difference is supposed to be fewer
extraneous
dependencies on libraries that used to be dragged in by using kdelibs4 and some
shifting
of dependencies from KDE to Qt library classes, the most troublesome of which
is the shift
from KStandardDirs to QStandardPaths… ;-)
Porting to Frameworks and Qt 5 is done on a 'frameworks' branch of the app's
repository and
finally merged into 'master'. If that work is done quickly, there should be
few large changes
on the 'master' branch during the porting work.
In practice, of course, porting work does get held up, sometimes for months,
and it is possible
(but unlikely?) for a lot of work to occur outside the 'frameworks' branch
while it is open.
I have just been assisting a guy in porting KMahjongg, a KDE game. It had a
huge, years-old
branch that that ported some of the code from KDE 3 to KDE 4, but had never
been merged
into 'master.… That branch and 'master' contained a dozen or more bug fixes
and there were
graphics glitches in the KDE 3-to-4 port that had to be fixed. So yes, in this
case the KF5
version, to be released in April, will definitely be "better".
Hopefully, that kind of mess will be the exception rather the the rule… but
there are an awful
lot of unmaintained applications in the KDE code base these days. The
workforce is a small
fraction of the 500 or so developers KDE 4 had 5-8 years ago… :-(
> I have some issues with that premise
Having said the above, I agree entirely, René. I have, and always have had,
issues with the
idea that a newer version is automatically better...
I have experienced many regressive releases of KDE apps, some due to apps
changes and
some due to library changes --- even of my own apps, in cases where I had made
no change.
Also, if there is ever a KF5 port of KMyMoney, I would hesitate to entrust all
my finances to it
on day one… ;-) … with all due respect to Marko and the KMyMoney developers.
> and know of nothing in MacPorts that would make it the default behaviour to
> force a choice between either KDE4 or KF5 versions of an application
> (fortunately, with all the inter-dependencies).
One hope I have is that MacPorts will help us avoid the day when KDE 4 and Qt 4
libraries are
no longer released and apps that have not yet been ported to KF5 will just
quietly disappear… :-(
On Linux, we lost a quite a few good KDE programs in the transition from KDE 3
to KDE 4.
> KF5 software doesn't leave a lot of leeway to configure it such that it won't
> clash with KDE4 versions of the same, in line with said premise. Fortunately
> most of the time the conflicts are limited to non-crucial things in
> ${prefix}/share, usually even things that were not changed w.r.t. their KDE4
> version. So most of the time, the +kde4compat variant of a KF5 ports just
> omits files that are already installed by the KDE4 version of the port.
The strategy on Linux is that an app is either KDE4 or KF5, no overlap. Apps
and the Frameworks
library are released separately, on different schedules. See
https://techbase.kde.org/Schedules …
Apps are released in KDE Applications YY.MM releases every four months and can
be a mix of
KDE 4 and KF5 apps. On Linux, KDE 4 libraries, Frameworks, Qt 4 and Qt 5 can
co-exist, but
that is all. Each app is either KDE 4 or KF5.
It would be very nice if MacPorts could be more flexible than that.
> There are however certain modifications that have to be made to (certain)
> KDE4 ports:
>
> - The most frequent conflict occurs at the level of headerfiles. This can be
> avoided very easily by building KDELibs4 with
> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers
> under include/KDE4 but also records the path in a cmake module, so that it is
> inherited by all dependents.
> The nice thing is that this change doesn't break binary compatibility, so I
> have set it
Re: New Mac OS Forge administrator
On 21/11/2015, at 7:15 AM, Bradley Giesbrecht wrote: > Bam, confidence restored! Congratulations, Ryan! It is great to know that you will be the person handling this important job. I hope you will still find some time to answer queries on the list or that someone else will step into your shoes. I have learned and benefited so much from your posts in the last few years and I am sure others would agree. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 06/08/2015, at 4:14 AM, Kyle Sammons wrote:
Hey everyone,
Currently I'm at a fork in the road for the Revitalizing Pallet GSoC
project, and was hoping to crowd source some ideas about how to deal
with the Apple authorization framework used to get super user privileges
to allow 'port' to execute correctly under the hood. This task is the
last major one on my GSoC queue. There are three possible roads to go
down here; I don't know which one is the best or correct one, hence
the crowd sourcing here.
Here is another possibility, which I used in Fossick… Note that I went the
command-line route and used tail -f to receive output asynchronously.
You may not need that if you have gone the other route. The guts of the
authorisation is to use AppleScript. Hope this helps.
/**
* This method uses AppleScript to run a privileged Unix script asynchronously
* in the background, with output to a file (e.g. a script containing MacPorts'
* port install software item command). The NSTask object defined above
* uses tail -f to collect the output as it occurs. The return string is nil
* if the script started OK or contains an error text if it failed. AppleScript
* is run with administrator privileges, which means that it pops up the usual
* Apple request for an admin password when installing non-Apple software.
*/
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath;
---
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath
{
NSDictionary * error;
NSString * script = [NSString stringWithFormat: @do shell script \
\'%@' '%@' 21 \ \
with administrator privileges \
without altering line endings,
filePath, outputFilePath];
NSLog(@SCRIPT: %@, script);
NSAppleScript * appleScript = [[NSAppleScript new] initWithSource:script];
if ([appleScript executeAndReturnError:error]) {
NSLog(@AppleScript running! '%@' '%@' 21 , filePath,
outputFilePath);
// Start the output-watcher.
self.task = [[NSTask alloc] init];
[self.task setLaunchPath:@/usr/bin/tail];
[self.task setArguments:[NSArray arrayWithObjects:
@-f, outputFilePath, nil]];
self.tailOfOutput = [NSPipe pipe];
self.errorOutput = [NSPipe pipe];
[self.task setStandardOutput: tailOfOutput];
[self.task setStandardError: errorOutput];
[self.task setStandardInput: [NSPipe pipe]]; // No standard input.
[self.task launch];
[[self.tailOfOutput fileHandleForReading] readInBackgroundAndNotify];
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector (receiveOutput:)
name: NSFileHandleReadCompletionNotification
object: nil];
return nil;
}
else {
NSLog(@Failed to run AppleScript!\n%@, error);
return [error description];
}
// TODO: User cancelled. is a possible error reason (i.e. hit Cancel
//instead of entering a password). OS X seems to allow unlimited
//failed attempts to enter the password.
}
0. Do nothing; leave the current code in place, but continue to ignore
it; require the user to run it with superuser privileges;
snip
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC Project: Revitalizing Pallet
Hi Kyle, On 02/06/2015, at 11:15 AM, Kyle Sammons wrote: Ian wrote: Well, Kyle, if you are interested, I could send you the code of Fossick and a specification/design document. You would be welcome to re-use any of it or any of the ideas contained in it Thanks for the offer, Ian! I'm working on getting the darn thing to compile on modern versions of OS X first, then I'll be considering different options and moving forward there. I'll definitely keep your offer in mind, and I'll make sure to reach out to the community before I do anything too crazy to make sure it's what we really want/need. :) Watch out for the evolutionary changes in Cocoa/OSX/ObjectiveC across successive versions of OS X !!! I was particularly having problems figuring out exactly what to write and for which OS X, in the light of *major* changes in: - Dynamic storage management (DIY vs. garbage-collect vs. reference-counting), - The GUI designer (Interface Builder) and its relationships (or links) to generated and hand-written chunks of code. Fundamental stuff. It did not help that I was also teaching myself Objective C… :-) nor that I have been designing and coding for various GUI and forms designers for about 40 years now. Each one is or was unique in its own way. Maybe Pallet won't even work with newer versions of Xcode, even if you can compile it. Pallet code is quite old now. I was (and still am) using Lion (OS X 10.7.5) and Xcode 4.6.1 and do not remember any particular problems compiling Pallet. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC Project: Revitalizing Pallet
Hi Kyle, On 07/05/2015, at 8:14 AM, Kyle Sammons wrote: My name's Kyle Sammons and I've been accepted into this years GSoC. I was also a GSoC participant for MacPorts last year working on Project Clean-up Stuff, which created the port doctor and port reclaim commands. I had been hoping to hear from you. Unfortunately personal circumstances have delayed my reply, so I hope it is mot too late. My project for this year is to get Pallet, the MacPorts GUI, up and running with the support for newest versions of OS X and XCode. After that, I intend to give it, and the Framework, some more modern-day-MacPorts features. No features are set in stone as of yet, but I'm considering adding doctor, reclaim, rev-upgrade, a progress bar, or possibly even the ability to edit portfiles. A couple of years ago I set out to revitalise Pallet. At the same time I had a look at other MacPorts GUIs: Porticus, Guigna and PortAuthority (non-free). I thought the Gui and functionality of Pallet could do with a lot of improvement. It was originally a GSoC project years ago. The mentor of that project (I think) whipped up a special library for interfacing to MacPorts, but the details of it were already somewhat outdated two years ago. There was also an interface to a notifier called Growl that was causing me difficulty. So, rather than get embroiled in all that before starting working on Pallet itself, I decided to avoid working on Pallet. Instead, I started to work on a new GUI which I named Fossick. It takes rather a different design approach - similar to that of Guigna and PortAuthority. Fossick uses only Objective C, Cocoa and Unix utilities and it interfaces to MacPorts by using only the port command and the portindex file. My idea is that this is not only easy and straightforward, but also more future proof than a special-purpose library, because the port command does not change much over time and edits to canned commands can easily be made if/when it does. Once again, none of these potential features are set in stone so if you guys would like to suggest any that would be nice to have, or have some questions/concerns about the project, feel free to shoot me an email. Fossick was reviewed on this list about two years ago. The reviews were lukewarm. I got the impression that guys here are much happier with a command-line or a script than a GUI and cannot see a lot of point in having a GUI for MacPorts. In my opinion, a really good and complete GUI would liberate MacPorts from its somewhat geeky image and make Open Source software accessible to a much wider range of Apple Mac users (i.e. some of the people you see at the Apple Store). However, I am not sure that this is what the MacPorts and FOSS communities would really want. It could be a Pandora's Box for them. Don't get me wrong. I think the MacPorts community is great and does a great job, especially by helping the occasional user on macports-users who asks How do I use a command-line? and above all by being patient. Some other lists I am on are not so welcoming. Anyway, I felt a bit discouraged about Fossick and decided to shelve it. I still use it occasionally, to perform search sessions on the MacPorts base. Well, Kyle, if you are interested, I could send you the code of Fossick and a specification/design document. You would be welcome to re-use any of it or any of the ideas contained in it. Should be a great summer. Yes, it will. All the best, Ian W. KDE Games developer, Author/maintainer of KGoldrunner, KSudoku, KJumpingCube, Kubrick and Palapeli ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] QSP - we're getting somewhere?
Hi René,
Well, I think we really are (getting somewhere). Keep pushing! :-)
On 12/03/2015, at 5:44 AM, René J.V. Bertin wrote:
Not that it's getting any easier to convince the powers that be what *I*
think will be ideal for the QStandardPaths in port:qt5-mac, but at least I
seem to have gotten the message across that any hard-coded solution is
sub-optimal.
My latest proposition is here:
https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=275639page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-275639
I have read through the patch in detail and it looks great. A couple of points:
a. Is it necessary to initialise QStandardPaths::usingXDGLocations in every
platform file (android, blackberry, etc.)? Could it be done in
conditional
code in qstandardpaths.cpp?
b. How does the qstandardpaths_use_xdg.cpp component work? I guess
it is intended to be loaded with any build that wants to use Qt with XDG
paths (e.g. all KF5 Frameworks and apps), but what actually makes it
execute and when?
The only path that remains a bit elusive is the (Generic)ConfigLocation; it's
/etc/xdg on Linux, but does it really make sense to set it to
${prefix}/etc/xdg in MacPorts (when using XDG-style locations, of course)?
I see that MacPorts currently uses /opt/local/etc and has quite a few subdirs
in it already, including /opt/local/etc/xdg, which contains a few things:
Tara:~ls /opt/local/etc/xdg/*
/opt/local/etc/xdg/autostart:
at-spi-dbus-bus.desktop gsettings-data-convert.desktop
/opt/local/etc/xdg/menus:
kde-information.menukde4-applications.menu
So perhaps it does make sense to re-use ${prefix}/etc/xdg in Qt5/KF5.
All the best, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends
On 12/02/2015, at 10:34 AM, Brandon Allbery wrote: On Wed, Feb 11, 2015 at 6:31 PM, René J.V. rjvber...@gmail.com wrote: I take that to mean that doing fork() doesn't oblige you to do an exec() afterwards, it's that you cannot do a fork() from a process that's not been started through exec. I will guess that this is related to the fact that such processes are actually started by launchd, and must play by launchd's rules (including not using fork()) so launchd can keep track of them. This would also imply that fork() is actually acceptable as long as the forked processes don't try to use the UI, but are merely background worker processes that communicate with the foreground process if they need UI interaction or etc. FWIW, there is some special code in the main() program of kdeinit5 that causes it to fork and re-exec *itself* on Apple OS X (the second time with a --no-fork arg) --- before it goes on to do its main work. For more detail, in frameworks/kinit/src/kdeinit/kinit.cpp code, see lines 1705 and 1576ff. The comments at the head of the second reference say: /** Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has always had issues on Mac OS X, but as of 10.5 is explicitly disallowed with an exception. As a result, in the case where we would normally fork and then dlopen code, or continue to run other code, we must now fork-and-exec. See CoreFoundation and fork() at http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html */ When I can get Qt 5 to build and then Frameworks and some KF5 apps, I propose to start tracking down what is happening on Apple OS X in some of the paths that kdeinit5 and friends are following, starting with what KToolInvocation is doing in a few major cases. For a rough but obviously now-out-of-date guide see: https://techbase.kde.org/Development/Architecture/KDE4/Starting_Other_Programs Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ~/.macports
On 10/02/2015, at 9:37 PM, René J.V. Bertin wrote: On Tuesday February 10 2015 21:08:18 Ian Wadham wrote: Hi Ian, Taking this to macports-dev... As I said, my ~/.macports on my Mac appears to be unused since november 2013 or so. However, the tiny test install I have on my Linux system does contain a lot of things that appear to be copies, but also things like home the function of which is unclear to me. A quick check in etc/macports/macports.conf didn't reveal anything that could explain this difference. And I really have no idea what in the Qt portfiles could cause this, esp. since it clear doesn't affect my own system. It's evident that you can throw out the qt4-mac stuff. But what does `port work qt5-mac-devel` return? It returns NOTHING, zilch, no output. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ~/.macports
Hi guys, I am the person who has this problem --- about 3 Gb of stuff in ~/.macports and a Time Machine that goes berserk, running mtmd [1] at about 90% CPU during port clean for example. I have had to turn Time Machine off. On 10/02/2015, at 10:47 PM, Clemens Lang wrote: - On 10 Feb, 2015, at 11:37, René J.V. Bertin rjvber...@gmail.com wrote: As I said, my ~/.macports on my Mac appears to be unused since november 2013 or so. However, the tiny test install I have on my Linux system does contain a lot of things that appear to be copies, but also things like home the function of which is unclear to me. ~/.macports is used instead of /opt/local/var/macports when you run MacPorts in a root installation but without root privileges. As such, MacPorts will put downloaded tarballs, work directories and build support files there when you, for example, run port build qt4-mac # note the lack of sudo The home directory in there is used as a target for $HOME during build, because some builds require a writable home but the default of the macportsuser is not, and we don't want to clutter your real home with whatever $buildsystem thinks it wants to put there. Thank you for a very clear explanation. And thank you, too, for Macports' concern at not wanting to clutter my real home directory. That is most professional. You can simply delete ~/.macports Do you mean rm -rf ~/.macports? I am in the middle of a build of René's new qt5-mac-devel port, which failed with compiler error messages in my machine. Maybe a port clean first?… But then there will still be downloaded tarballs and maybe untarred source code in there… I do not mind starting from scratch. The download and extract steps took only about an hour. On 11/02/2015, at 1:37 AM, Brandon Allbery wrote: On Tue, Feb 10, 2015 at 9:30 AM, René J.V. rjvber...@gmail.com wrote: On Tuesday February 10 2015, Brandon Allbery wrote regarding Re: ~/.macports Not supported, not a great idea, not an outright installation-breaking idea. (Among other potential problems, a Portfile bug could nuke your home directory; with a dedicates macports user, it would get a permission error.) True, but that kind of bugs are unlikely to appear in released ports, or so I'd hope. In any case I've never yet had this happen to me. I think someone did have this (try to) happen to them recently-ish. I also know people who had a Homebrew installation eat itself, because it does everything as the logged-in user. I strongly prefer safety in things like this. Amen to that, brother! I have probably done more builds than some people have had hot dinners, going back many decades. Taking shortcuts never pays… The few seconds or minutes you might save are sooner or later eclipsed by hours of stuffing around, as I am experiencing currently. From now on I want to use sudo, have a local-port structure that is NOT in /opt/local and have NO modifications of standard permissions in /opt/local. But how do I get there, *safely*, from where I am? A crashed port destroot run, a garbaged-up home directory, a local-port structure inside /opt/local and maybe a wobbly portindex. I am not an expert in MacPorts, just a user… but I still have a little intelligence and knowledge of UNIX left… :-) Well, I am a KDE developer too, which is why I am doing this stuff. We need to prepare for KF5/Frameworks in MacPorts, and to be able to install and run qt4-mac, qt5-mac, KF5 apps and KDE4 apps concurrently. @René: I need a new set of instructions for running the qt5-mac-devel build. Best regards, Ian W. [1] mtmd = Mobile Time Machine Demon, man 8 mtmd ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
An odd port
Hi guys, Is there a good reason why we have the yersinia port on MacPorts? Please read the description in full. Best regards, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: An odd port
On 12/01/2015, at 8:30 AM, Brandon Allbery wrote: On Sun, Jan 11, 2015 at 4:28 PM, Clemens Lang c...@macports.org wrote: - On 11 Jan, 2015, at 22:21, Ian Wadham iandw...@gmail.com wrote: Is there a good reason why we have the yersinia port on MacPorts? Please read the description in full. I don't see a problem with it? We have several other ports related to network security that could be equally disruptive depending on how you use them. If you're not comfortable with what it does, don't use it? Agreed; the boundary between black hat and white hat security tools is nonexistent these days. OK, thanks. I was just checking… Yersinia pestis = bubonic plague (aka the Black Death), so an odd name for a piece of software. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: (un)setting environment variables from a Portfile
In case anyone does not already know, QTDIR is an env variable
a developer can use when developing software based on Qt or
a development (test, non-standard) version of Qt.
I always export QTDIR=/opt/local when I am developing or building
with a bleeding-edge version of KDE libraries, externally to MacPorts.
If I built my own Qt (heaven forbid, it takes too long), I would point QTDIR
to the root directory of that Qt.
So yes, a foreign QTDIR value would not be a good thing to have around
when building Qt...
@René: I am hoping I will be able to point QTDIR to *either* qt4-mac
or qt5-mac when developing and testing KDE apps in the future, as
MacPorts goes through the transition from KDE 4 to KF 5. I am worried
that having one Qt in /opt/local and another in /opt/local/libexec will not
achieve that cleanly… :-( Also, I am hoping that there will be Qt apps
in /Applications/MacPorts/Qt5 that are different from the ones already
in the Qt4 subdir, such as an Assistant.app that finds, indexes, searches
and browses Qt 5's documentation not Qt 4's and a Designer.app that
outputs form-designs in whatever file-format is used by Qt 5.
On 12/01/2015, at 7:03 AM, René J.V. Bertin wrote:
On Sunday January 11 2015 14:49:21 Michael Dickens wrote:
PortGroup (qt4; I assume qt5 too), you'll see an if statement:
{{{
if {![info exists building_qt4]} {
configure.env-append \
QTDIR=${qt_dir} \
QMAKE=${qt_qmake_cmd} \
QMAKESPEC=${qt_qmake_spec} \
MOC=${qt_moc_cmd}
}}}
AHEM, right. I had noticed the QMAKE* and MOC lines, even ... :-/
All the best, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: (un)setting environment variables from a Portfile
On 12/01/2015, at 9:47 AM, René J.V. Bertin wrote: Ultimately you'll have /opt/local/libexec/qt4 and /opt/local/libexec/qt5 (and who knows, qt6 too). There really is no reason to worry. People on Linux have been going through those same motions for quite a while now. OK. Thanks for clarifying that… :-) Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] kshareddatacache_p.h forcibly avoids defining KSDC_THREAD_PROCESS_SHARED_SUPPORTED
Hi René, On 09/01/2015, at 1:00 AM, René J.V. Bertin wrote: A remark about OS X not providing posix_fallocate led me to browse kshareddatacache_p.h (because posix_fallocate can be emulated), and therein I noticed #if defined(_POSIX_THREAD_PROCESS_SHARED) ((_POSIX_THREAD_PROCESS_SHARED == 0) || (_POSIX_THREAD_PROCESS_SHARED = 200112L)) !defined(__APPLE__) #include pthread.h #define KSDC_THREAD_PROCESS_SHARED_SUPPORTED 1 #endif which surprises me because even is OS X doesn't have timed mutex locking, it does have standard pthread mutexes. Deactivating this when __APPLE__ is defined is not among the MacPorts patches, so where does it come from? Has anyone tested behaviour on OS X *with* KSDC_THREAD_PROCESS_SHARED_SUPPORTED defined? H, a blast from the past?… :-) One of first KDE libs bugs I noticed on Apple OS X was: https://bugs.kde.org/show_bug.cgi?id=307652 KSharedDataCache not working on Apple OS X 10.7.4 (Lion) Reported 2012-10-01 Michael Pyne (KSharedDataCache author) was very helpful, but of course he did not have a Mac to test on and I did not have the ability back then to build test versions of kdelibs. It bubbled along for a year or two and then the bug stopped happening in mid-2014, so we closed the Bugzilla report. Mysterious. Re your issue, René, there is just the one use of that POSIX macro in KDE: http://lxr.kde.org/search?_filestring=_string=_POSIX_THREAD_PROCESS_SHARED_casesensitive=1 Also see the following pages on KDE's repository browser: https://projects.kde.org/projects/kde/kdelibs/repository/show/kdecore/util?rev=Active%2FTwo https://projects.kde.org/projects/kde/kdelibs/repository/changes/kdecore/util/kshareddatacache_p.h?rev=Active%2FTwo https://projects.kde.org/projects/kde/kdelibs/repository/diff/kdecore/util/kshareddatacache_p.h?rev=a33bbd7cb7d8863e46af066bb447f80fe601ca98rev_to=15d04d6ea7cc45f70bfbd3e41b3cc4e6b15e367a The !defined(__APPLE__) string was added on 2011-07-31, a year or so before my bug report (see above), which answers your question about where it comes from, but it cannot be what fixed the bug... Weird. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
On 24/12/2014, at 9:27 PM, René J.V. Bertin wrote: On Wednesday December 24 2014 21:16:54 Ian Wadham wrote: The code always seems to work OK if the crash procedure in the failed program starts Dr Konqi by forking. But it never works (on Apple OS X) if the crash procedure contacts an independent process (kdeinit4) via a socket and asks kdeinit4 to run Dr Konqi. Starting via kdeinit4 is preferred to forking, in case the crashed program has a corrupted heap or whatever. And all that DrKonqi really does is starting and stopping the crashed process via signals, and spawning a debugger with the necessary arguments for it to connect to the target process. i.e. the crashing program, Dr Konqi and kdeinit4. That's the silly thing about this situation. OS X won't let Dr K set privileges it already has. Without having really looked at the code, have you tried NOT doing that (possibly after checking whether it has the required privileges)? I did, but the KDE ReviewBoard jockeys pooh-poohed that. In the end I modified KCrash not to attempt to use kdeinit4 to start Dr K in Apple OS X. I really am very weary of that whole business and I especially do not wish to discuss it on Christmas Day, which is just over 2 hours away ATM in Australia. Merry Christmas, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
Hi Clemens,
On 23/12/2014, at 11:33 PM, Clemens Lang wrote:
- On 23 Dec, 2014, at 13:02, René J.V. Bertin rjvber...@gmail.com wrote:
IIRC, OS X no longer allows setuuid/setguuid, or only under some conditions.
Isn't that something that ought to be addressed in the post-destroot?
I'd vote for removing the offending flags if they cannot have their intended
effect anyway.
That's the first time I hear of that. Unless you have a source you can quote
on
that I'm not going to believe you, especially since my SUID (not setuuid,
that's
not a thing) binaries still work as I expect them to.
Is this topic anything to do with the following Apple OS X message?
The application with bundle ID (null) is running setugid(), which is not
allowed.
Google on Apple setugid. That message has been giving people trouble for
a couple of years at least. setugid() is Apple's shorthand for (regexp)
set[ug]id().
I used to get the message from Dr Konqi (KDE's crash analyser), till I bypassed
the offending code by stopping KCrash from trying to run Dr Konqi via kdeinit4.
The source for main.cpp of Dr Konqi currently reads:
-
int main(int argc, char* argv[])
{
#ifndef Q_OS_WIN //krazy:exclude=cpp
// TODO - Investigate and fix this, or work around it as follows...
// #if !defined(Q_OS_WIN) !defined(Q_OS_MAC)
// When starting Dr Konqi via kdeinit4, Apple OS X aborts us unconditionally for
// using setgid/setuid, even if the privs were those of the logged-in user.
// Drop privs.
setgid(getgid());
if (setuid(getuid()) 0 geteuid() != getuid()) {
exit(255);
}
#endif
-
The notes are to remind me to investigate this problem further if I ever get
kdeinit4 (or kdeinit5) to work properly on Apple OS X and MacPorts.
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent
On 15/12/2014, at 9:46 AM, René J.V. Bertin wrote:
'evening!
I finally got around to finishing up (or almost) my draft version for a
qt4-mac port that can live alongside other (future) Qt port versions
installed with the same approach: see https://trac.macports.org/ticket/46238 .
Related submissions:
https://trac.macports.org/ticket/46239
https://trac.macports.org/ticket/46240
Hope this helps! :)
It is a great start !!! Thanks very much René!
Two things concern me about the proposed new directory structure, under We get
in ticket 46238.
a) Traditionally you can install new or development versions of Qt
somewhere else
and point to your test or development version via environment variable
$QTDIR.
Does this presuppose a fixed hierarchy of directories and names under
$QTDIR?
If so, changing that hierarchy may cause problems.
b) Shifting Qt libraries from ${prefix}/lib to
${prefix}/libexec/${qt_name}/lib might be
a no-op. In the lib subdir (/opt/local/lib on my system), Qt
libraries are installed
as links. For example, libQtCore.dylib, libQtCore.4.dylib,
libQtCore.4.8.dylib and
libQtCore.4.8.6.dylib all point to
/opt/local/Library/Frameworks/QtCore.framework/QtCore,
which in turn points to Versions/4/QtCore and THAT is actually a file
described as
Versions/4/QtCore: Mach-O 64-bit x86_64 dynamically linked shared
library.
Maybe I am missing something.
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Registry schema cleanup
Hi guys, On 19/11/2014, at 9:34 AM, Joshua Root wrote: On 2014-11-19 06:48 , Clemens Lang wrote: I'd like to clean up the database schema of the registry. We have a couple of fields in there that are currently unused, as well as a few possible indices that could improve performance and at least one index that is actively harmful. In detail: I'd like to drop the `url' column from the ports table. All ports I have installed have this set to NULL and I couldn't find a use-case where it was being used. I tried installing a port from a URL, but that doesn't set the field either. Even worse, the `url' column is part of a unique index `UNIQUE(url, epoch, version, revision, variants)', which is bad, because if `url' is always NULL, that means you can never install two ports with the same tuple of (epoch, version, revision, variants). I'm surprised we haven't hit this yet. SQLite considers NULLs to be distinct in this case. https://www.sqlite.org/nulls.html FWIW I think the operative phrase on that page is: -- I have about decided that SQL's treatment of NULLs is capricious and cannot be deduced by logic. It must be discovered by experiment. For this kind of reason, fellow relational database designers/programmers and I have always eschewed the use of nulls (wherever I have worked, since about the 80s). You cannot know for sure what they are going to do nor how they are going to perform resource-wise. An index with its leading term being null smells distinctly fishy to me - a change in internal implementation could change the performance, perhaps radically. It has always been the case, in my experience and AFAICR, that you can use a prescribed default value, such as , 0 or -1, in place of a null (missing/unknown value) and thus get completely predictable actions and performance. And it is not often (with apologies to the purists) that you really need to distinguish between null and empty values. Even then there is usually a simple, practical way around the problem. My 2c. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Database Browser 3.4.0 for SQLite
Hi Bradley, On 05/11/2014, at 5:26 AM, Bradley Giesbrecht wrote: On Nov 3, 2014, at 6:10 AM, Andrea D'Amore and.dam...@macports.org wrote: On Fri, Oct 31, 2014 at 9:01 PM, Ian Wadham iandw...@gmail.com wrote: On 01/11/2014, at 5:23 AM, Bradley Giesbrecht wrote: A nice SQlite GUI app: https://github.com/sqlitebrowser/sqlitebrowser/releases Don't we already have sqlitedbrowser in MacPorts? Apart from the d, what is the difference? The one already in port is a different project and much less mature, also it seems abandoned. I like that with Database Browser for SQLite I can view the table schema from the query editor. There is also a menu for loading extensions, MacPorts registry uses share/macports/sqlite/macports.sqlext. I cannot remember how I loaded extensions with sqlitedbrowser, probably the query editor. The GUI is the best I have found so far, clean and intuitive. Thanks, Bradley. I must give the new, improved DB Browser a try sometime. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Database Browser 3.4.0 for SQLite
On 01/11/2014, at 5:23 AM, Bradley Giesbrecht wrote: A nice SQlite GUI app: https://github.com/sqlitebrowser/sqlitebrowser/releases Don't we already have sqlitedbrowser in MacPorts? Apart from the d, what is the difference? Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi Nicolas, On 27/10/2014, at 3:02 PM, Nicolas Pavillon wrote: On 27/10/2014 12:24, Ian Wadham wrote: Well, I just tried that and here is what happened… Tara:~sudo port install palapeli +debug --- Computing dependencies for palapeli --- Fetching archive for palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://packages.macports.org/palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/palapeli --- Fetching distfiles for palapeli --- Attempting to fetch palapeli-4.13.3.tar.xz from http://mirror.internode.on.net/pub/kde/stable/4.13.3/src --- Verifying checksums for palapeli --- Extracting palapeli Error: org.macports.extract for port palapeli returned: ERROR: In order to install this port as +debug, Qt4 must also be installed with +debug. This is a behaviour that is specific to the kde4 portgroup. More specifically, it is specific to the qt4 portgroup, on which kde4 one depends (see r73101). If you then say that this is not needed, it is the portgroup which should be modified, not macports' behaviour. Well, yes, I agree. But portgroups are not my area of expertise, so I am relying on advice from you and Ryan here. The worst that can happen, FWICS, if you remove the requirement to install Qt4 with debug when anyone wants some KDE software with debug, is that, if they get a crash or want to use a debugger, the symbols will peter out if the problem was thrown up within the Qt4 library. It is quite normal for Qt4 to induce a crash, e.g. if one's KDE code marches past the end of a list or array. However, one can see where the KDE code was just before entering Qt and that and the Qt crash-message are enough information I reckon. OTOH, if you turn on debug in the Qt4 library, my understanding is that you will get flooded with loads of debug log-messages… for debugging Qt itself... I have never verified that, because KDE developer texts (on Linux) recommend that you NOT turn on debug in Qt4, so I have never (in 12 years) turned it on. If it will not break anything in MacPorts, let's remove the requirement for debug in Qt4. Then we will all be able to build debugging versions of KDE apps, libraries and utilities, to any required depth, using the principle Ryan has explained so well. That should be a lot of help with diagnosing KDE problems in MacPorts and Apple OS X, of which there are a few… ;-) And THEN there will be no need for René's nostrip variant, which is where this thread started out… :-) So what do you say, Nicolas? You're the man on this one. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi Ryan, On 27/10/2014, at 1:13 PM, Ryan Schmidt wrote: On Oct 26, 2014, at 9:03 PM, Ian Wadham wrote: On 27/10/2014, at 12:10 PM, Ryan Schmidt wrote: On Oct 26, 2014, at 7:10 PM, Marko Käning wrote: Ryan, any suggestions? My suggestions are: We try to avoid variant names beginning with no. We try to use variant names that mention enabling something, rather than names that mention disabling something. No problem with that… :-) When there is a variant that aids in debugging a program, it is typically named debug. With all due respect, Ryan (and my respect for you is very great), please not this hoary old chestnut… :-) I didn't realize this topic was hoary or a chestnut! Variants in MacPorts are global in scope, which means that variants like debug and also docs get applied to *every* dependency, back as far as Sumerian clay tablets… :-) With KDE and Qt having such a long list of dependencies, well… Well, variants are passed on to *uninstalled* dependencies. If dependencies are already installed, they're not rebuilt with that variant. So if you don't want the variant passed down to uninstalled dependencies, install the dependencies first. For example, you could install the port normally first, without the debug variant, which would install all needed dependencies. Then you can reinstall the port with the +debug variant and only that port will be built with the debug variant. Well, I just tried that and here is what happened… Tara:~sudo port install palapeli +debug --- Computing dependencies for palapeli --- Fetching archive for palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://packages.macports.org/palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/palapeli --- Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/palapeli --- Fetching distfiles for palapeli --- Attempting to fetch palapeli-4.13.3.tar.xz from http://mirror.internode.on.net/pub/kde/stable/4.13.3/src --- Verifying checksums for palapeli --- Extracting palapeli Error: org.macports.extract for port palapeli returned: ERROR: In order to install this port as +debug, Qt4 must also be installed with +debug. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi again Ryan, On 27/10/2014, at 2:24 PM, Ian Wadham wrote: On 27/10/2014, at 1:13 PM, Ryan Schmidt wrote: On Oct 26, 2014, at 9:03 PM, Ian Wadham wrote: Variants in MacPorts are global in scope, which means that variants like debug and also docs get applied to *every* dependency, back as far as Sumerian clay tablets… :-) With KDE and Qt having such a long list of dependencies, well… Well, variants are passed on to *uninstalled* dependencies. If dependencies are already installed, they're not rebuilt with that variant. So if you don't want the variant passed down to uninstalled dependencies, install the dependencies first. For example, you could install the port normally first, without the debug variant, which would install all needed dependencies. Then you can reinstall the port with the +debug variant and only that port will be built with the debug variant. Well, I just tried that and here is what happened… Tara:~sudo port install palapeli +debug --- Computing dependencies for palapeli snip Error: org.macports.extract for port palapeli returned: ERROR: In order to install this port as +debug, Qt4 must also be installed with +debug. But, to be fair, the following worked beautifully… :-) and exactly as you said, Ryan. It's the first time I have been able to see KDE doco on MacPorts in months… :-) Tara:~sudo port clean palapeli --- Cleaning palapeli Tara:~sudo port install palapeli +docs --- Computing dependencies for palapeli etc. So maybe there is a poison pill somewhere in the KDE or Qt portfiles which affects the +debug variant, but not +docs. It is certainly true that you CAN install KDE apps and libraries with debug options and without having debug in Qt. I do that almost every day in my KDE development environment, which uses git-repository versions of KDE, but links to qt4-mac in MacPorts, with no debug variant. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 29/09/2014, at 3:25 PM, Nicolas Pavillon wrote: On 29/09/2014 13:03, Brandon Allbery wrote: On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. I had mentioned the idea of making KDE3 obsolete quite some time ago (months) on the list, but never got to do it. I indeed started (independently from the imake discussion, just a coincidence) some days ago with the dependents ports. I going slightly slowly on this part as I am trying to find replacements for the few remaining kde3-based apps whenever possible. The idea would be to then remove the kde3 suite after all dependents have been taken care of. The biggest remaining issue is koffice. Ideally, it could be replaced by calligra (requested in ticket #https://trac.macports.org/ticket/37579), but it seems plagued with several problems at runtime making it only very partly usable on OS X. As Ryan said, it is not really the duty of MacPorts developers to keep ports alive if they are not supported upstream. KDE 3 is long since dead (unmaintained) and all KDE apps dependent on KDE 3 with it. So, do not worry about KOffice… :-( As a KDE developer, I do not like this aspect of KDE, but it is a fact of life. If there is nobody available to port a KDE app to a new version of KDE, then the app becomes unmaintained and is no longer released. KDE 4 is heading that way right now, as the emphasis (in the KDE project) shifts to Frameworks and KF5. Marko, René and I are working to make the transition easier for MacPorts developers and users this time around. When we have time, we should see what can be done to make Calligra more workable in KDE 4 on Apple OS X. ATM I do not see more than a trickle of KDE 4 apps that have been ported to KF5. Maybe that will become a flood later. Meanwhile, I do not know what other FOSS office suites might be a goer on MacPorts. I use LibreOffice… Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Configuration and environment check command (was: Re: [124047] trunk/base)
On 05/09/2014, at 9:59 AM, Lawrence Velázquez wrote: On Sep 4, 2014, at 5:07 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: Does it have to parallel selfupdate? diagnose works perfectly well by itself without the self in front of it... Of course it doesn't *have* to. But most of the port(1) verbs operate on ports and port names, whereas selfupdate operates on the MacPorts installation itself. So it would make sense to have a selfcheck that checks on the MacPorts environment itself, as a whole. So why not checkself? Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Configuration and environment check command (was: Re: [124047] trunk/base)
On 05/09/2014, at 10:20 AM, Lawrence Velázquez wrote: On Sep 4, 2014, at 8:04 PM, Ian Wadham iandw...@gmail.com wrote: So why not checkself? Cheers, Ian W. Because it's not updateself, it's selfupdate. Well, I was also going to suggest updateself… : -) the logic being that port commands usually follow the sequence port do-something to-something, but I realise selfupdate is deeply entrenched… I suggested checkself because someone, IIRC, did not want to have to type as far as the u if they required selfupdate. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to determine the dbus address on OSX/MacPorts OR How to make MacPorts-dbus work with non-MacPorts qt5-install
Hi David and Marko, On 23/08/2014, at 8:37 AM, David Evans wrote: On 8/22/14 12:41 PM, Marko Käning wrote: how can I determine the dbus address of the session dbus started by launchd? The environment contains only DBUS_LAUNCHD_SESSION_BUS_SOCKET: — DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-adIO4f/unix_domain_listener — So, the question is, can I query the session dbus somehow in order to obtain the dbus address which I could then use to set DBUS_SESSION_BUS_ADDRESS in my environment? Marko, You can form the DBUS_SESSION_BUS_ADDRESS as follows: export DBUS_SESSION_BUS_ADDRESS='unix:path='$DBUS_LAUNCHD_SESSION_BUS_SOCKET or, in your case, unix:path=/tmp/launch-adIO4f/unix_domain_listener The usual way to get the session bus address programatically is to the GDBus API provided by GIO in glib2. In MacPorts, this has been patched to work as I have described. See the definition of get_session_address_macports_specific (GError **error) in files/patch-get-launchd-dbus-session-address.diff. As a rider to that, Qt has several classes related to DBus and the QDBusConnection class has methods QDBusConnection::sessionBus() and QDBusConnection::systemBus() to get access to the most commonly used buses. The Qt methods would be used inside KDE and Qt apps. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Unable to launch Qt Assistant
On 15/07/2014, at 10:56 AM, Mark Brethen wrote:
On Jul 14, 2014, at 6:22 PM, Mark Brethen mark.bret...@gmail.com wrote:
I'm testing the FreeCAD build and discovered that the help menu returns the
error message: Unable to launch Qt Assistant
(/opt/local/bin/Assistant.app/Contents/MacOS/Assistant). Launching Qt
Assistant is done in the function startAssistant() which is found in
src/Gui/Assistant.cpp. The following lines get the name of the executable
and the doc path:
#ifdef Q_OS_WIN
QString app;
app = QDir::toNativeSeparators(QString::fromUtf8
(App::GetApplication().GetHomePath()) + QLatin1String(bin/));
#else
As a quick and dirty fix, you could include here:
#ifdef Q_OS_MAC
QString app = /Applications/MacPorts/Qt4/;
#else
QString app = QLibraryInfo::location(QLibraryInfo::BinariesPath) +
QDir::separator();
#endif
#endif
#if !defined(Q_OS_MAC)
app += QLatin1String(assistant);
#else
app += QLatin1String(Assistant.app/Contents/MacOS/Assistant);
#endif
QString exe =
QString::fromUtf8(App::GetApplication().getExecutableName());
QString doc =
QString::fromUtf8(App::Application::getHelpDir().c_str());
QString qhc = doc + exe.toLower() + QLatin1String(.qhc);
I'm not that familiar with c++ but I believe
'QLibraryInfo::location(QLibraryInfo::BinariesPath) + QDir::separator()' is
setting the variable 'app' to /opt/local/bin. This line needs to be patched
so that it finds /Applications/Macports/Qt4. How is a string used as a file
path In c++?
In other words, how is the macports variable included in the patch?
QString app = ${applications_dir} + QLatin1String(Qt/);
Note the extra #endif.
I don't know the official way to obtain the applications bundle path from
Qt4-Mac.
Using the literal path as above will get you the standard MacPorts bundle path
for Qt4 apps, if and only if you have used MacPorts to install the apps and used
the default MacPorts locations. So it will get you off the ground, but it is
in no way
general to any installation of FreeCAD on any Apple OS X host machine.
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
On 29/06/2014, at 7:52 PM, Marko Käning wrote: on the kde-mac ML the question came up whether the necessity to install qt4-mac in its debug variant - when one simply needs KDE ports installed in their debug variant - is only due to MacPorts' way of handling port variants... If that's indeed the case, it may seem to be a good idea to replace in all KDE software ports the debug variant by a new variant - perhaps called debug_kde. In that case all ports depending on kdelibs4 would nicely manage their debug_kde variants amongst themselves and not mess with the standard-MacPorts debug variant at all anymore. The debug output of qt4-mac is very verbose and of no much use when debugging crashing KDE applications anyways. Also one would not be forced to install qt4-mac +debug from source and only be left with locally rebuilding the much smaller KDE ports. What do you think? ++1 from me!!! I would also like us to consider something similar for +docs, especially with KDE. That would avoid pulling in all the other text-processing dependencies of other ports, such as the doxygen/texlive/latex chain, while leaving the user to take his or her own chances with meinproc4 (it never fails for me). Also a +docs_kde would not have to be a different binary package - just a downloading and compiling of docs subdirectories with meinproc4, which will be already installed. Come to think of it, I don't think debug or docs in one port is usually dependent on any other port, except for the tools used to format documents, so perhaps MacPorts could have --debug and --docs options for port install, which would apply to the ports that were being requested on that installation run and on upgrades of same. Something like that would give every user fine control over what ports to debug or document, but maybe it is not so easy to implement (?). Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fixing KDE debug dialog and Dr Konqui to run on OS X
On 16/06/2014, at 4:15 PM, Clemens Lang wrote: On June 16, 2014 5:57:36 AM CEST, Ian Wadham iandw...@gmail.com wrote: On 16/06/2014, at 1:38 PM, Brandon Allbery wrote: The normal time you need such code is after a fork() and before exec() to avoid leaking file descriptors to a child that won't know they're even there. Something like that happens in later KDE crash-processing code, which starts Dr Konqi (the crash-processing dialog app), but I have not looked at it in detail yet. It first tries to get a third party (kdeinit) to start Dr Konqi. This is preferred (the comments say) because it avoids inheriting possibly corrupted data. But if that fails, it forks and starts Dr Konqi as a child. If you need the file descriptors closed after the fork you can set the close on exec flag instead of closing them. I hear that won't bother libdispatch. Thanks again, Clemens. I'll keep that in mind for further down the track. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fixing KDE debug dialog and Dr Konqui to run on OS X
On 15/06/2014, at 6:28 PM, Clemens Lang wrote: On Sat, Jun 14, 2014 at 10:25 PM, Ian Wadham iandw...@gmail.com wrote: The procedure for closing the file descriptors is a bit brute force. It uses struct rlimit rlp; getrlimit(RLIMIT_NOFILE, rlp); to find out how many open files the user is allowed (my system says 2560) and then does close(); on ALL of them except 0, 1and 2 (stdin, etc.). I have now re-tested with a crash in another app, which can be induced by doing stuff on the app's screen. It gave SIGSEGV (=11), but the second signal was still SIGILL (=4), i.e. it is a new signal, not a repeat of the first one (as I originally thought). So there must be a second crash somewhere in the code that closes the files or handles 2500+ invalid file descriptors. I guess you're seeing what can be found by googling for BUG in libdispatch client: Do not close random Unix descriptors. Thanks, Clemens, that explains a lot. Long story short, you'll probably have to stop closing all file descriptors, because OS X's libdispatch library has a few file descriptors of its own and reacts with this signal if you close those. There doesn't seem to be a way to avoid libdispatch (disabling native language support apparently works for some people, but I'm sure that's not an option here) and no way to find out which file descriptors are used by libdispatch, so all you can do is only close descriptors where you know that they have been opened by KDE code. In an arbitrary app that has crashed that would be unknowable in principle. KDE apps can open FDs via Qt, KDE or even directly by UNIX calls or indirectly by calling a library that operates on a cache. AFAICT there is no way in UNIX/Linux/OS X to tell what FDs are in use period, which would be why the crash code closes every possible FD. So indeed, the only way to go is to exclude from compilation on OS X the code that closes all the file descriptors during the initial crash-processing. Later the the FDs get closed anyway and it works then, perhaps because the app gets issued with a STOP. Thanks again, All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fixing KDE debug dialog and Dr Konqui to run on OS X
On 16/06/2014, at 1:38 PM, Brandon Allbery wrote: On Sun, Jun 15, 2014 at 8:15 PM, Ian Wadham iandw...@gmail.com wrote: Later the the FDs get closed anyway and it works then, perhaps because the app gets issued with a STOP. Unix closes all fd-s at process exit (including abnormal exit) anyway; closing them preemptively like that doesn't make a whole lot of sense. Yes, understood. The normal time you need such code is after a fork() and before exec() to avoid leaking file descriptors to a child that won't know they're even there. Something like that happens in later KDE crash-processing code, which starts Dr Konqi (the crash-processing dialog app), but I have not looked at it in detail yet. It first tries to get a third party (kdeinit) to start Dr Konqi. This is preferred (the comments say) because it avoids inheriting possibly corrupted data. But if that fails, it forks and starts Dr Konqi as a child. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Fixing KDE debug dialog and Dr Konqui to run on OS X
Hi guys, I think I have found the reason for two KDE problems on OS X and MacPorts: 1. When a KDE app crashes, Dr Konqi often fails to run and produce the backtrace KDE developers ask for. 2. Also the debug dialog fails to run and take the user through the steps to report a bug on bugs.kde.org. UNIX signals, such as SIGSEGV, are caught by a default crash handler in kdelibs/kdeui/kcrash.cpp (void KCrash::defaultCrashHandler (int sig)). See source code at [1] That procedure has a crash recursion counter, to protect it from crashes within the crash procedure itself, then it has three stages: 1. Emergency save of data, if the app developer has provided it, 2. Close all open file descriptors, 3. Log the crash and start the Dr Konqi app to analyse it. What happens is that the signal comes in for a second time during step 2, the recursion counter becomes too high and the crash procedure skips step 3, issues the message Unable to start Dr. Konqi and does _exit(255). If I comment out step 2 (closing all file descriptors), the crash procedure starts Dr Konqi and runs normally. The files then get closed anyway, by a later process, after Dr Konqi gets started. Can someone more knowledgeable of OS X suggest what is the best way to fix the problem? I am using OS X 10.7.5 (Lion) with a KDE 4.13 library I have built myself, from the KDE repositories. The simplest fix would be to omit step 2 from the compilation (which is what happens with the MS Windows version), i.e. use #ifndef Q_OS_MAC. I cannot tell what is causing the second signal. Perhaps it is due to a restriction on what OS X allows an app to do during a crash procedure? The procedure for closing the file descriptors is a bit brute force. It uses struct rlimit rlp; getrlimit(RLIMIT_NOFILE, rlp); to find out how many open files the user is allowed (my system says 2560) and then does close(); on ALL of them except 0, 1and 2 (stdin, etc.). I thought that might be causing the second signal - there are only about 10 descriptors open - but it still happens even when I insert a test for a valid file descriptor (if (fcntl(i, F_GETFL) != -1)) and end the loo when I get to an invalid one. I know - not perfect … ;-) Is there some better way, in OS X, to find all the open files and close them? Or is just that much activity causing OS X to spit out a second signal? Ideas welcome, Cheers, Ian W. [1] https://projects.kde.org/projects/kde/kdelibs/repository/entry/kdeui/util/kcrash.cpp?rev=KDE%2F4.13 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fixing KDE debug dialog and Dr Konqui to run on OS X
Thanks for your very prompt reply, Bradley. On 15/06/2014, at 1:03 PM, Brandon Allbery wrote: On Sat, Jun 14, 2014 at 10:25 PM, Ian Wadham iandw...@gmail.com wrote: The procedure for closing the file descriptors is a bit brute force. It uses struct rlimit rlp; getrlimit(RLIMIT_NOFILE, rlp); to find out how many open files the user is allowed (my system says 2560) and then does close(); on ALL of them except 0, 1and 2 (stdin, etc.). I thought that might be causing the second signal - there are only about 10 descriptors open - but it still happens even when I insert a test for a valid file descriptor (if (fcntl(i, F_GETFL) != -1)) and end the loop when I get to an invalid one. I know - not perfect … ;-) Where exactly is it receiving the signal? Do you mean where is the line of code that causes the second signal? I don't know. And I don't really know how to find out. My UNIX skills (and memory) are still rather rusty after years with no use... :-) My original test used this code, in KGoldrunner's main.cpp: KGoldrunner * controller = 0; // IDW KCrash test. new KGoldrunner(); controller-show(); // controller is supposed to be the main window ptr, not 0. and it gave SIGILL (=4) and the second signal was also SIGILL. I have now re-tested with a crash in another app, which can be induced by doing stuff on the app's screen. It gave SIGSEGV (=11), but the second signal was still SIGILL (=4), i.e. it is a new signal, not a repeat of the first one (as I originally thought). So there must be a second crash somewhere in the code that closes the files or handles 2500+ invalid file descriptors. Beware of thread stacks, which may be in the heap; if the per-thread stack size is too small, you will definitely see things like this and stack allocation/extension in the SEGV handler (like, that struct rlimit) will make it worse unless you use sigaltstack. Possibly, but I don't think that struct is very large (2x64 bits). getrlimit() is not on the list of allowed signal-processing functions in man sigaction, but it gives a valid return and struct contents in this case. ATM, I am just looking for a fix for the file-closing code or a workaround (i.e. don't even compile the call to it, as is done in the MS Windows version of KCrash). If there is no simple fix, I will go for the workaround. My main objective is to get through KCrash and get Dr Konqi to run and then produce some crash info. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Questions re CI on Macports and KDE
Hello MacPorts Developers, As you may know, I am a developer of KDE Games working on Apple OS X Lion with an early-2011 Macbook Pro. I am here on a kind of diplomatic mission from KDE-land. But first a few words of background. KDE SC 4.13 is due for release on 16 April. Just over a month ago, one of the KDE promotional guys asked on the general KDE developers' list (kde-de...@kde.org) to nominate software he should advertise for people to test in the KDE SC 4.13 release candidate. I wrote and asked what testing of cross-platform and cross-desktop implementations is being done, pointed out some problems I had heard of with Apple OS X and Windows, suggested that some KDE people might have a joint sprint with Apple and Windows guys to clear up some of the problems and finally that it would be nice to have some regular testing … Marko Käning joined in and supported me. After much discussion some negatives and some positives emerged. On the negative side, it appears that no formal testing of cross-platform implementations of KDE software is currently done. There is some informal testing and fixing of problems on non-Linux platforms because some KDE core developers also work on those platforms. MacPorts is not so lucky. I think I am the only KDE developer working on a Mac and I am not a core KDE developer (i.e. not one who works on libraries, utilities or build systems). On the positive side, Mario Fux, who is organising a bunch of sprints and workshops at Randa, in the Swiss Alps this year [1], offered to organise some groups to tackle cross-platform issues. Marko and I joined Mario in some private discussions, along with present and former MacPorts-KDE developers: Nicolas Pavillon, Bradley Giesbrecht and Michael Dickens. Unfortunately, except for Marko, we all came from too far away to attend Randa, but we went on discussing ways and means to narrow down and solve KDE portability problems on MacPorts. The end result is that we have opened up discussions on the KDE Mac mailing list (kde-...@kde.org) and have set up a MacPorts wiki page to keep track of the problems (thanks, Marko) [2]. The idea is to list the known problems and then narrow them down one by one until it is possible to assign them either to a MacPorts ticket or to a bug report on bugs.kde.org, or even on Qt's bug system, depending on where the root cause of the problem is found to lie. Marko has already made a start on investigating some problems and I have started to look at the notorious meinproc4 problem. We will need expert help from KDE developers to diagnose the problems and Mario, who knows a lot of the key KDE developers, has offered to find helpers for us, as required by whatever part of KDE is involved. The KDE developers will also need *our* help to run tests and trials for them: there is not a lot of Apple hardware in KDE-land ATM … :-) Some of this has already begun to bear fruit. Please have a look at the new wiki page [2], which is growing daily, and feel free to add any KDE-related problems you know about that are not already listed. The other positive is that Ben Cooksley, one of KDE's leading sysadmin guys is interested in setting up continuous integration (CI) to build and test KDE software in an Apple OS X environment as it is developed and released and before it gets to MacPorts. And that is really why I am here. Ben is in a central position in KDE re repositories, servers and KDE's CI system, based on Jenkins. Right now there is a KDE release about to go out (KDE SC 4.13), so he is rather busy and has asked me to speak for him. Several parts of KDE software have test modules. KDE's Jenkins CI system compiles and builds all KDE software continuously, in a Linux environment, as it is committed. It also tests software that has test modules. Ben's idea is to extend this CI system to run in Apple OS X and Windows, so that the cross-platform versions can be kept clean after problems are cleared up. But first, Ben has some basic questions and he would like to get in touch with the guys who run MacPorts' CI system to discuss possibilities. There are potential benefits for both sides, it appears. I have told him what MacPorts' CI does, that it is based on buildbot and that you support multiple Apple hardware platforms and multiple versions of Apple OS X. Ben is not sure what would be required to set up CI of KDE in an Apple OS X envirionment. His immediate questions are to do with Apple OS X installation, but I am sure he has many more. - Can he virtualise Mac OS X legally on a Linux machine? - Must he invest in Apple hardware? - Does OS X licensing forbid installation on non-Apple hardware? - How can he get in contact with the MacPorts CI guys? Hoping you can help, All the best, Ian W. [1] http://randa-meetings.ch/ [2] https://trac.macports.org/wiki/KDEProblems ___ macports-dev mailing list macports-dev@lists.macosforge.org
KDE usage of Clang has been fixed
Hi guys, The KDE build-system developers have now fixed the problem with excessive symbol visibility (or invisibility in some cases), when Clang is used to compile KDE. The KDE build system, as of KDE 4.11.1, will have a section that recognises Clang and creates appropriate settings. Technical details are at: http://quickgit.kde.org/?p=kdelibs.gita=commith=90cb7ba760584a8010afef65fa14e649195af6c6 and in the committed code. KDE 4.11 was released about a week ago and KDE 4.11.1 will be released on 3 September. My original KDE bug report and Macports ticket are both closed now, see: https://bugs.kde.org/show_bug.cgi?id=300429 https://trac.macports.org/ticket/34605?replyto=1#comment The original topic for those was __KDE_HAVE_GCC_VISIBILITY not defined on Apple OS X 10.7.4 Lion Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Problem with KDE and Clang near to solution
It looks as though a solution to a problem compiling KDE with Clang is near. Apparently BSD has now changed over to Clang and found a similar problem, see https://bugs.kde.org/show_bug.cgi?id=313763 My original report was https://bugs.kde.org/show_bug.cgi?id=300429 KDE compiles and builds OK with Clang in Macports. My private source code using KDE libs also compiles and builds OK as long as I use Clang, not GCC, but the built modules have vastly more symbols than they need. A way to suppress the superfluous symbols has been found and should appear in KDE 4.11 and maybe in a bugfix release for KDE 4.10. See the above bug reports for details. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compilation issue with qt
On 06/06/2013, at 9:02 AM, Lawrence Velázquez wrote:
On Jun 5, 2013, at 12:03 PM, Nicolas Pavillon ni...@macports.org wrote:
This error seem to appear because Qt forward-declares
random_access_iterator_tag in qiterator.h in the part:
#ifdef QT_NO_STL
namespace std {
struct bidirectional_iterator_tag;
struct random_access_iterator_tag;
}
#endif
This declaration overrides the ones in std libraries, so that the compiler
does not recognise the code in grantlee as being valid, as reported in
http://llvm.org/bugs/show_bug.cgi?id=13925.
The fix proposed in the link above is to patch qiterator.h, by suppressing
the forward declarations, and include iterator instead. I tested it, and
this indeed works. However, it seems rather overreaching to have to patch Qt
(a huge port), in order to get kdevelop to compile. Would anyone have
another idea ?
As an app developer depending on kdelibs and Qt, I shudder at the thought
of making such a core change to Qt in Macports, without being quite sure it is
harmless. It could get right to the heart of container handling (e.g. QList),
for
those apps that use iterators over Qt containers.
What is the QT_NO_STL macro for? Could the build explicitly undefine it?
Googling on QT_NO_STL reveals a rich range of discussion by leading core
developers of both KDE and Qt. The easiest thread to follow might be:
http://comments.gmane.org/gmane.comp.lib.qt.devel/1670
and it is fairly recent.
From what I can gather, QT_NO_STL is intended for platforms where the
standard C++ library (STL/std) is not available.
It might be a good idea to contact the Qt developers about this issue.
OTOH it is maybe a Clang-related issue, as noted in Michael Dickens' post
and attachment. KDE is not Clang-ready yet and maybe Qt 4 is not.
Apologies if I do not know what I am talking about. This stuff is outside my
area.
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Please review first draft of Fossick - a MacPorts GUI
Hi guys, The first draft of the MacPorts GUI app called Fossick can be downloaded from: http://www.filedropper.com/fossickclonetar by clicking a Download button or two, once you can find your way past all the ads. Does anybody know a better file share site? I'm a newbie at this stuff. If you download into a working directory of your choice, you should get a file called FossickClone.tar.gz. Use tar xvzf FossickClone.tar.gz to unpack it into a subdirectory structure called FossickClone. Now you will need to use Xcode to Open… the Fossick.xcodeproj directory you will find in the FossickClone subdirectory. Use Command-B to build the code or use the Run arrow button at the top left of the Xcode toolbar to build and run. Before you do, just a few checks: 1. Fossick assumes the MacPorts prefix to be /opt/local: that is not configurable yet. 2. I have been compiling, building and testing with Xcode 4.6.1 and OS X 10.7.5 Lion: Fossick might not work with an earlier Xcode, compiler set or Cocoa library. The problem is that Apple has made sweeping and frequent changes to such fundamental features as dynamic memory management in Objective-C, how widgets behave when a window is resized, how Interface Builder links to apps and how Cocoa bindings and Interface Builder connections to apps work. 3. Please have a look at the README file first. It covers the development status of Fossick and the operation of the GUI. I would appreciate reviews of any aspect of Fossick, but in particular: a. The specification - in file FossickSpec.txt. b. The GUI - how it works, ease of use, etc. c. The source code. d. Backwards compatibilty - in theory Xcode 4.6 can build for earlier versions of OS X than 10.7 Lion and 10.8 Mountain Lion, but I have no idea how that works out in practice and documentation seems to be vague to non-existent. Re points c. and d., I have been struggling a bit with Xcode, Cocoa and Interface Builder and would appreciate some mentoring if anyone can offer it. After 11 years of C++ and the Qt library, I am experiencing a little culture shock … :-( I hope you will like Fossick. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Please review first draft of Fossick - a MacPorts GUI
Hello Kevin, On 21/04/2013, at 4:28 AM, Kevin Walzer wrote: I'm the competition here (http://www.codebykevin.com/portauthority.html), but since no one else has provided any comments yet, I'll offer a few. Thank you for being so chivalrous as to review my code. The app felt very sluggish the first time I ran it in Xcode--I wasn't sure if this was because of the overhead of running it under Xcode or what. It was a bit snappier when I closed Xcode and ran it separately. I find that every morning after booting up. I think it is an Xcode startup overhead. The first compile and run goes slowly, subsequent runs are faster. The Console app output indicates that Fossick itself takes about 3-4 secs to get going. From a design standpoint, the UI is a bit counterintuitive. I understand the idea behind the side-by-side text views, but it strikes me as fiddly and very much out of step with the customary two- and three-pane interfaces that are prevalent today: table view, tree view, text view. My solution is to have all data in a single text view; there may be other ways to do it, such as a floating window, etc. But I didn't grok the purpose of the twin text views until I read the readme. You can't assume users will do that. I thought about a sidebar, but could not see a use for one. The list of ports is essentially unstructured and subject to filtering, sorting, etc. The twin subviews idea arose because there was wasted space down there once I had all the columns in the table view and there was room for another view. Actually I find side-by-side views quite useful, putting on my MacPorts end-user hat … :-) I also noticed that changes in MacPorts were not reflected in the app after running an operation. For instance, I selected a random port (gawk) and installed it. It did not change state in the table view after the port was installed (i.e. was not listed as being installed). It did not show up as installed until I re-launched the app. That's a fairly significant issue; users will wonder if anything happened if they do not see changes in the UI that reflect operations they have run. Please have a look at the FossickSpec.txt file. The install was the last bit I got working. My intention is to complete it by automatically opening a subview to Results Of Run and afterwards to update the status. For beginning users, Results Of Run will be filtered to show overal success or failure only, plus progress through the dependencies. It would be nice if I coud find a way to do time estimates as well. In a similar vein, the app provides no visual feedback of an operation running. No scrolling text in the text view, not even a progress bar. I ran an install command and the app just sat there. A user should not have to select view output of operation from a tiny little popup menu to get an indication of what is happening. See above. I will probably have some kind of indicator(s) that something is going on in the background even if Results of Run is deselected. It appears you're handing a lot of the operations off to AppleScript to actually execute port commands, via the do shell script paradigm? That's an interesting choice. It solves the problem of running privileged operations without having to delve into the authorization libraries, but doesn't it run the risk of locking up the app? AppleScript blocks until a command is returned. (Wranging with this very dilemma years ago, I finally ran across a different solution, whereby a user password is echoed is piped to sudo port install or what not.) I'm curious how you keep the app responsive while you have this massive blocking operation going on under the hood. Did NSTask not provide useful tools for running port commands, or was there some other reason for choosing AppleScript? See the method runPrivilegedScript in SoftwareActions.m. It is non-blocking. I also like using the port command method because it is fast enough and is fairly stable as MacPorts changes. Pallet, by contrast, uses libraries, but these are out of date now ... I use AppleScript to get the usual Apple authorisation behaviour. The command it runs has an on the end, so it is non-blocking. I use an NSTask and tail -f to collect and display the output as it happens, rather than letting AppleScript show the whole lot at the end of the run. Anyway, I realize this is an alpha of an alpha build, and there's still a lot to be done, but some of what I'm responding to seems basic to the design rather than something that will be smoothed out later, so I felt it would be useful to raise these points. Hope they're helpful, Kevin Thank you, Kevin. Yes, it's very alpha, but I have very much appreciated your input. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Please review first draft of Fossick - a MacPorts GUI
On 21/04/2013, at 9:43 AM, Ryan Schmidt wrote: On Apr 20, 2013, at 18:17, Ian Wadham wrote: On 21/04/2013, at 7:33 AM, Ryan Schmidt wrote: All three panes are empty; I can't figure out how to make it do anything. I am sorry to hear that. It probably means it has crashed somehow during launch. Does the Console app say anything useful? What Xcode and OS X versions did you use? Fossick should start by listing all the ports, starting at 2Pong, and then become responsive. Yes, the Console says some things; I'm attaching the output. fossick.txt.bz2 It's Xcode 4.6.2 on OS X 10.8.3. Thanks, Ryan. That's very strange. Everything worked OK, except for a couple of (OS X 10.8?) grumbles I don't see on Lion. Fossick gets its list of ports (ATM) from the MacPorts Index file, but finds no ports on your system. It also runs commands installed, requested and outdated internally, to get statuses, and it finds some ports … Fossick is looking for the port command in /opt/local/bin and the Index file in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/PortIndex. Do you perchance have your MacPorts Index file in a different place? Is there a smarter way to locate that file? I hate using literals in programs. Does anyone know how to find out if an established project uses ARC? I couldn't find it. I found instructions for Xcode 4.2 but they didn't seem to apply on 4.6 anymore; what they told me to look for wasn't there. Re backwards compatibility of ARC (automatic reference counting), a method of dynamic memory management, I get the impression it is implemented by the compiler automatically generating the required memory management code, so maybe it will be possible to build ARC with Xcode 4.6 and target an earlier version of OS X. Who knows? ARC requires the 10.7 SDK or newer, and the deployment target set to 10.6 or newer. You can run an ARC app on Snow Leopard, but you cannot compile it on Snow Leopard because Snow Leopard's version of Xcode doesn't have the 10.7 SDK. Some information I found online said ARC on 10.6 was further limited in some way, but I couldn't figure out what they meant. Thanks again, Ryan. I'm a newbie with this Apple stuff … even an expert finds it hard … :-) Hopefully the documentaion will become more complete in time. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Please review first draft of Fossick - a MacPorts GUI
On 21/04/2013, at 7:34 AM, Leo Singer wrote: On Apr 20, 2013, at 12:00 PM, macports-dev-requ...@lists.macosforge.org wrote: From: Ian Wadham iandw...@gmail.com Subject: Please review first draft of Fossick - a MacPorts GUI Date: April 20, 2013 1:54:42 AM PDT To: macports-dev@lists.macosforge.org Development macports-dev@lists.macosforge.org Hi guys, The first draft of the MacPorts GUI app called Fossick can be downloaded from: http://www.filedropper.com/fossickclonetar by clicking a Download button or two, once you can find your way past all the ads. Does anybody know a better file share site? I'm a newbie at this stuff. Could you just create a git repo and push the entire Xcode project to GitHub, especially if you are sharing source code at this point? No, I decided against that and I am not sharing code at this point, just making it available for review. I have a local GIT repository, but I have other work I do on another remote GIT repository (KDE development) and I do not wish to mess with my GIT setup for remote access. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Macports GUI (Fossick) - First draft nearly ready
On 21/04/2013, at 12:51 AM, Jeremy Lavergne wrote: I am thinking of putting the tarball on Dropbox. Would that be suitable for list members to extract and review? I've never used dropbox, but I guess anonymous access should be possible there, right? Yes, Dropbox should be fine. Also mirrors can be setup pretty quickly. Thanks, Jeremy. I will use it next time. I was just about to, but Marko raised this doubt and I could find nothing on the Dropbox website that said you can share files publicly without users having to log in or join a group. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Macports GUI (Fossick) - First draft nearly ready
On 18/04/2013, at 5:42 AM, mk-macpo...@techno.ms wrote: if you haven't commit access to MacPorts' SVN server you could use github or bitbucket to publish your code. Thanks, Marko. I don't think I am ready to go remote with Fossick in git. Amongst other reasons, I do not wish to risk messing up the setup for my access to KDE's git repositories. I have made a local git clone of my local Fossick repository and extracted the .git files, leaving just the source files, Xcode project files and nib file. These compress down to a 56.3 Kb FossickClone.tar.gz file. I am thinking of putting the tarball on Dropbox. Would that be suitable for list members to extract and review? The code should build and run with Xcode 4.6 and Lion or later. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Macports GUI (Fossick) - First draft nearly ready
Hi guys, The first draft of the Macports GUI (Fossick) is nearly ready for its first push to a central repository. So far, it can retrieve an index of all ports, search it in a couple of ways, display information about a selected port (port info, port-file, file content list and dependencies), display port statuses and run install and uninstall commands. Can you tell me where I could push it to (i.e. repository URL) and whether I need an account or password to push to that repository? I guess I am assuming a GIT repository, but SVN would be fine too. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RFC: Spec for Fossick (proposed MacPorts GUI)
Hi guys, Attached is a pure-text file (made with vi), containing my ideas so far for a new MacPorts GUI. Comments, suggestions and reviews are welcome. It is intended to be a simple tool for first-time users (in Basic mode) and a more versatile tool for more advanced users (in Advanced mode) to browse the huge amount of information stored in MacPorts. Fossick is a working title for the GUI --- as explained in the attached. I have been slowly getting to grips with Xcode 4.6, Cocoa, the Interface Builder and Objective C in the last few weeks. It certainly has a different philosophy from Qt and C++. A rough prototype layout is now running. It can load and search all the ports, but needs more menus and toolbar items and the functionality that goes with them. The screenshot is 160 Kbytes. Should I attach it? I have also worked out a scheme to launch port commands in the background and monitor the output, requesting an admin password in the usual Apple OS X popup, when required. BTW none of the above uses Macports Framework. It works directly with the port index file and the port command. IMHO that will provide a more stable interface than MacPorts Framework, long-term, and its speed is adequate. The main window has three panes: top, bottom left and bottom right, all of which are resizable within the overall window size. The top pane is a table view of all ports or all those found by the most recent search (case-insensitive) of name and description and (optionally) a category. There will probably also be a way to select installation statuses (analogous to port installed, etc.). The bottom two panes will run a more advanced search, monitor the output from a background run of port commands or provide various kinds of information about ports clicked on and selected in the top pane. Please have a look and send your comments. All the best, Ian W. FOSSICK - Specification for a MacPorts GUI -- Fossick is an Australian word for free, unlicensed exploring of a mine site. Some fossickers have been known to find valuable gold nuggets, even in recent years. Fossick also begins with the letters FOSS, so it contains the idea of searching for and finding Free Open Source Software. Target Users 1. People who have just bought their first Apple Mac. 2. People who have used a Mac for some time, but have not encountered OS X up close or are not aware of FOSS (Free Open Source Software) available on the Mac. 3. Users of FOSS on the Mac who would prefer to use a GUI or at least have a simplified way of installing and updating FOSS. 4. Expert users of FOSS and MacPorts who would like an alternative tool to explore the huge amount of information available in a MacPorts environment (16,000+ ports and counting). Objectives -- 1. Make it easy for user groups 1 and 2 to install, update or uninstall the basic provider software such as MacPorts itself. 2. Make it easy to find FOSS that a particular user might find interesting, especially users in groups 1 and 2. 3. Make it easy to install, update and keep track of selected FOSS in the user's system. 4. Avoid surprises and uncertainty involving long installation times. 5. When an installation or update fails, make it easy for the user to gather and report the necessary diagnostic information and to recover to a pre-installation state --- maybe even to attempt to diagnose the problem him/herself. 6. During an installation or update, provide a selectable level of detail re what is happening. 7. Spend less time on handling tickets and mailing list queries (see 5 above). Requirements 1. For each FOSS provider (initially only MacPorts), retrieve a complete list of all software items provided and their attributes. 2. Make the list of items selectable and filterable by a range of attributes and values, similar to what is possible in MacPorts commands, but possibly including an additional list of root items on which no other items depend. 3. Display retrieved lists in table form, with name, installation status, version, short description, categories and variants of each item. 4. Provide a one-click display of full details (as in port info) for any item in in the table view. 5. For Basic user mode, provide a default search method and basic information on each software item (e.g. info, dependencies and home page). 6. For Advanced user mode, provide an advanced search method and a full range of information on each software item (e.g. portfiles, contents, etc.). 7. Provide menu/toolbar actions for install, upgrade, uninstall, etc. for any item in the table view, putting the required action in a list or queue of actions to be performed. 8. Analyse the dependencies and dependency actions implied by an action, before it is run, and warn the user if the total number of actions exceeds a limit set
Re: Submission: klusters
On 13/03/2013, at 11:07 AM, Nicolas Pavillon wrote: That's interesting, because there was a discussion some days ago about keeping (or not) kde3 in macports after its deprecation. I did not try to install kdelibs3 for a long time (essentially due to the conflict with kde4), though. The developers announce on their website that a port to qt4/kde4 should be done at some point, also. For at least 3 or 4 years after the beginning of KDE 4 it was possible to run KDE 3 apps on a KDE 4 desktop (i.e. so that KDE 4 would not lose almost all apps on day one). FAIK that is still true --- I have not tried it for a couple of years. From what I can remember, what made this possible was: - Separate and unique naming of KDE and Qt libraries, with links such as qt3.so to the latest versions of the basic XXX 3 and XXX 4 libraries and binaries. - Separate areas in $HOME (equivalent to $HOME/Libraries/Preferences) for keeping users' settings and work files. - Separate areas for other files such as temp files and caches. - Environment variables to keep track of it all. I am relying on memory, so if I have missed something, please excuse. Is it possible to do something similar on Macports and remove the conflicts with restriction on KDE 3 and Qt 3, or is there some more fundamental problem, such as qt4-mac is native to Mac OS X desktop and qt3 is not? It seems there are some people who still want to use the KDE 3 and Qt 3 libraries for their 3rd party apps, though I think the standard KDE 3 and Qt 3 apps have almost all been superseded by Qt 4 and KDE 4 versions. For those people still using Qt 3 and KDE 3 libraries, porting apps to KDE 4 and Qt 4 is indeed a large task. Been there, done that ... see my white hair … :-( So can we help a little? Or would it be just a lot of hard work for Macports people for little gain? Cheers, Ian W. On Mar 11, 2013, at 11:11 PM, Aljaž Srebrnič g...@macports.org wrote: What do you think about this[1] ticket? Can anyone test it? kdelibs3 won't compile on my machine... [1] https://trac.macports.org/ticket/38145 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: user manuals
On 07/03/2013, at 7:03 PM, mk-macpo...@techno.ms wrote: On Mar 7, 2013, at 4:57 AM, Ian Wadham wrote: I looked at the main.log for ticket 37620, but there is a lot of concurrency and it is hard… Concurrency?! I wasn't aware of that, actually. You must be. make runs parallel build streams all the time (-j option), but it is supposed to work out the dependencies and not try to compile code too soon. It crossed my mind that meinproc4 sometimes might not work in parallel with itself, but I think if that were so it would long ago have come up in KDE development builds. BTW, I don't think KMyMoney really needs a man page, so if parallelism is the problem you could just leave out the man page in Macports. I guess you tried commenting out the ADD_SUBDIRECTORY( doc ) line (line 309) in https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/master/entry/CMakeLists.txt and maybe lines 310-312 or either/both the lines in doc/CMakeLists.txt. Thanks so much for pointing THIS out!! Old kdegames4 trick. Sometimes, during development, other people's games fail to build … ;-) So, perhaps this is it now!!! Great! I'll take care of kmymoney4 itself later. Well, it gets meinproc4 out of your hair for now, but KMyMoney *should* have a Handbook … :-) Thanks again, Ian! :-) No worries. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: user manuals
Hello Marko, On 06/03/2013, at 9:00 AM, mk-macpo...@techno.ms wrote: On Mar 5, 2013, at 10:47 PM, Ian Wadham wrote: On 06/03/2013, at 1:14 AM, Jeremy Lavergne wrote: * doc building used meinproc4, which routinely crashed and prevented installation (might still be a problem) Ah, I understand. Well, I think meinproc4 is OK now. Last year I did extensive updates to some index.docbook files in KDE Games, for the KDE 4.9 and 4.10 releases, and was able to build and test-proofread them quite easily on a Macbook KDE-dev setup. meinproc4 is very fast (~ 1 second), so I would suggest the following: Ian, actually meinproc4 still *IS* a problem. The buildbots run into it some times, users do too as e.g. issue https://trac.macports.org/ticket/37620 shows. That's nasty … :-( I looked at the main.log for ticket 37620, but there is a lot of concurrency and it is hard to see what is going on. It's interesting that KMyMoney has two manuals to build, a Handbook and a man page and both meinproc4's are running at the same time. Also, KMM has multiple .docbook files for the Handbook, a header file and a file for each chapter. Maybe one of those factors is affecting meinproc4's fate on Apple Mac. I tried a small script with two meinproc4's in parallel working on two KDE Games Handbooks. It worked fine, but it was all over so quickly that I am not sure I got much concurrency. Would you like me to clone KMM from https://projects.kde.org/projects/extragear/office/kmymoney/repository and try building it in my development environment? My production copy of KMM (from Macports) is fine. It built both the Handbook and the man page OK and displays them OK. It is version 4.6.3_0, which I installed on 13 Sept 2012. I wished I knew how to avoid any calls to meinproc4 during the build procedure. I think I did everything possible in kmymoney4(-devel)'s ports to avoid building any bit of documentation, but for some reason meinproc4 gets still called. There was no response concerning this on KDE-DEVEL mailing list, unfortunately. So, I am clueless as to what else I might try to avoid this endless problem. Debugging is also not really possible, since the crash occurs only spuriously!!! :-( I guess you tried commenting out the ADD_SUBDIRECTORY( doc ) line (line 309) in https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/master/entry/CMakeLists.txt and maybe lines 310-312 or either/both the lines in doc/CMakeLists.txt. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] KDE modified
On 06/03/2013, at 12:14 AM, Nicolas Pavillon wrote: I wrote it a certain way to try to emphasize the necessity of performing these steps, even though it may not have been the best choice of words. I corrected it to hopefully avoid confusion. Fine by me. Nicolas, are you happy overall with the changes I made to the KDE Wiki yesterday? Re the unfinished List of ports section, maybe we could flesh out https://trac.macports.org/wiki/KDEPackages, which is already a good start, and just have a link to it in https://trac.macports.org/wiki/KDE I would be happy to add a section for KDE Games … :-) Maybe the KDEPackages page should follow the structure of the KDE Projects pages. Also, I would like to add links to our MacPorts KDE pages into KDE's page about Apple Mac (http://community.kde.org/Mac?id=build) and tell kde-...@kde.org list. Cheers, Ian W. On Mar 5, 2013, at 1:21 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: I think they convey the right air of dampening down end-users' expectations (recall two recent examples of those on macports-users). We might might as well lament you must run the MacPorts installer as we're not bundled with OS X. I do not think those words are any reflection on the power of MacPorts, but I would be happy to qualify them in some way if others think that. I fear it's ambiguous and distracting because the definition of out of the box could be interpreted as any number of things. I don't feel it contributes to the How do I setup KDE? conversation and is commentary—which I share I wouldn't put in a how to wiki. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: user manuals
On 06/03/2013, at 1:14 AM, Jeremy Lavergne wrote: It's probably better to create subports that install documentation only. The original reason these were left off were * slowing down an already humongous build cycle (no longer an issue thanks to buildbots) * doc building used meinproc4, which routinely crashed and prevented installation (might still be a problem) Ah, I understand. Well, I think meinproc4 is OK now. Last year I did extensive updates to some index.docbook files in KDE Games, for the KDE 4.9 and 4.10 releases, and was able to build and test-proofread them quite easily on a Macbook KDE-dev setup. meinproc4 is very fast (~ 1 second), so I would suggest the following: - Always build the user manual for a KDE port, using the CMakelists.txt file - Add a note to the Macports KDE Wiki to show where to find API docs online - Discontinue the +docs variant for KDE ports My reasons for discontinuing the +docs variant in KDE ports would be: - It brings in additional dependencies needed by Doxygen but not by all end-users - It acts recursively (if you are not careful or do not know), and could bring in all of the Qt doco, which is rather extensive … - No need for KDE subports ... What I am suggesting is essentially what Linux distros do, i.e. always supply the user manual and do not supply the API doco, except perhaps in a -devel binary package (ie. one with source-code headers for developers to use). All the best, Ian W. On Mar 5, 2013, at 12:01 AM, Ian Wadham wrote: 4. Many KDE apps come with user manuals: should MacPorts install them by default? If no, I will add a recommendation to the Wiki to use the +docs variant. If yes, is there perhaps some more efficient way for Macports to provide them? I am unclear on what variants do exactly (ie. local vs. global). If I ask for +docs, do I get it on all the dependencies? Also, with +docs I seem to get all the dependencies needed to generate every possible format of the application's API doco from Doxygen (not required by the average user). KDE user manuals are in XML and follow the Docbook convention and there is a KDE utility to convert them to HTML during build and installation. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE instructions
On 06/03/2013, at 1:27 AM, Nicolas Pavillon wrote: 1. Do we need the kde-i18n- ports? As these ports are from the kde3 suite, I would say they are as relevant as any KDE 3 port. Understood. 2. Do we need the KDE 3 ports? /snip It seems there is indeed not much left which uses kde 3, when looking at the status of most ports, though. Thanks for your detailed analysis of the situation, Nicolas. Very helpful. All I can think of is a few games that never got converted to KDE 4, such as KSokoban. I think most of those have been replaced, e.g. KSirtet == KBlocks for Tetris enthusiasts. And KOffice == Calligra, as you noted. 3. Does MacPorts delete KDE users' data files when it uninstalls/re-installs? I don't think Macports deletes these files, at least most of them. Macports only uninstalls the files copied during installation, not the files created at runtime by the application. If you run port contents appname, the appnamerc file will not show up, neither the files in ~/Library/KDE. I'll do some tests when I have time. I certainly had some home-made jigsaw files go missing and have not found out why, but they are easy to re-create … :-) Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: user manuals
On 06/03/2013, at 10:15 AM, Lawrence Velázquez wrote: On Mar 5, 2013, at 4:47 PM, Ian Wadham iandw...@gmail.com wrote: My reasons for discontinuing the +docs variant in KDE ports would be: - It brings in additional dependencies needed by Doxygen but not by all end-users Most of those dependencies are for graphviz, which I hope to remove from doxygen's dependencies soon. (See https://lists.macosforge.org/pipermail/macports-dev/2013-February/022085.html and replies.) Yes, I saw that. And IMHO it would be a good move to remove graphviz dependency. FWIW, the online API doco for kdelibs4 uses diagrams, see http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMainWindow.html But that does not mean that MacPorts ports should. As I suggested before, I think it would be fine to leave all API doco out of KDE ports, since it can easily be obtained by other means, if required. Cheers, Ian W ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] KDE modified
On 05/03/2013, at 12:22 PM, Jeremy Lavergne wrote: Unfortunately, MacPorts **does not provide an out-of-the-box working installation**. I'd almost leave that sentence out, and stick with the general these are the steps for doing ... in MacPorts. Those were Nicolas' original words and I saw no reason to change them. I think they convey the right air of dampening down end-users' expectations (recall two recent examples of those on macports-users). I do not think those words are any reflection on the power of MacPorts, but I would be happy to qualify them in some way if others think that. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE instructions
On 03/03/2013, at 4:28 PM, Lawrence Velázquez wrote: On Mar 3, 2013, at 12:05 AM, Ian Wadham iandw...@gmail.com wrote: This page is an excellent start, Nicolas! I have one or two points to add to it. Where do I find the wiki source? Can I edit it? Probably not. I do not have edit access to anything in MacPorts. So how would you like me to proceed? Anyone with a Trac account can edit the wiki; just click the Edit this page button at the bottom-left of any page. I have just finished some fairly extensive edits of https://trac.macports.org/wiki/KDE Reviews and comments are welcome. I am a newbie at Wiki editing, so please excuse any errors of style. Several questions arose during this work. Some I will put on a separate thread or a ticket. I'd like to deal with the following quickly and inline if possible: 1. Do we need the kde-i18n- ports? AFAIK kde-l10n- (localization) modules provide language translations for KDE and i18n (internationalization) issues are all handled upstream, starting at the developer's desk. 2. Do we need the KDE 3 ports? KDE 3 is now obsolete and no longer supported by KDE. MacPorts says that KDE 3 and KDE 4 ports conflict. I think that means you cannot install a mix of KDE 3 and KDE 4 ports. On Linux you still(?) can. They are kept separate by using different working directories, library names, etc. Some KDE 3 apps never got ported to KDE4/Qt4 and people come looking for them sometimes. The usual reply on KDE lists is, How about helping by porting it to KDE 4?. 3. Does MacPorts delete KDE users' data files when it uninstalls/re-installs? I suspect it does. See the section in the Wiki on Installation location. In ~/Library/Preferences/KDE, we have share/apps, share/config and share/kde4. share/config has one file per app, called appnamerc. This appears on Mac in the AppNamePreferences… menu item. It is right and proper to preserve this across installations. share/apps has one directory per app, called appname. KDE applications use this to store data the user has created when using the app. It should be preserved across installations. For example, if you are using kdegames4's Palapeli jigsaw-puzzle app, that directory contains puzzles you have created from your own pictures, plus the current state of all puzzles you are currently solving. You do not want mum to come and tidy them up … :-) 4. Many KDE apps come with user manuals: should MacPorts install them by default? If no, I will add a recommendation to the Wiki to use the +docs variant. If yes, is there perhaps some more efficient way for Macports to provide them? I am unclear on what variants do exactly (ie. local vs. global). If I ask for +docs, do I get it on all the dependencies? Also, with +docs I seem to get all the dependencies needed to generate every possible format of the application's API doco from Doxygen (not required by the average user). KDE user manuals are in XML and follow the Docbook convention and there is a KDE utility to convert them to HTML during build and installation. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Office software on Apple and MacPorts
Hi guys, For as long as I can remember (well, back to Macintosh days anyway), I have been going into Apple dealers, including the current chain of Apple Stores, and seeing customers (including me) asking for office apps and being told to buy Microsoft Office for Apple. This is surely a regrettable state of affairs, but perhaps an opportunity for FOSS … :-) For myself, I use Libre Office (a successor of Open Office) and it works fine for me on Macbook, Linux and Windows and I can interchange Libre Office files between platforms and with Microsoft Office. I use it to prepare notes and slideshows and the occasional spreadsheet. I see MacPorts has KOffice for KDE 3 (obsolete) and apparently not much else in the office software department. KOffice sort of limped into KDE4, then forked into Calligra, see http://en.wikipedia.org/wiki/KOffice#History It seems that KOffice for KDE 4 is moribund, but Calligra is alive and kicking. See http://www.calligra.org/news/calligra-2-6-1-released/ Is it worth taking a look at Calligra as a possible MacPorts port? I have not tried Calligra 2.6.1, nor any Calligra version. This is just an exploratory enquiry. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE instructions
On 02/03/2013, at 6:25 PM, Ryan Schmidt wrote: On Mar 2, 2013, at 01:23, Nicolas Pavillon wrote: Following the discussion concerning the improvement of the display of port notes, I was also considering gathering the information for installing KDE ports somewhere. I noticed that while we have an extensive page in the wiki concerning gnome (https://trac.macports.org/wiki/GNOME), KDE just links to the somewhat outdated external page of KDE about Mac. I am not sure anymore about the policy concerning the wiki. May I create directly the page and gather the information on a new page dedicated to KDE, or is there a validation procedure, since it is not monitored through commits like the Macports Guide ? Changes to the wiki do get sent to the macports-changes mailing list, just like commits to the repository. Please feel free to create wiki pages and write documentation to your heart's content! And if you need any help, review, etc. please let me know. Unfortunately, I do not know how to write wikis, but I do know a little about KDE and the KDE project, so maybe I can get some questions answered. I am not sure if anyone new to KDE apps will see the proposed wiki before they jump in at the deep end and try to get digikam or kdenlive installed and running and then get into trouble (as has happened just recently). But the wiki will be a valuable resource to show them after the event and help them recover. All the best, Ian W. KDE Games Developer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE instructions
On 03/03/2013, at 1:40 AM, Nicolas Pavillon wrote: I created a page (https://trac.macports.org/wiki/KDE) with the information I thought relevant for now, and added its link to the main wiki page. As I do not consider myself a KDE expert neither a Macports one, some parts may be incomplete or inaccurate. Please feel free to edit/correct them. I will also expand the ports list in order to try to have something describing the maze of KDE ports. This page is an excellent start, Nicolas! I have one or two points to add to it. Where do I find the wiki source? Can I edit it? Probably not. I do not have edit access to anything in MacPorts. So how would you like me to proceed? Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE instructions
On 03/03/2013, at 4:28 PM, Lawrence Velázquez wrote: On Mar 3, 2013, at 12:05 AM, Ian Wadham iandw...@gmail.com wrote: This page is an excellent start, Nicolas! I have one or two points to add to it. Where do I find the wiki source? Can I edit it? Probably not. I do not have edit access to anything in MacPorts. So how would you like me to proceed? Anyone with a Trac account can edit the wiki; just click the Edit this page button at the bottom-left of any page. Thanks, Lawrence. My login for submitting tickets is enough to get that … :-) Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
On 20/02/2013, at 11:43 AM, Jordan Hubbard wrote: On Feb 14, 2013, at 12:46 AM, Rainer Müller rai...@macports.org wrote: The message classification currently happens through a handful of procs such as ui_error, ui_warn, ui_msg, ui_notice, ui_info, ui_debug. These add the prefix for errors and warnings and decide whether to print the message at all based on the verbose, debug or quiet flag, -v -d -q, respectively. Right, that part is already well-segregated and easy to extend. I think Ian's more concerned with: Yep. I think port(1) is quite good in that respect already, but messages arising from builds are not. Port(1) puts --- and Error: prefixes on key lines of output. Thanks, Jordan, I am currently looking along the lines of running MacPorts commands as a Shell script in the background and collecting the stdout and stderr in the GUI app as the script proceeds, filtering it (if necessary for the kind of end-user involved) and displaying progress info. With the help of an Apple Tech Note I have worked out a reasonable way to do all this from Cocoa, requesting an admin password in the normal Apple OS X way when it is needed. There will probably be no need to parse build-messages. As I see it, it's more of a need to tick off MacPorts stages as they proceed (for filtered progress reporting). I think those will be easy to identify and parse. If anything goes wrong during a MacPorts run, there wouid be a need to recall error output for immediate troubleshooting or inclusion in an error report (e.g. the details commonly asked for on the macports-users list or in a ticket). I say pipe or pty since I'm not sure if a pipe would catch any and all types of subprocess I/O, but it probably would (and would be a lot simpler than doing the PTY allocation) so I'd try that first and just keep PTYs as a fall-back idea. port commands as they stand might provide all the output I need. A PTY might provide finer control over I/O between the GUI and MacPorts. Thanks for the idea, Jordan. For now, I am using a Cocoa/OS X NSPipe to listen to the usual port command output in the GUI. Cheers, Ian W. P.S. Re the main topic here: We have not heard back from the authors of Macports_Framework and Pallet and I am tending towards using the port command and the PortIndex file as the only interface between a GUI and MacPorts, i.e. no Macports_Framework. I think this will offer a more loosely bound and future-proof interface than Macports_Frameworks, as well as being more general (i.e. extendable to other sources of FOSS on the Mac). Using the PortIndex file is not strictly necessary, but should be more efficient timewise than using port commands alone to retrieve data about all the available ports. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
On 12/02/2013, at 9:03 PM, Rainer Müller wrote: On 2013-02-12 05:29, Guido Soranzio wrote: 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 tool since MacPorts needs root privileges. As of Snow Leopard and beyond, the ServiceManagement.framework is the preferred method of managing privilege escalation on Mac OS X and should be used instead of earlier approaches such as BetterAuthorizationSample or directly calling AuthorizationExecuteWithPrivileges: http://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html. The MacPorts.framework has a helper tool which bases its authorization on BetterAuthorizationSample [1]. There are helpers and helpers … I think the helper in ServiceManagement is some kind of middle man to prevent spoofing or masquerading of the front-end GUI to obtain unauthorised access to the Apple system. In our case, we are protecting Macports with sudo. Also the helper for Pallet uses a now-deprecated Apple facility (BetterAuthorizationSampleLib) and seems to get security functions intertwined with access to the Macports library code in a way that is very hard to follow. Another approach I have come across on forums is to use: NSString *script = @do shell script \some macports command\ with administrator privileges; NSAppleScript *appleScript = [[NSAppleScript new] initWithSource:script]; If the Macports command requires sudo, you get the usual Apple popup for entering an admin password. Porticus had a very solid management of privileged processes and that's why I petitioned its author to open source it: http://porticus.alittledrop.com/ downloads/Porticus.zip. Unfortunately Richard Laing hadn't the time to transition Porticus to OS X Lion and I decided for a totally different route. Thanks for reminding us that this code is available! I've downloaded that too, a few minutes ago, just to have a look. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
Hello Rainer, And thanks for very much your insights on what happened to Pallet and Macports_Framework. On 12/02/2013, at 8:58 PM, Rainer Müller wrote: thank you for your interest in MacPorts.framework. I will try to give some insight into the state of this framework and the MacPorts GUI, which will hopefully explain the state of the project. On 2013-02-10 10:59, Ian Wadham wrote: On 10/02/2013, at 8:11 PM, Ryan Schmidt wrote: On Feb 10, 2013, at 00:39, Ian Wadham wrote: Should I persevere with Macports_Framework? What alternative do you propose? For myself, acting alone? None. Find something smaller and easier to work on - not Macports_Framework, Pallet or other GUI. For Macports? That's up to you guys. Fix it or forget it, or at least withdraw Pallet and Macports_Framework from distribution for the time being. In my experience, most of the developers involved in MacPorts are coming from a Unix background and are driven by the need to run additional tools in their terminals on Mac OS X in the same way they would do on Linux or *BSD. For myself, I have absolutely no idea how to develop graphical user interfaces on Mac OS X and I have no interest to learn that as I am quite happy with a terminal. I come from a similar background too, but starting on an 80x24 character based terminal … :-) On the other hand, there is a wide user base with inexperienced users who would prefer a GUI to interact with MacPorts. I am thinking of all those customers I see in the Apple Shop who might like to know that there is free software available on Apple Mac and be able to get it easily. Not so much the tools, but more the big applications like Gimp and Digikam. When we were accepted into Google Summer of Code [1] a few years ago we tried to fix that with the idea that a student should have the opportunity to write GUI for MacPorts and being paid for that work. After that summer, we had the initial version of MacPorts.framework. In the next year, on top of that Pallet was implemented by a different student under supervision by the first and a third student improved the GUI in the year after that. The main problem now is that none of these original developers of the MacPorts.framework or Pallet sticked with the project, which means the code is currently orphaned and does not have any active maintainer. Since then, there were many changes and refactoring in the base code, including but not limited to the introduction of registry2.0. This lead to a lot of changes which seem to make MacPorts.framework incompatible. If someone can fix MP_Fr, I can assist, but I do not think I can handle it alone. I added all the previous developers of MacPorts.framework and GUI to Cc, I would be glad if some of them want to lend you a hand. I know that some of you retired, but I thought that you might be interested in where your work ends up now :-) The main technical leader seems to have been a guy called Randall Was he rhw...@macports.org? Was he a student or a Macports developer? The code contains several comments where people are looking for advice from Randall. If we could find *him* ... 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. I think maybe MP_Fr does something like that already ... No, the framework links with Tcl and makes calls to the macports1.0 library. There are some HeaderDoc comments in the source code, although I have no idea how to generate any HTML documentation from that… I was able to download HTML doc for Macports_Framework from a repository branch somewhere. It has been quite useful. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
On 13/02/2013, at 12:06 PM, Jordan Hubbard wrote: On Feb 10, 2013, at 8:13 PM, Ian Wadham iandw...@gmail.com wrote: I heartily agree with you that wrapping basic commands is not enough. I particularly hate GUIs that wrap basic programming and then pass through base-level error messages ---unedited and out of context. Just to riff on this a bit - it IS possible to design to a goal somewhere in between the ideal of Macports_Framework being a complete API for MacPorts' internals and just calling system(port install bletch) and hoping for the best as you attempt to parse an undisciplined stream of text flying out of the shell. What you do instead is add special text markers to port(1) which it emits when called in a special slave mode from a GUI (or, for that matter, a batch build wrapper doing macports builds for a Tinderbox server). Those let you differentiate different build phases and also separate normal build output from errors, all without having to know more than what text markers to look for. Hugely elegant it may not be, but it works - I know because this same approach has been used by numerous GUI wrappers for Unix tools over the years, the most successful ones using this technique. It's probably how XML was ultimately invented. :-) Yep. I think port(1) is quite good in that respect already, but messages arising from builds are not. Port(1) puts --- and Error: prefixes on key lines of output. From a GUI point of view, you can do as Guido Soranzio's Guigna app does and pass everything through a real Terminal window, unedited and unparsed (if there is such a word). Or it would probably be enough for an end-user to know: 1. Has the action finished? 2. Did it succeed or fail? 3. If it failed, what are the error messages? 4. If he/she cannot understand what went wrong (e.g. service provider's server is down), can messages and logs be made easily available for an email to macports.users or for submitting a ticket? 5. If port(1) is taking a long time, what is it doing, what remains to be done and what has it done already? IOW, should he/she kill it now or wait till he/she gets back from that urgent dental appointment? I think it may be possible to get all of that from port(1) without very much parsing. The idea of putting markers in port(1) outpu is nice. If that became necessary, would patches for review be acceptable to Macports developers? Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
The new Guigna app
Hi guys, Here is something you might like to have a look at. On 10 Feb, Guido Soranzio posted here https://lists.macosforge.org/pipermail/macports-dev/2013-February/021976.html about his new Guigna app. You can find it on GitHub at: https://github.com/gui-dos/Guigna and you can clone it (check out the source code) with: git clone https://github.com/gui-dos/Guigna.git in a suitable working directory. That creates a Guigna/git subdirectory. Or you can see a overview and screenshot here: https://github.com/gui-dos/Guigna/blob/master/README.md Two days ago, I cloned and built it. It is an Xcode project, written in OS X 4.8 I think, but I was able to change the Deployment Target project attribute to 10.7 and get it to go. It already provides much of functionality I would like to see in a Macports GUI --- and it takes care of not just Macports , but also Homebrew, Fink and some other sources. It even provides an inventory of your Apple and App Store software, and I was quite surprised to see my copy of Angry Birds in there … gotta keep up with the grandkids … ;-) Guigna is beautifully laid out, but has just a few rough edges … Hell, Guido's first commit was only nine days ago! Some of you will like the way it delegates port actions to a Terminal window, and that is where you put in your admin password, just as in the real Macports … :-) I believe you can even intervene in that window and insert some commands, just as if you were using port from a command-line. Wearing my end-user hat, I do not like that approach, but I believe it would be possible to have both Pro and Home options in Guigna, if Guido does not object. I'd like to write a mini-spec for the Home option in the next few days and put it up for review. Then, if it is OK with you, Guido, maybe I could start tinkering with some ideas on a local Git branch. And guys, Guigna is well worth a look! Give it a go. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
On 10/02/2013, at 8:11 PM, Ryan Schmidt wrote: On Feb 10, 2013, at 00:39, Ian Wadham wrote: Should I persevere with Macports_Framework? What alternative do you propose? For myself, acting alone? None. Find something smaller and easier to work on - not Macports_Framework, Pallet or other GUI. For Macports? That's up to you guys. Fix it or forget it, or at least withdraw Pallet and Macports_Framework from distribution for the time being. If someone can fix MP_Fr, I can assist, but I do not think I can handle it alone. 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. I think maybe MP_Fr does something like that already ... Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
Hello Guido, On 10/02/2013, at 10:36 PM, Guido Soranzio wrote: 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: https://github.com/gui-dos/Guigna. That looks very nice. You have certainly put in a lot of work. It is at a very early stage of development and it is rather naive: on the contrary of you, I am no so proficient in multithreading programming but I think that a screen scraping approach is not that evil. There is no great virtue in multi-threading or multi-processing if you do not have to, IMHO. I cut my teeth on multi-user O/S and real-time, but my rule-of-thumb has always been: The number of difficulties and bugs goes as the square of the number of threads or processes involved … :-) Conversely, by keeping processing simple, you get working results sooner. Screen scraping is a term that is new to me. What does it mean in Guigna's case? In my humble opinion, a really useful GUI for MacPorts should address not only the final users but also the developers and the budding new committers. It should go far beyond wrapping the basic commands and instead be capable of launching its own automating scripts, detecting other package managers and solving the conflicts, aggregating the latest commits from the Web and comparing the different versions available from different sources, connecting to experimental repositories from third parties. I think it might be confusing for end-users to have all of that in one app, but great for developers and system admins. I heartily agree with you that wrapping basic commands is not enough. I particularly hate GUIs that wrap basic programming and then pass through base-level error messages ---unedited and out of context. The popup message Invalid type. OK? is a classic example (from MSAccess 2000). What type is invalid? In which program? And what data was being accessed? The user/programmer is left to guess. Guigna passes through everything, in context, and that is a valid way to go, IMHO, as long as your target users can understand what they see. All the best with Guigna, Guido. Please keep in touch. A multi repository, multi system GUI for installing FOSS on a Mac is indeed an ambitious undertaking. Go Guido! Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is it worth persevering with Macports_Framework?
On 11/02/2013, at 4:51 AM, Kevin Walzer wrote: On 2/10/13 1:39 AM, Ian Wadham wrote: Should I persevere with Macports_Framework? It's been a while since I worked with threads and concurrent processes and Apple's way of doing things, in Objective C, OS X and Xcode is all new to me. I enjoy a challenge, but in this case, is it (Macports_Framework) worth the effort? People are lukewarm about having a GUI for Macports anyway. I am not, but I find the framework for interacting with Macports to be huge and rather daunting. It's been my observation that as long as MacPort devs have worked on a GUI, they have tried to do it the hard way--writing it in Cocoa, and making use of MacPorts internals. A classic Unix design pattern would limit the scope of the project to writing a user-friendly GUI, leaving MacPorts internals alone, and using the port tool as the point of contact. The GUI can drive MacPorts via commands to the port tool, then parse its output for its own purposes. Back in the day, I was a great fan of popen() (man 3 popen) for gathering info in real time from multi-host distributed database systems. You get multi-processing for free and synchronisation is as simple as sequential I/O. 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. Our founding fathers (Thompson, Ritchie, et al) knew what they were doing when they developed pipes. However, I stopped short of using the word parse in my previous email and used the word intercept instead. The port command has a slew of possible message texts and presumably they are subject to change at any time. I doubt if I have seen them all yet … :-) Also, do they get translated into other languages and locales? OTOH, just glancing at the Macports code, it does seem to have a consistent policy wrt messages, such as an error message always begins with Error: … ;-) A lot of Cocoa devs (professional ones) mock this approach as simply wrapping a GUI around a command-line tool. But this approach has the virtue of simplicity, letting MacPorts do what it does best and letting the UI concentrate on providing a pleasant user experience. Absolutely. And I think what a GUI should do is save the raw text, logs, etc. for port developers' attention, in case needed, and show the user basic summaries of progress, success or failure and inventories of what has been installed when, maybe with the option to display full text if that is what the user prefers. Re the multi-threading approach, which I think goes about three deep in Pallet and Macports, I find the code is in a thread when Pallet and Macports_Framework return from a port command, so I cannot issue a NSAlert message if there has been an error … ;-) As in Qt4-Mac, widgets don't work on a thread. Maybe that is why Pallet brought in Growl. Never mind, I will find a solution in due course and am using NSLog for now, while I am trying out Pallet and Macports_Framework further. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Is it worth persevering with Macports_Framework?
Hello everybody, I raised this topic on macports-users under the subject How to get a full list of dependents?, but it is undoubtedly better to discuss it here and under a proper subject line. I have been studying the source code of Pallet and Macports_Framework and doing a bit of testing of both, with a view to developing a GUI for Macports. I am using Xcode 4.6 and OS X 10.7.5 (Lion) on a Macbook Pro of 2011 vintage. Please note that I am new to Objective C, Xcode and OS X, but I have been developing in C++, Qt, KDE and Linux for a few years. I am in charge of KGoldrunner, KSudoku, Kubrick and KJumpingCube in the kdegames4 set. It appears that Pallet and Macports_Framework are both ex-GSoC projects that are not really finished. Certainly they have a few rough edges. Joshua Root described it as a pre-alpha state. On 10/02/2013, at 7:37 AM, Joshua Root wrote: MacPorts_Framework is still in a pretty pre-alpha state, so I wouldn't worry too much about maintaining compatibility if not doing so will make it better. Just make sure you mention the interface breakage in the commit logs, and fix Pallet to match. I replied as follows. It looks as though backwards compatibility is an impossible ask in an Xcode environment. For starters, there are all the .xcodeproj files. My Xcode 4.6 grumbles about them all the time and FAIK has already changed them a lot. The files in SVN are for Xcode 4.3, I think. Then Xcode keeps pushing newer features that are somewhat fundamental, such as automatic reference counting and Interface Builder layouts with constraints. These are nice features, but not backwards compatible. Re the pre-alpha state of Macports_Framework, tell me about it … :-) One problem is that there is almost zero error information (in an NSError object) passed back to Pallet, but lots of comments to self in the code about the need to do something. Another problem is that Pallet ignores the NSError object anyway and treats all actions as successful. A third is that actions like install Growl should always fail (the Growl port is broken), but sometimes are said to succeed (in the Console messages), when you use Pallet to do install Growl. Macports_Framework has over 12,000 lines of code, and nearly 4,000 lines are a copy of Apple code for BetterAuthorizationSampleLib, dated 2007 (Is that code still current, I wonder?). Should I persevere with Macports_Framework? It's been a while since I worked with threads and concurrent processes and Apple's way of doing things, in Objective C, OS X and Xcode is all new to me. I enjoy a challenge, but in this case, is it (Macports_Framework) worth the effort? People are lukewarm about having a GUI for Macports anyway. I am not, but I find the framework for interacting with Macports to be huge and rather daunting. I am happy about building a GUI for Macports and I hope it would be an improvement on Pallet, but I am getting cold feet about Macports_Framework. If I persevere, I could certainly use some help with it. Also the question arises, does Macports, as a group, want to persevere with Macports_Framework? Apparently Pallet is its only dependent and I would not say that either of the two ports is up to the standard of quality we expect from Macports and the port command, not to mention the hundreds of other ports in Macports. Maybe it is a question of fix or forget Macports_Framework. All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
