Re: How to keep uncommitted work in a git clone

[Jeremy Lavergne]

Religiously use `git status`, and perhaps update your shell prompt to
reflect it as well: branch name, unstaged changes, staged changes, etc.
Consider looking on Google for prompts that incorporate functions like
__git_ps1:
GIT_PS1_SHOWDIRTYSTATE="1"
GIT_PS1_SHOWUNTRACKEDFILES="1"
PS1="\h:\W \u$BLUE\$(__git_ps1 \" [%s]\")$DEFAULT\$ "


The current working tree is by default unstaged. You must select what to
stage, or explicitly indicate files during actions. For example, these
are equivalent commands for commits changes to foo.txt (a file already
in the repo):

 1echo "asdf" >> foo.txt
  git add foo.txt
  git commit -m "adding foo"

 2echo "asdf" >> foo.txt
  git commit foo.txt -m "adding foo"


That first form is how you commit only explicit files while leaving more
for a subsequent commit. Same idea for `git add -p` for parts of files.
Once things are staged, leaving off filenames means the actions apply to
the staged changes.



Regarding the stash situation:  The nice thing about git is won't do
anything destructive without you forcing it.

Checkout the stashes and see if you perhaps made a second one?
   git stash list  # (or otherwise `git help stash`)
   git show stash@{0}


So your changes are very likely still there: either as a second stash,
or perhaps conflicting with the new working tree.

git status :-)


On 11/03/2016 09:56 PM, Ryan Schmidt wrote:
> With Subversion, I was accustomed to keeping changes in my working copy that 
> I was not ready to commit yet.
> 
> Git doesn't let me do that. It complains and tells me to git stash and later 
> git stash pop.
> 
> 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.
> 
> I can get these particular changes back from my old Subversion working copy, 
> but I don't understand how I'm meant to work with git when I have changes 
> that I'm not ready to commit yet, yet there are other changes I need to make 
> and commit elsewhere within that same clone.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

branch -d and pushing (Was: Working with Git)

[Jeremy Lavergne]

Ensure you pull or fetch your merged changes otherwise you'll never be
allowed to delete the branch. So if on branch X you have GitHub merge
branch Y, you cannot delete Y until you fetch X.

If we get lots of branches, you can prune remote tracking easily:
git fetch -p

(remember:
 - local tracking "master"
 - remote tracking "origin/master")

On 11/03/2016 11:36 AM, Lawrence Vel�zquez wrote:
> Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
> suggested because these instructions are designed so that you can always
> fast-forward merge the PR branch into master. If "git branch -d" fails,
> something is not right, and you have to go back and figure out what.
> 
> One small addendum: Before "git push origin master", you should run "git
> pull --rebase" to get any new commits that were pushed by other
> committers.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Jeremy Lavergne]

You can `pull -r` immediately before pushing. Conveniently, you can
configure pull to autorebase. Either way, the simplest modification to
your last step is this:

git pull -r && git push


On 10/31/2016 05:01 PM, Eric A. Borisch wrote:
> Thanks for all the hard work with this transition! I'm sure once we're
> all "over the hump" we'll look back and wonder why we waited so long.
> 
> Just so I'm clear on this, is the desired approach for each committer to:
> 
> == setup ==
> 1) clone macports/macports-ports to the local filesystem
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before 5
> (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.
> 
> If I'm wrong, or if I've missed something, please let me know; there's
> been more discussion than I've had time to follow of late surrounding
> this transition...
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

[GSoC] Announcing Google Summer of Code 2017 and Google Code-in 2016

[Jeremy Lavergne]

GSoC 2017 is announced!

Please add or refines ideas on the MacPorts wiki; anyone interested in
mentoring is encouraged to contact those of us regularly involved with
the program (the likely administrators):
 * s...@macports.org (myself)
 * c...@macports.org (Clemens)
 * rai...@macports.org (Rainer)


 Forwarded Message 
Subject:[GSoC Mentors] Announcing Google Summer of Code 2017 and
Google Code-in 2016
Date:   Mon, 10 Oct 2016 10:11:19 -0700 (PDT)
Reply-To:   sttaylor 



Hello all,


We are pleased to announce Google Summer of Code 2017
, the 13th straight year of the program.


The GSoC 2017 timeline has been updated with next year's important
dates. More information including some changes to the Program Rules will
be updated in early November on the program site .


Organizations -- If you would like to apply for the 2017 program please
start thinking about the projects you would like students to work on and
also reach out to your community members to ask if they would like to be
mentors for the program.

We are looking forward to another exciting year of GSoC!


Today we also announced the Google Code-in 2016 contest
that will be open for past GSoC mentoring organizations to apply to be a
part of this exciting 7 week contest bringing teenagers into the open
source community. Organization applications are open for GCI from
October 24th - November 7th.  GCI opens for student participants on
November 28th!


For any questions about the programs please email us at
gsoc-supp...@google.com


Best,

Google OSPO team
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to use git

[Jeremy Lavergne]

I'm familiar with tig and gitk, if anyone needs assistance with those.


On 08/19/2016 09:49 PM, Mark Anderson wrote:
> I use git (and Github Enterprise) in my day to day work. I can help out. 
> 
> Another good (free (as in beer)) client is SourceTree
> https://www.sourcetreeapp.com/


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: #51392 Play @1.3.4 Patch

[Jeremy Lavergne]

Hi John,

Comments were provided on the ticket indicating it fails to build.

Could you update the ticket with your desired solution?
https://trac.macports.org/ticket/51392



On 06/01/2016 05:49 PM, John Patrick wrote:
> Hiya,
> 
> I raise a ticket (https://trac.macports.org/ticket/51392)
>  a few weeks ago, is someone
> also to look at the patch? The last play patch I submitted took 5 weeks
> before I emailed and then someone took a look.
> 
> I've got another version bump after this, I'm doing it each major
> version at a time as I need to be able to install specific version to
> support versions used.
> 
> Cheers,
> John


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: destroot

[Jeremy Lavergne]

Check out fs-traverse.

On 04/02/2016 12:17 PM, Mark Brethen wrote:
> I have to manually move an examples directory to destroot. xinstall will let 
> you either create directories or copy files, not both. Is there a simpler 
> method to copy the entire directory?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Jeremy Lavergne]

On 02/04/2016 03:32 PM, Joshua Root wrote:
>> The question is: what should be the general policy with these ports?
>> How long should we keep them around?
> 
> As long as they still build on some OS X version that base works on. If
> they break and nobody steps up to fix them, that's a pretty good
> indication that it's time for them to go.
> 
> As you mentioned, there are all kinds of reasons why people have to test
> against old versions. A deprecation warning in the description and notes
> would be a good idea.


Could this be considered reinforcing the expectation of no one fixing
tickets?

If people need to use the very old versions, we should encourage them to
use source control to look up these Portfiles. While stubbing ports with
this message would be helpful, I worry how many ports would become stubs.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[Jeremy Lavergne]

When using trace mode and armed with the dependency tree, I know that my
concurrent installs will not be impacting each other. The lock should be
intelligent enough to use the dependency tree�after all, MacPorts is the
one computing it.

I agree with Rene here: the lock should be smart enough to use the
dependency tree.


On 01/04/2016 04:18 PM, Daniel J. Luke wrote:
> On Jan 4, 2016, at 4:13 PM, Ren� J.V. Bertin  wrote:
>> Maybe the "simplest" solution would be to provide an option to ignore the 
>> lock if it's present, and leave it to the user to know what s/he is doing 
>> (and assume the consequences, like with -n, -p or -o)?
> 
> that's a pretty horrible idea.
> 
> The consequences of ignoring the lock (in the worst case) are worse than -n 
> -p or -o
> 
> if you want to improve the locking, I'm sure everyone will be happy about 
> that. If you want to hack your system to not use the lock, you can live with 
> the consequences - but it's not something we should ship.
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: portindex ignores (filters out) unchanged port

[Jeremy Lavergne]

Why not read the code rather than try to deduce it from observed behavior?


On December 31, 2015 5:29:42 AM EST, "René J.V. Bertin"  
wrote:
>On Tuesday December 29 2015 17:59:07 Rainer Müller wrote:
>
>>> 1 its mtime is newer (or just different)
>>
>>Different from what? Do you propose to store the mtime of the Portfile
>
>In first instance I don't see a reason to change how this is done.
>
>>> 2 it lives in a portdir not yet known
>>
>>As I told earlier, it is not possible to look up a port by portdir
>with
>>the current PortIndex format. The only key to find a port in the
>>PortIndex is by its name.
>
>Let's be precise: you mean the portdir name. And that's the bit being
>looked up from the PortIndex files. 2) means "I encounter a directory
>containing a Portfile and that directory is not yet listed in the
>index".
>
>>Looking up a port by portsdir requires either an additional portsdir
>map
>
>How does that claim not contradict what has been explained before,
>namely that a port name is "guessed" from its portdir name? I deduce
>that the name that's actually stored is the true name of the port, from
>the Portfile, but it is still compared to directory names. I think that
>must be how a port whose name doesn't match its portdir name is
>reindexed every time. AFAICS that corresponds to 2), supposing that the
>indexer takes the name of each directory it encounters that contains a
>Portfile, and then compares it to the list of already indexed (stored)
>names.
>
>Anyway, I proposed 2) based on the understanding that the portdir name
>is currently stored. I'm not sure if it is actually required (in fact I
>think it isn't).
>
>>> 3 its hash is different from the one stored in one or both of the
>>> PortIndex files (or none is stored, but that should already be
>caught by 2)
>>
>>What would that solve?
>
>The hole in the bucket :)
>
>The idea of adding a hash didn't come out of the blue in this thread.
>
>>Hashing the Portfile just needs more time. Maybe
>
>Well, yes, but that doesn't have to be a significant overhead. I invite
>anyone who doubts that to try port:unison for a while, for instance to
>sync the main port tree with a backup copy. It'll take a certain time
>on first run (I cannot recall having synced the port tree with it), but
>once that's done, checks for what to sync are almost instantaneous.
>From what I know of its implementation, it uses a combination of mtime,
>possibly size and a hash to determine whether a file has been changed.
>Getting the exact hashing function out may not be trivial given that
>unison is written in ocaml, but it certainly is a good proof of
>concept.
>
>Writing this got me curious, esp. since I was already working from my
>slowest machine (a 3yo netbook under Linux with a ZFS filesystem,
>everything to bog it down). I made a copy of
>svn.macports.org/trunk/dports, told unison to ignore the .svn and files
>directories, and let it compare the trees. The initial run took just
>over 2 minutes; subsequents rescans are maybe not "instantaneous" but
>take no more than a few eye beats (2-3 seconds).
>
>>we could only hash if it has the same mtime, but that would address a
>>hypothetical case.
>
>Actually, no; that would catch (avoid) the large majority of hash
>calculations. And if it doesn't: calculating a hash (*not* in pure Tcl
>code) is always faster than parsing the Portfile.
>
>Tcl has builtin support for (from faster to slower) crc32 (crc::crc32),
>md4 (md4::md4) and md5 (md5::md5), all of which can operate on a file.
>
>>Your proposal would make the generation of PortIndex more robust, but
>>also requires a redesign of the PortIndex format to make it possible
>to
>>look up ports by either portsdir or by port name.
>
>Yes. That too is something that was on the table.
>
>However:
>
>>Anyway, using the name of the port for the ports dir is a reasonable
>>convention in my opinion. We should just keep it that way, regardless
>of
>>the current technical requirement.
>
>If that's the consensus or majority opinion I am not going to invest
>any time in trying to design an improved (more robust AND more
>flexible) indexing algorithm (only to find that my investment was for
>nothing).
>
>R.
>___
>macports-dev mailing list
>macports-dev@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[Jeremy Lavergne]

