May 2007 - macports-dev - lists.macosforge.org

Track who installed what ports on what OS and on what processor
by Ryan Schmidt 13 May '07

13 May '07

I think it would be cool to track some statistics about how people are using MacPorts. We should track how many users have each port installed, so that we can determine what the "most popular" ports are. Not just how many have tried a port and then uninstalled it again, but how many people currently have a particular port active. When a user activates a port, the count should go up; when a user deactivates a port, the count should go back down. This might be considered an invasion of privacy... would anybody here be opposed to this? Participation in these statistics could be made optional through a config file setting. But it should probably be on by default, otherwise we probably wouldn't get much data. To implement it, data could be sent to a central server every time someone activates or deactivates a port, but that's probably a bad idea for those who aren't online when activating or deactivating, which is probably a not-that-uncommon occurrence. Rather than do this, we could transmit a list of active ports at each sync. A possible problem: I use "svn up" to update my ports tree; I don't use "port sync". If we sent statistics only on sync, my stats wouldn't get counted. Maybe there could be another target "port sendstats" which users like me could call manually, and sendstats would automatically be called by sync for the "normal" users. Also: Each user's stats should only be counted once. We could use the Ethernet MAC address as an ID to uniquely identify the user when reporting stats, but again, this could be seen as a privacy issue. We could encrypt the MAC address or take its sha1 hash. Or we could generate a random unique ID using uuidgen. But what if the user deletes their MacPorts installation? We don't want to count stats for a user who's no longer using MacPorts. What if they then reinstall MacPorts and we generate a new unique ID? We don't want to count both their old and their new stats. Probably the simplest method would be to only count stats that were submitted to the server in the last, say, 30 days. Stats will then be slightly off in the preceding cases, but will correct themselves over time. The stats should include the OS version and processor architecture. The stats should include the selected variants so that we can see which variants are the most popular. If we had this all set up, we could learn some interesting things about what people are actually doing with MacPorts, and what the hardware capabilities of our user population is like. We could have some nice graphs on the web site with this information. Thoughts?

2 1

ALC861 linux driver ported to OSX
by maildoduro＠gmail.com 13 May '07

13 May '07

I'd just like to know if its possible to port the Realtek alc 861 linux sound driver to OSX and to make it work with OSX 10.4.9 If yes, Then, how? I have one of those soundcards in my laptop, and I'd really like to have some sound comig out of it. thanks!

2 1

Is anybody else having problems committing to the MacPorts repository?
by Boey Maun Suang 13 May '07

13 May '07

Hi everyone, I seem to be having problems committing to the repository at the moment. Initially I thought my account had problems: Alexandria:~/src/macports-trunk/dports/science boeyms$ svn commit -F svn-commit.tmp eo/ Authentication realm: <http://svn.macosforge.org:80> Mac OS Forge Password for '<scrubbed />': Authentication realm: <http://svn.macosforge.org:80> Mac OS Forge Username: <scrubbed /> Password for '<scrubbed />': Authentication realm: <http://svn.macosforge.org:80> Mac OS Forge Username: <scrubbed /> Password for '<scrubbed />': svn: Commit failed (details follow): svn: MKACTIVITY of '/repository/macports/!svn/act/ 7aef5007-7815-4259-8462-31d597ba3896': authorization failed (http:// svn.macosforge.org) So I tried changing my password on Trac, and then got: Alexandria:~/src/macports-trunk/dports/science boeyms$ svn commit -F svn-commit.tmp eo/ Authentication realm: <http://svn.macosforge.org:80> Mac OS Forge Password for '<scrubbed />': Adding eo Adding eo/Portfile Transmitting file data .svn: Commit failed (details follow): svn: Can't set position pointer in file '/svn/repositories/macports/ db/transactions/25033-1.txn/rev': No space left on device This doesn't look good. Anyone able to comment on this or follow this up? Kind regards, Maun Suang P.S. "<scrubbed />" is only to give the spambots less fodder (I got my first macports spam today :-( ). No prizes for guessing what it actually is. -- Boey Maun Suang (Boey is my surname) Email: macports.org%boeyms (put the bit after the '%' before the '@' and vice versa)

7 7

pkgconfig - freedesktop.org down
by markd＠macports.org 13 May '07

13 May '07

