Re: MacPorts 2.3.0-rc1 now available for testing (WAS Re: Call for Testers: MacPorts Statistics)

[Clemens Lang]

Hi,

> I needed to run
> ---
> sudo chmod -R o+r /opt/local/libexec/macports/lib/tcllib1.15
> ---
> to make stats submission work.
> 
> 
> Is the non-readability of /opt/local/libexec/macports/lib/tcllib1.15
> intentional, or is it a bug?

That certainly is a bug. The question is, how did it happen. Did you use
the installer? Did you run selfupdate?

I'm pretty sure we actually fixed the Makefiles to correctly set the
permissions after the beta, so unless you had that folder created during
beta when this was still broken, I don't think it could be caused by our
current build scripts.

But then again, maybe somebody should re-check. I'll see if I have some
time this weekend to do that.

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

Re: MacPorts 2.3.0-rc1 now available for testing (WAS Re: Call for Testers: MacPorts Statistics)

[Marko Käning]

Turns out that I ran into this as a normal user:

On 13 May 2014, at 00:14 , mk-macpo...@techno.ms wrote:
> At least these two were needed here on my end:
> —
> $ sudo chmod o+r /opt/local/libexec/macports/lib/tcl8.5/.
> $ sudo chmod o+r /opt/local/libexec/macports
> —
> but it looks like /opt/local/libexec/macports/lib/tcllib1.15
> —
> drwxr-x--x 111 root admin3774 May 11 16:22 tcllib1.15
> —
> is another candidate.

I needed to run
---
sudo chmod -R o+r /opt/local/libexec/macports/lib/tcllib1.15
---
to make stats submission work.


Is the non-readability of /opt/local/libexec/macports/lib/tcllib1.15 
intentional, or is it a bug?

I am running
---
$ port version
Version: 2.3.1
---

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

Re: Call for Testers: MacPorts Statistics

[Marko Käning]

Hi Arno,

On 30 May 2014, at 02:54 , Clemens Lang  wrote:
> Nothing besides a commit doing that. If any committer reads this, feel
> free to do it right away before I find time to do it myself.

I’ve just committed it to the sysutils category.

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

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

Hi,

> Now that 2.3 is out, is trunk still a requirement for mpstats?

No.

> 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?

No, but you need 0.1.4 with MacPorts 2.3.0.


> What needs to happen before mpstats is added to the main tree?

Nothing besides a commit doing that. If any committer reads this, feel
free to do it right away before I find time to do it myself.

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

Re: Call for Testers: MacPorts Statistics

[Arno Hautala]

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: MacPorts 2.3.0-rc1 now available for testing (WAS Re: Call for Testers: MacPorts Statistics)

[MK-MacPorts]

At least these two were needed here on my end:
—
$ sudo chmod o+r /opt/local/libexec/macports/lib/tcl8.5/.
$ sudo chmod o+r /opt/local/libexec/macports
—
but it looks like /opt/local/libexec/macports/lib/tcllib1.15
—
drwxr-x--x 111 root admin3774 May 11 16:22 tcllib1.15
—
is another candidate.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts 2.3.0-rc1 now available for testing (WAS Re: Call for Testers: MacPorts Statistics)

[MK-MacPorts]

Hi Joshua,

when trying to run mpstats submit I met a problem which is caused by the 
current RC1.

On 11 May 2014, at 23:44 , Clemens Lang  wrote:
> 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?
—
$ ls -la /opt/local/libexec/macports/lib/tcl8.5/.
—
reports 
—
drwxr-x--x  17 root admin578 May 11 16:22 .
—

> 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.
Well, I was actually using the current Mavericks-PKG from [1] to install the 
RC1 version!

So, it looks like already the permissions IN THE PKG aren’t set correctly!

Greets,
Marko


P.S.: Clemens just verified "drwxr-x--x ./opt/local/libexec/macports” as well!


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

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

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

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

Hi Clemens,

this is what I get since I installed the current RC:
—
$ /opt/local/libexec/mpstats submit
Error: couldn't read file 
"/opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl": no such file 
or directory
—

