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

Re: gnu livecheck problem?
by N_Ox 16 Oct '07

16 Oct '07

Le 16 oct. 07 à 20:36, N_Ox a écrit : > > Le 16 oct. 07 à 20:01, Ryan Schmidt a écrit : > >> <snip> >> > > The two problems you reported are things i have noticed when i had > the gnu livecheck, but that could have occured before. > I thought i had already fixed them, obviously i was wrong. > Thanks for having found two nice test cases ;) > Hey! For one time, I'm right! :D Your MacPorts installation is outdated, please rebuild it and test again. Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

2 1

gnu livecheck problem?
by Ryan Schmidt 16 Oct '07

16 Oct '07

So I'm running MacPorts from trunk and I see that a gnu livecheck option was added. But the livecheck on two of my ports seems to have broken as a result. First libiconv: $ sudo port -dv livecheck libiconv DEBUG: Found port in file:///Users/rschmidt/macports/dports/textproc/ libiconv DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ textproc/libiconv DEBUG: Requested variant darwin is not provided by port libiconv. DEBUG: Requested variant i386 is not provided by port libiconv. DEBUG: Requested variant macosx is not provided by port libiconv. DEBUG: Executing variant darwin_8 provides darwin_8 DEBUG: Skipping completed org.macports.main (libiconv) DEBUG: Executing org.macports.livecheck (libiconv) DEBUG: Portfile modification date is Tue Sep 11 19:22:28 CDT 2007 DEBUG: Port (livecheck) version is 1.11 DEBUG: Fetching http://ftp.gnu.org/gnu/:gnu/?C=M&O=D Error: cannot check if libiconv was updated (HTTP response code said error) libiconv seems to be up to date $ "http://ftp.gnu.org/gnu/:gnu/?C=M&O=D" is clearly wrong. libiconv downloads from gnu, but it's specified this way: homepage http://www.gnu.org/software/libiconv/ master_sites \ gnu::gnu \ http://www2d.biglobe.ne.jp/~msyk/software/libiconv/:cp932fix If I change the download location to: master_sites \ gnu:${name}:gnu \ http://www2d.biglobe.ne.jp/~msyk/software/libiconv/:cp932fix Then the livecheck says: $ sudo port -dv livecheck DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ textproc/libiconv DEBUG: Requested variant darwin is not provided by port libiconv. DEBUG: Requested variant i386 is not provided by port libiconv. DEBUG: Requested variant macosx is not provided by port libiconv. DEBUG: Executing variant darwin_8 provides darwin_8 DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ textproc/libiconv DEBUG: Requested variant darwin is not provided by port libiconv. DEBUG: Requested variant i386 is not provided by port libiconv. DEBUG: Requested variant macosx is not provided by port libiconv. DEBUG: Executing variant darwin_8 provides darwin_8 Portfile changed since last build; discarding previous state. DEBUG: Executing org.macports.main (libiconv) DEBUG: Executing org.macports.livecheck (libiconv) DEBUG: Portfile modification date is Tue Oct 16 12:49:56 CDT 2007 DEBUG: Port (livecheck) version is 1.11 DEBUG: Fetching http://ftp.gnu.org/gnu/libiconv:gnu/?C=M&O=D Error: cannot check if libiconv was updated (HTTP response code said error) libiconv seems to be up to date $ As you can see, it still hasn't got the right project name. I fixed it by adding "livecheck.name ${name}" but that should have been the default, shouldn't it? Next problem is freetype: $ sudo port -dv livecheck freetype DEBUG: Found port in file:///Users/rschmidt/macports/dports/print/ freetype DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ print/freetype DEBUG: Requested variant darwin is not provided by port freetype. DEBUG: Requested variant i386 is not provided by port freetype. DEBUG: Requested variant macosx is not provided by port freetype. DEBUG: Skipping completed org.macports.main (freetype) DEBUG: Executing org.macports.livecheck (freetype) DEBUG: Portfile modification date is Thu Jul 05 16:55:44 CDT 2007 DEBUG: Port (livecheck) version is 2.3.5 DEBUG: Fetching http://ftp.gnu.org/gnu/freetype/?C=M&O=D Error: cannot check if freetype was updated (HTTP response code said error) freetype seems to be up to date $ Here's what the portfile says: homepage http://freetype.sourceforge.net/ master_sites \ http://download.savannah.gnu.org/releases/freetype/ \ sourceforge Freetype never used to check the GNU web site for its livecheck info. Why did it start doing so? Just because the first master site contains "gnu"? I fixed it by adding "livecheck.check sourceforge" but I wonder how many other ports are affected by this.