I believe the inquiry surrounds why we trigger a lock for the duration of
all phases when doing an install. Specifically, why do we not instead set
the lock only when in phases that could changes installed files.

So abstract a bit further beyond just uninstall phase: why do we need to
lock anything when we're not yet changing installed files?


On Tue, November 17, 2015 13:36, Joshua Root wrote:
>> I may have asked before, so apologies if I forgot the answer:
>>
>>
>> Why does "base" need a registry lock for operations up to destroot? I
>> realise configure and beyond may require installing missing ports, but
>> that could lead to locking the registry only when those ports are to be
>> installed. When none are missing a lock shouldn't be required, right?
>
> What if you uninstall some ports in another terminal while the operation
> is running?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Jeremy Lavergne]

That's a good idea. We could actually schedule downtime for the Yosemite box to 
be cloned then :-o (we could clear out all artifacts to possibly speed up the 
process).

But once it's released: how quickly could someone update the OS on this new 
buildslave?

It's still a blackbox of hope.


On Aug 17, 2015, at 1:18 PM, Sean Farley wrote:

> Darn. Could we at least allocate another buildslave with Yosemite so
> that when El Capitan is release, we could at least upgrade right away?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Jeremy Lavergne]

While the beta is a public release, it is under NDA.

"Don’t blog, post screen shots, tweet, or publicly post information about the 
public beta software, and don't discuss the public beta software with or 
demonstrate it to others who are not in the Apple Beta Software Program. If 
Apple has publicly disclosed technical information about the public beta 
software, it is no longer considered confidential."
https://beta.apple.com/sp/betaprogram/faq

Sadly, one must say this means a buildslave is not yet a viable option—even 
though the beta OS release is open the public.


On Aug 17, 2015, at 6:05 AM, Wahlstedt Jyrki wrote:

> I’d
> like to see this, too, but then, we haven’t a release for El Capitan yet, 
> have we!?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Jeremy Lavergne]

I suspect being available at release (even if rebuilding) is far better than 
waiting 2+ weeks.

On Aug 16, 2015, at 5:01 PM, Ryan Schmidt wrote:

> In the past, we haven't set up a build server for an OS until it public 
> release. It's conceivable that something would change between now and final 
> release that would necessitate rebuilding packages...

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Commit changes proposed in 48301

[Jeremy Lavergne]

Patched in r138848.

On Jul 21, 2015, at 12:09 PM, Sterling Smith wrote:

> Will someone with committing privileges accept the patch given in 
> https://trac.macports.org/ticket/48301?
> 
> If there is a different suggested workflow, I am open to suggestions.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts on COW filesystem

[Jeremy Lavergne]

This might give ideas on next steps:
https://www.sqlite.org/pragma.html#pragma_journal_mode

On Jul 10, 2015, at 2:26 PM, René J.V. Bertin wrote:

> I'm experimenting with running MacPorts on a COW filesystem (ZFS; 
> www.o3x.org). I've noticed the (transient) presence of a file 
> ${prefix}/var/macports/registry/registry.db-journal , which makes me wonder 
> if it's possible to configure the way the registry database is accessed (akin 
> to mysql.conf when using mysql DBs). If I'm not mistaken, registry.db-journal 
> acts more or less like the HFS, EXT3, NTFS (etc) journals work, and should be 
> completely redundant on a COW filesystem (as well as a significant 
> performance bottleneck).

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Could a port have a dependency on a port variant?

[Jeremy Lavergne]

Not officially, or in an intelligent way. MacPorts can point it out during your 
Portfile's own execution, which means the prereq might need rebuilt.

http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/active_variants-1.1.tcl

On Jun 25, 2015, at 6:19 AM, Joël Brogniart wrote:

> Could a port have a dependency on a port variant?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: embracing go compiler

[Jeremy Lavergne]

Certainly. While MacPorts has six Go-using portfiles, I'm seeing many more 
listed on just the first-google-hit:
http://go-lang.cat-v.org/go-code

Since there's has not been notable discussion on using Go compiler in MacPorts, 
it would advantageous to start on a PortGroup while there's only six portfiles 
to fixup.


On Jun 22, 2015, at 11:53 AM, Lawrence Velázquez wrote:

> Go might benefit from a portgroup, but I don't think it deserves special 
> treatment in base. There are only 6 ports that use it.
> 
> % port -v deps 'depends::go$'
> Full Name: codesearch @20131030_0
> Library Dependencies: port:go
> --
> Full Name: hub @2.2.0_0
> Library Dependencies: port:git, port:go
> --
> Full Name: asciinema @1.1.1_0
> Build Dependencies:   port:go
> --
> Full Name: go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0
> Build Dependencies:   port:go
> --
> Full Name: mongo-tools @3.1.4_0
> Build Dependencies:   port:go
> --
> Full Name: peco @0.3.2_0
> Build Dependencies:   port:go
> 
>> For example, see the MP_GOFLAGS in build.args for:
>> https://trac.macports.org/browser/trunk/dports/sysutils/asciinema/Portfile
> 
> I don't know whether there's a convention for passing flags to Go, à la 
> CFLAGS. You'll note that I had to patch asciinema's makefile to accept my 
> tweaks.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

embracing go compiler

[Jeremy Lavergne]

Will MacPorts set the appropriate compiler flags for the Go compiler? I suspect 
Go is popular enough to warrant some attention in base if someone has time.

For example, see the MP_GOFLAGS in build.args for:
https://trac.macports.org/browser/trunk/dports/sysutils/asciinema/Portfile

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: cloudflare/zlib on OS X

[Jeremy Lavergne]

That's the problem.

On Jun 2, 2015, at 4:40 AM, René J.V. Bertin wrote:

> I can safely assume

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: cloudflare/zlib on OS X

[Jeremy Lavergne]

Did you verify that this employ is actually empowered to dictate the company's 
licensing?

On Jun 1, 2015, at 8:52 PM, René J.V. Bertin wrote:

> They don't explicitly change the licensing of the files they modify. If those 
> files each carry a zlib license they will still carry that license after 
> applying the patch.
> 
> CloudFlare are the only ones who could accuse someone of stealing their code, 
> applying the wrong license etc. I forwarded a statement from a CloudFlare 
> employee using his work address that they didn't change a license. What more 
> could you want?!

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

trunk base failure

[Jeremy Lavergne]

Ideas on what happened here?

Inside the tarcmd  error.log, a bunch of no-such-file errors. In this 
situation, ZendFramework1 is installed but inactive:
  ZendFramework1 @1.12.13_0+php56