Luckily I had seen http://trac.macports.org/changeset/119760 so that I checked 
out your user repo locally and installed mpstats version 0.1.4_0 from there 
(before I had used your tar install hack). Unfortunately I cannot submit 
anything now:
—
$ /opt/local/libexec/mpstats submit
couldn't read directory "/opt/local/libexec/macports/lib/tcl8.5/": permission 
denied
while executing
"glob -directory $dir -join -nocomplain  * Resources Scripts pkgIndex.tcl"
(procedure "::tcl::MacOSXPkgUnknown" line 26)
invoked from within
"::tcl::MacOSXPkgUnknown ::tclPkgUnknown macports 0-"
("uplevel" body line 1)
invoked from within
"uplevel 1 $original [::linsert $args 0 $name]"
(procedure "::tcl::tm::UnknownHandler" line 114)
invoked from within
"::tcl::tm::UnknownHandler  {::tcl::MacOSXPkgUnknown ::tclPkgUnknown} macports 
0-"
("package unknown" script)
invoked from within
"package require macports"
(file "/opt/local/libexec/mpstats" line 43)
—

I am here on Mavericks running port 2.3.0-RC1.

Shall I file a ticket for that?

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

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

Hi,

On 30.04.2014, at 09:45, mk-macpo...@techno.ms wrote:

> I am not sure whether it had been already said, but I think it would be nice 
> to let query list also generate links to the port’s home URL, which holds 
> just as well for the MacPorts port list!

Patches welcome, I guess? The source is right there on 
http://trac.macports.org/browser/branches/gsoc11-statistics/stats-server and 
http://trac.macports.org/browser/trunk/www/ports.php and the modification 
shouldn’t be very difficult.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

I am not sure whether it had been already said, but I think it would be nice to 
let query list also generate links to the port’s home URL, which holds just as 
well for the MacPorts port list!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts Statistics

[Bradley Giesbrecht]

On Mar 28, 2014, at 7:03 PM, Craig Treleaven  wrote:

> Branching the subject a little, perhaps, but...
> 
> Looking at the statistics page for a particular port, say libpng:
> 
> http://stats.macports.neverpanic.de/categories/22/ports/2455
> 
> This has a lot of information that a user might be interested in before 
> installing a port.  Right now, the port search page on the web leads to the 
> Portfile, eg:
> 
> https://trac.macports.org/browser/trunk/dports/graphics/libpng/Portfile
> 
> which isn't the prettiest advertisement for a piece of software.
> 
> To me, the web search should give the potential user enough information to 
> decide if whether to install the package or not.  A rough draft would be:
> 
> =
> From Portfile:
> -port/subport name  (link to Portfile)
> -categories
> -version/revision
> -long_description
> -variants (list with descriptions)
> -homepage (as link)
> -license
> -platforms
> -supported_archs
> -dependencies (as links to other port pages; bonus marks if it could
> link to an rdeps graph!)
> 
> From statistics:
>> # reported installs
> -requested/   last week, 1 month ago, 1 year ago
> -installed as dependency  /   last week, 1 month ago, 1 year ago
> -rank of reported installs, requested, last week:  xxx of 18,312
> -link to page with more detailed statistics
> 
> From buildbots or package server (if possible):
>> Dates of most recent builds
> -version built   /   Mavericks,  Mtn Lion,  Lion,  Snow Leopard
> Eg:
> 1.2.3_4  yesterday   yesterday  failed unsupported
> (indicator if unsuccessful, not supported on that OS)
> =
> 
> I don't know if the last section is even possible.  Would likely require the 
> buildbots to update a database at the end of each build?
> 
> Thoughts?


I like the idea. I'm sure this is implied by your above text but it might be 
nice to have the build bots have mpstats installed by default to participate in 
the statistics.


Regards,
Bradley Giesbrecht (pixilla)

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

Re: MacPorts Statistics

[Craig Treleaven]

Branching the subject a little, perhaps, but...

Looking at the statistics page for a particular port, say libpng:

http://stats.macports.neverpanic.de/categories/22/ports/2455

This has a lot of information that a user might be interested in 
before installing a port.  Right now, the port search page on the web 
leads to the Portfile, eg:


https://trac.macports.org/browser/trunk/dports/graphics/libpng/Portfile

which isn't the prettiest advertisement for a piece of software.

To me, the web search should give the potential user enough 
information to decide if whether to install the package or not.  A 
rough draft would be:


=
From Portfile:
-port/subport name  (link to Portfile)
-categories
-version/revision
-long_description
-variants (list with descriptions)
-homepage (as link)
-license
-platforms
-supported_archs
-dependencies (as links to other port pages; bonus marks if it could
link to an rdeps graph!)

From statistics:

# reported installs

-requested/   last week, 1 month ago, 1 year ago
-installed as dependency  /   last week, 1 month ago, 1 year ago
-rank of reported installs, requested, last week:  xxx of 18,312
-link to page with more detailed statistics

From buildbots or package server (if possible):

Dates of most recent builds

-version built   /   Mavericks,  Mtn Lion,  Lion,  Snow Leopard
Eg:
1.2.3_4  yesterday   yesterday  failed unsupported
(indicator if unsuccessful, not supported on that OS)
=

I don't know if the last section is even possible.  Would likely 
require the buildbots to update a database at the end of each build?


Thoughts?

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

Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)

[Mojca Miklavec]

On Mon, Mar 24, 2014 at 11:31 PM, Clemens Lang wrote:
> Hi,
>
>> It would probably make sense to discuss and collect different ideas
>> somewhere (it could be Trac, but it's probably suboptimal at this
>> early stage of brainstorming where lots and lots of ideas could be
>> discussed, prioritized, written down, ...).
>
> I think we can keep discussing things on the lists. I moved the
> discussion to -dev and Bcc'd the -users list to keep anybody who wants
> to follow up on this informed. This really is a -dev discussion and I
> know some devs who hardly read -users.

Ouch. I actually failed to notice that the whole discussion was taking
place on the users mailing list.

> I have created a wiki page I will update from time to time with good
> ideas to prevent them from getting lost somewhere in the mail archive.
> Feel free to edit the page, add your comments, etc:
>   https://trac.macports.org/wiki/StatisticsIdeas

Thank you.

>> Just curious: if the user has two separate MacPorts installations and
>> installs mpstats on both – that would submit the statistics under two
>> different IDs, right?
>
> Yes. However, since mpstats requires a launchd plist, the installations
> would probably conflict on the path of this plist. Suggestions to solve
> this very welcome.

Depending on which names are allowed (I didn't check), MacPorts could
add hardcoded prefix, so instead of
/Library/LaunchDaemons/org.macports.mpstats.plist
one could have something like
/Library/LaunchDaemons/org.macports.opt_local.mpstats.plist
/Library/LaunchDaemons/org.macports.Users_me_macports.mpstats.plist

(One could still get conflicting names by installing MacPorts to
prefix=/opt_local, but I guess there would be other similar problems
related to that as well.)

But that should then apply to all ports.

> Speaking of which, it might also be worth submitting
>   default_prefix: [true, false].

Interesting idea.

While it's not directly useful for port authors, it would indeed be
nice to have.

>> (It would probably be nice if MacPorts would allow installing
>> dependencies to allow running the app locally without much hassle. The
>> app needs rails 3.2.)
>
> I agree – if somebody would like to do some ruby porting, please go
> ahead.

We probably need a separate discussion for that.

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

Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)

[Clemens Lang]

Hi,

> It would probably make sense to discuss and collect different ideas
> somewhere (it could be Trac, but it's probably suboptimal at this
> early stage of brainstorming where lots and lots of ideas could be
> discussed, prioritized, written down, ...).

I think we can keep discussing things on the lists. I moved the
discussion to -dev and Bcc'd the -users list to keep anybody who wants
to follow up on this informed. This really is a -dev discussion and I
know some devs who hardly read -users.

I have created a wiki page I will update from time to time with good
ideas to prevent them from getting lost somewhere in the mail archive.
Feel free to edit the page, add your comments, etc:
  https://trac.macports.org/wiki/StatisticsIdeas

> Below I have written down a few issues that would probably be nice to
> fix before the release of 2.30 (= before encouraging more people to
> install and submit statistics).

First off: We don't have to deploy this immediately with the 2.3 release.
2.3 only ships the requirements to get this done, but we can still wait
a few weeks before committing the mpstats port.

> - Would it be possible to configure Clemens' server/DNS to use
> something like http(s)://stats.macports.org even if it's not hosted on
> Apple servers?

Yeah, I consider this a necessity before deploying the system. I made
sure the config file that contains the URL is installed and can be
overwritten by the mpstats port, though.

> - When the user upgrades to 2.3.0 (or installs MacPorts from scratch),
> it would be nice to show a short notice saying something like "You are
> welcome to participate in anonymous collection of statistics of
> installed ports by running 'sudo port install mpstats'. See
> http:// for more details." So that every user would see the
> notice once for each major upgrade. (No notice if mpstats is already
> activated.)