It seems pkgconfig's master_site is down right now. http://pkgconfig.freedesktop.org/releases/ Is there any mirror site available? Someone reported a checksum problem 3 days ago that must be a result of that. http://trac.macosforge.org/projects/macports/ticket/11927 Mark

3 2

Tk port installs X11 headers
by Jann Röder 12 May '07

12 May '07

Hi, I just stumbled upon the fact that the Tk port installs X11 header like Xlib.h, this has caused me trouble when trying to compile an application that depended on some things that are declared in Apple's X11 header but not in Tk's . So why does Tk install those headers in the first place ? Is it save to delete them in the post-destroot stage ? Jann

2 2

*.bak files in svn
by Blair Zajac 12 May '07

12 May '07

Hello, In r24980, is there a reason to keep the *.bak files in Subversion? http://trac.macports.org/projects/macports/changeset/24980 Regards, Blair

3 3

Call for MacPorts documentation/site effort
by James Berry 11 May '07

11 May '07

On May 10, 2007, at 3:43 PM, Ryan Schmidt wrote: >> If there isn't, there should really be a Wiki page with all >> Portfile variables. Just the names would already be helpful, >> although it should obviously contain an explanation in the end. > > The documentation used to have that, or at least most of the useful > variables. We currently have no documentation, however. I know all of us would love to see better documentation and a better experience on first arrival to the MacPorts site. Despite complaints from time to time, nobody has stepped up to the chore to really make things better. Some resources: - We have an xml file containing all the documentation from the old site. - We hope to bring online soon a RoR app that will, among other things, provide listings of ports. One possibility would be to also use this as a server for the site front-end and other documentation, either to be served from statically generated pages or from the database. - We also have our WordPress site in all of its unglory, which we might hack on as needed. - Or something else. - Thomas Reifferscheid at Johannes Gutenberg-Universität Mainz in germany has graciously offered some hosting and bandwidth for whatever services we need to host a site. Apple will likely also at some point have the resources to allow us to host more of our site at MacOSForge (they are currently trying to hire an admin for that site). Some vision: - We need somebody with the vision, drive, and determination to fix the documentation end of things, including pursuing one of the options above. Portmgr would love to hear from you if you'd like to pull this off. - We really need a nicely designed front-presence that describes the project and gives access to ports and documentation. Our current front end does those things only marginally. Volunteers? James

3 2

Re: port activate error: can't read "revision": no such variable
by James Berry 10 May '07

10 May '07

On May 10, 2007, at 2:36 AM, Paulo Moura wrote: >> I'm in favor of getting the + out of your version number. > > The "3.0.1+" version number is not something I control as is used > by the third-party software. This software install on a directory > named after this version number. Using a different version number > in the portfile results in a broken installation. Moreover, what is > important here is to fix the MacPorts parsing bug uncovered by my > portfile, not finding a workaround for some specific portfile that > only a few people care about. Hi Paulo, When I rewrote major parts of the port(1) command driver a couple of years ago, I did put in accommodation for + in the version (the hack to terminate version with a /). Part of the problem is that the syntax has always allowed run together strings of version+-variants. I believe the problem in this case, however, is not in the port(1) command handler (as it can be forced to distinguish this case as I just said, but in other internal parts of macports that rely on using a combined version+variants string, and which don't automatically use the slash as I just described. As I recall these strings may even get used to build filenames. So yes, I believe that you _will_ run into problems with + in version numbers. I can't tell you exactly where/how/when, but it is a problem/ issue/restriction in the code. If somebody wants to work through this issue and patch the code, they are more than welcome to. Short of that, somebody should come up with a workaround for this particular port so that we can avoid the + in the version number: either by yelling at the port issuer, falling back to a version without the +, or (within macports) using a different version number (perhaps with an additional .1 component on the end instead of the +) to describe this version. The distfile key can then be used to explicitly name the file. Not idea, but I think it can be done. James

1 0

Re: [24915] branches/release_1_4/base
by Daniel J. Luke 09 May '07

09 May '07

On May 8, 2007, at 1:11 AM, source_changes(a)macosforge.org wrote: > Also, moving the IndexRegen.sh script to check out from the tags > dir, thus keeping the checkout always in sync with the latest > MacPorts release. NOTE to dluke: You should probably reinstall this > script and bootstrap it again ;-) This change won't actually work the way you want it to. Currently, I manually move a copy of IndexRegen.sh into position to actually run on my machine (as I don't particularly want anyone with commit access to be able to run arbitrary shell scripts on my machine (although it's probably a mute point as anyone with commit access could modify any of the base/ code that gets executed just as easily)). SVN_BASE_URL isn't actually used by the script for much more than documentation, so changing it wont change where the checkout happens. The script pulls from the latest release branch, and therefore doesn't need intervention unless/until major releases (when I would manually switch the repo to the later branch). Changing to a tag would require manual intervention on my part for every release. In fact, I would rather we went in the opposite direction, where there was a 'current-release' branch that was used for the index regen. -- Daniel J. Luke +========================================================+ | *---------------- dluke(a)geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

4 6

Do we still want Growl to install its prefpane into /Library/PreferencePanes ?
by Boey Maun Suang 09 May '07

09 May '07

Hi everyone, As I've just about gotten a port for Growl 0.7.6 working (had to fetch from tagged svn, since the tarball is actually missing an entire directory), I just wanted to check whether people were still happy for Growl to install its preference pane directly into /Library/ PreferencePanes (and GrowlMail directly into /Library/Mail/Bundles), or whether you think we should make it into ${prefix}/Library/... and symlink. I feel more comfortable about the latter, personally, but I want to make sure that there aren't any issues that I may have overlooked. Incidentally (I apologise for not putting this in a separate email, but I'm in a rush), Growl wouldn't build with the -t flag; it appears that the Rez command that gets invoked insists on creating temporary files in /.vol and fails when it can't: <snip> /Developer/Tools/Rez -o /opt/local/var/db/dports/build/ _Users_boeyms_src_macports-trunk_dports_aqua_Growl/work/Growl-0.7.6/ build/Growl.build/Development/GrowlHelperApp.build/ ResourceManagerResources/Objects/GrowlScripting.rsrc -d ... <rest of command omitted because it's really long /> ### /Developer/Tools/Rez - SysError -5000 during create of "/opt/ local/var/db/dports/build/_Users_boeyms_src_macports- trunk_dports_aqua_Growl/work/Growl-0.7.6/build/Growl.build/ Development/GrowlHelperApp.build/ResourceManagerResources/Objects/ GrowlScripting.rsrc". ### /Developer/Tools/Rez - Fatal error trying to open the resource file "/opt/local/var/db/dports/build/_Users_boeyms_src_macports- trunk_dports_aqua_Growl/work/Growl-0.7.6/build/Growl.build/ Development/GrowlHelperApp.build/ResourceManagerResources/Objects/ GrowlScripting.rsrc" for writing. Fatal Error! ### /Developer/Tools/Rez - Fatal Error, can't recover. ### /Developer/Tools/Rez - Since errors occurred, /opt/local/var/db/ dports/build/_Users_boeyms_src_macports-trunk_dports_aqua_Growl/work/ Growl-0.7.6/build/Growl.build/Development/GrowlHelperApp.build/ ResourceManagerResources/Objects/GrowlScripting.rsrc's resource fork was not written. ** BUILD FAILED ** make: *** [all] Error 1 Warning: Target build has an undeclared dependency on subversion Warning: A creation/deletion/modification was attempted outside sandbox: /.vol/234881026/10943819/main.applescript Warning: A creation/deletion/modification was attempted outside sandbox: /.vol/ 234881026/10944508/5C3BB5E0-6B3E-44AC-800F-49C65E3C0729-20650-000007779E AE5954 Warning: A creation/deletion/modification was attempted outside sandbox: /.vol/234881026/10944508/Growl.framework.dep Warning: A creation/deletion/modification was attempted outside sandbox: /.vol/234881026/10945013/GrowlScripting.rsrc Warning: A creation/deletion/modification was attempted outside sandbox: /System/Library/Caches/com.apple.IntlDataCache.le Warning: A creation/deletion/modification was attempted outside sandbox: /System/Library/Caches/com.apple.IntlDataCache.le Warning: A creation/deletion/modification was attempted outside sandbox: /System/Library/Caches/com.apple.IntlDataCache.le </snip> I don't know what tried to write to /System/Library/Caches, but suffice it to say that omitting the -t flag enabled it to build with no problems. It'd be nice if we could modify trace mode to allow writing to /.vol at least, but I won't mind if people are more concerned about that path being written to and not cleaned out. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms(a)macports.org

2 1