During a routine trunk/base svn up && make && sudo make install:

make[1]: Nothing to be done for `install'.
[ ! -f "/opt/pspp/etc/macports/mp_version" ] || rm -vf 
"/opt/pspp/etc/macports/mp_version"
/usr/bin/install -c -d -o "root" -g "admin" -m "0755" 
"/opt/pspp/share/macports/"
/usr/bin/install -c-o "root" -g "admin" -m 444 setupenv.bash  
"/opt/pspp/share/macports/"
/usr/bin/install -c-o "root" -g "admin" -m 444 ./macports-pubkey.pem  
"/opt/pspp/share/macports/"
/opt/pspp/libexec/macports/bin/tclsh8.5 ./src/upgrade_sources_conf_default.tcl 
"/opt/pspp"
/opt/pspp/libexec/macports/bin/tclsh8.5 ./src/images_to_archives.tcl
This could take a while...
Processing 264 of 385: ZendFramework1-1.12.13_0+php56.darwin_14.x86_64.tbz2
Command failed: /usr/bin/tar -cjf 
/opt/pspp/var/macports/software/ZendFramework1/ZendFramework1-1.12.13_0+php56.darwin_14.x86_64.tbz2
 -T /opt/pspp/var/macports/software/ZendFramework1/tarlist > 
/opt/pspp/var/macports/software/ZendFramework1/error.log 2>&1
Exit code: 1
command execution failed
while executing
"system "$tarcmd -cjf $newlocation -T ${targetdir}/tarlist > 
${targetdir}/error.log 2>&1""
("foreach" body line 78)
invoked from within
"foreach installed $ilist {
incr counter
set iname [lindex $installed 0]
set iversion [lindex $installed 1]
set irevision [lindex $inst..."
(file "./src/images_to_archives.tcl" line 38)
make: *** [install] Error 1

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

buildbot env

[Jeremy Lavergne]

Do we have our buildbot environments documented?

Today on IRC:
jedna:hi, i was wondering on the configuration used to build the binary 
packages on packages.macports.org, specificaly the darwin_12 ones. if gcc or 
clang is used, version, and so on. is it documented somewhere, please?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [135904] trunk/dports/aqua/Books/

[Jeremy Lavergne]

On May 6, 2015 1:46:14 PM EDT, Joshua Root  wrote:
>> Revision: 135904
>>   https://trac.macports.org/changeset/135904
>> Author:   snc at macports.org
>> Date: 2015-05-06 09:39:28 -0700 (Wed, 06 May 2015)
>> Log Message:
>> ---
>> Books: remove because this legacy software is now not available
>upstream
>
>http://sourceforge.net/projects/books-macosx/ ?
>___
>macports-dev mailing list
>macports-dev@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-dev

That page links to a dead site. Source forge is not Books' home...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gtk-using apps

[Jeremy Lavergne]

On April 18, 2015 4:47:17 AM EDT, "René J.V. Bertin"  
wrote:
>On Friday April 17 2015 18:54:19 David Evans wrote:
>
>>> We have the app portgroup, which is just a shell wrapper to run a
>program in $prefix/bin. Is that still the only available option?
>
>I have been working off and on (more off than on) on a version of the
>old DropScript, exactly with the goal of being able to integrate
>traditional applications with LaunchServices. It works well enough for
>me ATM but needs polishing, and officially a reply from the original
>author to know if and what kind of license we can stick on the code.
>
>For those who are (somehow :)) not aware: LaunchServices does not work
>like its equivalent on MS Windows, at least not the part that most Mac
>users interact with. Double-clicking a document, dragging a document
>onto the app icon do not lead to main being called with argc,argv set
>to reflect the documents concerned. Events ("messages") are used
>instead, and you need to declare a principle class that replies to
>these messages to be able to open the documents. Qt does have some
>infrastructure in place for that, but it clearly isn't automatic. I
>have no idea about GTk in this domain.
>BTW, it is also possible to send regular arguments via LaunchServices
>(e.g. `open -a Foo.app --args arg1 arg2 etc`).
>It's not impossible to write some code that intercepts the LS messages
>that can be injected at the head of main, but it given that it works by
>calling main once more (or doing an exec) it's just as clean to write
>an external wrapper which (re)creates a proper argc,argv structure.
>
>R.

Do you happen to know how ScriptExec (used by gimp-app) compares to DropScript?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

gtk-using apps

[Jeremy Lavergne]

Have there been any developments in having GTK apps "talk" with OS X, for 
example double clicking files and quitting from the Dock?

We have the app portgroup, which is just a shell wrapper to run a program in 
$prefix/bin. Is that still the only available option?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: doc and doc-new in svn

[Jeremy Lavergne]

Well, it will be reviewed soon.

On Apr 8, 2015, at 10:30 AM, Eitan Adler wrote:

> Is there any reason to keep the old doc tree around?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: parallel build suggestion

[Jeremy Lavergne]

On April 4, 2015 7:29:20 AM EDT, "René J.V. Bertin"  wrote:
>Hi,
>
>I just noticed my computer becoming quite unresponsive upgrading
>port:glew . I have buildjobs set to 4 (the number of cores in my
>system), and glew installed +universal.
>What happens of course is that clang -arch i386 -arch x86_64 does the 2
>arch builds in parallel, meaning I had 8 processes running in parallel
>on files that apparently required a lot of resources
>
>Would it be possible to adapt buildjobs automatically when a port is
>build +universal but not with the muniversal portgroup, i.e. limit it
>to nCores/2 ?
>
>R.
>___
>macports-dev mailing list
>macports-dev@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-dev

Why specify the number of cores when that is done automatically, and likely 
would avoid this situation?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

removing py-memcached

[Jeremy Lavergne]

I cannot find anything that depends on py-memcached, and it installs without 
issue in pip.

Any objections to removing py-memcached?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [134167] trunk/dports/lang/falcon/Portfile

[Jeremy Lavergne]

Ah, thanks.

I'll revisit back after I'm done with libftdi1.

On Thu, March 19, 2015 12:30, Lawrence Velázquez wrote:
> You should probably use build.dir here, instead of hard-coding
> "${workpath}/build".


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: circular dependencies

[Jeremy Lavergne]

On Mon, February 23, 2015 16:50, René J.V. Bertin wrote:
> Sure. As I said, I'd probably appreciate for certain things, but not as a
> mandatory feature.
>
> I have a hunch that it'd add non-negligible overhead too, if it's to be
> used in as many stages as possible.

As someone routinely using trace mode across 10.5 to 10.10, I've run into
no significant impacts. I greatly appreciate all it provides, and all
portfile maintainer should be making use of it.




___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Google Summer of Code 2015

[Jeremy Lavergne]

On Thu, February 19, 2015 06:52, Rainer Müller wrote:
> I noticed you started editing the SummerOfCode wiki page [1].
> Apparently, the mentoring organization application deadline is already
> *tomorrow* at 2015-02-20 19:00 UTC.
>
>
> Are you again going to file the application on behalf of The MacPorts
> Project?

Yes, so far the list of mentors/admins is similar to last year:
https://trac.macports.org/wiki/SummerOfCode#Mentors


Anyone else interested in mentoring should write the list so we can
discuss the role.

Similarly, any ideas for GSoC should be put into the wiki page:
https://trac.macports.org/wiki/SummerOfCode



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: ~/.macports

[Jeremy Lavergne]

>> I take it there is no official way to define the permissions mask for a
>>  macports user that would allow an admin user full control over content
>>  owned by the macports user (but not the reverse)?
>
>
> Not sure you can make extended ACLs propagate the right way.

The old school option is creating a common group for both users and have
appropriate umasks.

However, if you're the admin user sudo is already available.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildbot failure in MacPorts on buildports-mtln-x86_64

[Jeremy Lavergne]

> Are you thinking something like:
>
>
> - get list of files to be activated and populate the registry
> - start to actually activate the files
> - update the registry stating that activate finished
>
>
> with the ability to either auto-detect and attempt to rollback a
> non-completed activate (maybe on the next run) and/or a 'port
> cleanup_interrupted_activate' command?

I'm thinking that sequence, yes; the recording of files as not activated
could be the current indicator that something needs done.

As for a cleanup_interrupted_activate, I would use either a new command
(yet another?) or indicate the package can be upgraded. I expect a user to
not be so interested in "resume an interrupted install" as "upgrade the
package" or "try installing the package again".

We also have user prompts from GSoC available, so we can ask the user
immediately before doing any other actions.

What is the best way for MacPorts to present an interrupted activation to
users?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fwd: buildbot failure in MacPorts on buildports-mtln-x86_64

[Jeremy Lavergne]

> The registry is transactional, the file system is not.

Is MacPorts able to make use of rev-upgrade spotting missing files if it
marked a file activated prior to writing it?

Or would an intermediate status for a file be more helpful?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fwd: buildbot failure in MacPorts on buildports-mtln-x86_64

[Jeremy Lavergne]

> Forwarded to sysadmin for action.  I'm afraid I inadvertantly caused
> this by stopping a build of inkscape last
> night.  Sorry for any inconvenience.

Does this mean our activation step is no longer transactional (as a file
is installed, recording it)?





signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Cutting down on python versions

[Jeremy Lavergne]

>> Will your update include our stance on including all python packages
>> versus only c-modules (or otherwise needing MacPorts' involvement)?
>
> I'm not sure what you mean.

Joshua pointed it out in a previous thread: we don't make use of other
package managers (Pip in this instance), so we shouldn't have their
packages in MacPorts unless they have requisites in MacPorts.

If you don't see this as an issue, that's perfectly fine too (unless
Joshua wants to chime in again ;-) ).


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Cutting down on python versions

[Jeremy Lavergne]

>> I recall there being an effort to cut down the number of python ports,
>> what is the status of this
>
> Close to completion. I've been meaning to send out a status update but
> haven't gotten around to it.
>
>> and what python versions are we aiming to support going forward? The
>> reason I'm asking is that I'm in the middle of adding some new python
>> variants to a port and want to make sure that I'm not wasting time by
>> checking versions that are being dropped?
>
> New ports should only support the 2.7 and 3.4 series.

Will your update include our stance on including all python packages
versus only c-modules (or otherwise needing MacPorts' involvement)?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: libc++, C++11, and C++14 on Leopard and Snow Leopard

[Jeremy Lavergne]

On Thu, January 15, 2015 15:30, Lawrence Velázquez wrote:
> The archives don't encode the C++ stdlib that's active at build time.
> We'd have to add Yet Another Field to the archive names.

There's probably even further information we should include regarding
archives, however we shouldn't put so much data into a filename.

MacPorts already knows the Portfile's sha256. We could also put the
requested build settings (archs, os, variants, stdlib and more!) as
additional input to the hash, using the result as the filename.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Building all ports when setting up a new buildbot builder

[Jeremy Lavergne]

It simply looks like our setup is not made to handle building “all”, and we 
should just avoid doing it. The important packages (e.g. batches of top-100) 
should get built and then we rely on normal commit hooks from there.

On Dec 3, 2014, at 9:51, Daniel J. Luke  wrote:

> ick, so maybe something is capturing all stderr/stdout to memory while each 
> step is being run (instead of logging it to a file or filling a small buffer 
> and then writing it out when it gets full)?
> 
> Also, even so, is it a 64bit process? I would be surprised if it's actually 
> running out of virtual memory space (but maybe the virtual machine it's 
> running on is configured with some strict resource limits?).

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: Apache quit after last macports update...

[Jeremy Lavergne]

I’ve quickly updated the MAMP instructions since they were obsolete when they 
were mentioned on the userlist.
https://trac.macports.org/wiki/howto/MAMP

Please address any further updates/corrections.

Begin forwarded message:

> From: Jeremy Lavergne 
> Subject: Re: Apache quit after last macports update...
> Date: November 10, 2014 at 12:20:34 EST
> To: SH Development 
> Cc: macports-us...@lists.macosforge.org
> 
> Okay, it’s starting to sound like apxs needs run since php5 was made obsolete 
> (that’s the package libphp5.so belonged to).
> 
> I’d just follow the next steps for setting up php56 with Apache to get you up 
> and running again (uses php56-apache2handler), after deleting that libphp5.so 
> reference from line 118 of /opt/local/apache2/conf/httpd.conf:
> http://trac.macports.org/wiki/howto/MAMP#php
> 
> 
> 
> On Nov 10, 2014, at 12:06, SH Development  wrote:
> 
>> It was installed and working before the update, but when I do:
>> 
>> which php
>> 
>> I get usr/bin/php   not the one that macports would have installed, so it 
>> appears that it may have gotten hosed as well.
>> 
>> When I install php56, it acts like it's already installed.  Same with 
>> apache2.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: macports registry error when runtime dependency installed but not active

[Jeremy Lavergne]

>> Got a full log with the backtrace? The error may not even be coming from
>> base. Dependencies are installed before any target is executed in any
>> case, and runtime dependencies aren't required to be present at
>> configure time.
> 
> I ran clean/upgrade a few times; there error itself was not part of the log.
> It only showed up in stdout/stderr (didn’t check which)...

Also note that it’s not an immediate dependency, but a dependency of a 
dependency.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: macports registry error when runtime dependency installed but not active

[Jeremy Lavergne]

> Got a full log with the backtrace? The error may not even be coming from
> base. Dependencies are installed before any target is executed in any
> case, and runtime dependencies aren't required to be present at
> configure time.

I ran clean/upgrade a few times; there error itself was not part of the log.
It only showed up in stdout/stderr (didn’t check which)...

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

macports registry error when runtime dependency installed but not active

[Jeremy Lavergne]

I was updating akonadi using trunk today, and it error’d out complaining that 
virtuoso wasn’t installed.

--->  Configuring akonadi
Registry error: virtuoso not registered as installed & active.

Turns out virtuoso was installed, just not activated.

Is there a reason MacPorts is unable to activate this on its own and get on to 
building?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: unsigned kexts on Yosemite

[Jeremy Lavergne]

> We could remove these ports from MacPorts. Are signed binaries of them 
> available from their developers? If not, we could encourage the developers to 
> provide them, and refer them to this issue.

Shouldn't we keep them since when we support "two previous major OS versions"? 
They work fine everywhere except Yosemite, so only disable them there.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: depends

[Jeremy Lavergne]

You'd have it also share the variants/subport naming.

There's a portgroup for ensuring whether variants are selected:
https://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/active_variants-1.1.tcl

On Oct 18, 2014, at 3:13 PM, Mark Brethen wrote:

> Right, but I have subport C whose configure.args would be appended depending 
> on whether subport A or subport B or both are installed.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Migration instructions

[Jeremy Lavergne]

If there are missing dependencies, then the rebuild order may not be done 
correctly.

Trace mode or making a re-install list are the workarounds, as far as I know.

On Oct 17, 2014, at 13:56, James Berry  wrote:

> Given that the outdated pseudo port now returns all ports where the darwin 
> version doesn’t match the current version, is it true that Migration of ports 
> (following update of MacPorts) is as simple as:
> 
>   sudo port upgrade outdated
> 
> This has worked well for me in the last few OS updates, including for 
> Yosemite. If so, maybe the migration instructions here: 
> https://trac.macports.org/wiki/Migration should be updated?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)

[Jeremy Lavergne]

I’d assume (even though I’m not that Jeremy) that the clang on mavericks is 
newer and simply has more warnings as errors. The warning flags in the brackets 
are what were triggered: do they exist on the older compiler version and if so 
are they active? That’s probably all it is.

On Oct 14, 2014, at 21:22, Craig Treleaven  wrote:

> At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:
>> The Buildbot has detected a failed build on builder 
>> buildports-mavericks-x86_64 while building MacPorts.
>> Full details are available at:
>>  http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702
> 
> Can some kind person (Jeremy?) help me understand why the version of Clang on 
> the Mavericks buildbot is falling over while the Lion and MtnLion versions 
> don't even spit a warning?
> 
> Mavericks Clang errors out with the following:
> 
> test_dr.c:49:3: error: comparison of constant 12 with expression of type 
> 'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
>   BOZO_end_boolean(b_multiple_frame_rate)
>   ^~~
> ./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean'
> } while(!i_err && (s_decoded.name <= 12));  \
>~~ ^  ~~
> (Complete log from the Mavericks buildbot attached.)
> 
> If I understand correctly (always dicey given I'm not a C developer), this is 
> a unit test with (I guess) an awkward construct.  The thing is, Clang on 
> MtnLion doesn't complain at all on the same code.
> 
> What would be the best way to get past this?
> 
> Thanks,
> 
> Craig
> ___
> 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

after continue y/n, error out with nothing

[Jeremy Lavergne]

--->  Computing dependencies for kdepim4
The following dependencies will be installed: 
…
Continue? [Y/n]: 
Error: Follow http://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port kdepim4 failed

So.. that’s not helpful at all.




the log for kdepim4 shows a blank line:

DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
.:debug:main libkgapi has no conflicts
.:debug:main doxygen has no conflicts

DEBUG: dlist_eval: all entries in dependency list have unsatisfied 
dependencies; can't process


What happened there?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

buildbot trace mode

[Jeremy Lavergne]

Were considering enabling trace mode by default on the buildbots?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: doxygen dependencies

[Jeremy Lavergne]

Also seems that it needs wasysym from:
texlive-fonts-recommended

On Sep 6, 2014, at 11:02, Jeremy Lavergne  wrote:

> I’ve found that doxygen tries to use texlive-fontutils during build, and 
> gnumake will segfault out if it cannot access it.
> 
> Should this be added as a build dependency?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

doxygen dependencies

[Jeremy Lavergne]

I’ve found that doxygen tries to use texlive-fontutils during build, and 
gnumake will segfault out if it cannot access it.

Should this be added as a build dependency?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: deactivating dependency

[Jeremy Lavergne]

Also when there are conflicting ports: do we want to let the user deactivate 
them immediately?

--->  Computing dependencies for kdepim4
Error: Unable to execute port: Can't install libiodbc because conflicting ports 
are active: unixODBC

On Sep 6, 2014, at 9:59, Jeremy Lavergne  wrote:

> Should we consider changing this message to “also uninstall dependents?"
> 
> sudo port deactivate unixODBC
> Note: It is not recommended to uninstall/deactivate a port that has 
> dependents as it breaks the dependents.
> The following ports will break:
> php53-odbc @5.3.29_0
> php55-odbc @5.5.16_0
> Continue? [y/N]: 
> 
> ___
> 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

deactivating dependency

[Jeremy Lavergne]

Should we consider changing this message to “also uninstall dependents?"

sudo port deactivate unixODBC
Note: It is not recommended to uninstall/deactivate a port that has dependents 
as it breaks the dependents.
The following ports will break:
 php53-odbc @5.3.29_0
 php55-odbc @5.5.16_0
Continue? [y/N]: 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: extract multiple files with formats

[Jeremy Lavergne]

vim might be a good example on this.

distfiles-appendvim-7.4.16-fc19-breakindent.patch:breakindent


On Aug 26, 2014, at 13:27, Bradley Giesbrecht  wrote:

> Is something like this possible:
> 
> distfiles file1.gz file2.zip
> 
> 
> Regards,
> Bradley Giesbrecht (pixilla)
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: reinplace loop

[Jeremy Lavergne]

I’d use fs-traverse, filtering to just the specific files you’re after.

On Jul 13, 2014, at 16:18, Mark Brethen  wrote:

> In need to reinplace the CMakeLists file in each subdirectory, replacing 
> 'Mod/(subdirectory)' with 'lib/${name}/Mod/(subdirectory). How do you write a 
> tcl loop to accomplish this? (Avoids creating a multitude of patch files.)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbots

[Jeremy Lavergne]

Yes, oversight on my part. It only went into the “first” buildbot I went to, as 
I removed them from all the other requests ;-)

On Jul 1, 2014, at 10:13, Mojca Miklavec  wrote:

> PS: why would one put "qmake5-1.0.tcl qt5-1.0.tcl" to the list? Was
> that just an oversight or is that actually needed?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Question regarding +debug variant of KDE ports and qt4-mac

[Jeremy Lavergne]

You only need a stub if you’re renaming/replacing a variant to chain the 
requirement: it doesn’t really matter if it’s going away unless there is an 
active_variant dependent, in which case simply fix that first and wait two 
weeks.

On Jul 1, 2014, at 2:48, Marko Käning  wrote:

> The question is whether variants in general can be added temporally in order 
> to get rid of
> them once we've got MacPort changed according to Michael's proposal wrt 
> +debug?
> 
> Is it actually allowed to remove a port variant just like that or does it 
> require to leave
> some stub around in such a case? I hope we've got that documented somewhere 
> in the wiki,
> Guide or man pages?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbots

[Jeremy Lavergne]

Hi Mojca,

Some committers have accounts on the buildbots and are able to submit build 
requests on the site. I don’t mind being the person to handle rebuild requests 
like this, but you could also ask for a buildbot account ;-)

I'll put together a list of ports that need built from your changeset range and 
submit them to each buildbot, starting with clang-3.5.

On Jul 1, 2014, at 9:15, Mojca Miklavec  wrote:

> thanks a lot for bringing all the buildbots back to life.
> 
> However we now the commits between approximately 121538-121571 (exact
> numbers probably depend on the buildbot) haven't been built. I noticed
> a missing clang-3.5 which is one of those "building time monsters".
> 
> What's the proper way to force a rebuild of all "commits"?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Captcha error?

[Jeremy Lavergne]

Turns out, Shree is working on enabling captcha… my world is flipped upside 
down.

On Jun 19, 2014, at 9:11, Vincent  wrote:

> I’m trying to post an update to a ticket and I get this message : « Captcha 
> error », but I fail to see any Captcha in the original page. Any help would 
> be appreciated! :)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Captcha error?

[Jeremy Lavergne]

Pretty sure we don’t have a captcha.

On Jun 19, 2014, at 9:11, Vincent  wrote:

> I’m trying to post an update to a ticket and I get this message : « Captcha 
> error », but I fail to see any Captcha in the original page. Any help would 
> be appreciated! :)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [120643] trunk/dports/lang/eero-devel

[Jeremy Lavergne]

>From http://support.apple.com/kb/ta27005

The default shell (or command-line interface) used in Mac OS X 10.0 through 
10.2.8 is tcsh (with 10.3 and 10.4 it's bash). With Mac OS X 10.2 or later, 
other interactive shells are included, such as bash and zsh.

On Jun 7, 2014, at 12:15, Eric Gallager  wrote:

> Wasn't zsh actually already the default shell in OS X previously back
> in the early days of OS X, before Apple switched to bash? Or am I
> mis-remembering and getting it mixed up with tcsh?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDE3

[Jeremy Lavergne]

We can always revert your deletions, so I’d just go for it.

If there are any issues, it should start with a discussion of relevancy. As you 
point out KDE3 is beyond hope in many measures, but if there’s some very good 
reason that’s hidden then source control will show its magic.

On Jun 4, 2014, at 19:53, Nicolas Pavillon  wrote:

> Furthermore, it seems to not build presently on the later platforms (ticket 
> #41136). I would therefore start considering making the whole KDE3 suite 
> gradually obsolete unless there is some opposition after my mail. 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Troubles using port_binary_distributable.tcl

[Jeremy Lavergne]

Is this something we should have the scripts check before running? If the 
MacPorts version is newer than they’re expecting, demand the user download a 
fresh copy.

Or, perhaps, make the scripts a package that can be installed to libexec?

On May 20, 2014, at 19:01, Ryan Schmidt  wrote:

> All the scripts will need to be updated once MacPorts 2.3.0 is released.
> 
> port_binary_distributable.tcl was fixed to be compatible with both MacPorts 
> 2.2.x and 2.3.x so make sure you have the latest version of the script from 
> the repository.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbot failure for new ROOT ports

[Jeremy Lavergne]

> Could someone explain the reason for the failure in
> 
> 

error: forward declaration of class cannot have a nested name specifier
class AIDA::IAxis; // from AIDA

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Further Info for Missing Pings

[Jeremy Lavergne]

I’d hope they’d notice by now: it has yet to work for anyone but them.

Thanks for your effort, Shree. We do appreciate it :-)

On May 6, 2014, at 12:58, Shreeraj Karulkar  wrote:

> They just escalated the ticket back to me saying it works but I tested it 
> from my home and it is not working. I will attach your output to the ticket. 
> Sorry guys, I’ve been going back and forth with them for a couple of times 
> now. Will keep you updated.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Further Info for Missing Pings

[Jeremy Lavergne]

I checked TCP pings (ltr -VV -S 17.251.224.217, output attached). Do you think 
it’d be helpful to share it with the network people, and maybe see whether 
they've yet checked if:
 1 the blocking node/server has IP tables turned on
 2 ICMP is blocked / TTL is too high because it's going across an undesirable 
route?

Let us know if there’s anything we can do to help speed a resolution.

$ lft -VV -S 17.251.224.218
Layer Four Traceroute (LFT) version 3.6 ... (verbosity level 2)
Receiving on en1, transmitting on en1 as 10.0.1.171:53
Receive link type is EN10MB (1), skipping 14 bytes
Transmit Initial Sequence Number (ISN) will be 91024325
SENT TCP  TTL=1 SEQ=91024325 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024325 SRC=10.0.1.1 PTTL=1 PSEQ=91024325
SENT TCP  TTL=2 SEQ=91024326 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024326 SRC=10.23.192.1 PTTL=2 PSEQ=91024326
SENT TCP  TTL=3 SEQ=91024327 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024327 SRC=10.65.92.101 PTTL=3 PSEQ=91024327
SENT TCP  TTL=4 SEQ=91024328 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024328 SRC=207.172.15.148 PTTL=4 PSEQ=91024328
SENT TCP  TTL=5 SEQ=91024329 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024329 SRC=4.53.50.13 PTTL=5 PSEQ=91024329
SENT TCP  TTL=6 SEQ=91024330 FLAGS=0x2 ( SYN )
SENT TCP  TTL=7 SEQ=91024331 FLAGS=0x2 ( SYN )
SENT TCP  TTL=8 SEQ=91024332 FLAGS=0x2 ( SYN )
SENT TCP  TTL=9 SEQ=91024333 FLAGS=0x2 ( SYN )
SENT TCP  TTL=10 SEQ=91024334 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024330 SRC=4.69.140.98 PTTL=6 PSEQ=91024330
SENT TCP  TTL=11 SEQ=91024335 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024331 SRC=4.69.134.74 PTTL=7 PSEQ=91024331
RCVD ICMP SEQ=91024332 SRC=4.69.148.41 PTTL=8 PSEQ=91024332
RCVD ICMP SEQ=91024333 SRC=4.69.135.185 PTTL=9 PSEQ=91024333
RCVD ICMP SEQ=91024334 SRC=4.69.153.10 PTTL=10 PSEQ=91024334
SENT TCP  TTL=12 SEQ=91024336 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024335 SRC=4.69.152.135 PTTL=11 PSEQ=91024335
SENT TCP  TTL=13 SEQ=91024337 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=91024336 SRC=4.28.172.82 PTTL=12 PSEQ=91024336
SENT TCP  TTL=14 SEQ=91024338 FLAGS=0x2 ( SYN )
SENT TCP  TTL=15 SEQ=91024339 FLAGS=0x2 ( SYN )
SENT TCP  TTL=16 SEQ=91024340 FLAGS=0x2 ( SYN )
RCVD TCP  FLAGS=0x12 ( SYN ACK ) SEQ=1615477938 ACK=91024340 SRC=17.251.224.218 
PTTL=15 PSEQ=91024339
Port 80/tcp open; target attempted handshake.
SENT TCP  TTL=13 SEQ=91024341 FLAGS=0x2 ( SYN )
SENT TCP  TTL=14 SEQ=91024342 FLAGS=0x2 ( SYN )
SENT TCP  TTL=16 SEQ=91024343 FLAGS=0x2 ( SYN )
RCVD TCP  FLAGS=0x12 ( SYN ACK ) SEQ=2149391195 ACK=91024344 SRC=17.251.224.218 
PTTL=16 PSEQ=91024343
TTL LFT trace to packages.macports.org (17.251.224.218):80/tcp
 1  10.0.1.1 3.8ms
 2  10.23.192.1 9.7ms
 3  10.65.92.101 11.1ms
 4  tge0-1-0-0.border1.sbo.ma.rcn.net (207.172.15.148) 12.1ms
 5  xe-10-3-0.bar2.boston1.level3.net (4.53.50.13) 10.2ms
 6  ae-8-8.ebr1.newyork1.level3.net (4.69.140.98) 85.7ms
 7  ae-81-81.csw3.newyork1.level3.net (4.69.134.74) 83.7ms
 8  ae-82-82.ebr2.newyork1.level3.net (4.69.148.41) 84.1ms
 9  ae-2-2.ebr1.sanjose1.level3.net (4.69.135.185) 86.1ms
10  ae-81-81.csw3.sanjose1.level3.net (4.69.153.10) 83.0ms
11  ae-3-80.edge1.sanjose2.level3.net (4.69.152.135) 82.8ms
12  apple-compu.edge1.sanjose2.level3.net (4.28.172.82) 84.8ms
**  [neglected] no reply packets received from TTLs 13 through 14
15  [target open] packages.macports.org (17.251.224.218):80 85.4ms





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: macports or meld issue?

[Jeremy Lavergne]

>>> Not impressed with your download speeds.
>> 
>> You can thank Apple for crippling their servers: they promise to fix 
>> them--one day. In the mean time, you probably downloaded from a mirror 
>> overseas.
> 
> is it just the archives mirror where we don't have one in the US?
> 
> Do we know what the current mirror size requirements are? I just upgraded my 
> colocated host, so I can probably host a well-connected US mirror (at least 
> until Apple can get their act together on this), if that would be helpful.

>From what I saw, there are no mirrored binary archives for meld.

So he likely downloaded the source (412K) from some unfortunate location.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: Buildbots offline?

[Jeremy Lavergne]

Begin forwarded message:

> From: Craig Treleaven 
> Subject: Buildbots offline?
> Date: April 27, 2014 at 20:40:09 EDT
> To: macports-dev@lists.macosforge.org
> 
> For about 24 hours, I get a 503 "Service Temporarily Unavailable" message 
> trying to access https://build.macports.org/
> 
> Craig
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Welcome Our GSoC 2014 Students

[Jeremy Lavergne]

> I would like to suggest creating either new wiki pages or creating
> some subsections with the list of accepted GSOC projects over the
> years (and maybe a link to the official GSOC page). There is only a
> generic page, but no information about current and past projects.


http://trac.macports.org/wiki/SummerOfCodeArchive

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Any thoughts on changing configure...

[Jeremy Lavergne]

I remember “-dc” being used for mp_tarball_extract_cmd in place of “-d < “ for 
compat:
https://trac.macports.org/changeset/118736/trunk/base/aclocal.m4

That should not be forgotten in that ticket’s patch.

On Apr 24, 2014, at 13:11, Clemens Lang  wrote:

> Hi,
> 
>> See this ticket : https://trac.macports.org/ticket/43204#comment:12
>> Anyone? I'm ready to commit this up if there are no concerns.
> 
> I have no particularly strong feelings either way. But since this might
> be a regression in 2.3, you should probably merge the change back into
> the release_2_3 branch as well, if you commit it.
> 
> -- 
> Clemens Lang
> ___
> 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

Welcome Our GSoC 2014 Students

[Jeremy Lavergne]

Greetings all.

Clemens and I would like to introduce the Google Summer of Code 2014 students 
for MacPorts: Gaurav Bansal, Kyle Sammons and Shashwat Pandey.

Please join us in welcoming them to the team!


Gaurav will be with Bradley Giesbrecht (pixilla) working on pip2port. The 
project idea aims at generating portfiles for python packages in pip that are 
non- existent in MacPorts. Also, the idea aims to bring uniformity to the 
present system by automating the process of creating ports to make package 
names in Macports match with the ones in pip which is presently not applicable 
for each and every port. This can be summarized as – when a user runs a command 
such as pip2port  it returns the port file for that particular 
python-package.


Kyle has combined a lot of clean up proposals and will work with Michael 
Dickens (michaelld). The main thought behind this project is to combine 
multiple ideas that were listed on the wiki (and all had a similar theme of 
'cleaning-up') into one larger project with the end goal being improving the 
'port clean' command, and adding a 'brew doctor'-esque command.


Shashwat will be working on interactive mode for the port command with Rainer 
Müller (raimue). This project deals with building an interactive command line 
interface for the MacPorts port command. This will enable users to solve 
conflicts arising in various functions of MacPorts by giving an 
approval/decision on questions asked by the interactive console. Thus, the user 
experience will be improved as conflicts will be resolved automatically.

You can find more about their projects and how we work with Google Summer of 
Code on our wiki:
http://trac.macports.org/wiki/SummerOfCode

Thanks!

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Howto remove empty dirs in post-deactivate?

[Jeremy Lavergne]

>   # purge fetch-crl cache
>   delete [ glob ${prefix}/var/cache/fetch-crl/*.state ]

You like want to foreach the glob result (or map if its defined).

foreach {filename} [ glob ${prefix}/var/cache/fetch-crl/*.state ] {
delete $filename
}

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: textproc XML comprehensive update

[Jeremy Lavergne]

This. Reminding us on the dev list (sometimes repeatedly).

On Apr 15, 2014, at 20:34, Thomas Lockhart  wrote:

> What is the process for getting this to move forward either to incorporation 
> or to rejection?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

[Jeremy Lavergne]

Using verbose (port -v) might list out the types of dependencies.

On April 13, 2014 12:01:11 PM EDT, Brandon Allbery  wrote:
>On Sun, Apr 13, 2014 at 11:51 AM,  wrote:
>
>> On 13 Apr 2014, at 17:46 , Brandon Allbery 
>wrote:
>> > Looks like it's because it's a build dependency --- so, while the
>gtk2
>> port is what pulled it in, it is not needed at runtime.
>> Ahhh, I see.
>> Thanks for solving this mystery! :-)
>
>
>Well, this is still highlighting an inconsistency. In this case, I
>think
>it's between the actual record of dependencies in the package registry
>(produced by actually installing something) and the pre-recorded list
>of
>dependencies in the package index (usually downloaded along with the
>port
>tree)? That, or rdeps just ignores anything that isn't a runtime
>dependency.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to preserve patches to MacPorts base during "sudo port selfupdate"?

[Jeremy Lavergne]

You probably need add a local repo with higher priority, such as:
http://trac.macports.org/wiki/howto/SyncingWithSVN

Note the repo needs at least:
 dports/_resources/ for the PortGroups, and
 dports/devel/cmake/ for cmake

On Apr 10, 2014, at 16:02, mk-macpo...@techno.ms wrote:

> Hi MP devs,
> 
> currently I have to have patch [1] in place to be able to successfully 
> install qmake-based ports.
> 
> The problem is now that during "sudo port selfupdate” all these changes get 
> reverted.
> 
> How can I keep my needed patches for MacPorts base without the need to 
> re-patch base after the selfupdate call?
> 
> Greets,
> Marko
> 
> 
> 
> [1] https://trac.macports.org/ticket/41321
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: conflict between "portA +python33" and "portB +python33"

[Jeremy Lavergne]

The active_variants PortGroup can be used this way:
active_variants $depspec $required $forbidden

That forbidden section is likely what you’re after, inside a variant block.

On Apr 7, 2014, at 9:24, Mojca Miklavec  wrote:

> What is the most reasonable way to declare a conflict between "portA
> +pythonXY" and "portB +pythonXY"? The ports themeselves don't conflict
> and different python variants don't conflict either (portA +python33
> and portB +python34 works OK).
> 
> The problem is that both ports install files with the same name to
> $prefix/Library/Frameworks/Python.framework/Versions/X.Y/lib/pythonX.Y/site-packages
> when the same python variant is selected for both ports.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [118513] trunk/dports/devel/dbus

[Jeremy Lavergne]

We sort of relied on that mis-feature during the great x11/quartz divide, where 
only some dependencies had the variant but it needed to trickle down all the 
way to ensure it hit them all.

On Apr 3, 2014, at 18:22, Clemens Lang  wrote:

> I actually think this is a mis-feature, but it's not trivially solvable
> and I haven't thought of a good solution I'd implement yet.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: How do I cause standalone X11 apps to use MacPorts X11?

[Jeremy Lavergne]

>From the users list: some applications are pulling up the system stub X11 
>indicating that X11 is no longer available, even though MacPorts was used to 
>install xorg-server.

Is there a recommended solution to get MacPorts’ X11 to be used instead of the 
system stub?

Begin forwarded message:

> From: Kevin Reid 
> Subject: Re: How do I cause standalone X11 apps to use MacPorts X11?
> Date: March 26, 2014 at 13:12:54 EDT
> To: MacPorts Users 
> 
> On Mar 26, 2014, at 10:07, Jeremy Lavergne  wrote:
> 
>> This might really depend on the application: is it checking for x11 or 
>> giving up based on the OS?
> 
> The dialog does not come from the application but from the system-provided 
> X11.app (this is observable by Dock/menu bar) which is a nonfunctional stub 
> (this is what my research says).
> 
> It sounds like the assumption is that when you install third-party X11 as 
> instructed by the dialog, it will _replace_ the system-provided X11. But 
> MacPorts doesn't replace system files as a rule -- I'm looking for a solution 
> which fits into MacPorts's way of working.
> 
> -- 
> Kevin Reid  <http://switchb.org/kpreid/>
> 
> ___
> macports-users mailing list
> macports-us...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

buildbot emails

[Jeremy Lavergne]

Hello Shree.

I wanted to point out a few possible problems I’ve noticed about emails from 
the buildbot:
 * mixed-case headers
 * too many recipients

I suspect all headers should be title case while some of them are not e.g. 
Return-Path versus current Return-path:
Return-path: 
Authentication-results: symauth.service.identifier
Envelope-to: jeremy@...
Delivery-date: Sun, 23 Mar 2014 23:41:22 -0400
Content-transfer-encoding: base64
Content-type: text/plain; charset=utf8
Message-id: <20140324034119.ab017140...@build.macports.org>

When there are many builds, the recipient list can be quite large. Email 
services tend to think a huge, sorted list of recipients is spammy. Could we 
possibly become BCC on the email? Or one email generated per recipient?

Thanks for looking into these.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts automake and python

[Jeremy Lavergne]

Reverted and revbumped: r118111.

On Mar 22, 2014, at 20:28, Eric A. Borisch  wrote:

> On Thursday, March 20, 2014, David Evans  wrote:
> On 3/20/14 3:01 PM, Adam Mercer wrote:
> > On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch  
> > wrote:
> >
> >> What was broken that needed fixing (by the original change)? Is there a
> >> particular port that needed the change? Is there another way to fix it
> >> without modifying automake?
> >>
> The answer is yes, any port that uses AM_PYTHON_PATH to discover the
> Python install
> prefix will fail on MacPorts (or any other installation of Python into a
> non-standard path)
> without intervention and there are quite a few.
> 
> In the past this has been handled typically by applying a similar patch
> to the configure file
> provided with each project being ported.  This works and the patch here
> does not interfere
> with this because the configure file is not being regenerated.
> 
> However, increasingly, ports need to use autoreconf or even autogen.sh
> to regenerate configuration
> files prior to build for some other reason (intltool perl issues for
> instance).  This again effects a
> large number of ports.  In this case, patching of the configure file is
> impractical and the required
> patch to configure.ac amounts to replacing AM_PYTHON_PATH with custom
> code that is often
> package specific.  This change to automake makes that unnecessary.
> 
> Have to head home now but will follow up later this evening.  In the
> meantime, please don't revert
> this change on your own as there are many ports that WILL be broken.
> If, we, as a group decide
> that that is the preferred approach, I will make the change after the
> effected ports have been re-written.
> 
> Thanks
> 
> PS What ever happened to the doctrine that if you mix code in other
> installation prefixes with MacPorts
> ports, all bets are off and results are not guaranteed?
> 
> Dave,
> 
> Any updates on the ports that were fixed / simplified by this patch? I've 
> heard it said, and seen multiple requests for "which ones?" and "where are 
> the tickets?"
> 
> Can you please shed some light on this?
> 
> Thanks,
>   Eric 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: debug variants built by buildbots as well?

[Jeremy Lavergne]

Can you do your updates to a users/contribs version with debug on by default, 
then if it passes update the normal dports version?

On Mar 22, 2014, at 13:05, mk-macpo...@techno.ms wrote:

> On 22 Mar 2014, at 18:01 , Ryan Schmidt  wrote:
>> On Mar 22, 2014, at 11:51, mk-macpo...@techno.ms wrote:
>>> do MacPorts’ buildbots also build all debug variants of the various ports, 
>>> or only the default variant of every port?
>> Only default variants.
> I was afraid to hear that. :-)
> Had some hope that things had changed since I was last busy on that front.
> 
> This means, I’d have to go back to build from scratch most of the stuff if I 
> want debug variants of certain ports…
> Sniff.
> 
> Would be cool if there was a buildbot which would build all the debug 
> variants… :-D
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

[Jeremy Lavergne]

Google shows there are plugins available.

Is there somethign specific you’re interested in seeing?

On Mar 18, 2014, at 22:15, Mark Anderson  wrote:

> Does our install of Trac have any public APIs (XMLRPC, REST, SOAP, whatever)?
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: redis port update

[Jeremy Lavergne]

Completed
https://trac.macports.org/changeset/117933

On Mar 17, 2014, at 10:22, Ivan Larionov  wrote:

> Could someone take a look at https://trac.macports.org/ticket/42583 please
> 
> And please close https://trac.macports.org/ticket/39434 since it will be done 
> by this patch as well.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

[Jeremy Lavergne]

Email is not the way to do voting >_<

On March 16, 2014 9:17:37 PM EDT, Blair Zajac  wrote:
>
>On Mar 16, 2014, at 11:52 AM, mk-macpo...@techno.ms wrote:
>
>> On 16 Mar 2014, at 19:42 , Sean Farley  wrote:
>>> I would suggest Mercurial.
>> 
>> +1
>> 
>> But, in order to avoid any flamewars: I’d be going for git as well,
>if it would win in an election. :-)
>
>Since people are stating a preference between hg and git, I’ll throw in
>my hat and vote for git.
>
>Blair
>
>___
>macports-dev mailing list
>macports-dev@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #42727: Server certificate verification failed: issuer is not trusted (https://svn.macports.org

[Jeremy Lavergne]

I believe Clemens was attempting to trigger a connection to cause an 
interactive request to accept the certificate.

You might try his command again, but switch “info” for “update”. You will need 
to be cd'd inside a repository, but otherwise it should walk svn through a 
connection which prompts certificate acceptance.



If that still doesn’t work, I’m fairly confident what you’ve sent is the 
standard directory structure for .subversion/auth/.

The svn.simple file should serialized key/value store for authentication only. 
If the buildbots don’t use a specific svn account (e.g. read-only/guest access) 
then it likely doesn’t contain what we’re after.

The .subversion/server file does have a few CA-related sections, but I’m unsure 
if that’s how we want to set things.
###   ssl-authority-filesList of files, each of a trusted CA
###   ssl-trust-default-ca   Trust the system 'default' CAs
###   ssl-client-cert-file   PKCS#12 format client certificate file
###   ssl-client-cert-password   Client Key password, if needed.
###   ssl-pkcs11-providerName of PKCS#11 provider to use.

Clemens has likely turned in for the night, but we will likely hear more 
tomorrow if the simple switch from “info” to “update” doesn’t do the trick.


On Mar 10, 2014, at 20:34, Shreeraj Karulkar  wrote:

> eneight-slave:~ root# ls -ld  /buildbot/ports-slave/.subversion/auth/
> drwx--  6 buildbot  staff  204 Mar  7  2012 
> /buildbot/ports-slave/.subversion/auth/
> teneight-slave:~ root# cd !$
> cd /buildbot/ports-slave/.subversion/auth/
> teneight-slave:auth root# ls
> svn.simplesvn.ssl.server
> svn.ssl.client-passphrase svn.username
> teneight-slave:auth root# ls -l
> total 0
> drwxr-xr-x  2 buildbot  staff   68 Mar  7  2012 svn.simple
> drwxr-xr-x  2 buildbot  staff   68 Mar  7  2012 svn.ssl.client-passphrase
> drwxr-xr-x  4 buildbot  staff  136 Apr  4  2012 svn.ssl.server
> drwxr-xr-x  2 buildbot  staff   68 Mar  7  2012 svn.username

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: flags for base's configure script: should there be more or fewer? (was "Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl")

[Jeremy Lavergne]

>From the article:
"Being called an inclusionist or deletionist can sidetrack the issue from the 
actual debate,[21]”

On Mar 7, 2014, at 17:06, Eric Gallager  wrote:

> https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: commit rights ...

[Jeremy Lavergne]

portmgr@ could grow to include another volunteer though :-P

Maybe it should include someone as influential as Clemens.

On Feb 28, 2014, at 15:42, Clemens Lang  wrote:

> IMO, now is as good a time as any. Why delay it if it's finished earlier? Of 
> course portmgr@ are all volunteers, too.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Editing www/index.php Not Going to Site?

[Jeremy Lavergne]

I made an edit to the www/index.php, but it doesn’t seem to have deployed. Is 
immediate deployment expected?

I’ve got an email ready to send to the admins if this is unexpected behavior.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: pip2port

[Jeremy Lavergne]

The goal of pip2port is to generate a Portfile for a give Python package. 
MacPorts learns about packages from Portfiles, and makes them available by 
following commands and variables contained in them. Portfile development is 
covered in the guide:
http://guide.macports.org/#development

Once you understand what all goes into the Portfiles, you can see how the 
skeleton Portfile generator works:
http://trac.macports.org/browser/contrib/portfile-gen/portfile-gen

pip2port would go even further than this skeleton.

Most skeleton “replaceme” values can be found in the setup script included in 
most python packages:
http://docs.python.org/2/distutils/setupscript.html

Similarly, you’ll be able to pull out some python version dependency as well as 
module dependencies. You’ll want to get to know the Python PortGroup 
(effectively an include used in Portfiles) to see what options are available 
for handling various nuances in Python packages.

pip2port should complete the majority of a Portfile for the majority of Python 
packages.

On Feb 27, 2014, at 7:07, Gaurav Bansal  wrote:

> I would like to seek the mentors help regarding the project(s)
> Read packages from Python's PIP (pip2port)
> 
> which has been proposed for the GSoC as my skill set lies perfectly in match 
> with the required skill set.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: revision bump?

[Jeremy Lavergne]

Correct.

It keeps these archives locally, regardless of the ability to distribute them.

On Feb 20, 2014, at 14:07, Blair Zajac  wrote:

> Just to be clear, my understanding is that a buildbot will only attempt a 
> rebuild of a port if there is no binary archive for it when the Portfile 
> changes (with no rev bump).  If there’s a binary archive, then it won’t 
> attempt a rebuild.  Is this correct?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildbot and binary archives ...

[Jeremy Lavergne]

packages.macports.org/PACKAGENAME/

so, for pspp-devel for example, packages.macports.org/pspp-devel/

Perhaps it’s the license of the package that prevents the binaries? The logs 
area available on the buildbot master for the mavericks post slave:
https://build.macports.org/buildslaves/apple-mavericks-x86_64-ports

In base, the Tcl script that does the license:
http://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl

On Feb 20, 2014, at 9:54, Peter Danecek  wrote:

> from a user report I realised that there is probably no binary archive 
> available for Maverick of one port I am maintaining.
> 
> I am now, wondering if there is a way to obtain more information, e.g.
> - Which binary archives exist and when these were produced?
> - Are there problems with the build on the buildbot?
> - Can I get the main.log of these builds?
> - etc.
> 
> Note that I am maintainer, but have no commit rights. From what I understand 
> these info might be available to committers. 
> 
> Is there a way to access them as maintainer as well?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

[Jeremy Lavergne]

Eh, then prior to switching symlinks you ought to port unload all installed 
packages and then deactivate them, then switch and install and load all those 
packages.

At that point, it might take as long as a reboot depending on your build: but 
you should achieve the same outcome.

On Feb 16, 2014, at 16:40, mk-macpo...@techno.ms wrote:

> Yes, that’s possible, but to "M$ Windows"-like! ;-)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

[Jeremy Lavergne]

You could reboot after each switch: anything that’s no longer linked into 
/opt/local won’t load, and everything else will launch the appropriate version.

On Feb 16, 2014, at 16:23, mk-macpo...@techno.ms wrote:

> There is still one big problem with all of this, which is that a ton of 
> daemons and agents might be running as root or as another user for a given 
> MacPorts installation.
> 
> In case I want to swap in another installation, say a debug installation, I 
> would have to make sure that all these services would be restarted 
> gracefully! That means I would have to search using launchctl for all those 
> services, cancel them with the correct credentials and then restart all of 
> them accordingly.
> 
> What a project. :-/
> 
> Wondering whether this is actually doable just using launchctl as root…
> 
> (In the past I hadn’t been careful enough regarding all this, which lead to 
> quite a bit of trouble with dbus mostly!)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

[Jeremy Lavergne]

You might consider linking different directories to /opt/local for your various 
parallel installs. You’d similarly link other directories you need as well. The 
whole operation could be part of a bash function or alias to replace all the 
links.

But I am assuming macports can handle being inside a symlink since I recall it 
can operate across drives.

On Feb 16, 2014, at 15:40, mk-macpo...@techno.ms wrote:

> The thing is now that I don’t want to use anything else than /opt/local for 
> all my parallel installs, in order to be able to use binary installs!

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[Jeremy Lavergne]

You probably need to run trunk for access to POST, which isn’t available in a 
release yet.

On Feb 9, 2014, at 14:40, mk-macpo...@techno.ms wrote:

> Hi Clemens,
> 
> I installed mpstats but when trying to submit my installation details I got 
> this error thrown:
> —
> $ /opt/local/libexec/mpstats submit
> Submitting to http://stats.macports.neverpanic.de/submissions
> Error: bad option "post": must be fetch, isnewer, or getsize
>while executing
> "curl post "submission\[data\]=$json" $stats_url"
> —
> 
> What can be done about this?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbot out of disk space?

[Jeremy Lavergne]

Ah, now there’s a good point.

On Feb 5, 2014, at 21:57, Joshua Root  wrote:

> Even if you can't be bothered getting a buildbot account, why would you
> rev bump when literally any change to the portfile will trigger a build?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbot out of disk space?

[Jeremy Lavergne]

Not everyone has accounts for this, so that’s not really ideal. Revbumping (a 
change just went in so why not revbump it again?) would be fine.

On Feb 5, 2014, at 20:14, Ryan Schmidt  wrote:

> Don't revbump a port exclusively to have the buildbot rebuild it. If you just 
> need to buildbot to rebuild a port, there's a form in the buildbot interface 
> you can fill out to do that.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: Buildbot out of disk space?

[Jeremy Lavergne]

Shreeraj is taking the build slave offline to increase it’s disk space.

If you’re depending on it for a build, consider resubmitting (possibly 
revbump?) after it’s back.

Begin forwarded message:

> From: Shreeraj Karulkar 
> Subject: Re: Buildbot out of disk space?
> Date: February 5, 2014 at 20:04:50 EST
> To: Jeremy Lavergne 
> 
> i’m looking into it. I’ve asked people if downtime is possible? For me to 
> increase the disk space to the VM.
> Shree 
> 
> On Feb 5, 2014, at 4:32 PM, Jeremy Lavergne  
> wrote:
> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: David Evans 
>>> Subject: Buildbot out of disk space?
>>> Date: February 5, 2014 at 19:28:25 EST
>>> To: MacPorts Dev 
>>> 
>>> An attempted build of gimp2 just failed on the SL build bot with a string 
>>> of errors like this (in this case while extracting poppler):
>>> 
>>> x ./opt/local/lib/libpoppler-glib.dylib
>>> x ./opt/local/lib/libpoppler-glib.la
>>> x ./opt/local/lib/libpoppler.44.dylib
>>> x ./opt/local/lib/libpoppler.a: Write failed: No space left on device: No 
>>> space left on device
>>> x ./opt/local/lib/libpoppler.dylib: Can't create 
>>> 'opt/local/lib/libpoppler.dylib': No space left on device
>>> x ./opt/local/lib/libpoppler.la: Write failed: No space left on device: No 
>>> space left on device
>>> 
>>> See build log at
>>> 
>>> https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/24500/steps/compile/logs/stdio
>>> 
>>> Are we running out of disk space? 
>>> 
>>> 
>>> 
>>> ___
>>> 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

MacPorts Participation in GSoC 2014

[Jeremy Lavergne]

Google has once again announced their Google Summer of Code for 2014.
They have begun accepting mentoring organizations since February 3,
continuing until February 14. In GSoC students get money to work for an
open source project over the summer. MacPorts has participated since
2007 with good results (13 successful tasks out of 16 total) [1].

Any ideas you want to see implemented?

Would you like to mentor a project?

Coming up with ideas has always been part of the application for a
Mentoring Organization [2]: edit the wiki with your additions!

Students applying to GSoC may be starting college without any degree
yet. Therefore it's better for us to offer easier tasks to attract more
students as the slot count for our tasks assigned by Google is
influenced by the number of applications. Of course easier tasks are
also less prone to fail.

Over the years, most of the tasks marked with an easy to medium
challenge level have been implemented.

Also, it is now our policy that GSoC additions to MacPorts’ base
are migrated to trunk and into a release. Prior to this change,
almost no work has happened on the GUI or MacPorts
Web App outside of the Summer of Code tasks.

The wiki has the remainder of the questions and answers
from last year [3].

 1 https://trac.macports.org/wiki/SummerOfCodeArchive
 2 http://trac.macports.org/wiki/SummerOfCode#Tasks
 3 http://trac.macports.org/wiki/SummerOfCodeOrgApplication

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev