[Fink-devel] Dependency engine circular dependency problem
I've got libglade2 (and -shlibs) 2.0.1-13 installed. I see there's a -14 available, so I # fink update libglade2-shlibs The following package will be installed or updated: libglade2-shlibs Failed: Problem resolving dependencies. Check for circular dependencies. Which is true (libglade2-shlibs Depends on itself). But yet: # fink update libglade2 The following package will be installed or updated: libglade2 The following additional package will be installed: libglade2-shlibs Do you want to continue? [Y/n] y bzip2 -dc /sw/src/libglade-2.0.1.tar.bz2 | /sw/bin/tar -xvf - and the circular dependency is not noticed. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Where to find downloaded patches?
On Fri, Mar 05, 2004 at 11:44:23AM +0100, Beat Birkhofer wrote: > > "egrep -i -r '^Source.*(diff|patch)$' *" indicates that my package > easytag is perhaps the only one downloading it's patches. Problem: How > to find the place to where the files were downloaded by fink? > > For a user with a custom build-directory [cannot find the file > during PatchScript via ../.. or %p/src] Regardless of where a SourceN tarball is found, it expands (or at least is documented to expand) to a well-defined location. So I guess the problem is what happens for a Source(N) that is not of a recognized complression/archive scheme. Ideally (IMO), such a file should be treated as if it were already expanded. That is, it should be simply copied to %p/src/%f (and further into SourceNExtractDir if specified). What *actually* happens...dunno. Maybe the simplest solution (assuming fink doesn't do that) would be to convert your plain file into a tarball and then let fink expand it, placing your file in a predictable location. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Where to find downloaded patches?
On Fri, Mar 05, 2004 at 03:20:33AM -0800, Remi Mommsen wrote: > On Mar 5, 2004, at 2:44 AM, Beat Birkhofer wrote: > > > >"egrep -i -r '^Source.*(diff|patch)$' *" indicates that my package > >easytag is perhaps the only one downloading it's patches. > > At least the xv package in the unstable trees 10.2-gcc3.3 and 10.3 > is downloading its patch, too. Thought this patch is compressed, > therefore your grep does not find it (it ends with .gz). > > The SourceN should end up in %p/src. Is the patch file there? Conversely, the Packaging Manual states: %a the path where the patches can be found which somewhere in %p/fink/dists, so we'll have to fix that to mention that a patchfile via SourceN is treated as a source thing, not a patchfile thing. But more importantly, according to the fink.conf manpage, one could configure a FetchAltDir to "specify an alernate directory to look for downloaded source code in". Um, the spelling and grammar are fixed in future fink releases:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: binary release plans
On Mon, Mar 01, 2004 at 10:23:48PM -0500, Dave Vasilevsky wrote: Okay, Vasi and I have gotten the lame -dev and dependency mess cleaned up in 10.3, and I cleaned up the atk1 BDOnly mess in 10.3. Should 10.2-gcc3 get the same treatment, or is that tree not going into the bindist? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Feature idea: alternate build location
Package building currently happens in %p/src/%f and %p/src/root-%f. Would it be bad to move those two directories into a %p/src/build directory, and have a fink.conf variable that allows the user to specify another arbitrary location? These are really temp things that can get large, so one could could move them to a large /tmp partition, or a fast memory-resident fs. We could also put *Script tempfiles there (instead of /var/tmp) to keep everything together. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Feature idea: alternate build location
On Mon, Mar 08, 2004 at 12:01:39PM -0500, Chris Zubrzycki wrote: > On Mar 8, 2004, at 11:22 AM, Daniel Macks wrote: > > >Package building currently happens in %p/src/%f and %p/src/root-%f. > >Would it be bad to move those two directories into a %p/src/build > >directory, and have a fink.conf variable that allows the user to > >specify another arbitrary location? These are really temp things that > >can get large, so one could could move them to a large /tmp partition, > >or a fast memory-resident fs. > > I added this feature long ago, it's called Buildpath. I see (now, by looking for it by name in Fink/*). Any chance you want to document it? The doc-freeze does not (TTBOMK) apply to the fink.conf manpage. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/sci eden.info,1.4,1.5
[EMAIL PROTECTED] committed: > Log Message: > eden update of patch script to deal with trivial change in makefile >=== > RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/sci/eden.info,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -d -r1.4 -r1.5 > Version: 4.2 > -Revision: 2 > +Revision: 3 > Source: http://www.edencrystallography.org/%n.tar.gz > -Source-MD5: 5a0f7930c6c82ca3ffdbbbfa08d1347b > +Source-MD5: e550955327cacfa9d81d39c383eae208 So they just changed the tarball? That has been known to confuse finkmirrors: since the "Source" file already exists on the mirror, I'm not sure the mirroring software bothers to re-mirror it. That means folks who get Revision 3 and download from mirror will get the wrong tarball (thank goodness for MD5:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Xfree 4.4 linking
Any comments about 4.3 vs. 4.4 API or ABI compatibility? Are they the same library major-version? I've found myself going in circles on the XFree86 website, so a pointer to a summary would be fine if we don't want to rehash it here. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly warnings
On Sat, Mar 13, 2004 at 12:07:58AM +0100, jfm wrote: > > On Mar 12, 2004, at 10:44 PM, David R. Morrison wrote: > > >Following a suggestion on the fink-users list, the CVS version of fink > >will > >now only display the warnings about BuildDependsOnly if you set the > >verbosity > >level of fink to be higher than the default. All fink developers > >should > >do this, to avoid accidentally using a BuildDepends on an inappropriate > >package. The default level is "low", and the warnings are displayed if > >this is set to "medium" or "high". (Use "fink configure" to reset > >things > >like this.) > > Oh please Dave _ and give the same treatment to those > "WARNING: Deprecated multi-line format used for property ..." > that fill a terminal buffer at every fink index _ this perpetual > reindexing > is already a sufficient punishment w/o that !!! -) Have you updated your pacakge descriptions? I'm pretty sure that's been fixed in all of 10.2-gcc3.3 and 10.3 for a few weeks now. If there are some I missed, feel free to send me the fink index output and I'll fix them in CVS ASAP. The only way (using supported fink trees) I think one would see this would be if you have your own personal .info files. In that case, you really should fix them, since some future fink may start mis-parsing those fields and give a variety of possibly-hard-to-diagnose problems. It's very difficult to have only the validator catch these (since it uses the same parsing routine as fink itself) or to force people to run 'fink validate' so I made that message un-optional in order to give you lead-time to fix your stuff. And because I merely uncommented some code that had been commented-out for a while so I assumed the person who put it there (hi Max) wanted it that way (unless it was just for his own use and never meant to become part of live fink, in which case I apologize for putting words in his mouth). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New pathsetup.sh
On Sun, Mar 14, 2004 at 01:40:16AM +0100, Martin Costabel wrote: > I have written a new pathsetup utility "pathsetup.sh" that is meant to > replace the "pathsetup.command" script. It does the same things as the > old version, but it has a new interface: Following hints by Bill Scott, > I replaced the Terminal.app window by AppleScript-generated dialog > windows. This should eliminate the bug where the pathsetup.command > hijacked the Terminal.app windows. Excellent! > Another difference to the previous version is that it is no longer > double-clickable, but I have the impression that this was never > important anyway. The pathsetup script is run in two ways: Either by the > Fink binary installer, where it is called from a perl script via the > "system" function, or directly from the command line. In both cases, the > shell script in /sw/bin is used, not the double-clickable contraption on > the surface of the Fink Installer dmg. The latter would just disappear > with the new version. If an admin is trying to enable fink for a new user, he'd want to run this. Given that having a GUI-ish interface means you're targetting folks who may not be comfortable with CLI, keeping a double-clickable thing (even if it's just an AppleScript applet or a thing.command or maybe pathsetup.command so we don't have to change the docs:) that runs the new pathsetup.sh) might be polite dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: web/xml/packaging packaging.en.xml,1.3,1.4
On Mon, Mar 15, 2004 at 11:52:53PM +0900, Peter O'Gorman wrote: > Alexander K. Hansen wrote: > > >Sounds fine to me. > > > >On a slightly related note, and since it's the first time that we've had > >a scheduled go-live time (21:30 US/Eastern), I assume Daniel (cc'ed) is > >going to commit and activate all of the PHP files, since he was the last > >one to make a modification on the packaging manual. > > Hi, > Daniel asked me on irc today what the procedure was for makign changes to > docs. I asked him to commit the changes to the .xml files and post a diff > to -i18n, and do nothing else. Is this not the new procedure for making doc > changes? Why are you now asking that he commit and activate the .php files? Note that Peter's comment was ideitical to that in: http://fink.sourceforge.net/doc/multilingual/procedure.php Also note that leaving the .php and other "make && make install" files committed but not "live" on the website is not a stable situation. The update.sh script does not provide a way to activate only some changes and not others. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/stable/main/finkinfo/web uw-imap-c-client.info,NONE,1.1
[EMAIL PROTECTED] committed: > Update of /cvsroot/fink/dists/10.3/stable/main/finkinfo/web > > --- NEW FILE: uw-imap-c-client.info --- > CustomMirror: << > ais-JP: ftp://ftp.win.ne.jp/pub/network/mail/uw-imap/ > ais-JP: ftp://ftp.ayamura.org/pub/uw-imap/ ><< The canonical abbreviation for Asia is "asi" not "ais". You can look in /sw/lib/fink/mirror/_keys to see the continent-country values that Fink understands. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New pathsetup.sh
On Tue, Mar 16, 2004 at 12:44:29AM +0100, Martin Costabel wrote: > Daniel Macks wrote: > [] > >If an admin is trying to enable fink for a new user, he'd want to run > >this. Given that having a GUI-ish interface means you're targetting > >folks who may not be comfortable with CLI, keeping a double-clickable > >thing (even if it's just an AppleScript applet or a thing.command or > >maybe pathsetup.command so we don't have to change the docs:) that > >runs the new pathsetup.sh) might be polite > > OK, I made a "pathsetup.app" that does nothing else than execute the > pathsetup.sh script. It is, bzip2'ed, at > http://perso.wanadoo.fr/costabel/pathsetup.tar.bz2. > > Please try. Looks good. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] failed du_sk-tests in making fink-0.19.2.cvs-20040317
On Wed, Mar 17, 2004 at 06:48:52PM -0500, Dave Vasilevsky wrote: > On Mar 17, 2004, at 1:22 PM, jfm wrote: > >I thought this was quite correct : isn't a subdirectory a file in > >itself ? > > Directories are files, yes. But why doesn't du count directories on > HFS? I don't care which it does, as long as it's consistent. > > I'd like to both keep du_sk consistent with du, but I can't have that > and also have FS independence. So which is more important? I think if Debian uses 'du -sk' for Installed-Size then that's the behavior we should have, not 'du -sk as if it were run on a certain FS'. That field is created during compiling and used during installation, and in general, these two actions occur on the same filesystem. If you're going to the trouble to change fink, may as well make it give a correct-for-that-user size. If your test case is reasonable and it fails, then the solution seems to be fixing the code, not contorting the test to hide the regession:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink-cvs
On Thu, Mar 18, 2004 at 02:31:42PM +0100, jfm wrote: > Hi Dan, > > Since today's update to fink, I also get msgs : > > Failed: Can't resolve dependency "libsoup-ssl-shlibs (= 1.99.28-3)" for > package "libsoup-ssl-1.99.28-3" (no matching packages/versions found) > Failed: Can't resolve dependency "gal199-shlibs (= 1.99.11-6)" for > package "gal199-1.99.11-6" (no matching packages/versions found) > Failed: Can't resolve dependency "gtkhtml3-shlibs (= 3.0.10-9)" for > package "gtkhtml3-3.0.10-9" (no matching packages/versions found) > > This looks suspicious, no ? Yes. Man, what a rough night of hacking I had. This is now fixed. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unclear how to truly set up a package =/
On Tue, Mar 23, 2004 at 04:47:46PM -0500, Dave Vasilevsky wrote:
>
> You can usually test things by simulating yourself what Fink would do.
> Set these variables:
>
> export CPPFLAGS=-I/sw/include
> export LDFLAGS=-L/sw/lib
> export LD_PREBIND=1
> export LD_PREBIND_ALLOW_OVERLAP=1
> export LD_SEG_ADDR_TABLE=/sw/var/lib/fink/prebound/seg_addr_table
...which is slightly different than FAQ 8.3:
http://fink.sourceforge.net/faq/usage-general.php?phpLang=en#compile-myself
I wonder if we should have a /sw/bin/init-compileenv.{csh,sh} that
sets these so we don't have to keep updating the docs when we change
default flags?
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unclear how to truly set up a package =/
On Tue, Mar 23, 2004 at 11:17:03PM +0100, David H. wrote:
> Daniel Macks wrote:
> >
> > http://fink.sourceforge.net/faq/usage-general.php?phpLang=en#compile-myself
> >
> >I wonder if we should have a /sw/bin/init-compileenv.{csh,sh} that
> >sets these so we don't have to keep updating the docs when we
> >change default flags?
>
> We'd still have to update the documentation, script or not :)
Couldn't we just say "run this script", maybe put some explanatory
comments in the script itself, and "if you need to know the details,
RTFScript"? :)
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unclear how to truly set up a package =/
On Tue, Mar 23, 2004 at 08:26:55PM -0500, Daniel Henninger wrote: > > 3) you may have to run `fink index` here first, but try `fink -Kk build > > jwgc` > > What's -Kk? I don't see it in any docs. I think 'fink --help' mentions the -K and -k flags. They provide a way to specify the fink.conf KeepBuildDir and KeepRootDir options for a single invocation of the 'fink' command. See the fink.conf manpage for more info. And yes, our docs are deficient in this area. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new feature
On Thu, Mar 25, 2004 at 11:19:43AM -0700, TheSin wrote: > I'm about to add nice support to fink, I was thinking of a global nice > value in fink.conf like > > NICE: (-20 - 20) > > and then a CLi option for it like > > fink -n (-20 - 20) install bundle-kde > > if no nice value then nice = -20 and I whould set the nice value on > the shell that fink starts in the clean env area. Any comments, > objections?? Sounds like an interesting idea, but why couldn't people just nice +5 fink install bundle-kde instead of needing a setting within fink? Not that we can't have more than one way for a user to do things...I don't know how much redundancy is too much. Perhaps the useful mod would be to have fink apply its setting to the *Script but not to fink itself. If I say "fink build foo", I'd want to know ASAP what else is going to be built/installed/etc, but then let the compile phase get niced down. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new feature
On Thu, Mar 25, 2004 at 11:19:43AM -0700, TheSin wrote: > I'm about to add nice support to fink, I was thinking of a global nice > value in fink.conf like On Thu, Mar 25, 2004 at 11:52:52AM -0700, TheSin wrote: > I want it more for a default lvl, I hate when i forget to set it like > right now, I can't even use my system and I'm half way threw a > compile... That's why there's the "renice" command, no? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new feature
On Thu, Mar 25, 2004 at 03:21:53PM -0500, Benjamin Reed wrote: > Daniel Macks wrote: > > >That's why there's the "renice" command, no? > > renice doesn't renice children of whatever you're renicing, does it? > It'd be a PITA to renice fink, the fink that fink spawns, 5 different > "make" sub-children, the shells those makes run, and so on... A child takes the priority of its parent when it's spawned, so renice of a process would carry into all future child processes. So one would only have to renice a make or two; and definitely *not* back to the level of fink itself, since TheSin explained the feature to be applied just to the *Script not fink as a whole. Which I agree is how a feature like this should work. > I still think this is a reasonable idea, and dead easy to implement... > Is there any reason not to do it? It's reasonable. I was just curious if it pushed beyond "more than one way to do it" into the land of feature creep. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: current CVS: out-of-order splitoffs?
On Fri, Mar 26, 2004 at 12:49:28PM -0500, Benjamin Reed wrote: > I'm running into an issue building ffmpeg and it seems that somehow > things are getting out of order when the splitoff stuff is happening. [...] > Somewhere along the line, the splitoffs are ending up out of order. > Since ffmpeg-dev has "include/" as it's file spec, obviously things bomb > if libavformat1-dev wants to get a single header first. I glanced > through the code but couldn't figure out where this is happening. > Somewhere along the line are we getting splitoff stuff into a hash > rather than preserving order with arrays or something? Exactly. > I can only assume this is a recent change, packages would be breaking > left and right if things got out of order out in the field... This change was in my r1.238->r1.239 patch to PkgVersion.pm on March 11. TTBOMK, this is the first report of a problem. But whatever, I just committed a quick'n'dirty fix...let me know if it works for you. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: How to test the two variants of a package?
On Thu, Apr 08, 2004 at 02:48:37AM +0200, Martin Costabel wrote: > Daniel E. Macks wrote: > > > >Variants make it easier for the Maintainer to maintain multiple > >variants (in the conceptual, not Fink sense) of a package. It relieves > >what was becoming (became?) an unscalable mess of -pmXXX (and -pyXXX > >and -rbXXX, etc.) packages. Do you really believe that all those > >modules were tested with each perl version? > > You are saying that the variants system makes it easier to keep dead and > untested packages, exactly what I think is dangerous for Fink. I don't > really want to go into what I think about -pm560 and -pm580 packages on > Panther. What about when fink gets perl583, and then people want packages for it? Should we not provide any -pm583, or scrap all the -pm581? Or just copy the .info and remember to change all the versioned Depends packages. If we provide both, then even the existing package probably has to be modified anyway (the manpage files probably conflict). So why not make it as easy as possible? When a new version of foo.pm is published that requires different tweaking than the previous, why should we have to duplicate all the tweaking info in multiple .info files? > As for -py22 and -py23, I don't see the need to have both > variants for a given package. If it works with python23, why create a > -py22 variant? Because people want to use the a python module with python22! Or are you under the mistaken impression that all python modules are python-version-independent? > >Having a separate .info file for each variant makes it difficult for a > >Maintainer to keep variants in sync. It's too easy to forget to change > >one Depends package, or make a typo when applying the same tweak to a > >new revision of several files. > > I admit that this may be true in some situations. But in real life, > variants are not just differing configure options. You also have to > change other parts of Compile- or InstallScripts, and there you can also > forget to update some of the variants. Even for dependencies, you > should consider each variant separately whether it needs them. > I am not opposed to others using the variant system, I only wanted to > say that I don't see (yet?) how it can be useful for me, The simplest usage, language-versions, makes it easy to make sure you don't accidentally have foo-pmXXX depend on bar-pmXXY. It is now easy to say "use the same XXX everywhere in this .info file". In fact, my initial proposal for variants was *just* perl-language-version. But people were concerned that this was a highly specialized feature, and that it should be implemented so that it could be extended in the future should the need arise. While I was working on it, the need arose, in the form of a small flood of "I want package X to be compiled with feature Y enabled" requests. So I tweaked the language-variant support to handle other types of things. > and that I see the danger of untested packages becoming more widespread. I agree. Committers have done an outstanding job thus far keeping the packages in the dists mostly-working. We'll just have to be extra-vigilant, and not be afraid to ask submitters "do you really need variant X?". dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How to test the two variants of a package?
On Thu, Apr 08, 2004 at 09:20:25AM +0200, Martin Costabel wrote: > > BTW, fink validate doesn't yet seem to understand variants completely: > > % fink validate bluefish.info > Error: Package name may only contain lowercase letters, numbers,'.', '+' > and '-' (bluefish.info) > > Same for fink validate gnome2, so it's not a bug in bluefish.info, but > in fink validate. Yup. Unfortunately, I was away for a few days and missed Dave's "is 0.20.0 release okay?" email until too late. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How to test the two variants of a package?
On Thu, Apr 08, 2004 at 10:22:12AM +0200, Martin Costabel wrote: > Mich?le Garoche wrote: > [] > >So, if you would be so kind to have a look at it now > > I guess there need to be some Conflicts/Replaces fields or another > upgrade strategy, but again I don't know how this is handled within the > variants system. You're getting yourself *way* too worked up about variants, Martin. It's all just a game I play with the .info -> package db. By the time a user does anything other than 'fink index', there is no evidence that variants ever existsed. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Variant test for block of dependencies
On Thu, Apr 08, 2004 at 10:30:18AM -0700, Remi Mommsen wrote:
> Hi,
>
> I'm trying to figure out how to use the variant system. I'd like to use
> it for roofitcore package, where the essential difference between
> roofitcore and roofitcore4 is the depenency on the root version (root3
> or root4). I'd like to have a statement similar to
>
> Depends: <<
> %N-shlibs (=%v-%r),
> (%type_raw[root_version] = 4) { root4 | root4-cernlib, root4-shlibs |
> root4-cernlib-shlibs }
> (%type_raw[root_version] = .) { root3 | root3-cernlib, root3-shlibs |
> root3-cernlib-shlibs }
> <<
>
> However, AFAIK there is no support for having a block of dependencies
> for a given case.
That's correct. Right now you would have to do the conditional for
each package:
Depends: <<
%N-shlibs (=%v-%r),
(%type_raw[root_version] = 4) root4 | (%type_raw[root_version] = 4) root4-cernlib,
(%type_raw[root_version] = 4) root4-shlibs | (%type_raw[root_version] = 4)
root3-cernlib-shlibs,
(%type_raw[root_version] = .) root3 | (%type_raw[root_version] = .) root3-cernlib,
(%type_raw[root_version] = .) root3-shlibs | (%type_raw[root_version] = .)
root3-cernlib-shlibs,
<<
Are you stuck with 'Type: root_version (4 .)' or could you use (3 4)
instead? The latter would let you do
Depends: <<
%N-shlibs (=%v-%r),
root%type_raw[root_version] | root%type_raw[root_version]-cernlib,
root%type_raw[root_version]-shlibs | root%type_raw[root_version]-cernlib-shlibs
<<
> Is it possible to implement something like this?
Wouldn't be hard to do. The only reason I didn't was because I didn't
feel like having to write a routine to handle paren balancing given
that the underlying functionality was already available (though I
wasn't thinking how ugly it might become:).
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Variant test for block of dependencies
On Thu, Apr 08, 2004 at 11:39:56AM -0700, Remi Mommsen wrote:
> On Apr 8, 2004, at 11:07 AM, Daniel Macks wrote:
> >On Thu, Apr 08, 2004 at 10:30:18AM -0700, Remi Mommsen wrote:
> >>
> >>I'm trying to figure out how to use the variant system. I'd like to
> >>use it for roofitcore package, where the essential difference between
> >>roofitcore and roofitcore4 is the depenency on the root version (root3
> >>or root4). I'd like to have a statement similar to
> >>
> >>Depends: <<
> >> %N-shlibs (=%v-%r),
> >> (%type_raw[root_version] = 4) { root4 | root4-cernlib, root4-shlibs |
> >>root4-cernlib-shlibs }
> >> (%type_raw[root_version] = .) { root3 | root3-cernlib, root3-shlibs |
> >>root3-cernlib-shlibs }
> >><<
> >>
> >>However, AFAIK there is no support for having a block of dependencies
> >>for a given case.
> >
> >That's correct. Right now you would have to do the conditional for
> >each package:
> >
> >Depends: <<
> > %N-shlibs (=%v-%r),
> > (%type_raw[root_version] = 4) root4 | (%type_raw[root_version] = 4)
> >root4-cernlib,
> > (%type_raw[root_version] = 4) root4-shlibs | (%type_raw[root_version]
> >= 4) root3-cernlib-shlibs,
> > (%type_raw[root_version] = .) root3 | (%type_raw[root_version] = .)
> >root3-cernlib,
> > (%type_raw[root_version] = .) root3-shlibs | (%type_raw[root_version]
> >= .) root3-cernlib-shlibs,
> ><<
>
> Yep, that's what I suspected.
>
> >Are you stuck with 'Type: root_version (4 .)' or could you use (3 4)
> >instead? The latter would let you do
> >
> >Depends: <<
> > %N-shlibs (=%v-%r),
> > root%type_raw[root_version] | root%type_raw[root_version]-cernlib,
> > root%type_raw[root_version]-shlibs | root%type_raw[root_version]-cernlib-shlibs
> ><<
>
> That's a neat solution. However this would produce a package named
> roofitcore3 instead of roofitcore, isn't it?
Correct. I specifically made this easy to do, since it's in keeping
with fink shlib package naming policy. If there are going to be
multiple bar each the same but tied to a specific X of fooX it makes
some sense to have them as barX.
> No real problem as there is only one package depending on roofitcore
> which is going to be updated, too. However, it will break the
> automatic update for users having roofitcore installed.
If I understand correctly, the project at hand is to have a single
.info that gives roofitcore and roofitcore4 (both of which already
exist) and it would be a confusing upgrade because there would
suddenly be roofitcore3 in place of roofitcore?
> Thus I'm faced with the choice between a neat info file and a
> (minor) annoyance for (a few?) users. What's your opinion?
You could have (for a while) a roofitcore package that was just a
bundle for roofitcore3. That way when they update their roofitcore,
they wind up deleting their current roofitcore actual package and
getting on the versioned bandwagon. Or you could just dump roofitcore
altogether and have roofitcore[34] Conflicts/Replaces roofitcore (in
addition to each other as necessary). Users who have already installed
it won't be affected, since it's okay to have a package installed that
has no .info, but as soon as they want to update, 'fink list
roofitcore' will list the 3 and 4 variants.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] More issues with variants
On Sat, Apr 10, 2004 at 06:02:09PM -0700, Remi Mommsen wrote: > > Anyhow I plan to change it to roofitcore-root3 and roofitcore-root4 Excellent solution! > Package: roofitcore-%type_pkg[root_version] > Type: root_version (root3 root4) > > Depends: %type_raw[root_version] > > SplitOff: << >Package: %N-shlibs >Description: Shared libs of RooFitCore built against %type_raw[root_version] > << > > Which works as expected except for two points: > > (1) The Description is not parsed. [no %-expansion is performed] It never has been. But it looks like it probably should be. > (2) 'fink validate' is not happy: > Validating package file roofitcore.info... > Warning: File name should be roofitcore--1.00.04-12.info or > roofitcore-.info (roofitcore.info) I hadn't considered this usage of variants. > I'd be glad to hear any suggestions how to proceed. Pull fink from CVS HEAD, where these are fixed:). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] More issues with variants
On Sun, Apr 11, 2004 at 03:34:10PM -0700, Remi Mommsen wrote: > On Apr 11, 2004, at 1:14 PM, Daniel Macks wrote: > >On Sat, Apr 10, 2004 at 06:02:09PM -0700, Remi Mommsen wrote: > > Soon, the variant system can make coffee, too (-; -decaf, -regular, -sugar? > Can we release a new fink version which incorporates these changes? > I'd like to make the new package available as soon as possible. This is the first major stress-testing of variants, so soon as y'all stop uncovering 1-2 things like this each day, I'll sync branch_0_20 and then we can start bugging drm to put out 0.20.1. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
On Mon, Apr 12, 2004 at 01:36:48PM -0400, David R. Morrison wrote: > > How will we handle such provides from system-perl done in the virtuals? > > Excellent question! Can we easily get fink to think that the virtual > system-perl has provided certain things? Absolutely! There are already a number of "provides" in the virtual packages (and some are mentioned in the brand-spankin'-new virtpackage FAQ). It's just a matter of editing VirtPackage.pm. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [Fink-users] Problem updating fink
On Mon, Apr 12, 2004 at 11:45:21PM +0200, Martin Costabel wrote: > Duncan Galloway wrote: > >Hi all, > > I'm having trouble running "fink selfupdate", every time I get the > >error "Failed: No mirror site list file found for mirror 'gnu'.". It > >does this whether I use cvs or rsync; I don't understand what is the > >problem here. I'm running package manager 0.19.2 and distribution > >version 0.7.0.cvs on Panther (Mac OS X 10.3.3). Anyone have any idea > >what's going on here? > > What is the status of your fink-mirrors package? Maybe its needs > reinstalling? This is the latest of many such problem reports. It's easy enough to have a hard-coded default for this mirror (as we do for other mirrors). But it seems like there's an underlying problem with "Essential: yes" of fink-mirrors not being respected? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Source field in var/lib/dpkg/available
On Mon, Apr 19, 2004 at 01:49:09PM +0300, Antti Tapaninen wrote: > > I'd like to have an easy way to determine which packages have been > packaged and compiled from a mutual source. In debian, there doesn't seem > to be an easy tool to do this, but so far I've parsed the available/status > files myself. Package entries like zsh, zsh-doc and zsh-static all share > the same Source field entry, in this case 'zsh'. > > I was a bit surprised to notice that the same field in Fink 0.7.0 is > useless, since it's always the same as Package field. > Is this subject to change anytime soon? It would appear (from browsing the fink core code CVS) that we've always done it that way. That's probably because the Debian Packaging Manual states: 5.6.1 Source - This field identifies the source package name. So I don't think fink is going to change anytime soon:) What you would need is the data from the .info files (which describe the build process for each package). Unfortunately for you, the sources there often contain macros for the package name. That makes a pretty ugly manual parsing task. There's a feature in the not-yet-released version of fink that lets you extract this type of info directly from fink's own database. You will be able to fink dumpinfo --source > output.txt (or something like that...the exact syntax isn't quite set yet) and then you can browse a giant listing of all packages (or optionally limitted by package name) and their macro-expanded tarball names at your leisure. Would that provide the kind of info you want? > Otherwise I really like Fink and the packaging work compared to Debian, > thanks everyone for the hard work. :) You're quite welcome! dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Package and Version strings (was Re: [Fink-i18n] [translate] Fwd: web/xml/packaging packaging.en.xml,1.23,1.24)
On Tue, Apr 20, 2004 at 12:59:41AM +0200, Mich?le Garoche wrote: > > Could it be possible to note in chapter reference, for field package > that the name should begin with a letter and that the version could not > have letters at beginning ? I think the second part is recommended but not required by Debian Policy (see the link from Epoch) but it sure makes things less confusing! Any input from other admin-folks on a policy statement? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Package and Version strings (was Re: [Fink-i18n] [translate] Fwd: web/xml/packaging packaging.en.xml,1.23,1.24)
On Tue, Apr 20, 2004 at 01:24:29AM +0200, Mich?le Garoche wrote: > Le 20 avr. 2004, ? 1:13, Daniel Macks a ?crit : > >On Tue, Apr 20, 2004 at 12:59:41AM +0200, Mich?le Garoche wrote: > >> > >>Could it be possible to note in chapter reference, for field package > >>that the name should begin with a letter and that the version could > >>not have letters at beginning ? > > > >I think the second part is recommended but not required by Debian > >Policy (see the link from Epoch) but it sure makes things less > >confusing! Any input from other admin-folks on a policy statement? > > Quoted at the end of paragraph 5.6.11 > <http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f- > Version> > > [Quote] > Note that the purpose of epochs is to allow us to leave behind mistakes > in version numbering, and to cope with situations where the version > numbering scheme changes. It is not intended to cope with version > numbers containing strings of letters which the package management > system cannot interpret (such as ALPHA or pre-), or with silly > orderings (the author of this manual has heard of a package whose > versions went 1.1, 1.2, 1.3, 1, 2.1, 2.2, 2 and so forth). > [/Quote] I interpret that to mean Epoch is not designed just keep incrementing as a hack to get arbitrary versions to sort correctly (for example to use 1:2.0 to make 2.0 be higher than 2.0pre1). It doesn't seem to forbid versions "a1", "a2", "b1", etc. which *do* sort correctly. > and for upstream version at the beginning of the same paragraph > [Quote] > The upstream_version may contain only alphanumerics[28] and the > characters . + - : (full stop, plus, hyphen, colon) and should start > with a digit. > [/Quote] That's the exact sentence on which I based my comment, in particular the "should start with" being weaker (a suggestion) than "may contain only" (a requirement). The description of the sorting alogrithm does not require a leading digit, nor does the parsing alogrithm for %f (for full-package and .deb names) and other things that handle this information. See for example Fink's SourceForge Tracker bugs #766799. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Still >500 packages not moved from 10.2 tree, need help
On Mon, Apr 19, 2004 at 04:46:03PM -0700, Ben Hines wrote: > Still > 500 pkgs show 'not moved' from 10.2-gcc3.3 to 10.3. > > http://homepage.mac.com/bhines/finknotmoved.html Something's wrong...you list gnome/pygtk2-py* and libs/term-ansicolor-rb, but they are in 10.3. Shuold this maybe go on a Wiki somewhere or as a file in CVS so we can mark the disposition? I know some of mine on that list are obsolete... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] aquaterm 1.0-1 doesn't compile
On Mon, Apr 19, 2004 at 09:57:53PM +0200, salvo mac wrote: > Hi all, > > I would just understand why aquaterm 1.0-1 here in my system doen't > compile and doesn't permit to compile gnuplot. > > ld: warning prebinding not disabled because (__LINKEDIT segment > (address = 0x1b000 size = 0x24000) of > build/AquaTerm.app/Contents/MacOS/AquaTerm overlaps with __LINKEDIT > segment (address = 0xf000 size = 0x25000) of > /usr/local/lib/libaquaterm.1.0.0.dylib I don't know why the actual ld error happens > Touch build/AquaTerm.app > cd /sw/src/aquaterm-1.0-1/AquaTerm1.0.a2/src > /usr/bin/touch build/AquaTerm.app > ** BUILD SUCCEEDED ** > cp: /tmp/AquaTerm.dst/sw/lib/libaquaterm.1.0.0.dylib: No such file or > directory But you might want to email the Maintainer and tell him to fix his scripts so that they stop immediately upon an error rather than continuing (and giving more errors that obscure the actual one). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Source field in var/lib/dpkg/available
On Tue, Apr 20, 2004 at 04:25:37PM +0300, Antti Tapaninen wrote:
> On Mon, 19 Apr 2004, Daniel Macks wrote:
> >
> > fink dumpinfo --source > output.txt
> >
> > (or something like that...the exact syntax isn't quite set yet) and
> > then you can browse a giant listing of all packages (or optionally
> > limitted by package name) and their macro-expanded tarball names at
> > your leisure. Would that provide the kind of info you want?
>
> Probably, but then I would have to make two separate tools, one for
> standard debian and other for Fink. :)
Wait, I think I answered the wrong question ("source" meaning the
tarball of .c files, not the parent package name).
> I still don't understand why Fink needs to keep both Source and Package
> fields in the final .deb file information identical, I managed to modify
> fink packaging routines so that it'll generate the packages into same form
> as Debian does. This way I can easily determine for my owns statistics the
> original source and version, of which the package(s) have been generated.
>
> Here's the change that I made:
>
> --- /sw/lib/perl5/Fink/PkgVersion.pm.orig Tue Apr 20 15:52:37 2004
> +++ /sw/lib/perl5/Fink/PkgVersion.pm Tue Apr 20 16:09:47 2004
> @@ -1722,7 +1722,7 @@
> $instsize = $self->get_instsize("$destdir$basepath");
> $control = < Package: $pkgname
> -Source: $pkgname
> +Source: $self->{_expand}->{N}
> Version: $version
> Section: $section
> Installed-Size: $instsize
That indeed does look s like a bug. Appears to be unchanged when
SplitOffs (child packages) got implemented.
At least for fink, is the kind of thing you want?
% fink showparent gle3-shlibs
gle3-shlibs's parent is gle3.
% fink showparent gle3
gle3 is the parent.
% fink splitoffs gle3
gle3 has 1 child:
-> gle3-shlibs
% fink splitoffs gle3-shlibs
gle3-shlibs is a child, it's parent gle3 has 1 child:
-> gle3-shlibs
It's in fink now, but is completely undocumented.
> The tool that I started working on yesterday is at
> http://www.hut.fi/~aet/dpkg-glue. If anyone knows the correct spell that
> does about the same with standard dpkg/apt tools, please let me know. :)
The dpkg-* tools are the usual way to construct and manipulate .deb
archives and the various databasefiles. Have you looked at dpkg-query,
dpkg-scanpackages, and dpkg-deb? OTOH, it may be more efficient to
just read the files themselves as you are doing now.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Package and Version strings (was Re: [Fink-i18n] [translate] Fwd: web/xml/packaging packaging.en.xml,1.23,1.24)
Okay, any objections to saying that Version and Revision "must" begin with numbers? Or should we weaken the statement slightly to say "should" begin with numbers? FWIW, there are currently about 5 packages that do not conform to this. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] cvs inject today
On Thu, Apr 22, 2004 at 02:52:37PM -0600, TheSin wrote: > is this normal ?? > > Reading package info... > Could not load Text::DelimMatch so cannot handle ConfigureParam > conditionals. > Updating package index... done. It is (for the moment, since this morning) if you don't have text-delimmatch-pm installed:) I needed that module to implement conditional syntax in ConfigureParams (and eventually conditional groups instead of just single packages in Depends). But it's not part of perl-core and no release of fink needs it so I didn't want to make that package Essential right now. And it's only needed by CVS HEAD if you're experimenting with these new features so no reason to force people to install it yet. I.e., it's exactly what it says it is, or from the CVS commit log: Note that conditionals in ConfigureParams requires Text::DelimMatch, but text-delimmatch-pm is non-Essential. Warn (only once, Clef:) if not found and skip cond eval. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] cvs inject today
If by the time this functionality goes into a fink release that module is still needed, then yes. dan On Thu, Apr 22, 2004 at 03:49:30PM -0600, TheSin wrote: > okay so this will become an essential pkg then? > --- > TS > http://southofheaven.org > Chaos is the beginning and end, try dealing with the rest. > > On 22-Apr-04, at 3:34 PM, Daniel Macks wrote: > > >On Thu, Apr 22, 2004 at 02:52:37PM -0600, TheSin wrote: > >>is this normal ?? > >> > >>Reading package info... > >>Could not load Text::DelimMatch so cannot handle ConfigureParam > >>conditionals. > >>Updating package index... done. > > > >It is (for the moment, since this morning) if you don't have > >text-delimmatch-pm installed:) > > > >I needed that module to implement conditional syntax in > >ConfigureParams (and eventually conditional groups instead of just > >single packages in Depends). But it's not part of perl-core and no > >release of fink needs it so I didn't want to make that package > >Essential right now. And it's only needed by CVS HEAD if you're > >experimenting with these new features so no reason to force people to > >install it yet. I.e., it's exactly what it says it is, or from the CVS > >commit log: > > > > Note that conditionals in ConfigureParams requires Text::DelimMatch, > > but text-delimmatch-pm is non-Essential. Warn (only once, Clef:) if > > not found and skip cond eval. > > > >dan > > > >-- > >Daniel Macks > >[EMAIL PROTECTED] > >http://www.netspace.org/~dmacks > > > > > > > >--- > >This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > >For a limited time only, get FREE Ground shipping on all orders of $35 > >or more. Hurry up and shop folks, this offer expires April 30th! > >http://www.thinkgeek.com/freeshipping/?cpg=12297 > >___ > >Fink-devel mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/fink-devel > > > > > > --- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > ___ > Fink-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Source field in var/lib/dpkg/available
On Thu, Apr 22, 2004 at 01:19:56PM +0300, Antti Tapaninen wrote:
> On Tue, 20 Apr 2004, Daniel Macks wrote:
> > >
> > > -Source: $pkgname
> > > +Source: $self->{_expand}->{N}
> > > Version: $version
> > > Section: $section
> > > Installed-Size: $instsize
> >
> > That indeed does look s like a bug. Appears to be unchanged when
> > SplitOffs (child packages) got implemented.
>
> Ok, hopefully this gets fixed on future releases?
I just corrected it in fink core CVS. Whenever that gets released, any
package compiled *after* that will be correct. If you're using
apt-get, we probably won't be recomiling those binary distributions
anytime soon. So if you're going to be relying on this field for
something, you'd probably want to recompile your pre-existing packages
(which could take a lot of CPU time, but is not difficult to do). If
you really want to get a jump on this and are familiar with CVS, feel
free to use the bleeding edge ( :)
Thanks for finding this!
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New FAQ entry about "Failed: can't batch-install packages"
On Mon, Apr 26, 2004 at 05:18:35PM +0200, Christian Schaffner wrote: > On 26.04.2004, at 17:11, Martin Costabel wrote: > > > >I don't understand the usefulness of having > > > > Conflicts: svn-client-ssl (<= 0.26.0-2) > > Replaces: svn-client-ssl (<= 0.26.0-2) > > > >in a splitoff named svn-client-ssl. Doesn't every package conflict > >with and replace older versions of itself? Am I missing something? > > This is because there was a stand-alone package called 'svn-client-ssl' > before it appeared as a splitoff. At the time i did this (couple of > years ago...) i thought it made sense. I am no longer sure now, but i > think it doesn't hurt either. Under dpkg, there can never be more than one version (-revision) of a given real package installed at once. By the time dpkg sees things, there is no distinction between a parent and splitoff: each is a full and independent package. OTOH, fink knows this and for a couple of months has been (or at least should be:) automatically clearing the entry for a package from its own Conflicts/Replaces lists. This behavior is documented in the Packaging Manual. You can run 'dpkg -I' on the .deb with to see what happened, or if you're living on the CVS HEAD, 'fink dumpinfo -f conflicts,replaces whatever-pkg'. Tech note: this was implemented to make it easier to write mutually-exclusive variants and not have to worry about how a syntax to list "all variants but this one" in those fields. One simply lists *all*, and lets fink worry about removing %n. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Enhanced Conditionals Syntax
Several people have requested that 1) conditionals be implemented in
ConfigureParams (and perhaps the *Files and *Set* fields), and 2) a
way to apply a single conditional to more than one Depends
package. So...
1) It's easy to implement the same parenthesized conditional syntax on
CParams so that it applies to the next "word" (i.e., string of
non-whitespace and whitespace-in-quoted-string chars). That means
instead of having to do shell script with if/then/else to control
./configure flags, one could just say:
ConfigureParams: (%type_pkg[-x11]) --with-x --mandir=%p/share/man
>From there, it doesn't seem like it would be hard to give the same
treatment to Files (and DocFiles). That way it would be easy for only
the -py21 variant to install a missing-feature-compatibility module or
packages where certain variants are "enhancements" that require
additional support/documentation/whatever files. Along with this,
fields that contain information about files (InfoDocs, Shlibs, etc.)
would disregard any entries for files that aren't actually in that
particular variant of the package. (This last is a pretty good sanity
check to implement regardless). Also, some package variants may need
slightly different CPPFLAGS (for example, setting configure options
for packages that don't use autconf).
2) Certain variants require more than one Depends (and related field)
addition. Currently, a conditional only applies to the single
following package. It's easy to implement this using a syntax of:
BuildDepends: (%type_raw[-nox] != -nox) { gtk+, gtk+-dev }
And probably extensible to other conditionalizable fields.
Thoughts?
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: fink fink.8.in,1.18,1.18.16.1 fink.conf.5.in,1.12,1.12.2.1 ChangeLog,1.223.2.2,1.223.2.3
fink.8.in r1.18 -> r1.19 fink.conf.5.in r1.12 -> r1.13 ChangeLog r1.224 -> r1.225 dan On Sat, May 08, 2004 at 01:52:16PM -0400, David R. Morrison wrote: > > You called this a "backport" but I cannot find this in HEAD... only in the > branch... > > From: Daniel Macks <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: fink fink.8.in,1.18,1.18.16.1 fink.conf.5.in,1.12,1.12.2.1 > ChangeLog,1.223.2.2,1.223.2.3 > Date: Tue, 04 May 2004 04:50:43 + > > Update of /cvsroot/fink/fink > > Modified Files: > Tag: branch_0_20 > fink.8.in fink.conf.5.in ChangeLog > Log Message: > Backport: document -K and -k in fink and fink.conf manpages. > > > Index: fink.conf.5.in > === > RCS file: /cvsroot/fink/fink/fink.conf.5.in,v > retrieving revision 1.12 > retrieving revision 1.12.2.1 > diff -u -d -r1.12 -r1.12.2.1 > --- fink.conf.5.in19 Mar 2004 08:16:01 - 1.12 > +++ fink.conf.5.in4 May 2004 04:50:41 - 1.12.2.1 > @@ -263,14 +263,28 @@ > .Bl -tag -width flag > .It Cm KeepRootDir: Ar boolean > Causes Fink not to delete the > -.Pa @PREFIX@/src/root-name-version > +.Pa @PREFIX@/src/root-[name]-[version]-[revision] > directory after building a package. Defaults to false. > Be careful, this option can fill your hard-disk quickly! > +Passing > +.Cm fink > +the > +.Cm -K > +flag has the same effect, but only operates on that single > +.Cm fink > +invocation. > .It Cm KeepBuildDir: Ar boolean > Causes Fink not to delete the > -.Pa @PREFIX@/src/name-version > +.Pa @PREFIX@/src/[name]-[version]-[revision] > directory after building a package. Defaults to false. > Be careful, this option can fill your hard-disk quickly! > +Passing > +.Cm fink > +the > +.Cm -k > +flag has the same effect, but only operates on that single > +.Cm fink > +invocation. > .El > .\" > .\" > > Index: fink.8.in > === > RCS file: /cvsroot/fink/fink/fink.8.in,v > retrieving revision 1.18 > retrieving revision 1.18.16.1 > diff -u -d -r1.18 -r1.18.16.1 > --- fink.8.in 6 Oct 2003 13:44:07 - 1.18 > +++ fink.8.in 4 May 2004 04:50:41 - 1.18.16.1 > @@ -43,6 +43,14 @@ > Causes fink to be more verbose, opposite of --quiet > .It Cm -y, --yes > Assume default answer for all interactive questions > +.It Cm -K, --keep-root-dir > +Causes Fink not to delete the > +.Pa @PREFIX@/src/root-[name]-[version]-[revision] > +directory after building a package. > +.It Cm -k, --keep-build-dir > +Causes Fink not to delete the > +.Pa @PREFIX@/src/[name]-[version]-[revision] > +directory after building a package. > .El > .\" > .\" > > Index: ChangeLog > === > RCS file: /cvsroot/fink/fink/ChangeLog,v > retrieving revision 1.223.2.2 > retrieving revision 1.223.2.3 > diff -u -d -r1.223.2.2 -r1.223.2.3 > --- ChangeLog 29 Apr 2004 03:08:21 - 1.223.2.2 > +++ ChangeLog 4 May 2004 04:50:41 - 1.223.2.3 > @@ -1,3 +1,8 @@ > +2004-05-03 Daniel Macks <[EMAIL PROTECTED]> > + > + * fink.8.in: Document the -K and -k flags. > + * fink.conf.5.in: Mention -K and -k in the Keep*Dir sections. > + > 2004-04-28 Daniel Macks <[EMAIL PROTECTED]> > > * Makefile: Use /usr/bin/perl for tests since that's how fink runs. -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Type: NoSource bug (Re: [Fink-beginners] installing KDE-Again!-)
On Fri, May 07, 2004 at 03:15:38PM +0200, Martin Costabel wrote: > > To whoever did this: The "Type:" field apparently changed from being > case insensitive to case sensitive some time ago. There are still quite > a few packages in the 10.2-gcc3.3 tree that have "Type: NoSource". This > is not respected any more, so that fink tries to download a > non-existent foo.tar.gz tarball. > > Please either make this case insensitive again or fix all the packages > that still have this. Maybe fields other than Type: are concerned, too? I think this was my doing going into the 0.20.0 release. Was fixed (convert all Type major values to all lowercase) in CVS HEAD several weeks ago, but then never back-ported to the 0.20 branch until a few minutes ago. The situation as you found was that all Type values were suddenly treated in their exact case. I just checked all of 10.2-gcc3.3 and 10.3 for any capitalized Types, and all I found was "NoSource" in autoconf25 and automake in 10.2-gcc3.3 (both stable and unstable). Which I just lowercase-ified. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/editors vim.info,1.8,1.9
jswhit committed: > Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/editors > > Modified Files: > vim.info > Log Message: > New upstream verion. > > Index: vim.info >=== > RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/editors/vim.info,v > retrieving revision 1.8 > retrieving revision 1.9 > Package: vim > +Source: ftp://ftp.vim.org/pub/editors/vim/unstable/unix/vim-%va.tar.bz2 > +Version: 6.3 > +Revision: 1 > +SourceDirectory: vim63a I understood the vim webpage to say that this version is "6.3a" (which is consistent with the Source and SourceDirectory) not "6.3" as your Version...that this is a prerelease of a future 6.3 version. If so, how do you plan to handle the versioning of that future package? (FWIW, "6.3rel" sorts later than "6.3a", but there are probably other solutions as well). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shared binary-darwin-powerpc directories
On Tue, May 25, 2004 at 10:09:16AM -0500, Chris Dolan wrote: > I'm hoping someone else has already solved this problem more elegantly > that I did... > > Several machines in my office run Fink. I want to be able to share > .deb files that any of machine builds to save compile time on other > machines. [solution snipped] Just a thought based on what you're doing now... > What this accomplishes: > * any freshly built .deb files get written to the shared volume in the > appropriate binary-darwin-powerpc directories > * any instance of fink rebuilds the local /sw/fink/debs dir before > running. This is needed so you can know if anyone else has built > something since you last ran fink. Note that in my case, the debs dir > cannot be stored on the server because OSX can't build symlinks on SMB > volumes. What happens if you patch fink itself to store an actual copy of the .deb in /sw/fink/debs instead of a symlink to the file dists/? That way you could have /sw/fink/debs on your server and not need the recurse-and-symlink wrapper. Look in /sw/lib/perl5/Fink/PkgVersion.pm at around line 2332 for the symlink_f call. OTOH, if you only use fink (or FinkCommander, don't know about dpkg or dselect) to install packages, do you even need those /sw/fink/debs things at all? According to They were not present in early versions of fink, and glancing at the current code it appears that the /sw/fink/debs file is only used if the dists/... .deb file is not present. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl module File::Temp 0.14 needed, but Perl 5.8.1 has 0.13
On Thu, May 27, 2004 at 05:09:26PM +0200, Christian Schaffner wrote: > Hey > > > I am trying to port svk (<http://svk.elixus.org/>) to fink for Perl > 5.8.1 (since this is the perl version the subversion package uses). Svk > needs File::Temp >= 0.14, but the system perl (5.8.1) has only version > 0.13. > > What would be the recommended solution here? Port whatever the current CPAN version of File::Temp is? The existing (actual, != perlXXX-core provided) file-temp-pmXXX is/are un-maintained, so feel free to post a new and improved one on the Package Submissions tracker... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl module File::Temp 0.14 needed, but Perl 5.8.1 has 0.13
On Thu, May 27, 2004 at 11:38:42AM -0400, Daniel Macks wrote:
> On Thu, May 27, 2004 at 05:09:26PM +0200, Christian Schaffner wrote:
> >
> > I am trying to port svk (<http://svk.elixus.org/>) to fink for Perl
> > 5.8.1 (since this is the perl version the subversion package uses). Svk
> > needs File::Temp >= 0.14, but the system perl (5.8.1) has only version
> > 0.13.
> >
> > What would be the recommended solution here?
>
> Port whatever the current CPAN version of File::Temp is?
>
> The existing (actual, != perlXXX-core provided) file-temp-pmXXX is/are
> un-maintained, so feel free to post a new and improved one on the
> Package Submissions tracker...
[read the From just *after* sending that...I'm an idiot] Or just
commit it. An actual package should over-ride a virtual one,
especially if one Depends on it with version info ("Provides" does not
pass version info).
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [Fink-users] Upgrading to 10.3.4 and emacs21
On Thu, May 27, 2004 at 01:41:02PM -0400, Viktor Haag wrote: > > I upgraded my main machine to 10.3.4 today, and noticed that > you'll almost certainly need to rebuild emacs21 (and probably > emacsen-common, to be safe). > > Also, if you specifically set 'exec-path', after rebuilding > you'll need to adjust it to use > > /sw/lib/emacs/21.3.50/powerpc-apple-darwin7.4.0 Some other programs have similar kernel-versioned directories (probably g77 and other compilers? not sure what else). Oops. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] validating BuildDependsOnly
On Sun, May 30, 2004 at 11:33:20AM -0400, David R. Morrison wrote: > Dear Fink developers, > > For some time, I've wanted to have a way to validate that packages are > using the BuildDependsOnly field correctly. The test I want to employ > is this: if the package installs anything into /sw/include, it should > be declaring BuildDependsOnly to be true. (This doesn't guarantee that > the dylib symlinks have been put into the correct place, but it does > guard against someone overlooking the need to declare BuildDependsOnly > in a -dev splitoff.) > > Now this is a bit tricky: we need to do the validation on the .deb file > in order to see if anything was installed into /sw/include, but the > BuildDependsOnly declaration is in the .info file. And there is no way > to track which .info file was used to create a .deb file. Debian Packaging Manual 5.7 "User-defined fields" (though as I read it is self-contradictory), suggests we could maybe pass the BDO flag in the control file? If so, that would certainly be a cleaner solution than: > For each package, at build time I'll touch one of the following two files > (after creating the appropriate directory): > /sw/share/BuildDependsOnly/true/%n > or > /sw/share/BuildDependsOnly/false/%n dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [Fink-users] Upgrading to 10.3.4 and emacs21
On Fri, May 28, 2004 at 08:15:50AM +0200, Martin Costabel wrote: > Daniel Macks wrote: > >On Thu, May 27, 2004 at 01:41:02PM -0400, Viktor Haag wrote: > > > >>I upgraded my main machine to 10.3.4 today, and noticed that > >>you'll almost certainly need to rebuild emacs21 (and probably > >>emacsen-common, to be safe). > >>Also, if you specifically set 'exec-path', after rebuilding > >>you'll need to adjust it to use > >> > >> /sw/lib/emacs/21.3.50/powerpc-apple-darwin7.4.0 > > > >Some other programs have similar kernel-versioned directories > >(probably g77 and other compilers? not sure what else). Oops. > > Why oops? This shouldn't pose any problem and hasn't in the past. > These path names are not recomputed on the fly during runtime, they > are hard-coded in the package's executables and scripts. It's a problem if one has compiled any extensions or libraries that store files in kernel-versioned directory (or that hardcode such pathnames at compile-time). In that case, if one recompiles the main package under a different kernel, the libs are now either misplaced (and hence hidden) or broken (since they refer to incorect paths). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] multiple tarballs inside main source tarball?
On Thu, Jun 17, 2004 at 11:06:49AM -0400, Christian Pag? wrote: > Hi everyone, > > I am quite a newbie in fink devel... > I want to include a new package in fink, but this package has a > .tar.bz2 file which includes a src directory which contains multiple > tar.gz files along with corresponding .md5 files. These separate > .tar.gz files uncompress each one to a directory containing an src > directory. > > How can I deal with that in an .info file? The Source * and Source*-MD5 fields are only concerned with the actual thing you download; whether that tarball contains program sources, other tarballs, other checksums, and/or just a bunch of porn is not relevant. It's up to your *Script fields to know how to deal with it. In this case, you could have the PatchScript expand all the enclosed tarballs, and then the CompileScript go into each one and compile. If each enclosed thing seems like it should be its own fink package: you could either have lots of SplitOffs, or have multiple .info files, each one of which only expanded and compiled one of the enclosed tarballs. Or maybe there is somewhere that has each enclosed tarball available for direct and independent downloading (depending on licensing, fink could host these files also). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] 2nd draft: proposed policy on BuildDependsOnly
On Mon, Jun 21, 2004 at 04:35:46PM -0400, David R. Morrison wrote: > > Second draft: The BuildDependsOnly field [usual -dev case] > In addition, both packages should declare > BuildDependsOnly: true [...] > > There are some packages containing header files for which it's not > appropriate to declare BuildDependsOnly to be true. In that case, > the package should declare > BuildDependsOnly: false > and the reason must be given in the DescPackaging field. It does seem like we need a tri-state thing here. It feels funny to overload a boolean to accomplish that, but I can't think of a cleaner way, and this allows us to easily find these special-case packages and do .deb validation. The .info could use these three states: [usual boolean-true values | usual boolean-false values | blank/not-present] (note drm: just accepting "false" for the new special case makes this a four-state system) and (assuming dpkg makes a distinction between a blank value for a control field and that field not being listed) to get a third "value" for BDO while still being distinct from a .deb constructed from an "old" fink that did not encode this thing at all. > The BuildDependsOnly field should only be set if the package contains > header files, installed into /sw/include. Wording quibble: I don't think our parser currently makes a distinction between "present but blank" and "not present" for .info fields, and "set" sounds a lot like "boolean-true". Maybe something like "...should be _listed_..." would be clearer? Will think more...have to run now... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Shell startup should warn if init.* fails
Just had the N+1th user on #fink remove Fink and now have his shell startup abort when it tries to load /sw/bin/init.*. There is an error message about "no such file or directory" and then the remainder of the dotfile is skipped. Instead of just (for csh): source _file_ should we do: [ -x _file_ ] && source _file_ || echo "_some_warning_" That way they get a message about what is wrong (conceptually, not a Unix-ish) but dotfile processing continues so the environment they eventually get is as usual (modulo fink) instead of some mutant. OTOH, they do lose the useful-to-Unix-folks (including us, when they come for help) actual error message about what is wrong. Thoughts? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] os x 10.3.x tempnam() problem ?
On Wed, Jun 23, 2004 at 06:54:37PM +0200, Olivier Kaloudoff wrote: > > I'm experiencing problems compiling SGI FAM; > > OKs-Computer:/sw/src/fam/fam-2.6.10-patched/fam ikal$ make -e > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include > -DCONFIG_ETC_CONFIG_PATH=\"/usr/local/etc/fam.conf\" -D__FreeBSD__ -g > -O2 -c -o Listener.o `test -f 'Listener.c++' || echo './'`Listener.c++ > (...) > Listener.c++: In static member function `static void >Listener::create_local_client(TCP_Client&, unsigned int)': > Listener.c++:208: error: `tempnam' undeclared (first use this function) > Listener.c++:208: error: (Each undeclared identifier is reported only once > for >each function it appears in.) > make: *** [Listener.o] Error 1 > > Browsing the web for the tempnam() function, it found out that: > > #include is needed to make use of this function. > This is the case in Listener.c++ Various different platforms have their .h organized differently. On my OS X machine, the manpage for tempnam() says that this function is declared in stdio.h. But let's check just to be sure: % grep -lr tempnam /usr/include /usr/include/libc-gcc3.p /usr/include/php/ext/standard/file.h /usr/include/php/main/config.nw.h /usr/include/php/main/php_config.h /usr/include/stdio.h > Some users report that this function is broken on os x... I'm not able > to say I Googled for 'tempnam "os x"' and all the bug-reports I see mention OS X 10.0.x, or a general (not OS X specific) caveat about using this function (which is also mentioned in the manpage). Perhaps these users could be more specific about OS X version, and their own symptoms or other specific source of info? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [fink-commits] dists/10.3/unstable/main/finkinfo/utils rpm.info,NONE,1.1 rpm.patch,NONE,1.1
On Fri, Jun 25, 2004 at 08:13:54PM -0400, David R. Morrison wrote: > > > So I guess my suggestion for the second problem would be: when you are going > to revise one of your packages, you should probably start with the CVS > current version rather than a local copy. Whenever I try to commit something for which the CVS current verison has been changed, I get: cvs commit: Up-to-date check failed for `%s' cvs [commit aborted]: correct above errors first! and the commit does not go through. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [fink-commits] dists/10.3/unstable/main/finkinfo/utils rpm.info,NONE,1.1 rpm.patch,NONE,1.1
On Fri, Jun 25, 2004 at 08:19:15PM -0400, David R. Morrison wrote: > Hmmm... On second thought, maybe it wouldn't be so hard to modify what > happens when we check something in, so that the commit message is mailed > directly to the maintainer as well as to fink-commits (automatically). > Would that help? ...which would also help identify invalid Maintainer email addresses. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Changed MD5 handling: solved broken SF mirror problem?
I just patched fink in CVS HEAD to check MD5 checksum as each source tarball is downloaded and treat a mismatch as a download failure. For the end-user, that means if the download process succeeds but gets the incorrect file (hello, broken SF mirrors), he will immediately get the "try next mirror?" options. This solves a major problem useres are having and I'd love to get it into the next 0.20.x release, so if people could please test downloading and re-downloading with various broken and non-broken sites and let me know if it works... Thanks, dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Changed MD5 handling: solved broken SF mirror problem?
On Mon, Jun 28, 2004 at 08:25:55PM +0200, David H. wrote: > I just noticed that this breaks a convinince for developers. Because > wheny ou update an info file _without_ adding the MD5 sum (which you > presumably do not know by then) the download loop falsely assumes you > got the wrong file. So you end up "quitting" typing fink build foo > again, soy ou get the right loop this time. *If* I understand this all (and someone please correct me)... Now and previously, if one has a missing MD5, download gives a warning and then succeeds, and then unpacking fails. Previouosly if there was a *wrong* MD5 (for example, MD5 left over from previous version) download would succeed and then unpacking fail. Now, download itself fails in this situation. Conceptually, the whole goal here is that downloads that *appear* to work except for the fact that they fetch the wrong file should be considered a download failure. Having an incorrect MD5 in a .info is not even self- consistent, so I don't think we should allow non-failure in that case. For this scenario, commenting out the MD5 for the now-unknown file keeps the .info consistent, and allows 'fink fetch' (or the download phase of other fink modes) to succeed. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink false positive validation error
On Wed, Jun 30, 2004 at 12:49:43AM -0700, Blair Zajac wrote: > > fink validate 10.3/unstable/main/finkinfo/database/postgresql-python-all.info > Error: Package name may only contain lowercase letters, numbers,'.', '+' > and '-' > (postgresql-python-all.info). > > But this file uses Info2: > > Info2: << > Package: postgresql-python-py%type_pkg[python] > Type: python(2.1 2.2 2.3) This is a known issue with the 0.20.x branch. It works correctly in CVS HEAD, and will be in the future 0.21.x branch. Unfortunately, the changes to fix it were pretty complicated and happened well after 0.20.x branched, so we weren't enthusiastic about backporting them from HEAD to the branch. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Using GNU in the source URL always refers to Finks' GNU source mirror
On Wed, Jun 30, 2004 at 10:45:00AM -0700, Robert Leatherwood wrote: > I was trying to update the readline-4.3 package to include the readline > patches. So, I updated the readline.info file to grab the patches from GNU's > FTP site: > > Source: ftp://ftp.gnu.org/gnu/%n/%n-%v.tar.gz > > When I run fink, fink attempts to download from fink's GNU mirror sites not > GNU's site and since the patches do not exist on Fink's GNU mirrors, the > download fails. For kicks I renamed the source command URL to > http://gnu/ and it did the same thing. Looks like there is a BUG in Fink > that when it finds gnu anywhere in the URL, it defaults to Fink's GNU > mirrors. What happens when you use a site other than GNU? (i.e., is this a parsing error with ...gnu... URLs or something where fink thinks *everything* is a GNU-mirrored thing?) What are your fink mirror settings (set by 'fink configure' and stored in /sw/etc/fink.conf)? Are you perhaps configured to use fink-mirrors before the main sites? > I am running from the unstable tree using the latest Fink 20.5 (I > believe) on Mac OS X 10.3 If the above does not help, we need exact and definite info about versions, your configuration, what URLs it is accessing, etc. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: A suggestion
On Fri, Jul 02, 2004 at 12:55:27PM -0500, Corey Halpin wrote: > Daniel E. Macks wrote: > >Someone on -devel or #fink (perhaps jfm?) has a giant shell pipeline > >version of this (and that covers a lot of weird corner cases), that I > >encapsulated as fink-dep-check in my experimental dir. > > Cool. It didn't occur to me to look for (and through) people's > experimental directories. > If I were looking for your experimental dir, would I be able to find > it in cvs somewhere? Or does it just live in your sandbox on your machine? When fink folks talk about their experimental directories, they usually mean the "experimental" module in fink's CVS. You can browse at: http://cvs.sourceforge.net/viewcvs.py/fink/experimental/ and check-out using the usual CVS mechanisms or via that web interface. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Patching popt.info
On Sun, Jul 04, 2004 at 03:29:23PM -0700, Blair Zajac wrote: > Anybody mind if I patch popt.info to add this BuildDepends? > > RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/libs/popt.info,v > --- libs/popt.info 17 Jun 2004 00:41:09 - 1.1 > +++ libs/popt.info 4 Jul 2004 22:27:38 - > -Revision: 2 > +Revision: 3 > -BuildDepends: gettext-dev, gettext-bin > +BuildDepends: gettext-dev, gettext-bin, libiconv-dev Go for it. The Revision field relates to the resulting binary (.deb) of the package, not the .info, so if the package doesn't even compile with that missing (!= compiling incorrectly), you don't need to bump the Revision. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Virtual package handling
Okay, I'm getting mighty tired of "I can't find system-java14-dev" questions, and wondered how we could better handle these virtual packages. Currently, when VirtPackage does not find the requisite files for a given system-foo, the system-foo virtual package does not get created. That means users without the files have a fink that has never heard of system-foo. Two similar ideas came to mind, both aimed at giving these people at least some stub of a package that provides information on how to get the actual files. 1. When the files are not found, generate a package for system-foo that has a CompileScript that gives a verbose message about where to download whatever-is-needed and then fails. That way 'fink insall bar' where "bar:BuildDepends:x11-dev" will give the usual "do you want xfree86-dev or system-xfree86-dev" instead of assuming (usually incorrectly) to use the fink package, and then when user picks the system- one will get an error message about having to install X11User.pkg. 2. Have actual system-foo packages with "very low" version numbers that have the verbose-instructions/exit-with-error as PreInstScript. That way if the virtual package is present it will supercede this one. By having a real package as a backup, even binary-dist folks will benefit (cf. #1, where someone without X11User.pkg using apt would not get the new message). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Virtual package handling
On Tue, Jul 06, 2004 at 12:15:38PM -0400, Benjamin Reed wrote: > Mich?le Garoche wrote: > >Le 5 juil. 2004, ? 19:33, Daniel Macks a ?crit : > >> > >>1. When the files are not found, generate a package for system-foo > >> that has a CompileScript that gives a verbose message about where > >>to download whatever-is-needed and then fails. That way 'fink > >>insall bar' where "bar:BuildDepends:x11-dev" will give the usual > >>"do you want xfree86-dev or system-xfree86-dev" instead of assuming > >> (usually incorrectly) to use the fink package, and then when user > >>picks the system- one will get an error message about having to > >>install X11User.pkg. > > I've been changing VirtPackage.pm to show the 'status' field as "purge > ok not-installed" just like debian packages, for virtuals whose > dependencies aren't met. [...] > I'll keep tinkering on this, but I'm basically making it so they show up > in the package list, but as uninstalled, with a package DescDetail > saying how to download them. Yup, that's the kind of thing I was envisioning. > I'm now having to go in and look at other guts > in Fink and fix them, because it turns out they were treating the > package query from VirtPackage.pm wrong, but it always worked out (by > pure chance) because things that are in VirtPackage.pm don't also exist > in the dpkg database. I had fixed that in the virt_always_exists branch of VirtPackage.pm in preparation for implementing it. Didn't carry through because then I figured I'd ask on -devel if this was a good approach:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How should fink remove & purge handle editor recover files
On Tue, Jul 06, 2004 at 02:34:12PM -0700, Blair Zajac wrote: > I have the jove.info package which is a tiny version of Emacs, which I like > because it starts up fast. > > It has a global directory /var/tmp/jove where it dumps recover and > temporary files, unlike vi's .swp files which are in the same directory as > the file being edited. dmalloc already mentioned that this should maybe be in %p. Although I don't think that gets cleaned even at restart (unlike /var/tmp, IIRC). Maybe fink should install a StartupItem to do that? > So I'm wondering how best to handle files in /var/tmp/jove, which could be > important in case the editor may have crashed and somebody wants to recover > files from them. > > A couple of different methods of dealing with them that I see: > > 1) Having remove leave /var/tmp/jove alone and having purge delete > /var/tmp/jove. However, isn't purge for configuration files and not for > temporary files? Usually (or at least any "state" files, which could include crash- recovery things such as the files in question, which makes this a judgement call here:). > 2) Have a PreRmScript which tries to rmdir /var/tmp/jove. If there's > something in there, then rmdir fails and PreRmScript can ask the user to > D)elete it, L)eave it alone, or Q)uit and fail the remove. > > 3) Leave the files and /var/tmp/jove there regardless if remove or purge is > used. > > I like 2, but then people aren't used to having a PreRmScript take user > input, are they? Scripts can do whatever you want, but if you take this approach you also must implement *some* way to have it run unattended. Maybe a timeout with a default choice or somesuch? > 3) Would be nice if OS X cleaned up old files in /var/tmp/jove after they > are unread for two weeks like RedHat's tmpwatch package. If we don't have a tmpwatch package, have you considered porting it? Or maybe you could just have your jove pkg add an anacron (or whatever) task that handles just the jove/ subdirectory. If we had #3, I'd definitely say "leave them alone". But as-is, I lean towards #1. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How should fink remove & purge handle editor recover files
On Wed, Jul 07, 2004 at 08:52:11PM +0200, Robb Bean wrote:
> Blair Zajac schrieb:
> >
> >It has a global directory /var/tmp/jove where it dumps recover and
> >temporary files,
>
> Is this the editors "feature", leaving the files in a global tmp
> directory? As I know from people in the CCC and from the OpenBSD
> developer team this might be a security hole since it may be possible to
> access these files.
OTOH, as you also know, there are ways to do this type of thing
safely. So let's quash the FUD and decide if there is actually a
problem (which, if there is, is something that jove developers would
want to know). Fink's package is jove-4.16. Looking in io.c I see:
tfname = mktemp(tfname);
(void) close(creat(tfname, 0600));
tmpfd = open(tfname, 2);
if (tmpfd == -1)
complain("Warning: cannot create tmp file! %s", strerror(errno))
That seems less than ideal.
Searching the web, there's a note under the heading of "Changes since
4.16" that at some point on the way to 4.16.0.58:
+ use mkstemp to avoid a security loophole
and the latest jove available form the official jove repository on
www.cs.toronto.edu (4.16.0.64) indeed uses that function.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] whither local/bootstrap?
On Wed, Jul 07, 2004 at 06:04:27PM -0400, David R. Morrison wrote: > Hi folks. I'm contemplating doing away with the local/bootstrap tree. [...] > As far as the ./inject.pl scripts go, I would have them use the local/main > tree. This means that some foo.info files would get written to that > tree's finkinfo directory, but I'll save the old file as a backup and "the old file" == a pre-exising file of that name there? > won't overwrite without permission. If user refuses to let inject.pl overwrite his old file, what happens? > Does anybody see any drawbacks to this? Anything I've overlooked? There should be *some* place that users can put their own stuff and not have anything "official" ever touch it, and we've previously said that's the place. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: TclX
Sébastien Maret said: > > I'm working on a package that need TclX (Extended Tcl) to compile. > Do we have this in Fink ? Fink's package database lists all packages we have: http://fink.sourceforge.net/pdb/index.php Searching it for "tcl", I don't see anything that sounds likely. Maybe contact the Maintainer of the tcltk packages to see knows anything about porting it to OS X? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] freetype-1.3.1-7
On Sun, Jul 11, 2004 at 01:31:50AM +0200, HPE wrote: > Hello, > > I got this error message: > """ > [...] > checking for gcc... gcc3 > checking whether the C compiler (gcc3 -no-cpp-precomp -I/sw/include > -L/sw/lib) works... no > configure: error: installation or configuration problem: C compiler > cannot create executables. > ### execution of ./configure failed, exit code 1 > Failed: compiling freetype-1.3.1-7 failed > """ > > Why? ;) You didn't install the XCode (DevTools)? That's the .pkg that contains the compiler itself, and it's pretty hard to compile stuff without it. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] A little help with variants.
On Tue, Jul 13, 2004 at 06:37:02PM +0200, Andrea Riciputi wrote:
> Hi,
> I'm trying to modify some of the packages that I maintain in order to
> use the "variant" feature. Mostly all my packages consist in Python
> modules that always have come in two flawors (-py22, -py23).
>
> 1) Is the following naming scheme correct?
> Info2: <<
> Package: module_name-py%%type_pkg[python]
Spurious doubled percent. Should be:
Package: module_name-py%type_pkg[python]
> Type: python (2.2, 2.3)
The subtype list is space-separated:
Type: python(2.2 2.3)
> Version:
> Revision: x
> <<
>
> 2) Some of the packages need patch files where I change path according
> to the Python's flawor:
>
> - glob.glob(os.path.join(sys.prefix, "share", "pyx", "*.lfs"))
> + glob.glob(os.path.join(sys.prefix, "share", "pyx-py23", "*.lfs")) +
>
> How can I fix this in order to work correctly with the variants??
As you see from the Package field, the python flavor is available as a
percent-expansion, so you can just write a little PatchScript. If
you've got to change a big .patch with the flavor in many places, you
could put something like @PYTHON_FLAVOR@ in the patchfile and then
sed 's|@PYTHON_FLAVOR@|%type_pkg[python]|' < %a/%{ni}.patch
or else apply the patchfile (if any) normally and then use a bit of
perl to change "pyx" to "pyx-py%type_pkg[python]".
> 3) From the documentation I've seen examples like this:
>
> >Depends: (%type_raw[-x11] = -x11) x11
>
> How can I check against the "no-x11" variants? I can imagine that
> something like this:
>
> Depends: (%type_raw[-x11] != -x11) something_else_dependency
>
> will do the trick? Right?
According to the description of the "Depends" field in the Packaging
Manual, != is correct.
Once you have compiled a package, you can:
dpkg-deb --field /sw/fink/debs/%n_%v-%r_darwin-powerpc.deb depends
to see how the Depends in your .info was interpretted.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Abolish omitted-Source: default?
In .info files, if a Source: is not listed, a default of %n-%v.tar.gz is used, which is documented as being for "manual download". I'm proposing we phase out this default. I think it has outlived its usefulness. Consider: .gz compression is hardly as standard as it once was for source things. With varianted packages, %n probably doesn't give the desired result. It is counter-intuitive that we have an omitted field have a default value but then have at least two ways (Type:nosource (and also bundle) and Source:none) to say that there should not be a source tarball. To me at least, it makes a whole lot of sense to have "no Source: field" mean "no source tarball". It we ever change .info syntax relating to sources, we would either have to perpetuate this nothing-means-something/something-could-mean-nothing into a syntax or database format where it might make even less sense (so we maintain consistency with the current situation) or else have new syntax be more logical but not consistent with current way (makes migration more confusing). The syntax is only useful for private packages (since the default value is for a local file) so this would not affect anything in our public package trees. Any thoughts? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] TclX
On Fri, Jul 16, 2004 at 02:59:35PM -0500, [EMAIL PROTECTED] wrote: > hi all, > > I did some research on tclx and it looks like there hasn't been an explicit > release in 2 years, but one of the developers emailed me back and said to get > it from cvs. So I did and I can get it to work, so I have some questions on > packaging this beast... > > 1. How should I manage the source? Should I make a tar ball from a cvs > snapshot and call it their version number plus a date? That sounds like a very good solution. > Something like this: tclx-8.4.0-snapshot-16072004.tar.gz Put the date in MMDD order, so versions will sort properly. Also could cut down the verbosity a bunch: 8.4.0.cvs20030716 > 2. This beasty needs access to internal files from the tcl and tk > sources to build. I was thinking that the info file could grab tcl > and tk of the right version and build against those (using SourceN). > Then I would have a Depend that was NOT >= 8.4.6-2 but =8.4.6-2. > However this seems like a major pain to keep in sync. Does the resulting package (TclX) actually interact with the system's tcl/tk stuff? Or does it just leach some of its sources but not need tcl/tk at runtime? If the former, then you don't need those dependencies at all. If the latter, then...um... > Suggestions?!?!? I could loosen up the requirements to be =8.4.? > It should work against any 8.4 version, right? I don't know how well apt and dpkg and fink's dependency engines handle revisionless values (or even if they all do it the same way). Try it and report back? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Errors in percent expansions (Modified by jfm)
On Sun, Jul 18, 2004 at 04:38:24PM +0200, jfm wrote: > On Jul 18, 2004, at 4:27 PM, jfm wrote: > > >Using fink HEAD: Trying to build postgresql74-ssl-7.4.3-25: > >Failed: Error performing percent expansion: unknown % expansion or > >nesting too deep: " sed 's|@INSTPREFIX@|/sw|g' %a/libpqpp-4.0.patch | > >patch -p1 && \" > >(/sw/fink/dists/unstable/crypto/finkinfo/postgresql74-ssl.info > >"CompileScript") > > > >(Note that apparently the build could understand the PatchScript _ > >it stumbled only on an analoguous line in the CompileScript) > > I see [dmacks] log msg 'Restrict use of %a to PatchScript.' from > this morning. (Is there a real need for this restriction?) An idea that has been kicked around on #fink and is a Features tracker request is MD5 for patchfiles. This is for end-user convenience (avoid getting .info and .patch out-of-sync if pulling random CVS revisions) and to increase the integrity and security of our mirroring farm. Verifying checksum is easy to implement for the Patch field, but difficult for PatchScript because that field allows arbitrary scripting and filename use. A better approach is to have a new field, for example "PatchFile", that one *always* uses for the patchfile. The full path to this file would be available as a new %patchfile, and %a would become obsolete. By forcing the filename to be routed through fink instead of directly written into PatchScript, fink always has the opportunity to verify checksum. As a first step, I implemented this %a restriction...makes future work easier if there aren't so many ways to subvert it:) And I checked 10.2-gcc3.3 and 10.3 and *thought* I didn't find any %a in fields other than PatchScript. Okay, I *actually* didn't find any, but clearly screwed up how I checked. > >And fink dumpinfo postgresql74-ssl to : > > > >Failed: Error performing percent expansion: unknown % expansion or > >nesting too deep: "sed -e 's|@BUILDDIR@|.|g' -e 's|@INSTPREFIX@|/sw|g' > >< %a/postgresql74-ssl.patch | patch -p1" > >(/sw/fink/dists/unstable/crypto/finkinfo/postgresql74-ssl.info > >"PatchScript") And I forgot to commit the fix for dumpinfo. Will do so shortly... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Errors in percent expansions (Modified by jfm)
On Tue, Jul 20, 2004 at 09:02:49PM +0200, David H. wrote: > Benjamin Reed wrote: > | David H. wrote: > |> jfm wrote: > |> | > |> | There are probably 2 different issues: one is that in some > |> | cases it may be clearer or more convenient to use several > |> | different 'patchfiles', with very distinct roles _ so a > |> | 'PatchFile' field might have to be plural Yes. Would be PatchFile, PatchFile2, etc. to mirror our SourceN syntax. > |> Actually this is one thing I would veto strongly. There is no valid > |> technical reason for more than one (unified) patch file. Fink has supported multiple patchfiles in the Patch field for a *long* time. Looking at the code, this was intentionally implemented (though no current packages use it. > | Having things split up logically makes it easier to maintain; especially > | when your package consists of multiple source tarballs. Or for variants. Have one .patch that covers basic portability issues, and then other variant-specific and maybe conflicting-with-each-other .patch related to those specific variants. > Once more, there is no _technical_ reason to have more than one patch > file. That it makes things easier to maintain is something I am not > going to argue, however, it makes it harder on our side to > a) verify that every patch file used is present That's what 'fink validate' is for, no? It even knows to look in PatchScript. > b) that each patch file is up to date and the md5 are ok 'fink validate' would obviously check MD5. I'm not sure what yuo mean by "up to date", since one major feature we *gain* by using MD5 is the ability to make sure the patchfile is in sync with .info. > c) that each patch file sticks to the unofficial size limitations we set > a long time ago It would be trivial to add this to the validator. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] source file with different names
On Wed, Jul 21, 2004 at 06:49:57PM -0400, Koen van der Drift wrote: > On Jul 21, 2004, at 4:57 PM, Martin Costabel wrote: > > > >You probably want NoSourceDirectory: True > > Yes, that worked, thanks. I have to do a manual decompress in the info > file though, but that is no problem, I guess. Careful...you cannot assume that the sources are in %p/src. If you want Source2 decompressed somewhere under the structure of Source, SourceNExtractDir might be useful. Although without details of exactly how the tarballs are structured and how you want the results, I'm kinda shooting in the dark. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] source file with different names
On Thu, Jul 22, 2004 at 07:56:01PM -0400, Koen van der Drift wrote: > On Jul 21, 2004, at 11:23 PM, Daniel Macks wrote: > > > >Careful...you cannot assume that the sources are in %p/src. > > > >If you want Source2 decompressed somewhere under the structure of > >Source, SourceNExtractDir might be useful. Although without details of > >exactly how the tarballs are structured and how you want the results, > >I'm kinda shooting in the dark. > > I am using this code, no need for %p/src: > > NoSourceDirectory: TRUE > CompileScript: << > gunzip source.%v.Z > gunzip source2.%v.Z > << > > They end up in /sw/src/foo-1.0-1 Looks good, and functional for all user configurations:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] error in validation code ?
On Tue, Jul 27, 2004 at 08:41:08PM -0400, Koen van der Drift wrote: > Hi, > > I keep getting the following error when I validate one of my packages: > > Validating package file > /sw/fink/10.3/unstable/main/finkinfo/libs/perlmods/xml-node-pm.info... > Error: Package name may only contain lowercase letters, numbers,'.', > '+' and '-' (xml-nodel-pm.info) > RubyTuesday:~ koen$ > > The package name looks fine: > Package: xml-node-pm%type_pkg[perl] The validator in the currently-released versions of fink do not handle variants well. It was fixed a while ago in CVS HEAD, but IIRC the fix was too intertwined with other major changes there to easily backport to the current release branch. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Making io-tty perl version independent
On Thu, Jul 29, 2004 at 12:13:57PM -0700, Blair Zajac wrote: > I've got a .info file for IPC::Run ready to check into CVS and currently I > have it like this depending > > Info2: << > Package: ipc-run-pm%type_pkg[perl] > Version: 0.78 > Revision: 1 > Type: perl (5.8.1 5.8.4 5.8.5) > Description: Child procs w/ piping, redir and psuedo-ttys > License: Artistic > Homepage: http://search.cpan.org/dist/IPC-Run/ > Maintainer: Blair Zajac <[EMAIL PROTECTED]> > > # Dependencies. > Depends: perl%type_pkg[perl]-core, io-tty-pm%type_pkg[perl] > > The problem is that on my 10.3 box if I want to have Fink's perl 5.8.4 also > installed, then having io-tty-pm581 and io-tty-pm584 (which I made by > copying io-tty-pm58) installed will conflict because the man pages are not > versioned with the perl version. Each -pmXXX could put its manpages in a -pmXXX-man splitoff (which all conflict with each other). That way you can concurrently have all -pmXXX, and any *one* set of manpages. > IPC::Run could be made perl version independent, but because it depends > upon io-tty-pm which only has versioned Perl packages, I need a versioned > ipc-run-pm package. I could depend upon io-tty-pm580 | io-tty-pm581, etc, > but that seems like a bad idea. Correct. That is forbidden (it's functionally the same as having -pm bundle packages). > The diffs between the various io-tty's are minor, so why don't we just have > io-tty-pm? io-tty is a compiled C module, and thus is tied to the version of perl that compiled it. That's essentially the whole reason we have to deal with versioned perl packages in the first place. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [PATCH] compress-zlib-pm to use system zlib.dylib
On Thu, Jul 29, 2004 at 03:16:21PM -0700, Blair Zajac wrote: > David H. wrote: > >Blair Zajac wrote: > >| > >| The Compress::Zlib package currently compiles and links against it's own > >| private copy of zlib 1.1.4. This seems to be a waste of disk and memory > >| space when Mac OS X 103.3 comes with the same version of zlib (10.2 > >| still have 1.1.3, but I'm guessing it's probably patched). On my 10.3.4 machine, I have /usr/lib/libz.1.1.3.dylib [Blair's patch to link against system's zlib] > >That is not allowed. If the package brings its own zlib or there is a > >version of zlib IN Fink already it HAS to use that version. > >This is policy :) Or it can force the link to go to the system's always (regardless of whether one has the fink lib installed). But: > Fink doesn't have it's own zlib. ...at this time. It has in the past, however, and may again in the future. Not sure why fink dropped it, since we supplied a 1.1.4 package in the 10.1 tree. Maybe we should bring it back, and then have compress-zlib-pmXXX use it. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [PATCH] compress-zlib-pm to use system zlib.dylib
On Thu, Jul 29, 2004 at 04:13:17PM -0700, Blair Zajac wrote: > Daniel Macks wrote: > > > >On my 10.3.4 machine, I have /usr/lib/libz.1.1.3.dylib > > Funny, I was looking at the header files to see which version OS X has: > > % less /usr/include/zlib.h > /* zlib.h -- interface of the 'zlib' general purpose compression library > version 1.1.4, March 11th, 2002 > > > #define ZLIB_VERSION "1.1.4" Oh, looks like 1.1.3 is just for backward compatibility: % ls -l /usr/lib/libz.* -rwxr-xr-x 1 root wheel 56416 27 May 13:10 /usr/lib/libz.1.1.3.dylib* -rwxr-xr-x 1 root wheel 56200 27 May 13:10 /usr/lib/libz.1.dylib* lrwxr-xr-x 1 root wheel 12 21 May 11:22 /usr/lib/libz.dylib@ -> libz.1.dylib % strings /usr/lib/libz.1.1.3.dylib | grep Copyright deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly inflate 1.1.3 Copyright 1995-1998 Mark Adler % strings /usr/lib/libz.1.dylib | grep Copyright deflate 1.1.4 Copyright 1995-2002 Jean-loup Gailly inflate 1.1.4 Copyright 1995-2002 Mark Adler So no need for fink to provide 1.1.4, and okay for the perl mod to link system's lib IMO. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] FAQ 9.11
On Wed, Aug 04, 2004 at 12:42:33AM +0200, Martin Costabel wrote: [...] > > 2. Users are right in experiencing some hard feelings when Fink > downloads 100MB of sources, compiles for 5 hours and then says "Well, > you probably didn't want this anyway, just throw it away". We should > find a way to do the check at the beginning, before downloading and > compiling xfree86. Here is a proposition: > > Have xfree86 Depend or BuildDepend (it is too late in the evening now > for me to see clearly which one would be better) on a new package > "xfree86-check" which does nothing than running the current Pre- and > PostInstScripts from the xfree86 package. [All downloads] happen before [any build/install], so xfree86-check wouldn't do its thing until too late. There's a feature in CVS HEAD that gives users a choice of the system-xfree86 or xfree86 pkgs when needed instead of just assuming that (when the needed *xfree86* is present) to just use Fink's pkg. Then if one selects system-xfree86 fink will give a message explaining that use must manually install a thing (w/refs to FAQs). Just rename one of the critical files system-xfree86* checks for and see what happens when a pkg BuildDepends:x11-dev. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Info2 and C perl mods
On Tue, Aug 03, 2004 at 10:26:42PM -0700, Blair Zajac wrote: > So it appears to me that if you have a single Perl module with some C code > in it and you use Info2, then every Perl module that depends on this needs > to use Info2 to properly depend upon the versioned perl module. > > I'm thinking here of Compress::Zlib, which IO::Zlib, depends upon, which is > then dependent upon by Archive::Tar, and then Module::Build. > > I also understand that having compress-zlib-pm-5XX have a Provides doesn't > work to well, although I'm not to clear on the reasons. Consider a user who has perl561 and perl581, who installs foo-pm581:Provides:foo-pm bar-pm:Depends:foo-pm bar-pm is pure-perl, so is installed in a place that is accessible to both perlXXX and has all its dependencies met, but will only be usable with perl581 because that's the only perl for which foo-pmXXX is present. That's pretty confusing, no? Another package quux that wants to use bar-pm shouldn't have to jump through hoops figuring out what sub-dependency mess the package foo-pm has caused. So instead we have the current arrangement that makes it completely clear at all levels of dependency whether one can use "any perl" or only a specific one. > There's got to be a better of way of doing this. We'd love to hear it. The way you observe is current policy (well, not that you must use Info2, but just that even pure-perl modules be -pmXXX if they depend on any C ones). It was the result of -devel discussion that you are welcome to read. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Module::Build and perlarchdir
On Wed, Aug 04, 2004 at 10:07:07AM -0700, Blair Zajac wrote:
> The default CompileScript and InstallScript when Type: Perl is used
> contains the perlarchdir variable, which is expanded in PkgVersion.pm.
>
> I'm building some Perl packages that use Module::Build instead of the
> standard Makefile.PL
There's an item in the Patches tracker that adds native Build.PL
support to Type:perl. Seems like something we should have, given it's
supposed increasing popularity.
> and could use perlarchdir myself when I call this:
>
> perl%type_raw[perl] Build.PL \
> --install_path arch=%i/lib/perl5/%type_raw[perl]/`perl%type_raw[perl]
> -MConfig -e 'print $Config{archname}'` \
[...]
Yeah, that seems a bit hackish. Would probably look cleaner to assign
to a variable first instead of on the Build.PL command itself, like:
#!/bin/sh -ev
eval export "`perl -V:archname`"
perl%type_raw[perl] Build.PL \
--install_path arch=%i/lib/perl5/%type_raw[perl]/${archname} \
[...]
> Could we add %{perlarchdir} to expand in .info files?
It seems pretty special-purpose, especially since there are already
ways to get this info (several methods to access Config, or with some
shell if/then based on %type_raw[perl]).
> Also, I noticed that $perlarchdir is determined like this:
[in sub get_perl_dir_arch()...]
> if ($perlversion ge "5.8.1") {
> $perlarchdir = 'darwin-thread-multi-2level';
> } else {
> $perlarchdir = 'darwin';
> }
>
> I think a better way of doing this for future use would be just to use the
> Config{archname} value which generates the same values as this test, but
> would work regardless of what Apple does later in any future releases:
>
> use Config:
> $perlarchdir = $Config{archname};
[coupla thoughts here; longish full brain-dump follows...]
That does seem a lot more generalizable. I wonder if it would lead to
harder-to-debug problems with -pmXXX packages if a user has installed
his own perlX.X.X with a different archdir config? Now, that situation
fails (in his eyes) immediately: the script installs it in what fink
thinks is archdir results in a module that is not accessible to his
funky perl. Using Config{archname}, he'll get a working module, but
installing precompiled .deb of -pmXXX will not work (NB: breakage of
Fink policy that every fink gives compiles same .deb for everyone
everytime everywhere). And later if he upgrades to fink's perlXXX, his
modules will suddenly disappear.
I doubt (but don't know for certain) that Apple would make such a
major change as perl archdir for an already-extant /usr/bin/perl since
that would break many people's systems. I also suspect that a perl
version upgrade would only happen as part of a larger system (kernel)
upgrade. Fink already throws a warning when being installed on an OS
version for which that fink version has not been tested, and that
gives us the opportunity to push a new fink release that knows about
whatever wacky things Apple does in the new OS. I wonder if fink
should check this at fink runtime, since one could upgrade OS but not
fink and then be in an "untested" state?
Also, reading the value of Config{archdir} in get_perl_dir_arch()
(vs. returning something constant by if/then or a bit of script to
read archdir when the script is eventually run) makes the *Script
field itseld only determined at actual build-time. That is a big (IMO)
change from the current situation. When debugging variants and when
trying to compile "by hand" based on a fink package template, I like
being able to query fink "what script would you use?" and not have to
install a perl that I might not even be using just to find out.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] FAQ 9.11
On Wed, Aug 04, 2004 at 08:42:33AM +0200, Martin Costabel wrote: > Martin Costabel wrote: > [] > >The real test with BuildDepends will have to wait until I have finished > >reconstructing my X11 installation :( > > OK, thanks to rsync and a fast DSL connection, this was not too painful.. Oo, sorry about that. > Next try: Moved /usr/X11R6/include/X11/Xlib.h away. This removes > x11-dev, but leaves everything else there, in particular > system-xfree86-dev. From fink-virtual-pkgs: > > >Package: system-xfree86-dev > >Status: install ok installed > >Version: 2:4.3-2 > >provides: libgl-dev, xft2-dev, fontconfig1-dev *Ick*. The goal was to have virtual things always be present in the PDB, but not marked "installed" if their file checks failed. Looks like we are not catching partially-installed X11* packages, since we did not account for having multiple independent (may be present or not, and so may be Provides or not) pkgs for a single virtual package. RangerRick: maybe we should put the not-found packages as provides of some new "system-free86-that-you-must-install-manually" package (which behaves the New Way that the other virtuals do)? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: fink/perlmod/Fink PkgVersion.pm,1.289,1.290 Engine.pm,1.189,1.190 ChangeLog,1.685,1.686
On Mon, Aug 09, 2004 at 01:04:14AM -0400, David R. Morrison wrote: > On Aug 9, 2004, at 12:14 AM, Daniel Macks wrote: > > >Update of /cvsroot/fink/fink/perlmod/Fink > > > >Modified Files: > > PkgVersion.pm Engine.pm ChangeLog > >Log Message: > >Recompute %c value every time get_*script() is called. > >Rename PkgVersion::parse_configureparams() to ::prepare_percent_c(). > > Thanks, that fixed the immediate problem with bootstrapping. > > However, there is another problem later on, having to do with the > default values for LDFLAGS and CFLAGS getting the wrong value of %p or > %i. I'll send a more detailed description of this second problem, > later. Sounds like a similar cause...PkgVersion::get_env() caches the ENV used for running *Script. That's a pretty expensive method and it gets called about 7 times during package building, so I'd like to keep caching if possible. So we could either have enable_bootstrap() and disable_bootstrap() clear the cache, or have get_env() only cache if the _bootstrap flag is not set. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: fink/perlmod/Fink PkgVersion.pm,1.289,1.290 Engine.pm,1.189,1.190 ChangeLog,1.685,1.686
On Mon, Aug 09, 2004 at 01:00:38PM -0400, David R. Morrison wrote: > On Aug 9, 2004, at 12:15 PM, Daniel Macks wrote: > > [snip] > > > So we could either have enable_bootstrap() and > >disable_bootstrap() clear the cache, or have get_env() only cache if > >the _bootstrap flag is not set. > > Either one sounds good to me: why don't you do it in the way you think > would be easiest to remember/maintain. Plan B, since other methods already react to _bootstrap, and it keeps from having to change *_bootstrap() whenever we'd want to cache other things. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: base-files ChangeLog,1.28,1.29 init.csh.in,1.11,1.12 init.sh.in,1.12,1.13
On Mon, Aug 09, 2004 at 03:23:11PM -0400, David R. Morrison wrote: > > On Aug 9, 2004, at 2:30 PM, Daniel Macks wrote: > > >Update of /cvsroot/fink/base-files > >In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26056 > > > >Modified Files: > > ChangeLog init.csh.in init.sh.in > >Log Message: > >Include "." (default when unset) when explicitly setting CLASSPATH > >(Bugs #1005793) > > Should I release a new version of base-files with this change? Give me a day or two...I want to get feedback from the bug reporters that this is an adequate solution. I don't use anything Java, so I can only check that the patched files behave as I intend. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] shlibs vs Type variants
On Thu, Aug 12, 2004 at 12:57:43AM -0400, Jack Howarth wrote: > I am trying to create a -mpi variant of the fftw package using the > Type field. I have managed to create a fftw.info that will build either > fftw/fftw-shlibs or fftw-mpi/fftw-mpi-shlibs depending on what (fftw > or fftw-mpi) is passed to 'fink install'. However am baffled on what > options I have to solve the problem with the Files: and Shlibs: fields. These two variants sound like they implement the same functions (from the caller's perspective). I know they have different filenames, which means both could co-exist and when compiling a program one chooses which to link and hence which will always be used at runtime. I wonder if those could be made with the same filename instead? That way they'd be drop-in replacements for each other, and then the choice would be made at *runtime* which to use. But anyway... > I need someway to be able to wrapper the mpi based shared libs on those > lines with (%type_raw[-mpi] = -mpi) or such, Is there any undocumented > method for doing this or have I ran smack up against the limitations > of current fink. You've hit a limitation of current fink. The only thing documented for this situation are two notes buried in the source code in Fink CVS. Where we handle Files: # FIXME: # * prefix conditional syntax And where we handle Shlibs: # FIXME-dmacks: #* Make sure each file is actually present in $destdir #* Remove file if package isn't listed as a provider # (needed since only some variants may provide but we don't # have any condiitonal syntax in Shlibs) Now that we have a real-world case where it would be useful, I guess we should implement them, huh? Feel free to open a Feature Requests tracker item assigned to me or watch the ChangeLog and/or CVS commits for status updates. > Below is the fftw.info spec which I came up with so far. > > Package: fftw%type_pkg[-mpi] > Type: -mpi (boolean) [...] > SplitOff: << > Package: %N-shlibs > Files: lib/libdfftw.*.dylib lib/libdfftw_threads.*.dylib lib/libdrfftw.*.dylib > lib/libdrfftw_threads.*.dylib lib/libsfftw.*.dylib lib/libsfftw_threads.*.dylib > lib/libsrfftw.*.dylib lib/libsrfftw_threads.*.dylib lib/libsrfftw_mpi.*.dylib > lib/libdrfftw_mpi.*.dylib lib/libdfftw_mpi.*.dylib lib/libsfftw_mpi.*.dylib Files just moves files from the install dir of the main package (%I) to that of the SplitOff (%i) by handing each item listed to /bin/mv. Is there some shell glob that would accomplish what you want? Seems pretty fragile. Better, what about instead of listing these optional files in Files, having an InstallScript in this SplitOff that has so if/else logic to move the appropriate files. That, coupled with the above not-yet-implemented feature would mean instead of these Shlibs: >%p/lib/libsrfftw.2.dylib 3.0.0 %n (>= 2.1.3-12) >%p/lib/libsrfftw_mpi.2.dylib 3.0.0 %n (>= 2.1.3-12) you could have: %p/lib/libsrfftw.2.dylib 3.0.0 fftw-shlibs (>= 2.1.3-12) %p/lib/libsrfftw_mpi.2.dylib 3.0.0 fftw-mpi-shlibs (>= 2.1.3-12) and each one would only get applied to the correct variant. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Do we still need 'fink checksums'?
The 'fink checksums' mode was added two years ago when we first started requiring MD5 for source tarballs. The code implementing it is marked: # HACK HACK HACK # This is to be removed soon again, only a temporary tool to allow # checking of all available MD5 values in all packages. Does anyone still use this mode? Do we still need this functionality? Or can we axe it (or at least deprecate it now, then axe it soon)? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Do we still need 'fink checksums'?
On Fri, Aug 13, 2004 at 12:51:11PM +, [EMAIL PROTECTED] wrote: > >Daniel Macks wrote: > > > >> The 'fink checksums' mode was added two years ago when we first > >> started requiring MD5 for source tarballs. [...] > >> Does anyone still use this mode? Do we still need this > >> functionality? > > Why removing it? It's a hack that was not intended to be a permanent addition to Fink. Internally, the less cruft code we have to maintain and worry about breaking the better. > I prefer that the function would stay. Figured I'd receive this just *after* removing it from HEAD. *grr* > I check my /sw/src with that function if there > are incomplete or broken downloads. Fink now checks MD5 at download time. That means 'fink fetch' will fail if it downloads an incomplete or broken file (instead of succeeding, but then having 'fink build' fail). Does that provide adequate protection for your situation? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] percent expansions in Files fields
On Mon, Aug 16, 2004 at 08:08:36PM +0200, jfm wrote: > > Trying to update after holidays, libpng3 doesn't build _ with fink HEAD > from today : > > /bin/mv /sw/src/root-libpng3-1.2.6-5/sw/lib/libpng12.0.%vrc5.dylib > /sw/src/root-libpng3-shlibs-1.2.6-5/sw/lib/ > mv: rename /sw/src/root-libpng3-1.2.6-5/sw/lib/libpng12.0.%vrc5.dylib > to /sw/src/root-libpng3-shlibs-1.2.6-5/sw/lib/libpng12.0.%vrc5.dylib: > No such file or directory Fixed. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/sci fftw.info,1.3,1.4
jswhit committed: > >=== > RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/sci/fftw.info,v > +Info2: << > +Package: fftw%type_pkg[-mpi] > +Type: -mpi (boolean) > +Conflicts: fftw-absoft, (%type_raw[-mpi] = -mpi) fftw, (%type_raw[-mpi] = .) > fftw-mpi > +Replaces: fftw-absoft, (%type_raw[-mpi] = -mpi) fftw, (%type_raw[-mpi] = .) fftw-mpi Packages automaticaly purge themselves from Conflicts and Replaces. Instead of that conditionals mess, you can just: Conflicts: fftw-absoft, fftw, fftw-mpi Replaces: fftw-absoft, fftw, fftw-mpi and fink will do What You Want to make fftw and fftw-mpi mutually exclusive. The Right Thing. > +CompileScript: echo "No Compile Script" > +InstallScript: << > + #!/bin/bash -ev > + if [ "%type_raw[-mpi]" == "-mpi" ]; then > +./configure %c --enable-mpi > + else > +./configure %c > + fi > + make install prefix=%i infodir=%i/share/info > + make clean > + if [ "%type_raw[-mpi]" == "-mpi" ]; then > +./configure %c --enable-float --enable-altivec --enable-mpi > + else > +./configure %c --enable-float --enable-altivec > + fi > + make > + make install prefix=%i infodir=%i/share/info It seems strange that the compiling is done in InstallPhase. If there are two independent sets of things being compiled here, perhaps it should really be two separate packages? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Package database webpage layout
The version availability table on the page for an individual package seems confusing. Consider http://fink.sourceforge.net/pdb/package.php/passwd It's not clear what a 0.7.0 tree is, or how the point distribution trees relate to stable and unstable branches of other trees, or that there is a clear upgrade path from bindist to stable. Logically, a user would know his OS X, and want to know what's available for it, right? So let's structure the table with those as the axes: http://fink.sourceforge.net/pdb/passwd.html Thoughts on concept? Improvements on details of the new layout? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Package database webpage layout
On Tue, Aug 17, 2004 at 10:15:36AM +0200, Martin Costabel wrote: > Daniel Macks wrote: > > > http://fink.sourceforge.net/pdb/passwd.html > > > >Thoughts on concept? Improvements on details of the new layout? > > The concept is good, but I find the optical layout confusing. "What do > all those numbers mean?" > > Could you perhaps print the version numbers in some color, red or so? > Or put small-print headings like "bindist version" and "package version"? > Or use visible cell borders and backgrounds? > > In the old form, there were clear columns, the first column containing > the tree, the second and third the package version. It is too mixed-up now. Good point about the different types of numbers. I just added subheadings to clarify what is what. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Rsync not being updated
On Fri, Aug 20, 2004 at 12:55:02AM +0200, Martin Costabel wrote: > > Yes, I think it is a bug in the new fink. > > In SelfUpdate.pm, the line > > next unless ($tree =~ /stable/); > > was changed to > > next unless ($tree eq "stable" or $tree eq "unstable"); > > But $tree is typically something like "stable/crypto", so this never > matches. This was added 6 weeks ago, but since developers never use > selfupdate-rsync, it was not noticed until the CVS HEAD hit the streets :-) > Bug author CCed. Fixed in CVS HEAD. Please check that this now works correctly, and we'll push a new fink pkg ASAP. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] openssl | openssl097
I see several packages have constructs like: Depends: openssl-shlibs | openssl097-shlibs BuildDepends: openssl-dev | openssl097-dev This is not correct--if, for example, one has openssl097-dev installed at build-time, then one *must* have openssl097-shlibs at run-time (openssl-shlibs will not suffice). A quick check of the crypto branch of the 10.3 and 10.2-gcc3.3 trees finds: 10.3: stable/crypto/finkinfo/stunnel4.info unstable/crypto/finkinfo/dcmtk-ssl.info unstable/crypto/finkinfo/net-snmp-ssl.info unstable/crypto/finkinfo/stunnel4.info 10.2-gcc3.3: unstable/crypto/finkinfo/ettercap-ssl-0.6.9-12.info unstable/crypto/finkinfo/net-snmp-ssl.info What's our current thought on us changing these and telling $Maintainer the situation vs. telling them to fix their packages and waiting for them to do so? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] XCode issue
On Tue, Aug 24, 2004 at 01:13:34AM +0200, Martin Costabel wrote: > Dave Vasilevsky wrote: > >On Aug 23, 2004, at 5:32 PM, [EMAIL PROTECTED] wrote: > > > >>>ld: warning prebinding disabled because of undefined symbols > >>>ld: Undefined symbols: > >>>_pm_seek2 > >>>_pm_tell2 > >>>make[2]: *** [pnmtopng] Error 1 > >>>make[1]: *** [other/all] Error 2 > >>>make: *** [converter/all] Error 2 > >>>### execution of make failed, exit code 2 > >>>Failed: compiling netpbm10-10.24-1 failed > >> > >>First result: they are defined in > >>/sw/src/netpbm10-10.24-1/netpbm-10.24/lib/pm.h > >>and for some unknown reason these directory wasn?t included. > > > >They are DECLARED in pm.h, not defined. The "definition" of a symbol is > >the (compiled) function body. You probably have to look for a .c file. > > Right, they are defined in lib/libpm.c and should end up in > lib/libnetpbm.dylib which was present on the original linker line. So > probably something went wrong already in the compilation of > lib/libnetpbm.dylib. I wonder if when linking against that .dylib the linker is picking /sw/lib/libnetpbm.dylib instead of the one just compiled as part of the nascent package? Maybe having the package (or a previous version of it) already installed or not is an important variable here? Just speculating... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink gcc?
On Thu, Aug 26, 2004 at 01:24:58AM +0200, Max Horn wrote: > Am 25.08.2004 um 19:40 schrieb David R. Morrison: > > > >The troubles with g++ under XCode 1.5 and the lack of any quick > >response from Apple, combined with earlier incidents of an analogous > >nature, lead me to ask: would we be better off with a fink gcc package > >in place of the Developer Tools? As I understand it, the Apple > >compiler team has been good about pushing their changes upstream. > >Would we lose anything by relying on FSF gcc rather than Apple's > >releases? I think we'd be setting ourselves up for a user support nightmare, as others have mentioned. But just to see what the state of the art is... > > The FSF gcc is lacking many essential features compared to the Apple > GCC, e.g. Objective C++, Altivec stuff, pascal string support and more; > going with it would break compilation of a lot of OSX specific things. The gcc-3.4.1 suite has a confiugre flag --enable-altivec: Specify that the target supports AltiVec vector enhancements. This option will adjust the ABI for AltiVec enhancements, as well as generate AltiVec code when appropriate. This option is only available for PowerPC systems. It sounds like Apple is contributing ObjC++ support back upstream: http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html but I don't know if it's done yet. But even if it's there by 3.5 (or some branch thereof, or whatever we can find to release), it feels like we'd always be _at_best_ up to the same version# as Apple's. Though there are arguments to be made for having a known-to-be-functional thing as a fallback for when Apple hoses us. > Besides that, David H?hn already did a nice job at summing up some of > the further troubles this would cause for us. /me nods dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