I think we should create a generic notification mechanism for that, e.g.
by putting files into trunk/dports/_messages/ with a header like:

<= 2.3.0
  && !port::installed(mpstats)
delay_until_reqs_fulfilled: yes
title: MacPorts now has statistics!
---
Put your text here
EOF

Then, after selfupdate, base should check for the existence of new files
(or re-evaluate unread messages that have delay_until_reqs_fulfilled set)
and display a message like
 ---> You have %d new messages. Run `port messages' to read them.
When `port messages' is run, it should display the messages one after
another (possibly using less(1)) and offer to mark them read. It should
also give a list of past messages.

> Some suggestions for changes in the format of file that gets submitted
> (optimally this should be done before a lot of people start submitting
> statistics):
> 
> - Add a field stating the version of file. In case that the format
> changes in future, it would be nice to still be able to handle
> submissions from users running the older version of MacPorts.

I agree.

> - Add a field '"requested": true' for requested ports (even if the
> application isn't yet able to display any useful statistics related to
> that, it will be easier to change the app in the future than to
> convince everyone to apply the fix).

I agree.

> - Variants are currently submitted as a plain string:
> "variants": "biosig + python27 +";
>   it would be a lot cleaner to use a list instead:
> "variants": ["biosig", "python27"]

Completely agree, too.

