Re: How to keep uncommitted work in a git clone
On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt wrote: > > Well, I tried that. I git stashed, then made changes to curl and committed > them, and later when I tried to git stash pop, my other changes that I had in > my git clone were not restored. I have no idea where they are now. Can you try `git stash list`? That should list everything that you've stashed. If that doesn't list anything, what commands did you run exactly? There's also another paradigm to adopt which avoids stashing entirely. Just always work in a branch and feel free to commit even if you're in the middle of something. In your case, you're working on something (let's say it's wget), but curl needs to be fixed too. Commit your incomplete changes on the "wget-update" branch, `git checkout -b curl-update master` to create and checkout a curl branch, complete your work there, and then switch back to the "wget-update" branch. Alternatively, stash your wget work and pop it after finishing with curl rather than committing incomplete work. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Pull Requests for Work in Progress (WIP)
>>> The main question of procedure is: Should the main macports repo be >>> used for proposing review of work in progress via pull requests? If >>> not, what is the proposed method? >> >> I propose you put your changes on a branch, add the compare URL to a >> ticket or send an email to macports-dev. >> > The downside (as I see it) of using the compare URL, as opposed to a full > pull request, is that line by line comments are not available. I started out on the side of just keeping the pull request for a completed work. But, it occurs to me that one of the goals of moving to GitHub is greater collaboration and that is facilitated by inline comments on the pull request. Plus, a completed pull request is one comment away from a work in progress anyway. The other side that I see is that this furthers the existing separation where pull requests (and now work-in-progress discussions) are on GitHub and ticket discussions are on Trac. Given that pull requests are already on GitHub, I don't think this is a significant issue. The alternative to WiP pull requests is posting multiple comparison URLs to reference different lines of code that must be opened in different windows. Plus, those references will break as soon as any changes are made to the branch. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] WorkingWithGit modified
On Fri, Sep 23, 2016 at 4:02 PM, Ryan Schmidt wrote: > Building untrusted pull requests is however an entirely different matter Hah, excellent point. Though now it strikes me what the current situation is... Hold on, I have to go burn my computers. ;-) -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] WorkingWithGit modified
On Fri, Sep 23, 2016 at 3:14 PM, Ryan Schmidt wrote: > Seems best to always create a branch before beginning any work, in case you > find out later you have more work you want to submit. I use git at work and our workflow is to create a new branch for every issue, even if it's as small as a single character typo in a documentation file. git clones are really inexpensive so I think the advantage really shows itself for smaller changes where you can quickly open multiple pull requests. We also require that all tests pass before any pull is merged to master with the goal that master is never broken. I'm not sure if there's any way to integrate the status from the buildbot with Github pull requests. Or if there's an easy way to have the buildbot build from external branches. It would certainly be nifty if the status of each buildbot could be listed next to the pull request for base and ports. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Swift source now available on GitHub
>From the Readme.md: > You can also use a third-party packaging tool like Homebrew to install CMake > and Ninja on OS X: > > brew install cmake ninja Ouch. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New Mac OS Forge administrator
Congratulations. That's great news for everyone! On Thu, Nov 19, 2015 at 9:49 PM, Ryan Schmidt wrote: > Dear MacPorts users and developers, > > I'm pleased finally to be able to tell you that I have been hired to be your > new Mac OS Forge administrator. I have been involved in improving MacPorts > for years as a committer and as a manager, and now as a Mac OS Forge > administrator I will work on ensuring our infrastructure runs smoothly too. > > I apologize for the downtime we've experienced in the past months. My > priority right now is to resolve the existing issues, as I become familiar > with the systems. > > Please continue to report new problems with MacPorts infrastructure (server > not working) as you have before, using the server/hosting component in Trac > or via email to admin at macosforge dot org. And continue to report MacPorts > administrative issues (mailing list issues, commit access requests) to > portmgr at macports dot org. > > Thanks for your patience and support and thank you for using MacPorts. > > -Ryan > > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Owner of MacPorts account on GitHub
On Fri, Nov 13, 2015 at 12:31 PM, Rainer Müller wrote: > > Maybe it would be enough to search in the subject instead, but for some ports > with generic names this would return many unrelated results. It's less than ideal, but a convention of something like port_portname would work for narrowing down searches. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: outage notice?
On Mon, Aug 31, 2015 at 1:56 PM, Ryan Schmidt wrote: > Still, there's not much difference to the user between the server doesn't > respond (what we currently have) and a temporary server delivering a message > stating that the server is temporarily out of service. The latter might even > have negative consequences, like affecting search engine contents or page > rankings. I disagree there. A message, even if it's just on the main MacPorts site, at least lets users know that you're aware of the issue and are working on it, without requiring each interested party to contact one of the mailing lists. The lists certainly aren't drowning in traffic, but a banner on the main page is going to reach a wider audience. Anyway, here's to hoping for better lines of communication with the admin. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
outage notice?
There have been several messages to the MacPorts lists regarding the trac outage. It might be a good idea to post an outage notice acknowledging this issue. Maybe even change all trac links to point to this notice? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: size of distfile mirror?
Thanks, That is a lot of bits. On Wed, Aug 19, 2015 at 9:37 PM, Mihai Moldovan wrote: > On 20.08.2015 03:31 AM, Arno Hautala wrote: >> Thanks, I've sent a question to a couple of them and I'll post back >> any responses I get. >> >> I'm not quite sure how I missed seeing the admin email address column. > > Current utilization on my mirror for the different submodules: > > 258Gdistfiles > 469Gpackages > 535Mrelease > 18M trunk > > > > Mihai > > > > -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: size of distfile mirror?
Thanks, I've sent a question to a couple of them and I'll post back any responses I get. I'm not quite sure how I missed seeing the admin email address column. On Wed, Aug 19, 2015 at 5:27 PM, Ryan Schmidt wrote: > > On Aug 19, 2015, at 3:07 PM, Arno Hautala wrote: > >> What's the current size of a distfile mirror? I haven't seen any >> statistics on any of the listed mirrors[1]. >> >> Thanks. >> >> [1]: https://trac.macports.org/wiki/Mirrors > > I'm not sure that anybody here knows. You may want to try asking the > administrator of any of the servers listed on that page. > > -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
size of distfile mirror?
What's the current size of a distfile mirror? I haven't seen any statistics on any of the listed mirrors[1]. Thanks. [1]: https://trac.macports.org/wiki/Mirrors -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: El Capitan Buildbot
On Mon, Aug 17, 2015 at 5:03 AM, Mojca Miklavec wrote: > I don't want to be pessimistic, but I will be enormously happy if > we'll get the buildbot up and running at all. > Given how long the 10.6 and 10.7 buildbots have been broken ... > > And yes, it would make a lot of sense to start the process now if > there is anyone at Apple who is willing and able to look into it. Given the time it's taken in the past to get a build slave set up and the difficulty with fixing errors when is it worthwhile to start looking at setting up a slave that's under closer control? This could run the gamut from a hosted VM to a spare machine that someone is willing to keep in a closet. I already archive all my packages on a home NAS and, if everyone was trusted on the Internet, MacPorts could just accept package uploads from anyone to be shared to all. Conceptually, there's no real difference with any of the committers (maybe just the management team or elder council) being able to share packages and someone from the team being able to configure the official build slave. I suppose I'd be personally happy just running a VM slave on my NAS. Though that doesn't contribute anything to anyone else and not everyone has the means to host their own buildbot. Are the buildbots just using MPAB? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Trace mode (was Re: port upgrade outdated order)
On Wed, Mar 4, 2015 at 6:52 AM, Chris Jones wrote: > > trace mode, which blocks access to files a port should not be using (because > they have not declared a dependency) is a great tool at providing this > reproducibility. I do not see any use case for an individual port being able > to by itself opt in or out of this feature, it should be completely up to > the user running port to decide, either via a command line switch, or via > macports.conf. I would not be in favour of ports being able to forcibly opt > out, as the only reason for doing so in my opinion is because they have bugs > that should instead be fixed. I remember discussions about enabling trace mode by default and concerns that it included a performance hit. I also seem to remember discussion about this penalty being reduced recently. Is there any reason that trace mode shouldn't be enabled by default? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Order of activation/deactivation pre/post phases
On Wed, Feb 25, 2015 at 8:54 AM, Artur Szostak wrote: > > Why does a pre-activate phase happen before a deactivation phase when > upgrading from an older port revision to a newer one? My assumption is that deactivating v1 is a requirement (dependency / prerequisite) of activating v2, so it occurs before that step. Your proposed order would make deactivating v1 a prerequisite of the pre-activate phase of v2. This is the sort of thing where I can see arguments for both behaviors, but in the end it's going to be a wash. Is there a specific goal you're trying to achieve that can't be solved by conforming to how things are done now? Can you explicitly call deactivate from pre-activate? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: memberlist
On Tue, Feb 10, 2015 at 4:33 PM, Ryan Schmidt wrote: > I'm pretty sure it's a feature of Gmail that deduplicates your mail. I do not > use Gmail and I do get duplicate copies of mailing list messages that are > also Cc'd to me. As sent by Lawrence: > http://www.list.org/mailman-member/node21.html >> Mailman can be set to check and see if you are in the To: or CC: lines of >> the message. If your address appears there, then Mailman can be told not to >> deliver another copy to you. If you're on BCC, Mailman wouldn't be able to do anything about it. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: memberlist
On Tue, Feb 10, 2015 at 11:22 AM, René J.V. wrote: > On Tuesday February 10 2015 10:49:40 Arno Hautala wrote: > >>list. There's no way to ensure they *won't* get a message. > > Not by sending to the list, no. But there's always the option of sending to a > hand-picked selection of list members, if there's a reason to limit the > audience. Also something that doesn't require having a public members list. > X-No-Archive: True ;) An easily ignored request :-) > I said interesting, not useful! Knowing that someone is from 12 timezones > away can be useful in certain cases though, for the rest , well, it's part of > the stats that could somehow be useful to project maintainers. I'm not sure what subscriber information would be of interest to project maintainers. It seems like that is better handled by the mpstats stuff. For me at least, I can't see any benefit to having an obfuscated list. Having a clear list seems creepy. Anything would need to be opt-in regardless, further decreasing any benefit. I feel like there are better alternatives (forums) that already support member lists from the beginning. > In fact, I'd be very much in favour of that. Between that and a ML, I much > prefer to have a browser window that shows me "new posts since last visit" > and emails that alert me (and show the content of) new messages in a thread I > participate in. > It typically also allows post authors to edit their prose, should a need for > that arise. I don't know if it's been discussed before, but a MacPorts forum would seem like a valid topic to be spun off from this point. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: memberlist
On Tue, Feb 10, 2015 at 10:23 AM, René J.V. wrote: > > I realised later that I should have evoked "knowledge of how many copies a > given person would get". There are valid situations in which you'd like (or > should) know if someone is on the list and would thus get a non-zero number > of copies ;) I'm not sure I understand this. You either want to be sure someone gets a message and add them to the TO/CC list, or you just send to the list. There's no way to ensure they *won't* get a message. >>get a duplicate. You and the list are in the To and CC fields with >>this message. Did you get it twice? > > No, not that I can see (= unless gmail hid an additional copy somewhere, but > it could also be that gmail consolidated the copies). I'm pretty sure it's the list software that sees that an address is already on the list and doesn't send an additional copy to them. >>It's only a mail list, but it feels weird to make that publicly >>visible. (visible only to members is essentially the same thing) > > I don't see how, esp. if you put the entries through a filter that makes them > useless to people who don't already know the full address. Censoring the addresses has problems. If you obscure the server portion it can be fairly easy to guess that rjvbertin@g... might be gmail. And r...@gmail.com isn't helpful either. I think Trac takes the latter approach, at least for non-logged in users. I keep having to remind myself that I'm just talking about an email list, that I post to, and is archived publicly. If this were to be implemented (I'm sure it's not available in the stock software) it would have to be opt-in. And at least for the proposed purpose, doesn't that defeat the goal? > And then there's additional potentially interesting info that could be > recorded alongside: join date, location (if shared and as precise as the user > allows), etc. I have no idea if the ML software allows this, but from the > few forums on which I am or was moderator I know it's "nice" to have such > information. I'd go so far as to say that it increases the sense of community. It's this "interesting info" that I find creepy. The only scenarios that I can think of where it's useful are to advertisers. I don't see how knowing how long I've been subscribed increases any sort of community. Maybe I'm just getting more cynical and codgerly. It'd probably be easier to just set up a MacPorts forum / subreddit and deal with the additional complexity of another destination for help and support. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: memberlist
Just CC them. Most mail clients / list servers will consolidate the duplicate message and even if it doesn't it's not the worst thing to get a duplicate. You and the list are in the To and CC fields with this message. Did you get it twice? It's only a mail list, but it feels weird to make that publicly visible. (visible only to members is essentially the same thing) On Tue, Feb 10, 2015 at 8:01 AM, René J.V. wrote: > Hello, > > Would it be possible to give members of the list access to the memberlist, > possibly "mangled" in a way that addresses appear like > > rjvbertin@g > > or something similarly useful when you already know a person's address and > just want to verify if s/he is subscribed and thus doesn't need to be CCed? > > When I tried to access the list recently I kept getting an authentication > error that I suppose means that I simply don't have access (took me a while > to realise that, esp. since I rarely use the credentials :)) > > R. > > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Yosemite binaries
Wouldn't testing and an announcement be a bit overdue? Aren't they already available to be downloaded and installed? At least, I'm pretty sure I've seen some packages being pulled down instead of being built. I mean, testing probably isn't a bad idea, but if there are specific issues that need to be tested, shouldn't they have already been handled before being served as packages? On Thu, Dec 18, 2014 at 1:43 AM, René J.V. wrote: > On Wednesday December 17 2014 19:38:01 Ryan Schmidt wrote: > >>If so, should we announce the availability of Yosemite binaries? Looking >>through the news entries on our web site, we previously announced the >>availability of Lion and Mountain Lion binaries, but not Snow Leopard or >>Mavericks binaries. > > Maybe do some testing of the generated packages first, preferably with port > for which issues with 10.10 have been reported? > > R. > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Yosemite Build Slave
Cool, thanks for the update. On Sat, Oct 18, 2014 at 1:18 PM, Joshua Root wrote: > On 2014-10-19 02:49 , Ryan Schmidt wrote: >> >> On Oct 18, 2014, at 8:20 AM, Arno Hautala wrote: >> >>> I know Yosemite is officially only a couple days old, but I was >>> wondering if a new build slave is on the schedule. I think I recall >>> hearing that they're all VMs now so setting up new versions should be >>> "easier". >> >> We requested it at the beginning of the month but have not heard back yet. > > Shree mentioned to me that he was waiting on some internal IT stuff. > > - Josh -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Yosemite Build Slave
I know Yosemite is officially only a couple days old, but I was wondering if a new build slave is on the schedule. I think I recall hearing that they're all VMs now so setting up new versions should be "easier". Thanks, --Arno -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Usage of the term MacPorts (was: Topological sorting of perl modules)
On Wed, Aug 13, 2014 at 12:20 PM, Lawrence Velázquez wrote: > > a Subversion of Portfiles That one nicely abstracts to VCS in general too. A Subversion of Commits Though it'd be annoying to change if the project ever switches to another... A Git of Commits? A Fool of Gits? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Usage of the term MacPorts (was: Topological sorting of perl modules)
On Wed, Aug 13, 2014 at 6:45 AM, Joshua Root wrote:
>
> If we were talking about portmgr then I would agree. But I don't think
> MacPorts is a collective noun, it's a proper noun denoting a single
> project. That the name has a plural form probably confuses the issue
> further.
>
> If we referred to the ports themselves as MacPorts then it might be
> different ("MacPorts are easy to write"), but almost nobody does that.
These seem to make sense to me:
> Portmgr are the people that direct the MacPorts project.
> MacPorts is a software package management tool.
> Portfiles are the files that describe how a package will be built and
> installed.
> A single Portfile is generally easy to write.
I think the more important question is what the "venery" term is for portfiles.
"A MacPorts of Portfiles" doesn't sound that great.
A TCL of Portfiles?
--
arno s hautala/-| a...@alum.wpi.edu
pgp b2c9d448
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainers census
On Tue, Jul 22, 2014 at 1:33 PM, Frank Schima wrote: > > Any thoughts or suggestions? It might be usefull to include the list of ports that the maintainer is listed on. Or at least implore the receiver to check on their end. Bonus points for including the commands they need to run. Of course, this would require additional features in your script and many more messages (though automated). > One issue is should I use To: or Bcc: for the list? "To" because the data isn't exactly private (anyone could put together a similar script on their own) "BCC" because you know someone is going to start a "Reply All; Please take me off this mailing list" fire. Plus, you're conducting a census, not a discussion. If you end up sending a message containing only the relevant ports to each maintainer you'll avoid the "Reply All" issue as well. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: What would YOU like to see 'port doctor' do?
On Tue, Jul 22, 2014 at 2:28 AM, Joshua Root wrote:
> On 2014-7-22 10:08 , Adam Dershowitz wrote:
>>
>> Checking for files that should not be in macports directory, that end up
>> being there. They could be left either by an old install, or by a different
>> installer that inappropriately put them in the directory (there was some
>> recent discussion of an installer for an application that was built using
>> macports then shipped with an installer so the installer would just put
>> stuff there). Perhaps this could be done by looking at all the files in
>> /opt/local and comparing with all the port contents? Any extras are an
>> error.
>
> Unfortunately this is not quite that easy, as there will be various
> config files, data files, cache files and so on that are not registered
> to a port. Probably restricting it to mach-o files would avoid false
> positives, but would unavoidably introduce false negatives. We simply
> don't have the information needed to do what you'd really want here.
Even given the false positives, I still think this would be a valuable
tool. For one it could be used to make an additional list of files
that are installed / used by a port. A future enhancement could track
optional files. In other words you'd have the current list of files
installed by a port ("contents"), but also a list of files that are
associated with a port, but not initially installed (cache files, user
config, etc.).
I recently had a case where a kernel panic occurred while upgrading
ports [1]. Upon reboot, my registry was damaged. I restored the
database from a backup, but now I had several ports that were
installed, but not listed in the registry. I was able to force install
the newer versions and everything looks good.
A tool that listed all the unknown files would have helped identify
the ports that had been upgraded, but weren't in the registry.
Repeating the upgrades worked too, but it would have been nice to be
able to investigate first, without needing to write my own script
(which I did anyway).
[1]:
https://www.mail-archive.com/macports-users@lists.macosforge.org/msg34966.html
--
arno s hautala/-| a...@alum.wpi.edu
pgp b2c9d448
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Call for Testers: MacPorts Statistics
Now that 2.3 is out, is trunk still a requirement for mpstats? I tried installing the package from the original message, but I see that it's installing mpstats 0.1.3, which is outdated. Is there a 0.1.4 package? I can put the files in a local tree if I need to, but I figured I'd check on the package first. What needs to happen before mpstats is added to the main tree? On Sun, May 11, 2014 at 5:44 PM, Clemens Lang wrote: > Hi, > >> I am here on Mavericks running port 2.3.0-RC1. >> Shall I file a ticket for that? > > It seems your tcl8.5 directory isn't readable by your user. Which user did > you use > to install it? Which umask was set while you installed it? What are the > permissions > of /opt/local/libexec/macports/lib/tcl8.5? > > I'm fairly confident the Tcl Makefiles get this right by installing using > install -m$explicitMode > but let's make sure that's really the case. > > -- > Clemens Lang > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
On Mon, Apr 7, 2014 at 12:58 PM, Peter Danecek wrote: > > Thanks for this hint. This is not yet documented in the man page, right? Or I > just missed it? > ~petr Yeah, I don't think it's documented anywhere. Maybe the man page? I found out about it myself by asking on one of the mail lists a few years back. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: binary install details ...
On Mon, Apr 7, 2014 at 12:03 PM, Peter Danecek wrote: > > 2. Is there a way to "fetch" available binary packages, without installing > the right away? There is the possibility do fetch all sources relevant for > some port. Sometimes I would like to do something very similar with binary > packages to install later when offline or on a pure internet connection. Is > there a way to do this? The command for this is "archivefetch". As in "port archivefetch ". I'd think you'd also be able to run something like: "port archivefetch depof:", though I haven't tested that last one. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New MacPorts web site
On Mon, Apr 7, 2014 at 11:01 AM, Ryan Schmidt wrote: > > Dear fellow MacPorts developers and enthusiasts, > > I’ve been working on a new MacPorts web site for some time, and I would like > to share with you my work so far: I really like the direction you've got so far. I've only been able to look on my phone so far, so I only have two real critical statements. (I'll check out the desktop version later today) 1) I'd like a like to see the non-mobile version 2) the font used for the "macports" header seems ... in the wrong direction. I don't think it needs to be Helvetica Neue Ultra Light. But something a bit lighter and less "futuristic", might fit better with the rest of the theming. > Further work to be done, in no particular order and not necessarily before > the first release: > * Port pages: I'd love to see some of the statistics linked in to the port pages. Maybe something as simple as the percentage and count of users that have the port installed. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Restarting Perl Arguments. :-P
I'm guessing it will be here: https://github.com/markemer/Macports On Sun, Feb 9, 2014 at 5:27 PM, Eric Gallager wrote: > Do you have a link to your fork on Github? I would like to "star" it. > > > > On Sun, Feb 9, 2014 at 2:52 PM, Mark Anderson wrote: >> >> So I've started messing around with getting a Proof of Concept CPAN->MP >> link working, so we don't need to have to have 8 billion perl ports. This >> was an idea on a thread long ago. I'll be keeping a github branch in my fork >> as soon as I get something that resembles something that isn't "how in the >> hell does this work" jibberish. >> >> Anyone who's interested, give me a holler, and I'll keep you in the loop. >> >> —Mark >> ___ >> Mark E. Anderson >> >> ___ >> 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 > -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
rdfind update to 1.3.4 - commit needed
Can someone look at #40985 and commit the patch? Thanks. --Arno -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: introducing Trac_Assigner: a script to automatically assign tickets to their port maintainer
On Tue, Oct 1, 2013 at 4:25 PM, Joshua Root wrote: > > I wonder if the license will be a problem. Apple apparently has a policy > against shipping GPLv3 code in their products, but I don't know if the > same applies for something hosted on macosforge. I think the problem with GPLv3 is that there is a restriction in the license that effectively prohibits inclusion of code with products that are not fully licensed in a GPLv3 compatible way. I wouldn't think there's anything conflicting there with using a GPLv3 plugin as part of a Trac server. If there is, I presume that Eric could just dual license or grant an exception. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Friendly talk
On Tue, Sep 3, 2013 at 12:27 PM, Rainer Müller wrote: > > I am opposed to moving to a whole new hosting provider due to the > technical implications on the infrastructure. Our database of issues in > Trac is quite large and I don't think it could easily be transferred to > Github or anywhere else. Just an aside that it looks like there are a number of ways of converting Trac issues to GitHub. http://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts buildmaster down
On Tue, Dec 4, 2012 at 1:02 PM, Joshua Root wrote: > On 2012-12-5 03:39 , Arno Hautala wrote: >> >> Is there anything holding back a "build all"? > > It's already done one, that's the upload that failed because of not > enough disk space mentioned earlier in the thread. Is there something holding back the binaries then? I see a lot of ports that are missing packages for darwin_12 (gawk, gsed, bash), so I assumed they hadn't been built yet. Though I also see several that don't have darwin_11 either (gnupg). Or did the failure occur fairly early in the run? In which case, I nominate another "build all". Or am I misunderstanding something about the packages. I know some aren't distributable, but I think I've been looking at ports that should be. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts buildmaster down
On Tue, Dec 4, 2012 at 11:17 AM, Jeremy Lavergne wrote: > > It's definitely capable of doing "build all". Is there anything holding back a "build all"? It'd be nice to get the rest of the packages available for ML. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts and sandboxing
What about other options like chroot? Would it be possible to build within a chrooted environment? Maybe that would be too heavy in having to copy all dependencies to the chroot. Maybe switch the macports prefix to /opt/local/chroot, move everything in there (building, installing, etc), and then create links in the /opt/local prefix upon activaton. Or something like FreeBSD's jails where the /opt/local prefix could be mounted within the jail. Or would that break libraries? I could imagine all sorts of problems with absolute paths. Though maybe that could be solved by having the system /opt/local mounted at the jail's /opt/local. On Thu, Sep 27, 2012 at 2:31 PM, Jordan K. Hubbard wrote: > Yeah, and, after talking to the sandbox gurus at Apple last night it's > pretty clear that sandboxing is fairly monomaniacal in its focus: It just > wants to deny things. It doesn't want to hide, redirect or otherwise > interpose filesystem / other operations, and given all of the complexities > inherent in the other approaches, that makes sense. Rats. It would have > been so much simpler if we could have figured out how to piggy-back on > sandboxing. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration handling
On Thu, Sep 13, 2012 at 1:04 PM, Jeremy Lavergne wrote: > > Hmm, well that all depends if system things changed out from under MacPorts. > For example, if libcurl breaks: > > Since it can (and has) happened in the past, it's better to just always > install a fresh version of the MacPorts files. Ah, gotcha. Yeah, that's unfortunate. So, I don't have time to write patches, when will this be implemented? ;-) Should I file a feature request referencing this discussion? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration handling
On Thu, Sep 13, 2012 at 12:53 PM, Jeremy Lavergne wrote: > > Now that we're adding build-time conflicts, we might also be able to address > opportunistic linking at build time (an old package is still active while > rebuilding another). Until that's hammered out though (it's not even released > yet) we need to have people uninstall everything prior to reinstalling. No, I get that all ports need to be uninstalled, cleaned, and reintalled. I'm talking about reinstalling MacPorts itself. Is it necessary to reinstall the MacPorts base software after an OS upgrade? I didn't think this was necessary, but the Migration guide says that it is. If this isn't so, the guide should be updated, but it also simplifies automated migration. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration handling
On Thu, Sep 13, 2012 at 11:24 AM, Jeremy Lavergne wrote: > > I think we suggest uninstall rather than deactivate, so that removes > everything from sqlite db; it won't know about those ports' requested status > any longer. However, we could make a temporary table that lists the > requested-after-migration ports to reinstall. Yeah, a temp table sounds good. What about the reinstall MacPorts part? I could have sworn that 'selfupdate' was good enough; that the installers were system OS-dependent, but running 'selfupdate' got you to an OS-apathetic installation. But, the migration instructions state reinstalling is necessary. Is that still the case? If so, the migration phase would need to write out the table and then instruct the user to reinstall. It culd then pick up from that temp table on first run. Or as part of the installer, though rebuilding a bunch of ports would be lengthy for an installer. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration handling
On Thu, Sep 13, 2012 at 11:15 AM, Jeremy Lavergne wrote: > > It could be nice to have ryan's script in there, however we don't necessarily > know where the output file will get stashed. That'd be a bit more tricky, I > think. And of course, convincing novices on piping or specifying the file > input so they can be reinstalled... it's best to leave that on the site I > think, unless we can make it a pretty rigid environment so the file is always > stored at a set location. Absolutely, I wouldn't want this to involve piping at all. Couldn't it just be stored within the MacPorts prefix? If it needs to be written out at all that is; if 'selfupdate' is enough to carry an installation across an OS upgrade (I could have sworn this was enough), couldn't that data just be held in memory? Or referenced from the existing databases? Things could even be further restricted to only supporting an /opt/local prefix if that makes things easier if a file is required. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: migration handling
On Thu, Sep 13, 2012 at 11:08 AM, Jeremy Lavergne wrote: >> Thoughts? What's already available for this? What is needed? What >> isn't possible? > > We probably just need to store the version of the OS/Xcode in the sqlite db. > If something doesn't match, we should (could) refuse to run and print out > messages like you suggest. That sounds like quite a bit less work than I anticipated. I also note that there's a script that can perform some of the reinstall work. Is there any reason that this couldn't be (hasn't already been) incorporated into port? It could be enhanced to include requested and active state of ports as well. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
migration handling
One of the issues that I see time after time is problems due to users having not followed the Migration instructions. I think it'd be beneficial if MacPorts included code to detect a major OS change and could then aid the user in completing the migration. Migration consists of: Reinstall Xcode (and all associated command line utilities, accept license, etc.) Reinstall MacPorts (Is this necessary? Or only if you've performed a clean install? I thought 'selfupdate' was enough?) Make note of installed ports. Uninstall all ports. Clean all. Install all previously installed ports. So, the notation of installed ports, uninstall, clean, reinstall process sounds easily scriptable. This could even include an option to only reinstall the "requested" ports to save a bit of time, though unless the user's system was very old and didn't have the requested status populated this isn't likely to be different than installing everything. Of most benefit would be automatically restoring the requested status. Reinstalling Xcode can't be automated, but the required steps could be displayed for the user to follow. I know there has been discussion about determining which version is installed and how the latest Xcode versions make that a bit harder, but detecting the different steps would be beneficial (Xcode, command line tools, license). The same goes for reinstalling MacPorts (if that's actually necessary instead of 'selfupdate'). MacPorts could print the required steps and URLs and write out a status file so the next invocation after reinstall MacPorts (or even the installer) could pick up reinstalling the ports. Of course, detecting a major OS change should be easily detectable and would start off this whole process; either by prompting the user that MacPorts cannot continue without running 'port migrate-OS' or maybe even just running the migration if Xcode is already satisfied (and if 'selfupdate' is enough for the MacPorts upgrade). Thoughts? What's already available for this? What is needed? What isn't possible? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: archive_site_local [was: MacPorts 2.1.0 has been released]
On 5/15/12, C D wrote:
>
> Then there might be a bug: following the procedure in
> https://trac.macports.org/wiki/howto/ShareArchives2, I have set up a local
> archive repository, which I access through the URL http://localhost:6227/ .
> When this URL is put into ${prefix}/etc/archive_sites.conf, the port number
> 6227 gets replaced with the port name in the fetch command. E.g.: "port -v
> upgrade openssl" leads to
>
> "---> Attempting to fetch
> openssl-1.0.1c_0+universal.darwin_10.i386-x86_64.tbz2 from
> http://localhostopenssl/openssl";
>
> instead of "[...] from http://localhost:6227/openssl";.
This does, at least initially, sound like a bug, unless there's a new
way to specify the port number.
I haven't upgraded yet, but I should have time later today; when I'll
investigate further. In the mean time, you should be able to serve the
portfiles on port 80 and drop the port number in
archive_site_local.conf
If there isn't a proper way to specify the port number, this should be
reported as a bug ( trac.macports.org ).
--
arno s hautala/-| a...@alum.wpi.edu
pgp b2c9d448
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: first experiences with rev-upgrade
On Sun, Apr 8, 2012 at 07:57, Clemens Lang wrote: > On Sun, Apr 08, 2012 at 03:28:47AM -0500, Ryan Schmidt wrote: > >> It's unclear what I'm meant to do with the warnings about files not >> existing. > > Those are the reasons rev-upgrade will attempt to rebuild ports. We > could omit them from the output, but that would look a bit like magic > happening when determining which ports to rebuild. That being said, > Gentoo's revdep-rebuild doesn't print those as far as I know. I think for must users, it's enough to be awed by the magic and save the "warnings" for verbose output. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Ignore MisbehavingServers rather than fail with an error
On Sun, Apr 8, 2012 at 07:42, Ryan Schmidt wrote: > > Let's discuss it now. (Or, tomorrow; I need to sleep.) I want this change in > MacPorts 2.1.0. Please help me understand what your objections are. > > [...] > > and raised a second concern about proxy servers, which I did not understand If I may interject. I think the proxy issue is if there is an error on the user's end (misconfigured proxy, unacknowledged hotel wireless terms, etc.) this change could lead to port downloading from multiple sources and reporting that each is misbehaving. The correct fix in this case is on the user. Downloading multiple times is a waste, but shouldn't be too heavy. It's not like this would download the full distfile and the HTML error page every time. You could always cache the checksum for the previous fetch and then report to the user that it may be a misbehaving server / bad proxy if subsequent fetches match. Though I can see how a bad proxy wouldn't necessarily deliver the exact same payload every time. In my opinion, grabbing an error page from every mirror server before reporting a misbehaving server isn't an unacceptable option. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: sha1 and rmd160
On 2012-04-06, Joshua Root wrote: > On 2012-4-6 23:33 , Arno Hautala wrote: >> Is there an effort to remove the deprecated algorithms? Or a date / >> version for support to be removed? Just curious. > > Only md5 is really deprecated, and then only when used by itself. There > should probably be a lint warning for that. Gotcha. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: sha1 and rmd160
> On 2012-4-6 23:07 , Arno Hautala wrote: > > I don't think MacPorts actually verifies every hash that is provided > in the Portfile. On 2012-04-06, Joshua Root wrote: > > It does. On 2012-04-06, Clemens Lang wrote: > > It does verify every checksum the Portfile provides. On 2012-04-06, Jeremy Lavergne wrote: > > MacPorts checks all listed hashes. OK, OK, I get it, I'm sorry, please stop the beatings! ;-) Today I learned; thanks. On 2012-04-06, Clemens Lang wrote: > > We're documenting two hash algorithms that are "blessed". All others are > deprecated. Is there an effort to remove the deprecated algorithms? Or a date / version for support to be removed? Just curious. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: sha1 and rmd160
On 2012-04-06, Craig Treleaven wrote: > > Just curious, why two checkums? Is one not sufficient? One thought would be that while one hash algorithm may exhibit a flaw that allows arbitrary changes to the payload without altering the hash, it's extremely unlikely that two hashes would be affected in the same way. I don't think MacPorts actually verifies every hash that is provided in the Portfile. I think the actual reason is to provide a backup hash if the first algorithm isn't available. Though, I'm pretty sure rmd160 and sha256 have been available in OS X for quite some time, via openssl, python, perl, etc. Hmm, apparently a year ago sha256 support was broken in MacPorts anyway, I'm not sure if that's been corrected. It'd certainly be simpler to document if only one hash algorithm was "blessed", with all others marked for removal by a certain date / version. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: sha1 and rmd160
On 2012-04-06, Blair Zajac wrote: > On 4/5/12 9:53 PM, Arno Hautala wrote: >> >> Also, I think md5 in Portfiles is deprecated. The preferred hashes are >> rmd160 and sha256. > > If upstream provides a md5, I like to use it, as it makes double checking > the > port easier. MacPorts is trying to phase out usage of md5 as it's considered cryptographically broken. In this case, it'd be fine for you to use the md5 to verify the checksum, but I still think the Portfile should contain rmd160 and/or sha256. I'm aware of the ... "oddity" (?) and extra effort of using different hashes at different stages, but I presume that at some point md5 support will be removed from MacPorts. You might as well start using the preferred hashes now, if only to get used to a workflow that will be required in the future. At least, that's my take on things. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: sha1 and rmd160
On Fri, Apr 6, 2012 at 00:15, M. Daniel Becque wrote: > I'm working on upgrading the port of Proftpd from 1.3.3c to 1.3.3g as a > first step. From the binary file repository i see where the md5 # comes > from but how do you get the sha1 and rmd160 numbers to place in the port > file? There is another file with each release, .asc, in the repository. sha1 and rmd160 can be generated with openssl: openssl sha1 path/to/file openssl rmd160 path/to/file The .asc file is a PGP signature that can be used to verify the integrity and authenticity of the source file. You don't need to worry about that for the Portfile. Also, I think md5 in Portfiles is deprecated. The preferred hashes are rmd160 and sha256. See: http://guide.macports.org/chunked/development.creating-portfile.html -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: handle only subports install files
On 2012-03-19, Joshua Root wrote: > > There is no "default". There are just a bunch of ports. You get > precisely the one you ask for. If you can't decide which one to declare > at the top level, roll dice or something. This seems then, like there shouldn't be a top-level port when subports are defined. In both cases (multiple versions of PHP, Python, Perl, etc. or a mechanism to group similar ports or those that share the same distfile) common sections are declared at the top-level and the differences are declared within the sub port sections. The top-level should then also be marked as not installable whenever a subport section is present and that top-level port name should not show up in the the index. This solves the issue of user confusion when asking to install "py-foo" and unknowingly also getting "py2x-foo". It also enforces the pattern of depending on py2x-foo instead of py-foo and therefore no warning messages, dummy README files, or behind the scenes dependencies are required. That said, the only advantage of this over picking any one of the grouped ports to be the top-level, is when the top-level port is dropped, but the sub ports are to remain. top: python (non-installable) sub: py24 sub: py25 sub: py26 vs. top: py24 sub: py25 sub: py26 When dropping support for py24, the first can just remove the subport. The second must replace the top-level information that from one of the subports, potentially requiring changes to the other subports as well. The current behavior of the top-level port essentially being a subport that hasn't explicitly been defined as such just seems a bit shifty to me. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Fading zmq20
On Wed, Feb 15, 2012 at 11:41, Jeremy Lavergne wrote: > > The "default" version that zmq would depend on could be a subport of the port > it depends on, no? That'll make it easier to just move a line or two from the > "default" portfile. True, I was avoiding getting too far into implementation; trying to stay at the hierarchy level. On Wed, Feb 15, 2012 at 11:59, Ryan Schmidt wrote: > > We shouldn't repeat the "perl5" antipattern any further. Perl should have > been using "port select" all along; I don't know why it never did. > > However, there is talk of offering only perl 5.14 and deleting the others, so > changes to the perl selection mechanism should perhaps wait until a decision > on that is reached. That's why I left it at "as with perl currently". I probably should have just left that option off entirely, given what's been discussed. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Fading zmq20
On Tue, Feb 14, 2012 at 18:21, Andrea D'Amore wrote: > > There's a pending upcoming 3.x zeromq with incompatible API, what will > 2.1.11 be called when 3 will become available, zmq21? It would probably be most appropriate to use zmq (2.x) and zmq3 (3.x). At least until most ports / projects are upgraded to work with the new API. At that point, it might make sense to move zmq to the 3.x branch and create zmq2. I'm suggesting this, however, without any familiarity with zmq. Other options are having zmq2 and zmq3 with a zmq port that is used to set the default, as with perl currently. Or using "port select" to set this. Or, maybe zmq2 and zmq3 can coexist without conflict or need to set a default. Then again, it may be best to just move zmq to 3.x and fix any ports / projects that aren't compatible. I think the biggest factor is how does the zmq project refer to the 3.x release. If it's seen as simply the next version, that happens to break compatibility, it 3.x should probably be zmq. If they're referring to it as an almost new project, possibly with continued development on 2.x, it should probably be zmq3. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: How to pick a license
On Tue, Feb 14, 2012 at 09:36, Jeremy Lavergne wrote: >> Is there a license among good_licenses that could fit [1]? If not the >> case should I add one? > > That is the MIT license they're using. > http://www.opensource.org/licenses/mit-license.php Good catch. It's wonderful how their web page identifies it as "Open Source", their GitHub page states "the same license as Lua 5.1", and their LuaForge page states MIT/X. Easy peasy. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: How to pick a license
On Tue, Feb 14, 2012 at 09:07, Andrea D'Amore wrote: > Is there a license among good_licenses that could fit [1]? If not the > case should I add one? > > [1] http://keplerproject.github.com/cgilua/license.html I think "permissive" is probably the best match. Here's a list of the current "known" licenses: https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Suggestion for new pseudo-portnames
On Thu, Feb 2, 2012 at 05:01, Rainer Müller wrote: > > Hello Howdy > Note there is already the port -u upgrade/uninstall option. However, I think > it would make sense to add this new redundant pseudo-port name. Ah, good point I always forget about that option. And, I agree that it still has a place in conveniently removing ports when -u hasn't been used. > This is a general problem for the handling of logical operators with > pseudo-ports. We always build large lists and then merge them. As we are > using a SQL-based registry, we could do more sophisticated queries for this > purpose. actinact would benefit from this as well, and probably plenty of others. Are there any complex queries that are currently in use? > I suggest the name missingdep: for this. I like that. But, maybe missingdepof (and missingrdepof?) to be consistent with rdepof. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Suggestion for new pseudo-portnames
The recent RFC for making an alias action for active and inactive reminded me of some queries that I frequently use when working with ports. Specifically, outdated ports that have been upgraded (redundant), and uninstalled dependencies (outstanding). redundant can currently be achieved with "actinact and inactive" For example: > port selfupdate > port echo outdated > port upgrade outdated > port uninstall actinact and inactive or rather > port uninstall redundant outstanding right now would be "rdepof: and not installed" For example: > port echo outstanding:gimp ...very long list ^C > forget this! One quandary for "outstanding" is whether the rdep search should be performed first, or should branches be pruned as soon as an installed port is discovered? Maybe separate that question into "outstanding" and "routstanding"? There may be better names of course. Is this worth submitting an issue to trac? Or, are these just redundant names for queries that are already possible? I'd like to start hacking on base myself, so I'll be looking at port.tcl, but I don't anticipate having anything to submit anytime soon, just in case anyone considers this such an amazing idea they can't wait to implement it ;-). -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: "None" license
On Mon, Jan 2, 2012 at 19:24, Joshua Root wrote: > > The author doesn't appear to understand how copyright works and/or what > a license is. He also states that symlinks has been around many years before the open source "fad", but the earliest release that I've been able to find (1.0) is from 1994. GPLv1 has been around since 1989. > If there is no license (and the work is not in the public > domain), we can't distribute the software at all. His direction to "Use > and distribute and modify as you (or anyone else) sees fit" is a (very > permissive) license. I'm a bit confused here. You seem to be saying that without a license an archive can't be distributed, but also that it's a Permissive license, which is identified as distributable. Or am I misinterpreting? I agree that the author isn't exactly answering the license question. In my reading, he seems to be all but explicitly releasing it as public domain. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: "None" license
On Mon, Jan 2, 2012 at 12:55, Jeremy Lavergne wrote: > > I'd just put in Permissive. On Mon, Jan 2, 2012 at 12:57, Rainer Müller wrote: > > I would recommend "Permissive" which indicates that the source code may > be modified and we can distribute binary archives of the port. Excellent, thanks. On Mon, Jan 2, 2012 at 12:57, Rainer Müller wrote: > > At the moment, the only documentation is the script itself: Great, I started looking through the source, but didn't think to look at that script. Thanks. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
"None" license
I'm putting together a Portfile for "symlinks" by Mark Lord. The source doesn't come with a license and the author has stated that it doesn't have one [1]. Is there such an identifier for the license field in a Portfile? For that matter, is there documentation on valid identifiers? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273338#17 -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Macports 2.0.3/Lion 10.7.2 Perl
On Thu, Nov 3, 2011 at 21:04, Ryan Schmidt wrote:
>
> As "man port" says,
What? You expect me to read the man page?
> "Available select groups are installed as subdirectories of
> ${prefix}/etc/select/."
Thanks, that's a helpful tip.
--
arno s hautala /-| a...@alum.wpi.edu
pgp b2c9d448
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Macports 2.0.3/Lion 10.7.2 Perl
On Wed, Nov 2, 2011 at 22:15, Ryan Schmidt wrote: > > Why don't we use "port select" to select the perl symlink? Why is perl unique > in having this perl5 port to do that job? I was planning to ask the same question, so I'll move this to the dev list. My assumption is that's it's a left over from before perl5 was revamped and no one has put in the effort to make it a group and make any other modifications to other port dependents. Also, I'm only aware of the python group, are there others? I would think that ruby would be a good candidate here as well. A way to pass '*', 'all', or 'groups' to 'port select --list' would be useful too. '*' and 'all' could print all groups and their versions, 'groups' could just print the available groups. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Lion Recovery Partition
On Mon, Oct 17, 2011 at 11:17, Jeremy Lavergne wrote: > > Well the people who could create that are the ones here on macports-dev. > :-) I'd say it's worth discussing, even if it's separate. Absolutely. > Make every portfile into a meta package, where each has a directory for > the old versions? That's how I imagined it. Well, a directory for each version, to account for patches, etc. >>> Does TimeMachine already crawl the MacPorts directories to provide this? >> >> Unless the user has exclude the MacPorts prefix it should be backed up. > > Ah, then for the time being perhaps we should point users to doing this if > they desperately want to revert to previously installed version that they > uninstalled? Hmm, but maybe not. I'm now thinking about $applications_dir > and what not that are outside of $prefix. Lots of forced activation will > suddenly be required. Yeah, it'd work (re: could work), but it'd be complicated. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Lion Recovery Partition
On Mon, Oct 17, 2011 at 10:53, Jeremy Lavergne wrote: >> Tie in for what reason? >> >> What's your higher goal with the recovery partition / TimeMachine. > > We've had a recent thread (I think on -users) about making the > installation of previous portfile versions easier. > > I was wondering if we had a simple way of providing Portfiles of > previously installed packages, without relying on deactivation to bring > them back. I realize allowing granular restores is impossible, but > reverting your entire MacPorts install back to how it was on day X would > be handy. This doesn't sound like the kind of thing that should be built in to MacPorts, but it does sound like a useful 3rd party tool. One way would be to include the Portfile in the binary archive (I think this was discussed as well; I'm not sure where it went). Then, the user could install an old port with: "port install /path/to/archive". Personally, I think the proper way to handle this is to implement version dependencies (may as well do variants as well and close the oldest open bug MacPorts has #126). Multiple, version-tagged portfiles could be kept for each port. Then again, there's a reason versions and variants aren't dependable like this, there's a lot of thought that needs to go into the design and implementation. > Does TimeMachine already crawl the MacPorts directories to provide this? Unless the user has exclude the MacPorts prefix it should be backed up. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Lion Recovery Partition
On Mon, Oct 17, 2011 at 10:42, Jeremy Lavergne wrote: > Does anyone know if MacPorts is permitted to put anything on the recovery > partition? It's not designed to do that. You _can_ mount the recovery partition and likely modify its contents, but there's limited space on that partition. > Or perhaps any way we can tie into TimeMachine? Tie in for what reason? What's your higher goal with the recovery partition / TimeMachine. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Archive fetch problem
On Thu, Oct 13, 2011 at 23:04, Joshua Root wrote: > > There hasn't been an announcement sent out about binaries yet, > so when there is, let's mention that users should check this setting. An announcement could also be printed by port if the user's configuration doesn't match what is expected for fetching binaries. Just ignoring the configuration settings for archivefetch would work, but would be quite unexpected for anyone who had knowingly changed the setting. Then again, this setting could always be removed. Is there a reason for offering this option to users? -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Synchronizing Two Macports Installations
On Thu, Sep 29, 2011 at 17:14, Francisco Garcia Rodriguez wrote: > Hi people > > I have two macs at home and I would like to offload some work to my mac mini. > One of the things I do not want to do is compiling twice in every machine. This is why I wrote up this how-to: https://trac.macports.org/wiki/howto/ShareArchives2 I also have been meaning to write one up with a LaunchD task for upgrading outdated ports every day / week / etc. It won't do everything for you, but if you're good about installing first on the Mini, it's about as close to a MacPorts sanctioned method as you'll find (in my opinion). -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Diffing compressed tarballs
On Mon, Sep 12, 2011 at 02:43, Ryan Schmidt wrote: > > However, after all that, tardiff does not appear to actually show me a diff > of what changed. It will just show me a list of the files that changed, and > optionally how many lines were added and removed to each. It *runs* "diff > -ru" to get that information, but doesn't appear to have an option to just > print that diff out, which is what I really want to see. Maybe we can add a > new "-d" flag to actually print the diffs. This is starting to look less like a Portfile patch, and more like a project fork. :-) -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: macports fetch suggestion
On Mon, Sep 12, 2011 at 02:40, Ryan Schmidt wrote: > > The useful idea suggested in the ticket is to fetch in a separate thread, > while MacPorts is building other already-fetched ports, and this would indeed > reduce the time it takes to build, but that would probably be difficult to > implement without rewriting a lot of how MacPorts base works since we don't > currently use threads. And even if I felt comfortable doing so, which I don't > because I'm not that familiar with MacPorts base code or C or threads > programming, I would be wary to do so, since it more or less works now, and I > don't want to break it. I'm not that familiar with base either, but I think one improvement would be finer grained locking. It seems right now that only one install or fetch command can be run at a time. But, it would seem to me that these could be independently locked. You don't want to build with multiple threads, but it should be fine to build one task, while another task fetches. One issue could be if a database is updated after the fetch which impacts a subsequent build task that has already read the database. There's still probably plenty of race conditions that would need to be examined, but finer grained locking might be an easier step towards the goal. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Diffing compressed tarballs
I've opened a ticket [1] which looks to solve things for tarballs without an enclosing parent. The port should also probably be updated to use gnutar. [1]: https://trac.macports.org/ticket/31205 -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Diffing compressed tarballs
On Fri, Sep 9, 2011 at 20:44, Ryan Schmidt wrote: > > I see there is another project called "tardiff", also from 2005, here: > > http://tardiff.sourceforge.net/ Right now it's required to create a new archive containing the difference between the two input. Not quite the desired goal. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Diffing compressed tarballs
On Fri, Sep 9, 2011 at 20:28, Ryan Schmidt wrote: > > The case is for .bz2, not .tbz2. Ah, so it is. Probably want to add '.tgz' as well. > gnutar does not produce an error, but I also still don't see a diff. Using gnutar works for me, though it fails if the tarball doesn't contain an enclosing directory. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Diffing compressed tarballs
On Fri, Sep 9, 2011 at 20:14, Ryan Schmidt wrote: > > It doesn't seem to recognize the .tbz2 extension we use; I'll try to patch it. It should, there's a case for it. I'm thinking it's probably an issue of BSD vs GNU. I'm installing gnutar right now to see if that fares any better. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: New HowTo: Sharing Archives
> https://trac.macports.org/wiki/howto/ShareArchives2 It's been a while now since I've had any edits to submit on this page. Just now I took another quick pass and if there aren't any further comments, I'd like to move it up from the incomplete section. Thanks to everyone that suggested improvements and corrections. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: A Plea to Reduce Dependences
On Tue, Sep 6, 2011 at 08:24, Anders F Björklund wrote: > > Fink only has one tree now (called "stable"), for lack of resources... Really? That's interesting. Without dragging this thread too far off track, did they just merge the trees? Or, just drop support for unstable? > But how many trees are available isn't limited with either system ? My understanding is that MacPorts doesn't have the concept of trees as much as it supports an arbitrary number and location of trees that are merged together. I think that Fink required switching between stable and unstable, I don't remember if or how one could include an arbitrary tree with the current selection. Meh, details. > Both MacPorts and Fink do use _some_ system resources, and Homebrew > does allow _some_ dupes, so it's a rather fuzzy difference all around. True, I was going more for the philisophical goals rather than the gritty details. > The main difference is that you can install the packages without > needing the rest of the build system and ports/formula sources, > there was some talk about such a feature for MacPorts as part of > the Google Summer of Code projects - but it didn't happen... Ah, true. That's still a good goal. > But you can (soon?) use it without Xcode, which is "good enough" ? Another (upcoming?) feature I didn't know about. I need to subscribe to the VCS feed or idle on IRC more. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: A Plea to Reduce Dependences
On Tue, Sep 6, 2011 at 03:29, Anders F Björklund wrote: > > Pity, though. There's nothing *that* special between > all the various package managers and their file formats > and their dependencies, except that they're "different" ? It's not so much that they're different, but that they track and manage what has been installed and can break if a resource is used that shouldn't be available (from the perspective of the package manager). There's also the philosophical differences: MacPorts and Fink install packages that are already available from the OS because the resource is then not subject to breakage when the OS changes; Fink uses stable and unstable trees; Homebrew uses system resources, installs to an "overloaded" prefix, and suggests that this location be made writeable by unauthenticated users. > Not that Macports or Homebrew manage packages, but anyway. How so? Aside from compiling the software on the client machine, they do everything else that comes to mind for the definition of a package manager. Many *nix package managers also allow compiling from source when a binary isn't available. And, MacPorts does offer some precompiled binary packages. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: clean only old distfiles?
On Tue, Aug 30, 2011 at 17:47, Daniel J. Luke wrote: > On Aug 30, 2011, at 4:35 PM, Ryan Schmidt wrote: >> >> I use this script: >> >> http://lists.macosforge.org/pipermail/macports-users/2010-June/020560.html >> >> Actually, an updated version of that script I should commit it to the >> repository or something. > > which does something similar, but not exactly what the poster wanted... I was just about to post the same thing. The linked script deletes distfiles that are more than a year old, incomplete files more than a day old, and empty directories. It has the potential to both miss deleting distfiles (multiple upgrades within the year) and delete relevant ones (ports without an update in over a year). > I think it would be useful for 'port' to be able to remove all non-current > distfiles for installed ports. As well as port signatures for uninstalled ports. :-) -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Active version error
On Sun, Aug 21, 2011 at 05:42, Frank J. R. Hanstick wrote: > Hello, > The following occurred during an upgrade: > > [snip] > > ---> Activating p5.12-scalar-list-utils @1.230.0_2 > Error: Target org.macports.deactivate returned: Active version of > p5-scalar-list-utils is not 1.230.0_1 but 1.23_1. > Log for p5-scalar-list-utils is at: > /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_p5-scalar-list-utils_1.23_1/p5-scalar-list-utils/main.log > Warning: Failed to execute portfile from registry for p5-scalar-list-utils > @1.23_1 > ---> Deactivating p5-scalar-list-utils @1.23_1 > ---> Cleaning p5.12-scalar-list-utils > > This was not a show stopper. A log is attached. It's a bug in the Perl 5 PortGroup. I'm looking at in now and have figured out where the issue occurs, but I'm not sure of the correct solution as I'm unfamiliar with _why_ the version string is being manipulated. It's being tracked at https://trac.macports.org/ticket/30833 -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Auto-variants
On Mon, Aug 8, 2011 at 03:44, Clemens Lang wrote: > On Sun, Aug 07, 2011 at 10:28:48PM -0400, Arno Hautala wrote: >> >> I think the GSOC project that would introduce "rev-upgrade" >> could be of use here. It could at least mark decencies after >> compilation has occurred. > > It currently does not do that, but will detect broken binaries and > rebuild the port (in this case without the auto-variant enabled). Yeah, I mispoke. I didn't think rev-upgrade _would_ detect missing dependencies, just that it _could_ be used to that end. On Mon, Aug 8, 2011 at 03:58, Rainer Müller wrote: > > Yes, the post-destroot-check is intended to find this kind of hidden > dependencies and report them. Introducing dependencies automatically > without manual interaction isn't really possible as it requires changes > to the Portfile which might be too complex for an automated task to > succeed. So this should be left to the maintainer. That's a better solution as these issues really should be corrected in the Portfile anyway. On Mon, Aug 8, 2011 at 04:21, Joshua Root wrote: > > There's also trace mode which will prevent non-dependencies from being used. Even better news. I do remember hearing about trace mode. And I think I recall that the goal is to always enable it? Sheesh, is it really Monday morning? -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Auto-variants
On Sun, Aug 7, 2011 at 20:03, Bradley Giesbrecht wrote: > > Blair: I thought you were meaning; IF +cpio is not specified AND port cpio is > an activate port; than add cpio to rpm52 ports DEFAULT variants. This brings to light the problem of "hidden dependencies" where the configuration notices that a library is available, compiles against that, but doesn't record a dependency. The dependent library could then be removed and lead to runtime problems. Either all optional libraries should always be disabled and dependencies marked only as they are enabled, or this auto-variant behavior could be adapted. I think the GSOC project that would introduce "rev-upgrade" could be of use here. It could at least mark decencies after compilation has occurred. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: New HowTo: Sharing Archives
On Wed, Aug 3, 2011 at 11:37, Bradley Giesbrecht wrote:
>
> You use "/opt/local" throughout the document except for a few cases where you
> use "${prefix}".
> For readability consider using "/opt/local" everywhere and add a blurb at the
> top "This document assumes the default MacPorts install prefix of /opt/local.
> If you use a non-default install prefix change all occurrences of /opt/local
> to your prefix."
Thanks and done.
--
arno s hautala /-| a...@alum.wpi.edu
pgp b2c9d448
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: New HowTo: Sharing Archives
On Wed, Aug 3, 2011 at 04:07, Ryan Schmidt wrote: > > You're talking about this: > > https://trac.macports.org/wiki/howto/ShareArchives2 I always forget the most important piece right? > Please pick a different suggested location for the keys that is not within > /usr/local. Good point. I'd considered using /opt/local, and had meant to ask about that, I wasn't sure if it was the right place. Would /opt/local/ be an acceptable prefix for the keys and config? What about the signing script? Thanks for taking a look. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
New HowTo: Sharing Archives
I've just published a new HowTo on the Wiki regarding signing and sharing archives under MacPorts 2. I'd appreciate a few eyes looking over it for accuracy and clarity. Specifically, anything that needs to, or could, be clarified or trimmed. It's a bit lengthy, but the majority of that are inline file contents. I think overall, it's pretty straightforward. But, please, tear it to pieces. Thanks and I hope it helps. --Arno -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: buildbot questions
On Tue, Aug 2, 2011 at 12:23, Marko Käning wrote: > > How many ports could you successfully build so far? I mean, are you stuck at > 10, 30, or only 80% of all ports? And how does the build proceed? Seeing as there are ports that conflict with each other, I imagine that a straight "port install all" would run into problems. Starting each port build without any other ports already installed would probably be a good (albeit more lengthy) test that would also catch missing dependencies. I'm sure there are some misconceptions in here with how the buildbot actually functions. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: 2.0.1
On Mon, Aug 1, 2011 at 19:54, Dan Ports wrote: > > It only comes up for ports which install multiple files with the same > name but different caps. openssl seems to be the main culprit, so I > committed a hack to make it skip fetching archives in r81559. If other > ports have the same problem, we may need to do the same or disable > archive fetching globally. I'd think a more appropriate fix would be to detect this behavior when packing or unpacking the archives and discard the archive in that case only. It can then be corrected in the port or upstream such that future archives will be useful again. Or, treat the case sensitivity of the file system as another build qualifier and not allow matching unless explicitly unpacked by the user. Either way, disabling archive fetching for a port (or all ports) because of an edge case like this doesn't seem like a good solution. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: port install but not activate
On Mon, Jul 25, 2011 at 19:27, Joshua Root wrote: > > The 'archive' action was repurposed to install but not activate, yes. Nice, thanks. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: port install but not activate
On Wed, Jun 15, 2011 at 13:56, Ryan Schmidt wrote: > > On Jun 15, 2011, at 11:02, Bradley Giesbrecht wrote: > >> Is there a port command to install but not activate a port? > > Not in MacPorts 1.9.2. I think I saw something go into trunk to do that a > little while ago? Now that 2.0 is out, is this indeed possible? Did it make it to the release? -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [GSoC] libelf license
On Fri, Jun 24, 2011 at 16:52, Felipe Tanus wrote: > 2011/6/23 Rainer Müller : >> >> LGPL would definitely be a license issue as MacPorts is licensed under BSD. > > Oh, that's bad. Ok, thank you. I didn't think LGPL within BSD was a problem. Is this a MacPorts decision? Or am I misinformed as to this direction of license mixing. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [PATCH] Let the default compiler be configurable
On Thu, Jun 9, 2011 at 17:07, Jeremy Huddleston wrote: > I assumed that this was already possible and was amazed that it wasn't... > with this patch, one can set "compiler" in $prefix/etc/macports.conf to > choose a default compiler. > > Thoughts? What's the use case for wanting to select a compiler like this? It seems that this would be better left to the requirements of an individual port. The other case that does come to mind is a larger set of changes that would allow a user to run independent of Xcode [1], but that seems like it would require a huge amount of change. [1]: I keep meaning to bring up that this is probably something that will need to be addressed soon. It seems to me that future versions of Xcode are going to only be offered through the App Store. With Lion being MAS only and Lion Server a $50 add-on, I doubt Apple will release Xcode 4 for free. Even if version 3 remains freely available, I imagine ports will begin to require newer tool chains. But, I don't want to derail this thread, further comments should fork off in a new thread. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Threat modeling and MacPorts [was Re: security projects thoughts]
On Tue, Apr 19, 2011 at 17:03, Jordan K. Hubbard wrote: > > Step 1: Source tarballs on random web/ftp sites. > [...] > Do we get more or less assurance by caching all of the tarballs on Mac OS > Forge? It restores some level of control, but it also means there's one > centralized location to attack now, too. This actually sounds tempting to me. It would solve the problem of unannounced edits to the source tarball and would also provide a consistent resource for hosting VCS snapshots where tarballs aren't provided. I don't know that I'd be concerned about the centralized attack. The MacPorts binaries would already be there and the package management systems for pretty much every *nix distribution uses a centralized repository (even if they also use repository mirrors). > Recommendation: 1a ... 1b ... All this sounds good. Mirroring sources would of course solve the issue of upstream hash failures. > Step 2: The runtime behavior of individual ports during the build and > installation process. This definitely gets into the realm of quality control. Try as hard as possible to audit your Portfiles before submitting them and test the software as best you can. One alternative is the Fink route with stable and unstable branches. Personally, I'd prefer a more restrictive submission process; something that tries to enforce that port submitters have thoroughly audited and tested their ports. I don't know how effective that would be though. It could at least be a recommendation in the port submission guide. > Recommendation: Run this part of the build/install process under a highly > restrictive trace mode "chroot" [...] You're the chroot expert. :-) The only addition that I can think of relates to how ports are accepted in the first place. Should any sort of tracking of the port submitter occur? Should submitters be required to sign their submissions? Should things all fall back to whoever commits the Portfile? Some of this is getting to deep into the details. > Step 3: The MacPorts infrastructure itself. > Recommendation: > 2a. Sign the official MacPorts packages if they aren't already. They are. Thanks Josh! > 2b. Make sure r/w access to the repository [...] Sounds good. > 2c. Make sure that all of the MacPorts infrastructure files on-disk are > properly owned by a privileged user and not easily modifiable [...] Probably a good idea to check permissions and such, but this is where it starts to get into the realm of trying to keep users from doing something stupid. Or protecting against physical access attacks. Both are good ideas, but there's only so much that is reasonable to try. I think it'd be enough to verify the infrastructure when it is initially installed and then provide a tool that can verify (and repair?) on demand. _Maybe_ also during "port selfupdate"? > Step 4: The legendary MacPorts Binary Packages. All that sounds good. Again, you're the chroot / sandbox expert :-) > Step 5: Runtime behavior of MacPorts-provided software. > Recommendation: This is clearly a sandbox challenge, and I'll be able > to say a lot more about the whys and wherefores of that in the future, just > not quite yet. :-) That sounds deliciously cryptic and enticing. One question about sandboxing though. What is actually restricted? Would you not be allowed to run "rm", for example, because it could alter user or system files? Or is sandboxing an optional feature that is turned on and off as needed? Or will all be revealed soon? ;-) > Does that about cover it? Did I miss anything? The only other item regards the key that is used to sign everything. Currently it looks to be JMR's personal key. This is fine, but it might be nice to generate an "official" MacPorts key that is controlled by whoever is the current project lead. This key can then be regenerated by whoever takes over as the new lead and optionally signed by the old lead. That's getting into the details though and can wait for a later day. Though I'd certainly be up for a MacPorts key signing party :-) -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 12:36, Jeff Johnson wrote: > > On Apr 18, 2011, at 12:04 PM, Arno Hautala wrote: > >> On Mon, Apr 18, 2011 at 11:34, Jeff Johnson wrote: >>> >>> You asked what other systems are in use. I replied. If you >>> don't like what is implemented, all I can say is >>> Patches cheerfully accepted. >> >> I asked what systems are in use in order to investigate options for MacPorts. >> I'm pointing out an issue that I see with this example. > > And I replied and your objections were both read and noted. And now I've replied to that. It seemed to me that you were dismissing my response as if to say you were just responding to my request for what other systems did and weren't interested in a discussion of their merits. >>> What is the connection between a "web server" and "package management"? >>> There are serious differences in the implementations and usage cases >>> and risk factors involved. You cannot just reason that all "content >>> delivery" >>> is the same. >> >> You mentioned non-repudiable signing as used by RedHat to be similar >> to "self-signed host certs". I assumed this to be an analogy to web >> servers. So I offered a critique of that analogy. > > I described a non-repudiable signature scheme in use by RPM, not > by Red Hat, which is in fact more interested in "branding" > as represented by an "official" signing key. Sorry for the conflation of RedHat and RPM. My bad. > There are no XSS threats in most cases for "package management" > because the delivery is usually from static content on mirrors, > not from some dynamic store. Even if "packages" are delivered from > a "web server" the attack is against the server, not the > sausages delivered by the server. The sausages (in the scheme I described) > WILL continue to have a public key and a signature that can be verified > no matter what other exploits there are. So I'm not sure the analogy > to a "web server" is meaningful or useful to "package management". I didn't bring XSS or anything else in to the picture. You mentioned "self-signed host certs" as an analogy for the RPM signing method. I took, and still take, this as an analogy to self signed certificates as used by SSL for a web server. I was pointing out that single use key pairs were less useful than a self signed web cert because at least the web cert would be reused from day to day and convey some sense of identity between visits. If the RPM single use key pairs are actually signed by another authority, that analogy breaks down. Did you have something else in mind in mentioning "self-signed host certs" that I'm still misunderstanding? >>> Not even close to the point if you think more bits in a hash >>> is more "secure". >> >> It's at least part of the goal (re: larger hash space, lower chance of >> collision). > > I do not read your thoughts. Say what you mean as precisely as possible. I mean that a longer hash probably isn't longer just for the sake of being harder to type. It's using more bits in order to increase the range of hash values. If the hash is implemented correctly, this means accidental collisions are less likely than they are in a shorter hash. In other words, an 8 bit hash can securely verify the alphabet, but will start running into collisions when you start hashing phone numbers. MD5 should be fine for either, but starts to break down when you use it for documents. >>> A trusted 3rd party registrar for pubkeys as well as including the pubkey >>> in signed content (to avoid DoS attacks preventing pubkey retrieval) is >>> the basis for the "trust". >> >> I fail to see how trust is achieved from using single use key pairs. >> Also, you hadn't previously mention anything about a 3rd party >> registrar. If the single use keys are also signed by that 3rd party, >> you're back to the issue of who to trust. > > I'm not responsible for your, or anyone else's, opinion of > how trust is achieved. I have described a mechansim only. > Don't do that if you don't "trust" what is implemented in RPM. I never asked you to be responsible for my opinion. And no one ever asked you to be the one to implement the features that are being discussed here. This isn't a place where you're expected to implement or shut up. You offered an example of what RPM does. I can see some merit to what they do, but there are also some decisions that are questionable or of dubious benefit. I'm discussing those. And I don't ne
Re: security projects thoughts
On Mon, Apr 18, 2011 at 11:34, Jeff Johnson wrote: > > You asked what other systems are in use. I replied. If you > don't like what is implemented, all I can say is > Patches cheerfully accepted. I asked what systems are in use in order to investigate options for MacPorts. I'm pointing out an issue that I see with this example. > What is the connection between a "web server" and "package management"? > There are serious differences in the implementations and usage cases > and risk factors involved. You cannot just reason that all "content delivery" > is the same. You mentioned non-repudiable signing as used by RedHat to be similar to "self-signed host certs". I assumed this to be an analogy to web servers. So I offered a critique of that analogy. > Not even close to the point if you think more bits in a hash > is more "secure". It's at least part of the goal (re: larger hash space, lower chance of collision). > A trusted 3rd party registrar for pubkeys as well as including the pubkey > in signed content (to avoid DoS attacks preventing pubkey retrieval) is > the basis for the "trust". I fail to see how trust is achieved from using single use key pairs. Also, you hadn't previously mention anything about a 3rd party registrar. If the single use keys are also signed by that 3rd party, you're back to the issue of who to trust. These are critiques of the system as presented to be in use by RedHat and how that might direct MacPorts. Personally, for trusting the build system, I'm leaning towards supporting a system that robo-signs packages as they're built. It might be nice to track ports back to their submitters with key signing, but it's probably more trouble than it's worth right now. And there's still the VCS history and Trac. A leaked robo-key can always be revoked and nothing in effective security is ever ideal. Even PGP key signing could be improved by tracing DNA back to most recent common ancestor. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 10:35, Jeff Johnson wrote: > > The actual implementation goes something like this: > a keypair is generated > just built packages are > a) include the pubkey > b) signed with the private key > and the private key is discarded. > > This isn't much different than "self-signed host certs" applied > to software packages. It would also seem to carry the same problems and introduce a few new. It's effectively just saying that "this data is what it says it is". No one runs a web server that generates a new cert for each page, asset, or user. And at least with a static self-signed cert you can run something like Certificate Patrol that informs you if the cert has changed since you were there last. You can then decide whether to investigate a cause for the change, if you care. Maybe I'm missing something, but generating a new key pair for each package doesn't seem any better than using a larger hash. Or is that the point? > A non-repudiable signature as above added to a package delivery > service is what Jordan has been saying all along. True, Jordan is advocating (I think) a system where a package is only able to impact files that are part of the package, as identified by the UUID. It would seem that some sort of signing would still be required in order to ensure that an attacker doesn't simply duplicate the UUID of another package. And then you're back to who to trust. Have I miscontstrued anything here? -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 10:04, Jeff Johnson wrote: > > On Apr 18, 2011, at 9:40 AM, Arno Hautala wrote: > >> I'm all for more GPG adoption, but it might be a good idea to be >> consistent and stick with OpenSSL. > > These are opinions only, without any supplied reason to prefer OpenPGP > over OpenSSL. DOes DSA from OpenSSL taste better to you somehow than > OpenPGP? Perhaps the random big numbers are "fresher" if wrapped in > OpenSSL than OpenPGP? The argument for OpenSSL was consistency. I never said anything about OpenPGP being better than OpenSSL. My personal enthusiasm for GPG is to see more widespread use of crypto. >> A common key either means every developer gets a copy. But, do you >> really want to issue a new key everytime a developer leaves or >> accidentally leaks the key? > > Key management is a whole different issue. SInce noone in a possition > of "authority" in MacPorts has volunteered to issue anything, well, > there just ain't no keys to manage, are there? This whole thread is speculation and brainstorming. If keys are the best way forward, there would be keys to manage. If not, there wouldn't be. > There is nothing wrong with robo-signing, its called a "non-repudiable" > signature, > and one can devise a credible security framework based on robo-signing > or any other "central authority". From my perspective, a credible security framework using non-repudiation relies on the key staying secure. For open source software this means a key that isn't publicly distributed. These seem to be opposing statements. I suppose the same issue occurs with a proposed MacPorts cert authority, but at least it can be revoked if something goes wrong. In a key based system, this would be the biggest issue. > What is the basis for "attractive" or not? In the above? I suppose it's my opinion. > I'm not at all sure why you think my comments qualify as "shot down". > > I am in fact just a lurker here, with an opinion no different than your own, > no means to approve/reject anything, and have indeed provided "constructive > criticism" > albeit harshly (and rigorously). Shot down in the sense that I suggested a method of exploit (which I think was along the lines of what Bayard initially proposed) and you countered with "if you're worried about it, don't use MacPorts". Constructive criticism wolud have been to discuss how the scenario wasn't an actual exploit risk. Or how better to mitigate it. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 10:02, Bayard Bell wrote: > > I think we need to temper how the examples are flying: an evil network > operator can do egregious damage, but macports isn't exactly the thing end of > the wedge for exploiting the implied level of trust. True. Outlandish examples can be saved for extending a system once it exists. I think my arguments at this point can boil down to looking at other package systems. Why do they bother with signing? Are their issues relevant to MacPorts? Are their solutions relevant to MacPorts? -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 09:55, Jeff Johnson wrote: > >> So let's say you're for some reason using the MacPorts sudo instead of >> the system shipped version (maybe the system version is out of date >> and insecure). You're updating your ports at a cafe and someone spoofs >> the update for the sudo port. With signed portfiles and packages they >> can't [1]. With the current scheme, they can spoof the portfile and >> replace the package source and hash. >> > > Sure "Let's say ..." whatever. The answer is the same: > If you are worried abt sudo in MacPorts as a threat vector, nuke it. > There's no loss of functionality using the system sudo. > >> [1] Or at least they'd have to spoof the initial MacPorts >> installation, but at least signed packages and portfiles have shut >> down some exploit avenues. >> > > How has the existence (or not) of digital signatures "shut down some > exploits"? > Which exploits? Name them please. It's hard to name an exploit that can be mitigated when the idea is shot down with "If you're worried about X, don't use X." -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 09:38, Daniel J. Luke wrote: > On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote: >> >> So let's say you're for some reason using the MacPorts sudo instead of >> the system shipped version (maybe the system version is out of date >> and insecure). You're updating your ports at a cafe and someone spoofs >> the update for the sudo port. > > Which method are they using to do this? Magic? ;-) The easiest example is the malicious network operator. >> With signed portfiles and packages they >> can't [1]. With the current scheme, they can spoof the portfile and >> replace the package source and hash. > > I think it's worthwhile to think about this, but it's probably also important > to remember that it's not the only (or even the most likely) threat model. This is why netsec is fun. You get to seriously discuss models that are unlikely :-) > It's not like most maintainers (or probably any) really audit upstream source > releases to make sure they don't contain anything malicious [which brings us > back to jkh's sandbox everything idea, which is a good one]. I suppose it's a good time to remember that spending too much time on miniscule threats can make other vulnerabilities greater risks than they were previously. Security in layers and tradeoffs. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 06:12, Bayard Bell wrote: > > I've read back on the threads from March about binary packaging and > appreciate better what constraints were accepted to simplify deployment. The > signed Macports releases in distfiles that Anders pointed me to is signed > with GPG. Given that we're talking about developer tools rather than > packaging, is it reasonable to add this to the base requirements for > macports? Are people fine with the idea of using PGP with macports and > openssl with the packaging system? I'm all for more GPG adoption, but it might be a good idea to be consistent and stick with OpenSSL. > If you go the GPG route for macports, do you want individual developers > signing things with their own keys, or do you want to have a common > key, as do the major RPM and apt distros? A common key either means every developer gets a copy. But, do you really want to issue a new key everytime a developer leaves or accidentally leaks the key? Or packages are signed by a central entity. This either puts a lot of pressure on a single developer or means robo-signing with a passphrase-less key or storing the passphrase on the server. None of those are all that attractive. Each developer having their own key, that has been signed by a MacPorts "master" key or cert authority, distributes the work load, is easily scalable, and easily revokable as needed. You can do this with OpenSSL or GPG. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: security projects thoughts
On Mon, Apr 18, 2011 at 08:27, Jeff Johnson wrote: > > You are assuming a threat vector reasoning that starts: > 0) assume sudo is "infected" maliciosly. > ... > 42) anything is possible, including other ppkgs infected and > distributed. > > The answer there is not using an possibly infected sudo in the build system. You may as well just say, "don't use a possibly compromised system", or in other words, "don't use a system". The example given isn't "assume sudo is infected", but "assume sudo could become infected. How can that be mitigated?" >> I've not been over the MacPorts sources in a long time, I'm just realizing >> how easy it would have been for any of the hackers around me during my >> studies to completely own any of my Mac laptops back then. Them and the >> bloody sysadmins. > > Presumably you already "own" ... "any of my Mac Laptops" ... by definition. Ah, common mis-spelling. He meant "0wn". > Its you trust decision: The corollary to your stated constraint "network > operator should ... not be allowed to inject code" > is either > TUrn off your netwwork. > or > Don't use MacPorts. Then why do we have things like SSL, GPG, and passwords in general? They're there to enhance the security of an insecure channel and authenticate the client and server. Of course there are still ways to compromise the system (forge an SSL certificate, log a password, etc.). You can't protect against everything, but you can take steps to get better. > Correct: MacPorts contains sudo which is built and installed *AS ROOT* > just like every other package. So let's say you're for some reason using the MacPorts sudo instead of the system shipped version (maybe the system version is out of date and insecure). You're updating your ports at a cafe and someone spoofs the update for the sudo port. With signed portfiles and packages they can't [1]. With the current scheme, they can spoof the portfile and replace the package source and hash. [1] Or at least they'd have to spoof the initial MacPorts installation, but at least signed packages and portfiles have shut down some exploit avenues. -- arno s hautala /-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
