Hi Markus, Juan and I have decided that we'll delay any decision on package formats until: (a) We can ensure you can participate fully. (b) We see what we can squeeze out of Jordan to help make it happen. James.
If you had recently upgraded you perl, p5-xml-parser would have broken on that. Its not an intltool issue. On 31 Mar 2006, at 13:27, Scott C. Kennedy wrote: > I just went through and upgraded all my outdated ports and came across > this, and thought others might need it... > > Biko:~ sck$ sudo port outdated > The following installed ports are outdated: > libbonobo 2.10.1_0 < 2.14.0_0 > Biko:~ sck$ sudo port upgrade libbonobo > ---> Configuring libbonobo > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of > Makefiles... no > checking for perl... /opt/local/bin/perl > checking for XML::Parser... configure: error: XML::Parser perl > module is > required for intltool > Error: Target com.apple.configure returned: configure failure: shell > command "cd > "/opt/local/var/db/dports/build/ > _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ > dports_gnome_libbonobo/work/libbonobo-2.14.0" > && CPPFLAGS="-I/opt/local/include -L/opt/local/lib" > CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" ./(Continue reading)
I've mostly got this working without having to modify ports
variant lowerport { configure.args --listenportmin= ${lowerport} }
works, and has to be invoked with port install +lowerport lowerport=3555
Is there any way that I can change the name that the port number
appears in the package name? such as
foo @1.0+lowerport3555
rather than foo @1.0+lowerport
On 01/04/2006, at 9:18 AM, Marcus Pallinger wrote:
> I'd much rather patch DP to allow a syntax to allow variants to
> accept variable values than to patch the program to require a
> config file than to change a program that rarely needs it's ports
> changed once it's installed, and in fact hasn't been updated since
> 1995.
>
> So I guess it's time to ask what kind of syntax would be best to do
> this?
> Perhaps something like:
> port install foo +lowerport=3555 +upperport=3699
>
> and perhaps define a variable so the port file would contain
>
> variant lowerport { configure.args --listenportmin= ${lowerport} }
> variant upperport { configure.args --listenportmax= ${upperport} }
>
> which will install foo @1.0+lowerport-3555+upperport-3699
(Continue reading)
On Mar 31, 2006, at 6:52 PM, Marcus Pallinger wrote:
> I've mostly got this working without having to modify ports
>
> variant lowerport { configure.args --listenportmin= ${lowerport} }
>
> works, and has to be invoked with port install +lowerport
> lowerport=3555
>
> Is there any way that I can change the name that the port number
> appears in the package name? such as
> foo @1.0+lowerport3555
> rather than foo @1.0+lowerport
Marcus,
You really don't want to do what you're doing. For one thing,
metadata like this won't survive upgrade.
If you need static configuration like this you should provide some
means to set a reasonable default (in the Portfile, if necessary) and
be able to change it later (using a config file, or something).
Don't try to change a parameter like this using either a variant or
an environment/option variable.
James.
>
(Continue reading)Quoting "Jordan K. Hubbard" <jkh <at> opendarwin.org>: > > On Mar 30, 2006, at 3:56 PM, Bryan Blackburn wrote: > >> So I've been putting together some scripts for this (my personal >> rewrites of buildall.sh so I know better what it's doing and to >> make it somewhat more modular) and have come up with a question: >> when building, should previously-built items stored in DP's >> packages be allowed to satisfy later dependencies, or should things >> always be built from scratch? > > I think satisfying deps with previously built packages, assuming that > each and every package has been built with the same cleanroom > scripts (so you know you can trust it), is the only way such a > system can ultimately work. Let's say DP were to decide to build > its own X.org package for all ports which depended on X11; building > all of X for each and every package which lists it as a dep would be > cost prohibitive, to say the least. That's just one example - > there are many others! While I would tend to agree with this for the most part. I am wondering about trapping apps that do not; or correctly; search and satisfy their dependencies. That is; gimp needs glib and sources it's availability on the system; then proceeds to build; having found it's existance on the system. But what if gimp needs glib; sources it on the system; but doesn't find it and doesn't properly source the source for creating/ building it. Or finds the sources, but doesn't initiate the building of glib correctly? Basically, what if the app doesn't call the right build process for(Continue reading)
Hey all, i've done : > sudo port install mod_ruby this results in installing first pcre, second Apache2 both sucessfully. howver, the latest, mod_ruby-1.2.4 install failed with those error messages : ---> Attempting to fetch mod_ruby-1.2.4.tar.gz from http:// modruby.net//archive/ ---> Verifying checksum(s) for mod_ruby ---> Extracting mod_ruby ---> Configuring mod_ruby ---> Building mod_ruby with target all Error: Target com.apple.build returned: shell command "cd "/opt/local/ var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_www_mod_ruby/work/mod_ruby-1.2.4" && make all" returned error 2 Command output: mod_ruby.c:1300: error: 'dconf' undeclared (first use in this function) mod_ruby.c:1300: error: dereferencing pointer to incomplete type mod_ruby.c:1300: error: parse error before ')' token mod_ruby.c:1300: error: dereferencing pointer to incomplete type mod_ruby.c: In function 'ruby_log_handler': mod_ruby.c:1309: error: 'dconf' undeclared (first use in this function) mod_ruby.c:1309: error: dereferencing pointer to incomplete type mod_ruby.c:1309: error: parse error before ')' token(Continue reading)
Hi, I am curious about what I should do to get my new ports forward? Updates proceed usually quite well, the record being an update to fortune that was committed in minutes, compliments to the maintainer/ committer (toby)! The concern is now a package of four ports that all go together. One of the ports (midgard-core) is already in distribution, but the other three (#7609, #7610, #7611) are still waiting. I even mailed the category's responsible committer this week (cms), but nothing has happened (is the documentation correct?). I don't know, whether the 72 hours rule applies here, but it would really be nice, if someone could do something about them. I know each of you committers has lots of other things to do, so the extra work here deserves gratitude, but it is frustrating just to wait… What should I do then? I have tested those ports and they should be ok. I could modify the ports perhaps a bit and let bugzilla remind people about those ports, then I could send these emails to list, but I don't think this should be necessary. Please, if there are some problems with the ports, I'd like to get feedback to be able to correct them, but if not, I'd like to see them in distribution! Thanks for your patience, ! ! Jyrki Wahlstedt ! Männikkötie 5 D 19 mob. +358-40-502 0164 skype:jyrkiwahlstedt ! FI-00630 Helsinki ! ! Our life is no dream; but it ought to become one and perhaps will.(Continue reading)
I have APR 1.2.2 installed: $ port installed | grep apr apr @1.2.2_0 (active) apr-util @1.2.2_1+no_bdb (active) Now I want to upgrade to 1.2.6. $ port outdated | grep apr apr 1.2.2_0 < 1.2.6_0 apr-util 1.2.2_1 < 1.2.6_0 $ sudo port -cuf upgrade apr-util ---> Fetching apr ---> Attempting to fetch apr-1.2.6.tar.bz2 from http:// www.apache.org/dist/apr ---> Verifying checksum(s) for apr ---> Extracting apr ---> Configuring apr ---> Building apr with target all ---> Staging apr into destroot ---> Unable to uninstall apr 1.2.2_0, the following ports depend on it: ---> apr-util ---> subversion ---> apache2 Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating apr 1.2.2_0 ---> Uninstalling apr 1.2.2_0 ---> Packaging tgz archive for apr 1.2.6_0 ---> Installing apr 1.2.6_0(Continue reading)
On Saturday 01 April 2006 05:05, Yvon Thoraval wrote: > Hey all, > > i've done : > > sudo port install mod_ruby > I don't have an answer but I have another questionIf one uses DP to install Apache modules, is there anything that needs to be done to enable those modules in Apache other then include the correct words in the httpd.conf file? On another note, how easy is it to back out DP Apache and get back to the Apple Version later and how do you start DP Apache at boot up? I guess that's three questions. Peace and Metta to the list john
(sent to the list. I hit reply but somehow it only got sent to the OP) > > sudo port install mod_ruby > > this results in installing first pcre, second Apache2 both > sucessfully. > > howver, the latest, mod_ruby-1.2.4 install failed with those error > messages : > <snip> > See: BUG: mod_ruby fails to build (Opened: 2005-12-30): http:// bugzilla.opendarwin.org/show_bug.cgi?id=6303 UPDATE mod_ruby-1.2.5 (Opened: 2006-02-25): http:// bugzilla.opendarwin.org/show_bug.cgi?id=7473 The update has not yet been committed. -- Daniel
RSS Feed1 | |
|---|---|
122 | |
415 | |
219 | |
366 | |
534 | |
567 | |
846 | |
552 | |
573 | |
630 | |
323 | |
803 | |
661 | |
500 | |
414 | |
486 | |
581 | |
652 | |
352 | |
375 | |
722 | |
545 | |
453 | |
318 | |
374 | |
116 | |
218 | |
168 | |
255 | |
379 | |
343 | |
641 | |
557 | |
322 | |
317 | |
279 | |
111 | |
392 | |
197 | |
235 | |
290 | |
414 | |
226 | |
111 | |
165 | |
113 | |
166 | |
316 | |
134 | |
47 | |
4 |