2 1

"outdated" and similar actions broken in trunk's port.tcl, a possible fix
by Juan Manuel Palacios 16 Oct '07

16 Oct '07

Hi guys! I'm putting together a patch to fix the regression experienced in trunk's port.tcl after the recent API tweaks to macports1.0. As it turns out, many actions (installed, outdated, search and others) are currently broken because the "ports_no_args" flag in the "global_options" array is not being reached; but all in all, I feel this is more of a symptom of a general mix-up in port.tcl's two main global arrays that was revealed by the API changes rather than plain breakage, and I believe the appropriate fix is to clean the mess-up altogether. Basically, port.tcl has two main global arrays: 1) ui_options, for storing user interface options like verbose/debug/ quiet (but also some other things I believe do not belong in it), passed to macports1.0; 2) global_options, for storing all sorts mixed-up things (read below), passed to macports1.0 too; 3) (there's also global_variations, but I think that's orthogonal to the issue at hand). The breakage occurs because at the time the "global_options" array is passed to macports1.0, "ports_no_args" hasn't been set yet; subsequently, "[macports:global_option_isset ports_no_args]" is used to determine the behavior of the outdated/installed/search/etc actions and as the flag is not yet set, things naturally break. As Kevin noted recently, port.tcl stores options that are "private" to port.tcl and options that are passed to the macports1.0 layer *both* inside the global_options array, and I believe the proper fix is to split these two types into their own properly named arrays. In my ongoing patch I created a "private_options" global array in which I store flags like "ports_no_args" and managed to recover some of the broken functionality by polling the former for the latter flag (through [info exists private_options(ports_no_args)]), rather than using the now in macports1.0 "global_option_isset" proc on the "global_options" array (which does not contain the needed flag). So to me this is an obvious example of what should be an option *private* to port.tcl, candidate for storing inside "private_options". In order to complete the patch I would need to know exactly what options are private and which ones should be passed to macports1.0 through "global_options". Polling the appropriate array throughout port.tcl will not only recover all the broken functionality but also clear up any confusion as to what stays and what is handed over. Global options that should be passed to macports1.0 are, I think: *) 'ports_force', port(1)'s -f; *) 'ports_ignore_older', port(1)'s -o; *) 'ports_nodeps', port(1)'s -n; *) 'port_uninstall_old', port(1)'s -u; *) 'ports_do_dependents', port(1)'s -R; *) 'ports_source_only', port(1)'s -s; *) 'ports_binary_only', port(1)'s -b; *) 'ports_autoclean', port(1)'s -c & -k; *) 'ports_trace', port(1)'s -t; Am I right? Did I miss any? Or am I, instead, including some options that don't need to be passed to macports1.0? Conversely, options that are private to port.tcl are: *) ports_no_args, currently being stored in global_options but opting for private_options, I believe; *) I'm sure I'm missing others throughout port.tcl that are really of private scope and need not be stored in global_options; care to illuminate? Thirdly, options I'm not sure about where they should be: *) long arguments processed in the "parse_options" proc, which are being stored in "global_options". Do they need to stay there or can they be moved to the private array? Or maybe split between the two? *) 'ports_commandfiles' in the "parse_options" proc too, why is it being saved in ui_options? What does it have to do with the user interface? Seems to me like this is another perfect candidate for the private_options array (and in lack of it, I would have imagined this option is more appropriate for saving inside the global_options array, not in ui_options); *) 'ports_processall', same comments as above; *) 'ports_exit', ditto; So as you can see, even though a quick fix for this regression could be a very simple patch (which I could commit like *now*), what I think is the proper one gets a bit more involved. After knowing all the information I request above, the final part to call the fix complete is knowing in what situations I would need to poll the "global_options" array and/or "private_options". As the code stands now, many constructs simply [array get global_options] and thus obtain all the baggage that's stored there (I'm sure sometimes unnecessarily so), but that would naturally need to change if we do split the options (including some proc prototypes). So... can more port.tcl illuminated souls shine some light on me? ;-) Thanks for even reading all this mail this far! Regards,... -jmpp PS; The patch I'm working on is attached in its current, still incipient form. If you're careful you'll also notice the removal of some global calls in some procs, which are due to the API changes to macpors1.0 (the corresponding vars need no longer be brought into scope).

1 0

Ticket #12900 port glade does not build
by David Evans 15 Oct '07

15 Oct '07

Have submitted https://svn.macosforge.org/projects/macports/ticket/12900 which contains a patch to resolve a build problem with glade 2.12.1 due to changes in libbonobo. Have reported the problem upstream at http://bugzilla.gnome.org/show_bug.cgi?id=486174 Could someone with commit authority take a look at this? Thanks

2 1

"port outdated" broken in trunk
by Ryan Schmidt 15 Oct '07

15 Oct '07

In trunk @29497 "port outdated" returns the list of outdated ports: $ port outdated The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ However in trunk @29502 "port outdated" finds nothing: $ port outdated None of the specified ports are outdated. $ I can still query individual ports: $ port outdated wxWidgets The following installed ports are outdated: wxWidgets 2.8.4_2 < 2.8.6_1 $ Or all installed ports: $ port outdated installed The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ But is this change in behavior intentional? There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.

5 9

Website & documentation updates
by Juan Manuel Palacios 15 Oct '07

15 Oct '07

Hello documentation team! (and, of course, anyone else who wants to lend a hand for the heavy lifting ;-) First off, I would like to apologize for having disappeared for the last couple of weeks, that annoying "real life & work" thing hasn't left me with much extra time lately to work with you guys ;-) I hope I can still mull your interest to work on a little reorganization of our documentation priorities. As you may have seen in r29593, I recently committed a facelift to the MacPorts installation instructions in the new 'install.php' page (following some suggestions on this list), revamped & renamed from the old 'getmp.php' page. It has come to my attention, though (as some of you have already pointed out), that we are chronically and needlessly duplicating information all over the place (web pages, guide, wiki, in-source text files, etc), so I wanted to call on the doc team's initiative to stop this practice and centralize everything in a single location. The in-this-case relevant examples are a) the content of the new 'install.php' page and Chapter 1 of the new guide, and b) the overall contents of our Wiki (particularly the main page, http://trac.macports.org/) and Chapter 2 of the new guide. I am aware we're currently facing this situation simply because for a long time we lacked a coordinated documentation strategy, but I think it's time we put a stop & fix to this practice. We have been advancing rather slow on our new documentation and website efforts so far, unfortunately, so I would like to call for a small reorganization of our priorities by pulling a Steve&iPhone&Leopard move ;-) I wanted to ask you guys if it's possible for you to momentarily re-focus your energies into helping me complete the content of the new website before continuing on the new guide, so that we can finally provide a friendly project portal to newcomers ASAP. What I committed to 'install.php' is basically a) what was in the old 'getmp.php' page, plus b) some suggestions taken from this list (Ryan's and Chris', IIRC), and c) hints taken from the wiki doc "InstallingMacPorts". I believe we should reorganize these three sources by first taking from the wiki doc what's useful and then obliterating it, following with a reduction of 'install.php' to some smart cues that lead users in smart ways into specific sections of the new guide (where content from the other two sources should be concentrated). Any one up to the plate for this? Secondly, we need to start enforcing wiki documentation rules: HOTOWs like "Installing GNOME with MacPorts", "Setting up a MySQL & PHP server with MacPorts", FAQs, members' pages, etc., but no "official" MacPorts installation/usage/troubleshooting/membership/ ticketing guides and/or documents -- those belong in the *official* (new) guide. Our trac entry page (http://trac.macports.org/projects/ macports, which maps to http://trac.macports.org/projects/macports/ wiki/WikiStart) currently holds the following titles (next to which you'll find my thoughts on each): 1) http://trac.macports.org/projects/macports/wiki/InstallingMacPorts -- integrate into 'install.php' & chapter 1 of the guide and obliterate; 2) http://trac.macports.org/projects/macports/wiki/ UsingMacPortsQuickStart -- integrate into chapter 2 of the guide and obliterate; 3) http://trac.macports.org/projects/macports/wiki/GetMacPortsSource -- integrate into 'install.php' & chapter 1 of the guide and obliterate; 4) http://trac.macports.org/projects/macports/wiki/NewCommittersGuide -- integrate into the new guide (chapter 7?) and obliterate; 5) http://trac.macports.org/projects/macports/wiki/FAQ -- should remain in the Wiki, I believe (and properly advertised on the wiki's front page --as it now is--, in 'install.php' and in the guide); 6) http://trac.macports.org/projects/macports/wiki/BuildPhases -- integrate into the new guide, not too sure where, and obliterate; 7) http://trac.macports.org/projects/macports/wiki/GNOME -- perfect example of what Wiki docs should be for, just like the FAQ; 8) http://trac.macports.org/projects/macports/wiki/TracGuide -- a Trac default document, should remain in the Wiki's front page; 9) http://trac.macports.org/projects/macports/wiki/ProblemHotlist -- totally Wiki document; 10) http://trac.macports.org/projects/macports/wiki/TracTicketing -- this one and NewTracTicketing should be merged into the new guide (mostly done, see ticket #12714) and then obliterated; 11) http://trac.macports.org/projects/macports/wiki/MailingLists -- moved to the guide and obliterated. The result of these moves doesn't necessarily have to be a scant introductory Wiki page, as we can always link to the relevant guide pages (and whatever else we find appropriate) off it (thus favoring doc centralization again). After that's done, the only thing keeping us from going live with the new website would be a new "Home" section, 'index.php', per the guidelines I outlined for it in an earlier thread on this list: -) Home: a front page detailing what the project is about (including a brief description of our ports tree), mission goals (very brief summary of a project roadmap) and introductory text of how to participate/join. Blog functionality would be provided by our existing Wordpress installation, but a way to smoothly tie the latter into the former has to be thought out. Of course, feel free to brainstorm over that if you have other/ better ideas. Anyone willing to help writing that text? The rest of the pending tasks for a fully functional site are mostly server related issues that I would have to work out with Mac OS Forge admin personnel. But that shouldn't stop us from moving forward as soon as we have the content ready, as we can always roll in new functionality incrementally. So.... this is just another one of my a-tad-too-long mails, so I'm gonna wrap it up here hoping you don't get too bored reading and instead step forward to volunteer some much needed help ;-) Thanks in advance! Regards,.... -jmpp

4 8

dnsupdate broke in revision 28938
by Ryan Schmidt 15 Oct '07

15 Oct '07

The commit message for r28938 reads "dnsupdate: Whitespace changes." However, you also made non-whitespace changes which broke the port. You changed the port to use the xcode portgroup, and you changed the destroot phase, including removing the ${appName} variable on which the rest of the destroot phase depends.

2 1

Re: [29910] trunk/dports/net/http-replicator/Portfile
by Ryan Schmidt 15 Oct '07

15 Oct '07

Oops, sorry, mww, I didn't check whether this port had a maintainer before committing this fix. I hope you don't mind. The distfile wouldn't fetch without this change. On Oct 15, 2007, at 00:18, source_changes(a)macosforge.org wrote: > Revision: 29910 > http://trac.macosforge.org/projects/macports/changeset/29910 > Author: ryandesign(a)macports.org > Date: 2007-10-14 22:18:13 -0700 (Sun, 14 Oct 2007) > > Log Message: > ----------- > http-replicator: fix distname > > Modified Paths: > -------------- > trunk/dports/net/http-replicator/Portfile > > Modified: trunk/dports/net/http-replicator/Portfile > =================================================================== > --- trunk/dports/net/http-replicator/Portfile 2007-10-15 05:16:29 > UTC (rev 29909) > +++ trunk/dports/net/http-replicator/Portfile 2007-10-15 05:18:13 > UTC (rev 29910) > @@ -17,6 +17,7 @@ > > homepage http://gertjan.freezope.org/replicator/ > master_sites ${homepage} > +distname ${name}_${version} > checksums md5 7d8d69175a5dc3d470273b1e508a27f3 > > depends_run bin:python:python24

1 0

Re: [29859] trunk/dports/devel
by Daniel J. Luke 15 Oct '07

15 Oct '07

On Oct 12, 2007, at 9:16 PM, source_changes(a)macosforge.org wrote: > Revision 29859 Author nox(a)macports.org Date 2007-10-12 18:16:22 > -0700 (Fri, 12 Oct 2007) Log Messagecvs: Renamed cvs directory, it > should be named after the portname, right?Added Paths > trunk/dports/devel/cvs/ > Removed Paths > trunk/dports/devel/cvs-port/ > Diff > Copied: trunk/dports/devel/cvs (from rev 29838, trunk/dports/devel/ > cvs-port) good change. It was named cvs-port because the portfiles used to be stored in a cvs repository and having a directory called cvs when cvs uses CVS/ directories in your checkout causes problems on case-insensitive filesystems. -- 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. | +========================================================+

1 0

PortIndex Regen Failure on Saturday 2007-10-13 at 15:30:00
by mp-user＠geeklair.net 13 Oct '07

13 Oct '07

svn: Commit failed (details follow): svn: Can't create directory '/svn/repositories/macports/db/transactions/29860-1.txn': No space left on device SVN commit failed.

1 0