> - I would remove "gcc_version" from submitted data (even though it
> doesn't hurt, so it can just as well stay).

Yeah, that should be replaced with the version of the Command Line Tools.
We can get that using pkgutil --file-info /usr/bin/make

> - The program submits:
> "os_arch": "i386",
> "build_arch": "x86_64",
>   I don't know if it's just me, but what exactly is the point of
> "os_arch"? It's interesting to distinguish between ppc/i386/x86_64;
> but why is os_arch "i386" important?

It's meant to show us the CPU architecture, but it should really
distinguish x86_64 and i386-only CPUs, because that information might
be helpful in the future.

> - The program submits the OS X version as 10.7/10.8/10.9. Are there
> cases when having the patch level available would be useful? (I don't
> think so, but I'm asking just in case.)

I don't think that's very useful, especially because we'd have to
re-aggregate the data in the web interface later.

> Just curious: if the user has two separate MacPorts installations and
> installs mpstats on both – that would submit the statistics under two
> different IDs, right?

Yes. However, since mpstats requires a launchd plist, the installations
would probably conflict on the path of this plist. Suggestions to solve
this very welcome.
Speaking of which, it might also be worth submitting
  default_prefix: [true, false].

> I didn't check it yet, but I guess that there are no IPs stored in the
> database anyway (or at least it would make sense if they weren't).

Correct, the database doesn't contain any IPs.

> I w

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

Hi,

> I see your point, but that’s probably something which might occur more often
> than we think now, effectively making it impossible to find actually
> existing ports. Probably it would make sense to handle cases like that
> differently?!

Yes, you're absolutely right: https://trac.macports.org/changeset/116902.

> And, do I need trunk to be able to run mpstats?

Yes. 2.2.1 doesn't have "curl post" from pextlib, which is needed to send the 
data.

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

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

On 09 Feb 2014, at 22:12 , Clemens Lang  wrote:
> but it's really the port that's to blame here.

I see your point, but that’s probably something which might occur more often 
than we think now, effectively making it impossible to find actually existing 
ports. Probably it would make sense to handle cases like that differently?!

And, do I need trunk to be able to run mpstats?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

> The problem here is that the aqbanking Portfile violates lint:
Oh, good to know.
Can be fixed. :)
Will do so right away.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

(re-sent to the list)

The problem here is that the aqbanking Portfile violates lint:

:) clemens@cSchlepptop:[…]/dports/devel/aqbanking$ port lint
--->  Verifying Portfile for aqbanking
Error: Missing required variable: categories
Warning: no license set
--->  1 errors and 1 warnings found.

That causes the "categories" property of the aqbanking port to be nil and thus 
doesn't match any path router in the webinterface, effectively causing the 404 
you're seeing. I agree this fails in an unexpected way, but it's really the 
port that's to blame here.

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

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

Hi Clemens,

I am seeing a page stating this:

—
The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved.
—

in case I try to search for a non-existing or replaced_by port, e.g. [1].

I guess one could rather state on this page that the port is replaced_by or 
simply non-existing?!

Greets,
Marko



[1] http://stats.macports.neverpanic.de/ports/search/name/aqbanking
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[MK-MacPorts]

On 09 Feb 2014, at 20:42 , Jeremy Lavergne  wrote:
> You probably need to run trunk for access to POST, which isn’t available in a 
> release yet.
Ooops, I see. I wasn’t aware of that trunk is a must for this feature.
___
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: Call for Testers: MacPorts Statistics

[MK-MacPorts]

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?

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

Re: Call for Testers: MacPorts Statistics

[Lawrence Velázquez]

On Feb 8, 2014, at 4:55 PM, Eric Gallager  wrote:

> Really? That sounds dangerous, but if you say it works fine, I guess I can 
> give it a try...

That's more or less what selfupdate already does.

If you also want to switch to using a checkout of the ports tree, you'll have 
to edit your sources.conf accordingly.

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

Re: Call for Testers: MacPorts Statistics

[Eric Gallager]

Really? That sounds dangerous, but if you say it works fine, I guess I can
give it a try...



On Sat, Feb 8, 2014 at 4:49 PM, Clemens Lang  wrote:

> Just install right over it, that works fine.
>
> --
> Clemens Lang
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

[Clemens Lang]

Just install right over it, that works fine.

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

Re: Call for Testers: MacPorts Statistics

[Eric Gallager]

Is there an easy way to convert a non-trunk installation of MacPorts into a
trunk installation of it? The relevant guide
section
says:
"If you installed MacPorts using the package installer, skip this section."
I don't exactly have room for multiple installations of MacPorts on my
current drive... I also found two different HowTo guides on the Wiki, but I
am not sure which one would be better to follow:
https://trac.macports.org/wiki/howto/SyncingWithSVN and
https://trac.macports.org/wiki/howto/RunningTrunk



On Sat, Feb 8, 2014 at 2:46 PM, Joshua Root  wrote:

> On 2014-2-9 03:39 , Clemens Lang wrote:
> > Note that the port uses `startupitem.autostart` in a way that only works
> with the most recent trunk [2]. If your MacPorts installation isn't
> compatible, the auto-loading will fail and you'll have to run `port load
> mpstats` manually.
>
> Trunk is actually a hard requirement since it also needs the curl post
> command.
>
> - Josh
> ___
> 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: Call for Testers: MacPorts Statistics

[Joshua Root]

On 2014-2-9 03:39 , Clemens Lang wrote:
> Note that the port uses `startupitem.autostart` in a way that only works with 
> the most recent trunk [2]. If your MacPorts installation isn't compatible, 
> the auto-loading will fail and you'll have to run `port load mpstats` 
> manually.

Trunk is actually a hard requirement since it also needs the curl post
command.

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

Call for Testers: MacPorts Statistics

[Clemens Lang]

Hello MacPorts Developers,

I'd like to invite you to test the MacPorts statistics service that Derek 
Ingrouville wrote during GSoC 2011. I made some progress over the last few days 
and while I was running a copy of the server for quite a while now I never had 
time to look at the client to finish it.

Luckily, Joshua was keeping a work-in-progress port version of the statistics 
client in his user directory and I found it almost complete. With some 
modifications and some server-side bugfixes, I'm pleased to announce that it 
works fine for me.

Because statistics aren't any fun without data, I'd like to invite you to test 
the statistics service. To do that, you can install the `mpstats` port from my 
user directory [1] or use the shortcut (feel free to inspect the tarball before 
installing)
  port -yourflags install https://www.neverpanic.de/documents/mpstats.tar

Note that the port uses `startupitem.autostart` in a way that only works with 
the most recent trunk [2]. If your MacPorts installation isn't compatible, the 
auto-loading will fail and you'll have to run `port load mpstats` manually. If 
you'd like to get your statistics data out there immediately, I'd also 
recommend to run `$prefix/libexec/mpstats submit` after you've installed the 
port. The webinterface [3] will update immediately. Please also test the web 
application extensively and fix any typos or bad wording you might encounter in 
SVN [4] – remember I'm not a native speaker.

NOTE: The mpstats port from my user directory is currently configured to submit 
to my development installation of the statistics server at 
http://stats.macports.neverpanic.de/. We do not have an installation as 
MacOSForge at the moment.

[1] https://trac.macports.org/browser/users/cal/ports/macports/mpstats
[2] https://trac.macports.org/changeset/116820
[3] http://stats.macports.neverpanic.de/
[4] https://trac.macports.org/browser/branches/gsoc11-statistics/stats-server

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