Re: [Fink-devel] Adding bit-torrent to download options for fink, yes/no? Vote, comment. Thank you
Yeah, it definitely requires infrastructure work. Debian has done some work on torrents-for-apt, which would presumably be extensible to torrents-for-tarballs: http://debtorrent.alioth.debian.org/ Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Python patch for offlineimap
This bug has already been reported to the OfflineIMAP folks: http://software.complete.org/software/issues/show/20 . Apparently the bug in Python is fixed, so this problem will no longer occur with Python 2.5.3 and higher. However, contrary to the impression given by the issue tracker, earlier versions of Python (including the python25 in Fink) do not have the fix so far as I can tell. For earlier versions of Python, there is a way to fix OfflineIMAP without hacking on Python; see my patch in the issue tracker. Vincent, what do you think of including my patch in Fink's OfflineIMAP until Python 2.5.3 is released and distributed by Fink? At that time, we can remove the patch and add a dependency on python25 (= 1:2.5.2-1) . Cheers, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dpkg-deb: use --no-unquote as argument to tar
But Fink's tar is in the dependency list of dpkg, so it should be used.
I think this is true only when fink calls dpkg, because fink does some
path munging first. However I just tried this:
sudo dtrace -n 'syscall::execve:entry { self-path = copyinstr(arg0);
} syscall::execve:return / arg0 == 0 / { trace(self-path); }' -c
'dpkg-deb -b target target.deb'
and it confirms that the first 'tar' in my path (which is not fink's
tar) is being called. Also even when fink calls dpkg we're not
absolutely guaranteed to get a recent tar, since during bootstrap
fink's tar isn't installed yet.
One option would be to patch dpkg to read something like this:
struct stat sb;
if (stat(PATH_TO_FINKS_TAR) == 0) {
execlp(PATH_TO_FINKS_TAR,tar,-cf, -, --null, -T, -,
--no-recursion, --no-unquote, (char*)0);
} else {
execlp(TAR,tar,-cf, -, --null, -T, -, --no-recursion,
--no-unquote, (char*)0);
}
I'd still rather see a patch of the package in question. Can you tell
us what it is? Maybe we can come up with a safe way around the use of
strange paths.
Dave
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] new pdb (hopefully) ready for testing
Looks very cool! A few minor quibbles: * The 'Sort order' field seems meaningless. The only option is 'Descending', but the results are always sorted ascending by name anyhow. I'd suggest just scrapping the field, what's the point of sorting descending-by-name? * Could you add a way to search only the current distributions? Might even want to turn that on by default--if Joe User sees a package in the result list he'd probably assume the package is actually available, can't trust him to click through to the package page. Thanks for all your pdb work! Dave - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Info3?
On Dec 30, 2006, at 11:59 AM, Martin Costabel wrote: Michèle Garoche wrote: Sorry if my question seems to be trivial. I need an answer first for my own understanding, second for correct translation. Sorry for putting new things into Fink without sufficient explanation to some developers, I'll try to be more careful about that in the future. Here I'll explain first the new features in Info3 (and potentially Info4), then the reasons why we use InfoN at all. Martin understood correctly most of the new features in Info3, here's a complete summary: 1. Removal of RFC-822 continuations, which allows the following syntax in .info files: DescDetail: This package does all kinds of useful things. A long time ago, we came up with a heredoc-based syntax, which is generally agreed to be cleaner: DescDetail: This packages does all kinds of useful things. RFC-822 has been deprecated in Fink for awhile, so it was decided to remove it in Info3. 2. Intelligent leading-whitespace removal for heredocs. This is just to make .info files more readable, so we don't end up with things looking like this: Info2: Package: foo SplitOff: Package: %N-shlibs InstallScript: #!/bin/sh cat EOD foo some random file EOD Instead it can be prettified with indentation: Info2: Package: foo SplitOff: Package: %N-shlibs InstallScript: #!/bin/sh cat EOD foo some random file EOD This could also be useful if for future .info file fields, for example we could if we wanted have whitespace-sensitive fields. 3. Pkglist improvements. A pkglist is just any fink field that lists packages (and sometimes versions), for example Depends or Provides. For awhile now it's been possible to use heredocs for pkglists: Depends: foo (= 1.2-3), bar, iggy-pm, blah A number of developers use comments (starting with '#') to document parts of their .info files, so it seemed a reasonable extension to allow them within pkglist fields. If you find yourself copy-pasting or deleting depends lines, often you end up leaving a trailing comma-- since this is completely unambiguous, fink now simply ignores trailing commas in pkglists. Here's a pkglist illustrating the new features. Depends: foo (= 1.2-3), bar, iggy-pm, # Needed for PostInst blah, 4. If we adopt Info4, the only new feature will be a new percent- expansion. We have yet to decide on a final name, I'll assume '%V' for now. The reason we want a new expansion is that a number of packages use fields like the following: Depends: %N-shlibs (= %v-%r) If you add an Epoch to this package, now most uses of %v-%r are no longer correct, instead you must use %e:%v-%r. So we propose to make % V = the full version of a package, so you can write: Depends: %N-shlibs (= %V) This will be correct regardless of whether a package does or does not have an epoch--and it saves typing as well. Ok, now I'll explain about the InfoN concept. First, let me get something out of the way: You don't have to use InfoN unless you want the new features it includes. Let me repeat that: InfoN is NOT MANDATORY. You can happily write .info files which don't use any InfoN at all, or continue to use Info2 even if the newest fink supports Info3. The only times you need to use InfoN are when you want the new features--for example, you'll need Info4 for the new % lib percent expansion. Now the history: Usually .info file features are backwards- compatible. If there's a new field that you use (for example AppBundles), you simply have to add a dependency on the proper version of fink: BuildDepends: fink ( 0.23.1) You should always be able to find the proper version on this page: http://fink.sourceforge.net/doc/packaging/reference.php?phpLang=en Unfortunately, certain new features completely confuse older versions of fink, before it even gets a chance to see the BuildDepends line. Usually these are percent-expansions, let's use %V for an example: BuildDepends: foo (= %V), fink (= 0.27) If an old fink sees this line, it sees %V and doesn't know what to do, even before it notices that it's not a new enough fink to build this package. We first encountered this situation when adding variants (eg: foo-pm% type_pkg[perl]). The only reasonable solution that we could find, which would allow older finks to ignore confusing things, was to wrap the whole .info file in a heredoc-field, hence Info2. Now when fink sees a InfoN that is too new, it knows to ignore that .info file, and it won't crash. This gives the user time to selfupdate to a newer version of fink. When other features are desired that would confuse older finks, the
Re: [Fink-devel] Some recent weirdness
On Dec 11, 2006, at 2:52 AM, Martin Costabel wrote: The latter file does indeed have incomplete sections that consist only of 3 lines and have no Packages: line, for example: Filename: dists/unstable/main/binary-darwin-powerpc/base/ libncurses5-shlibs_5.4-20041023-9_darwin-powerpc.deb Size: 311630 MD5sum: 17e9edbf3a40692c6176eecb6e7a3065 I know you already said you tried deleting cache files, but you might not know about /sw/var/lib/fink/scanpackages.db . Does deleting that help? I'm not sure what could possibly be causing this, so some more info would help. What do you get if you run 'dpkg -I' on the deb in question? Also, can you successfully use dpkg-scanpackages or apt- ftparchive to update your Packages.gz, or do they fail as well? Dave PGP.sig Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] multiple notify plugins?
On Dec 7, 2006, at 9:09 AM, Charles Lepple wrote: I was looking through the Fink/Notify.pm code, and it seems like only one plugin can be active at a time. I'm not well versed in Perl OOP, so I'm wondering if anyone knows of any architectural showstoppers for changing the NotifyPlugin config option so that it takes a list of plugins, or if it was just written this way for simplicity. No showstoppers, it's quite easy to add. I just implemented it in Fink CVS, thanks for the suggestion! Please test so it can go into the next release. Dave PGP.sig Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Good way for testing stable-readiness?
On Apr 6, 2006, at 2:54 AM, Daniel Macks wrote: Yeah, but neither works for other tree than the one I am using right now, do they? By other tree, you mean in the Distribution sense (can't check 10.3 from a 10.4-transitional machine; can't check intel from a powerpc machine) right? The --trees flag *overrides* Trees in fink.conf. No, it doesn't. It *selects a subset* of the Trees in fink.conf. You can't use it to include a tree that's not in your fink.conf. (It's a design choice so that --exclude-trees makes sense.) So anyways, what Max is really asking is about Distributions. And unfortunately, there's no good way to check if a package's deps would be satisfied in another Distribution. This is because the virtual packages--representing the kernel, gcc, X11, perl, etc--are all different, and fink has no way to know what versions of those you would have on another Distribution. Fink can already read the .info files from another distro, if you play some tricks like changing when %p/fink/dists points. So if we want to test what would happen on another distro, we could put together some code to make Fink::VirtPackage pretend that a certain set of virtual packages are present. (We could also do this to Fink::Status, to pretend that a different set of packages are installed.) Then just generate for each Distribution what we'd like these sets of packages to be. Max, would you like to help implement this? Dan, any thoughts? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Good way for testing stable-readiness?
On Apr 6, 2006, at 11:01 AM, Daniel Macks wrote: Do we assume that if a user is forging $distribution, it should only be for use within fink itself (for dep-checking and listing), not actually to be able to install these packages? Yes, I think so. We should assume that it's in dry-run mode. just have VirtPackages consider *all* its packages as not installed regardless of what's on the local filesystem. I'm not sure that's such a great idea for dep resolution purposes. 1. Fink will currently deal ok with existing-but-not-installed virtual packages because it assumes any package that exists is installable. I don't want to encourage this assumption, in the future we may want to let the dep engine know you can't really install this package. (Eg: If X11User but not X11SDK is installed, we don't want system-* as a choice.) 2. A lot of important things about virtual packages are determined only if the package is present, eg: the provides of perl. So marking it absent could cause deps to not be satisfied. Status is just a subset of .info data when the package that is installed is at the current version ... Not sure what that means, but status reflects the actual installed version, regardless of whether there's a corresponding .info. So if package 'foo' is only in unstable, but you have it installed, 'fink -- tree=stable,virtual ...' won't realize that deps on foo are broken. Pretending that status is empty (nothing installed) is probably ok here. Maybe just assume that the current essential is installed? I'm not sure what's better. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Good way for testing stable-readiness?
On Apr 5, 2006, at 10:56 AM, Daniel Macks wrote: fink --trees=stable/main,stable/crypto,virtual rebuild foo Note that this is equivalent to fink --trees=stable,virtual rebuild foo Just to save you all some typing. :-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] perl -pi.bak
On Mar 31, 2006, at 4:54 PM, William Scott wrote: Should we no longer be using perl -pi.bak instead of perl - pi? Some of my packages got changed back to the latter, so I am wondering if I should fix the rest of them It doesn't really matter usually. Just don't do perl -pi.bak on files that are in %i, since that causes a .bak file to go in the deb. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Merge fink ChangeLogs?
On Mar 29, 2006, at 8:01 AM, Max Horn wrote: such that they list the full file path, i.e. update/config.guess, update/config.sub in this case. I'm perfectly happy to have a merged Changelog. May I suggest, however, that for non-duplicate filenames we omit the full path? By far most of the changes happen to perlmod/Fink/*.pm, and having 'perlmod/Fink/' over and over will get tiring fast (both to read and to write). Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Machine readable package list?
On Mar 20, 2006, at 5:14 PM, Chris Dolan wrote: Yes, fink list data are indeed exactly what I'm seeking, but the numbers need to be accessible to a non-Mac and Macs that don't have Fink installed. I can do fink list or the equivalent on my own machine and upload the data to my own website via cron, but I was hoping to find something a little more official. Fink is all written in perl, there's no particular reason why the package indexing part couldn't run on any Unix. Probably some small patches or options would be needed, eg: for Architecture. If I still had Linux installed, I'd try it now, but I don't. However if you want to give it a try, I'll be around in #fink to answer questions. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Maintainers (was: FYI: SDL change)
On Mar 19, 2006, at 5:10 PM, Trevor Harmon wrote: And though I understand that you feel snubbed at having your package taken out of your hands, I feel that packages *should* be able to be taken out of a maintainer's hands, as long as responsibility for the changes are also taken out of the maintainer's hands. And: And as you said in your response to Max, sometimes changes are so trivial that there's no need to defer to the original maintainer. It would be nice to have a sort of wiki-like model for editing package descriptions. Interesting thoughts, thanks for posting them :-) However, I must disagree about how wonderful collaborative packaging could be. Once upon a time, somebody had the great idea that rather than individual maintainers for each of the Gnome packages, Fink should have a Gnome Team which worked together. As we're all aware, this didn't work out too well! While a few people would make changes to each package, it was too hard to decide things by consensus. Packages would fork when different maintainers had different ideas, nobody was really sure when things were ready for release, coordination was nearly impossible with the variance of time zones and schedules. Now this doesn't mean it's impossible to collaborate successfully, but it's tough. The system we have now means there's always some single individual who is responsible, and that's a big bonus. I imagine that's why Debian also uses this system. However... it's clear there are some issues that come up every so often! Trevor, why don't you document things a bit on the wiki? We could definitely start formalising the process of package abandonment/ take-over-ment, what small changes are considered ok without asking first, etc. You could also add some ideas/RFCs for how me might change things. Also, feel free to experiment. If some maintainers want a more collaborative sort of maintainership, why not try it out (as long as it's opt-in)? Just let people know, maybe add a line '# Please fix me!' to your .info files. If the system starts working well, perhaps soon we'll all want to adopt it. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Dependency problem in cdat
On Mar 15, 2006, at 12:02 AM, Daniel Macks wrote: $ fink build cdat unable to resolve version conflict on multiple dependencies python = 1:2.4-1 python = 2.5-1 Exiting with failure. The offending dependency is: python (= 1:2.4-1) | python (= 2.5-1) I can't tell you why such a weird dependency is being used, but I can explain why this error occurs. The short answer is Fink's dep engine is broken, of course. But if you're willing to delve into black magic... When Fink tries to choose packages to satisfy a dependency such as 'python (= 1:2.4-1) | python (= 2.5-1)', it does it in two steps: 1. It gets a list of PkgVersion objects which satisfy the dep. While this is happening, if it seems any version specs like '(= 1:2.4-1)', it stores them off to the side somewhere. 2. It tries to choose between the PkgVersion objects. It tries to choose one that's already going to be installed/built in this Fink run, then it tries to choose one that's already installed. Otherwise, it picks a Package (eg 'python'), and then chooses the highest-versioned PkgVersion from that package, subject to the version specs that were stored earlier. So the problem here is that step 1 sees both (= 1:2.4-1) and (= 2.5-1), but has no way to communicate to step 2 that these are in an OR relationship. If you already have python installed, step 2 just picks that, and you're good. But if it gets to the next step, it tries to pick the highest-versioned PkgVersion of python subject to BOTH specs, which clearly won't work. The good news is that this only happens with very weird specs, like the one in this package. The easy solution is just to use sane deps. I'll attempt to fix this in HEAD, but there are so many weird side- effects like this in our dep engine that it's likely to cause more trouble. We'll see! Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Q: how to get a current version of fink (the manager)?
On Mar 1, 2006, at 12:57 PM, Adrian Mugnolo wrote: Earlier today I came accross a problem with the fink validate command (a call to an undefined Perl subroutine). When I checked against CVS, fink (the manager) files on my system were not current. Adrian, Fink (the package manager) has a new release every so often, but between releases we still work on it in CVS. When you run 'fink- selfupdate', you only get new releases--so it's normal for your Fink to be out of date compared to CVS. The current released version of Fink, 0.24.12, should work fine in almost all cases. If you'd like to use the cutting-edge CVS version of Fink, you have to checkout the 'fink' module from CVS and run ./inject.pl . Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Q: Trees search order or precedence?
On Feb 28, 2006, at 3:16 AM, Martin Costabel wrote: In very old versions of fink, the search order used to be from left to right in the Trees line (or so the documentation said). Nowadays it seems to be from right to left. This is, of course, not reasonable, given that local/main is by default still the first item on that line but should be searched first. Yes, .info files in trees on the right override trees on the left. You're right about the positioning of local/main on the left, thanks for pointing that out. But then local/injected is on the right but should also be high-priority, so left-to-right doesn't work too well either. What do you think the correct precedence should be? In reality you should not depend on that search order. It is not only at build time where this can lead to confusion. Also at install time, if you built packages with identical version-revision in two different trees, you have to pray that dpkg finds the right one of the deb files with identical names. When Fink runs dpkg, it will always install the .deb corresponding to the .info with highest precedence. But you're right in the general sense, for example apt-get may become confused. The better solution is to increase the revision for the info file in your local tree: If you have foo-1.2-3 in unstable, make it foo-1.2-3.0 or similar in local. This has the advantage that once the revision in unstable is increased to foo-1.2-4, it will supersede the one in local, which is often what you want. Exactly. The primary directive of Fink is that identical version/ revision means an identical .deb. This prevents much breakage, and keeps things predictable. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Proposal: New percent-expansion for full version (Was: HEAD buildlocks (and maybe others?) don't handle epoch)
On Feb 27, 2006, at 10:11 AM, Daniel Macks wrote: So either there's a bug in get_depends (either its implementation or how it is being called in this code snippet) or there's a bug in your .info file (missing %e in the Depends line). It's a bug in the .info file. The SplitOffs had Depends: %N (= %v-% r). But now that there's an epoch, that should be Depends: %N (= %e: %v-%r). I propose that we add a %V expansion for full version, so we can just write (= %V) and forget about whether or not an epoch is needed. Any objections? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] KDE builds on Intel! (mostly)
On Feb 27, 2006, at 9:57 PM, Daniel Johnson wrote: The blocker for kdeaccessibility3 is gstreamer (at least) which uses assembly language files for it's x86 build. Unfortunately, Apple's assembler appears to use a different syntax than the Gnu assembler and dies horribly when trying to parse the files. It's possible to use the generic C code instead, but it won't be simple to decouple the assembly code from the rest of the x86isms. This could turn out to be a problem with other assembly-using packages. Which version of gstreamer fails, and what's the error? I think the gstreamer folks removed most of their assembly code lately. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree
Alright, here's the reason SysState exists, and why it gives an error. Dpkg has a reasonably serious bug in it: when a package is upgraded, dpkg doesn't check to see if there are any versioned dependencies that have become invalid. This has yet to be fixed upstream, here's one of the several reports on the Debian bugs tracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217862 Typically this bug manifests itself when fink builds an updated version of some package, but then only installs the upgraded -shlibs (not the other splitoffs). The old -dev is now sitting around, with a (= %v-%r) dependency which is no longer valid. (Eg: We now have installed foo-shlibs-2.0-1 and foo-dev-1.0-1 with Depends: foo-shlibs (= 1.0-1) .) There can be other situations where the bug shows up, but this is the most common. When this happens, it's not just an issue of dpkg being less strict, it puts the dependency system in an inconsistent state because Depends are being violated. If you run 'apt-get check', it will report the problem--apt is smarter than dpkg. Fink::SysState is basically a workaround for the problem. When fink installs a package, SysState first checks to make sure that it's not hitting the dpkg bug--if it is, it has a simple algorithm which can fix the most common case (involving splitoffs). If SysState yields an error, it's because the state of installed packages is violating a Depends or Conflicts, so it certainly is an error situation and not a warning. Clearly there are a couple of issues with SysState. It has a small but annoying bug which JFM found earlier, but I have just that single report of it happening, and it doesn't relate to the gettext issue. The error message that it gives is misleading--most often, a SysState error happens when a buildlock is in the way of switching between two conflicts/replace package, in which case 'apt-get -f install' is not at all appropriate. I intend to fix the small bug, and change the error message, but it doesn't help the gettext situation. The real problem is finding an upgrade sequence for all the gettext packages that never leaves the dpkg state inconsistent. I've not looked closely at the situation, so I'm not sure what the answer is, I'll help check it out. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree
On Feb 25, 2006, at 9:48 AM, David R. Morrison wrote: However, there are some pairs of packages (dclib0 and valknut come to mind) which have been set up so that one depends on a precise version of another. It seems to me that these would be completely impossible to update with the strict checking you are discussing, right? There are actually two solutions for tightly-bound packages like this. 1. If we tell dpkg to install both of them at the same time (dpkg -i foo.deb bar.deb), then everything's great. Fink usually does this if they're relatives, such as a parent and its splitoff, or two splitoffs of the same parent. 2. Even if we don't tell dpkg to install both at once, the SysState algorithm will figure things out in the simple cases, when upgrading the depender fixes things. For example, say you have foo-shlibs-1.0-1 and foo-dev-1.0-1 installed with the usual Depends: foo-shlibs (= 1.0-1). If you try to install foo-shlibs-2.0-1, SysState will figure out that foo-dev needs to be upgraded as well. Another thought about this. It should be possible to run SysState *before* building something, to determine what the state will be after the current package is built and installed. That way we could detect in advance that there was going to be a problem, and possibly treat it like a Buildconflicts (i.e., remove something in advance of building the package, possibly putting it back afterwards). This isn't possible in all cases. With AutoShlibDeps (or whatever it's called), we don't actually *know* what the dependencies will be until we're done building something. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree
On Feb 25, 2006, at 11:23 AM, David R. Morrison wrote: 2. Even if we don't tell dpkg to install both at once, the SysState algorithm will figure things out in the simple cases, when upgrading the depender fixes things. For example, say you have foo-shlibs-1.0-1 and foo-dev-1.0-1 installed with the usual Depends: foo-shlibs (= 1.0-1). If you try to install foo- shlibs-2.0-1, SysState will figure out that foo-dev needs to be upgraded as well. Right. In both of your examples, the packages are splitoffs of the same parent, and its clear how to make SysState handle such a situation. My example for SysState's algorithm involved splitoffs, but that's not necessary. It works just as well with non-splitoffs. The problem with gettext is that when you build and install libgettext3-shlibs, the new gettext-tools hasn't been built yet! Even though SysState *wants* to upgrade them as a unit, it can't do so until it has .debs for all of them. The most sensible solution may be to build gettext-tools at the same time as libgettext3-shlibs, I'm not sure what the reasoning is for building them separately. Otherwise, maybe we should make libgettext3-shlibs Conflicts: gettext- tools ( whatever), so that old gettext-tools are removed before we try to upgrade libgettext3-shlibs. I'm not sure how well the dep engine will deal with that solution especially in the dclib0/valknut case, but it may be worth a try. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree
On Feb 25, 2006, at 3:28 PM, David R. Morrison wrote: To explain: after the update, gettext (which really means gettext- shlibs but for historical reasons is called gettext) and gettext- dev are in one package, which is really just a legacy package for the old version of the library. The libgettext3-shlibs package contains gettext-bin as a splitoff (this is one of the things that was causing problems during the update). And gettext-tools is in yet a third package. The split between libgettext3-shlibs and gettext-tools follows the packaging recommendations of the upstream author, and is a good thing to do because eventually libgettext3-shlibs will be essential and a part of our bootstrap and this split will dramatically decrease the bootstrap time. The split itself, though, is irrelevant for the current problem since both gettext-bin and gettext-tools are causing trouble. It's actually only gettext-tools that is the problem. SysState would be able to resolve the gettext-bin part alone, since the .deb is available, but it can't resolve it in combination with the gettext- tools part. Since it can't figure out how to completely fix the situation, it just reports all the problems--including those it could fix. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree
On Feb 25, 2006, at 4:07 PM, David R. Morrison wrote: So its only because we don't have a deb for (old) gettext-tools? If I built the old gettext-tools first it would be OK? Gah, I've been getting things wrong. Lemme see if I can get this straight. We have these packages in stable: gettext (-bin -dev -tools) 0.10.40-19 And in unstable: gettext (-dev) 0.10.40-24 libgettext3-shlibs (-dev gettext-bin gettext-doc) 0.14.5-1 gettext-tools (libgettextpo2-dev libgettextpo2-shlibs) 0.14.5-3 The problem occurs on the upgrade from gettext 0.10.x in stable to gettext 0.10.x in unstable, right? I was getting this mixed up before, so you can neglect my last mail. What we need then is to ensure that the old gettext-bin/tools are no longer installed at the time when the new gettext is installed. Either the gettext-bin/tools packages could be completely uninstalled, or they could be upgraded to the new gettext-bin/tools-- both situations would work. It's still possible that adding to the new gettext Conflicts: gettext- bin ( 0.14.5-1), gettext-tools ( 0.14.5-1) would satisfy, I'm not sure how the dep engine would treat that. Or, we could be hacky and add 'fink build gettext-bin gettext-tools' to the new gettext's CompileScript, like we used to do in some other weird case. I'm unsure what to do about valknut/dclib0, I'm not sure that there's any good way to tell fink that it needs to uninstall an old valknut, then build the new dclib0, then build and install the new valknut. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] some gtk+2 issues
Thanks for the testing Daniel! Indeed no such file exists in any gtk+2 splitoffs, but if I run /sw/ sbin/update-gdk-pixbuf-loaders from gtk+2 that file is created and abiword works. I think update-gdk-pixbuf-loaders needs to be run during the gtk+2 build. Actually it needs to be run at install time--and lo and behold, the PostInstScript runs it. I'm not sure what happened on your system to stop it from running. Also, gtk+2 must be installed at runtime in addition to gtk+2- shlibs or abiword crashes anyway. Yeah, end user programs are likely to need gtk+2 as a dependency. If they use SVG, they'll also need librsvg2-gtk . Notify the maintainer-- if Jeffrey Whitaker is currently unavailable/on vacation, it's ok to make a simple dependency change like this yourself as well. Abiword also crashes when quitting, but that's not terribly important and I didn't look into it very closely. Got a crash log/backtrace? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] fink commander 0.5.4 known broken?
On Dec 7, 2005, at 6:04 AM, Randal L. Schwartz wrote: Or is it something peculiar to me that keeps it saying updating the table data with a barber pole forever? Randal, What version of Fink are you running? Unreleased versions from CVS have a known issue with FinkCommander updating the table extremely slowly. There's a fix for this in FinkCommander CVS. Otherwise check the process tree to see if FC has any sub-processes, perhaps one is hanging. You could also run FinkCommander in gdb and get us a stack trace while it's stalled. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Fink binary distributions
On Nov 5, 2005, at 11:28 PM, Chris Dolan wrote: On Nov 5, 2005, at 5:45 PM, Alexander K. Hansen wrote: A problem opposite to the one that you mentioned also occurs: building on different machines with different packages that solve the same virtual dependency (e.g. Xorg vs. Apple's X11) will generally result in more than one MD5 for the same package. Also, many .debs can be built with different versions of a dependency. This gives the binaries different results for 'otool -L', and different MD5's. I think prebinding also plays some games with libs that can cause MD5's to differ, not sure if this is still relevant though. I wouldn't be surprised if some packages include a date in the build, as well, which would make MD5's differ too. Anyhow, the point is that comparing MD5's, while a cool idea, is unlikely to work. Hmm... Then, wouldn't that be a problem for bindist in general? The bindist only needs a single, correct .deb per package. Many of the things that could make a MD5 differ aren't really problems, any of the individual .debs with different MD5's could replace each other. In some cases, like xorg/x11 and foo/foo-ssl, there are actual compatibility issues introduced. The solution to this is to build with the *least restrictive* packages. Eg: Build with x11 installed rather than xorg, since that package will work with either. This is something that buildfink will need to be taught before we use it to make the bindist. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Fink binary distributions
On Nov 5, 2005, at 1:01 AM, Philip Lamb wrote: Originally, I was under the impression that there was a machine autobuilding packages and uploading the binaries. However this is obviously untrue. Does the fink project have the resources to have such an autobuild system established? Ideally, packages would be built as .info files are committed, and so there wouldn't be too much of a massive load. There exists a tool 'buildfink', written by Matt Sachs at Apple, which essentially attempts to build (and validate) all of Fink. You can find it in our 'scripts' module in CVS. We have the intention of modifying it so it can work with a queue of .info files, at which point it could be used to handle submissions from the tracker and/or commits to a tree. Nobody has gotten around to that yet, but if you'd like to hack on it you're welcome to! When it comes to a system to perform the builds on, we don't really have anything at this point. A build box should ideally be a very clean system, since we don't want any .debs to be accidentally polluted. Also, we'd have to be careful it's under the control of trusted people, since there's a security risk with distributing binaries. Something to think about once we get sufficient work done on buildfink. Aside from hacking on buildfink, the best way to help is testing packages. Maybe we should have a 'Test Week', when we ask all developers to NOT write new packages, and instead test various packages out and move them into stable? Another good thing would be to do more buildfink runs. If anybody has a box that can churn for a week... Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Intriguing!
On Oct 27, 2005, at 8:42 AM, Murali Vadivelu wrote: configure: WARNING: There is an installation error in jpeg support. You seem to have only one of either the headers _or_ the libraries installed. You may need to either provide correct --with-extra-... options, or the development package of libjpeg6b. You can get a source package of libjpeg from http:// www.ijg.org/ Disabling JPEG support. Please show us relevant parts of the config.log in your build directory. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] May I try to maintain deborphan orphaned package ?
On Oct 8, 2005, at 4:31 AM, Philippe Lelédy wrote: I've used Fink since the beginning, both binary and source distibutions. I've experimented a bit with software packaging in general and with fink packaging in particular. So I'd like trying maintaining some fink packages, and I thought deborphan could be a good choice for starting. What shall I do. Salut Philippe, You should probably make an updated .info file for deborphan, and then submit it to our package submission tracker. You can also check out our *draft* guide for new maintainers: http://wiki.opendarwin.org/ index.php/Fink:NewMaintainer Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Binary Installer (0.8.0) not very usable on a non-dev system
On Oct 5, 2005, at 2:56 AM, Martin Costabel wrote: If you only use apt-get, you don't need the dev tools. The new -- use-binary-dist flag in fink rather muddies the waters here, because it seems to promise that you can use the binary dist with the fink command which is only partly true. Yeah, my instructions to new users has always been install Fink with the binary installer, then use apt-get. If it's desirable, we could make fink-the-program display a Very Prominent Warning if someone tries to run it without the dev tools installed, suggesting that the user either install the tools or use apt. Yea or nay? We may also want to talk with the FinkCommander folks to see if they can make FC deal with this situation gracefully. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] renaming a package
On Sep 25, 2005, at 7:22 AM, Koen van der Drift wrote: Found the problem, I forgot to remove the Conflicts field in biopython-py.info: What about the Replaces and Provides fields, can they stay in the info file ? Hmm, it looks to me like they should all be there (including Conflicts). I hope this doesn't mean my dependency resolution algorithm is broken, I'll have to look into the situation. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] renaming a package
Hi Koen, Judging from your error messages, it looks like the biopython-py24 you had installed and the one you had in a .deb were different, even though they had the same version/revision. (This can happen if you make changes and rebuild.) Could you try installing python-biopython- py24 again, and see if the error is the same or different? Also, please run fink with the -v flag, just in case there are any messages that Fink isn't printing. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] gettext problems
On Sep 21, 2005, at 10:37 PM, TheSin wrote: The following errors remain: Unsatisfied dependency in gettext-tools: gettext (= 0.10.40-19) To fix manually, run: sudo apt-get install gettext-dev=0.10.40-24 gettext=0.10.40-24 Hmm, why is there no gettext-tools 0.10.40-19? There should either be one, or if it's no longer necessary then gettext should Conflict/ Replace it. Can somebody look into this? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Developer access for committing info files
On Sep 13, 2005, at 6:10 PM, Philip Lamb wrote: A quick question as to what the criteria are for giving a developer access to commit info files to the fink repository. It's been kinda informal up to now, basically after you have a few packages under your belt some developer will take notice and ask fink- core to give you developer privileges. I'd say the usual number of packages it takes is 3 to 10. I have several more that I use locally, and would add to fink except that I know that they will languish in the tracker, for want of someone to look at them. How many people on the fink project have access to move info files into the cvs repository? Judging by the number of packages in the tracker with group undergoing validation it seems that there are too few. You can find the full list by checking the file CVSROOT/avail in Fink's CVS repository. It seems the current number is 62, which is quite a lot. However, with 2600 .info files in 10.4-transitional/ unstable, most of the more involved developers have dozens of packages to maintain, so it's hard for people to find time to look at submissions. This clearly has caused much suckiness in the tracker. We're well aware of this, there's even a top-priority bug on the tracker devoted to dealing with it: http://sourceforge.net/tracker/index.php? func=detailaid=1286402group_id=17203atid=117203 Some of the ideas we've had to speed things up are: - Automatic building/validation of packages, to automatically catch common problems. This would need some work on tools to perform the auto-building. - Mentoring of new developers by existing devs, to focus efforts into getting submitters ready for full privileges. (Would you like to be the first to sign up? http://wiki.opendarwin.org/index.php/ Fink:Mentoring ) - Allowing existing devs to give up their packages for adoption by new devs. This could give new devs a good starting point, and could lessen the workload on some of our more prolific devs. There are some *draft* documents on the wiki that I encourage everyone to look at and critique: http://wiki.opendarwin.org/ index.php/Fink#The_new-maintainer_process I'd like to hear any constructive comments about the process, so press the reply button or just drop by #fink. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] New dep-fixing algorithm
Hi folks, I worked on that algorithm that was causing so much trouble before. It should now ignore any pre-existing problems, it will just make sure not to cause more trouble. Testing would be appreciated. Thanks for the bug reports, Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildConflicts swapping code still not quite there
On Sep 12, 2005, at 11:07 AM, Jean-François Mertens wrote: Do you want to continue? [Y/n] (assuming default) Could not resolve inconsistent dependencies! The following errors remain: Unsatisfied dependency in font-ttf-pm-bin: font-ttf-pm (= 0.34-1) snip about 20 more bad deps Wow, that's a lot of breakage. You might want to rebuild some packages... For this type of thing, an opt-out mechanism would be useful, Yeah, it's clear that a user may still have to install things via Fink, and Fink shouldn't block that entirely. Here's what I'm planning on doing. I'm going to modify Fink's algorithm for deciding when it's safe to install things. The new algorithm will leave intact any broken dependencies with are pre- existing, but it will make sure that NEW problems are not introduced. Will that be a good enough fix? I'd rather not have an option to allow Fink to automatically mess up a user's system, it's not really safe. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildConflicts swapping code still not quite there
On Sep 11, 2005, at 8:38 AM, Martin Costabel wrote: Whereas the swapping code now manages to swap several BuildConflicts in and out during one run, there seem to be narrow limits to its capacity. BuildConflicts is known to be mostly broken, there's a bug on the tracker. It also hasn't been improved lately, the BuildDepends swapping which was added in Fink 0.24.9 is a different issue. dpkg: regarding .../fink-buildlock- python24-2.4.1-101_2005.09.11-14.02.25_darwin-powerpc.deb containing fink-buildlock-python24-2.4.1-101: fink-buildlock- python24-2.4.1-101 conflicts with libquicktime0 libquicktime0 (version 0.9.4-11) is installed. You can almost certainly get around this for now by manually removing libquicktime0, then building python24. After that the original command should work, or at least get farther. Removing fink-buildlock-fink-0.24.99.cvs-20050911.1229 ... Failed: Fink::SysState: Could not resolve inconsistent dependencies ### execution of /sw/bin/fink failed, exit code 1 Ok, the error message for this should probably be more verbose by default. Try installing the new fink in verbose mode: 'fink -v update fink'. That should make it say what's inconsistent about your system's dependency state. Also, see if running 'apt-get check' finds any problems. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildConflicts swapping code still not quite there
On Sep 11, 2005, at 1:50 PM, Martin Costabel wrote: Dave Vasilevsky wrote: You can almost certainly get around this for now by manually removing libquicktime0, then building python24. After that the original command should work, or at least get farther. Sure, but it's a bug anyway. It works even when I just update python24; it is then able to remove libquicktime0 by itself. Only after the preceding useless swapping in and out it doesn't work. It seems to me BuildConflicts always only work right once at the beginning of a build process, but they are only detected later, in general, when it's too late. Martin, Yup, it definitely is still a bug. You're right about why it happens: Fink only deals with BuildConflicts at the very start of the build process. I intend to fix this bug sooner or later. The way I'd like it to work is kinda like the BuildDepends swapping: immediately before building a package, Fink checks for BuildConflicts and removes them. Then just after the build, they're reinstalled. Dan has been looking into a way to uninstall buildlocks after a build, regardless of whether it succeeds or fails--so I'll probably use whatever mechanism he comes up with to reinstall the BuildConflicts after. and so on, and fink -v install fink said Could not resolve inconsistency! The following dependency errors remain: Unsatisfied dependency in gdal-shlibs: postgresql80 (= 8.0.2-12) | postgresql80-ssl (= 8.0.2-12) Unsatisfied dependency in gdal: postgresql80 (= 8.0.2-13) | postgresql80-ssl (= 8.0.2-13) Just some explanation of what this is all about. Due to a bug in dpkg, installing a package can sometimes cause unsatisfied dependencies. As an example, say you have foo and foo-shlibs version 1.0-1 installed, where foo Depends: foo-shlibs (= 1.0-1). If a new version 2.0-1 is released, then 'fink update foo-shlibs' used to update foo- shlibs to 2.0-1 but leave foo at 1.0-1, which is broken. To prevent this, Fink (from CVS HEAD) now refuses to install anything unless it determines that all dependencies on the system will be satisfied. Currently there's a primitive problem-resolver algorithm in Fink, which can deal with the specific situation above but not much else. The general solution is running 'apt-get -f install', as you did. If anybody has a problem with this new way of doing things, now's the time to tell me. I could make Fink less strict if people need the ability to have some broken deps. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Re: fink ChangeLog,1.363,1.364 fink.conf.5.in,1.31,1.32
On Aug 30, 2005, at 10:38 PM, Benjamin Reed wrote: Bzip2Path: the path to your bzip2 (or compatible) binary The Bzip2Path option lets you override the default path for the bzip2 command-line tool. This allows you to specify an alternate location to your bzip2 executable, pass optional command- line options, or use a drop-in replacement like pbzip2 for decompressing .bz2 archives Ben, This seems a little...er...specific. Maybe that's ok I guess, but it feels wrong somehow. If this is an ability that people find themselves wanting, maybe we should generalize it? We could have a Executables: option that lists name:path pairs, and could eventually let users specify alternatives for anything. Or a exec-prefix dir where users could just drop symlinks to executables they'd prefer Fink would use. Or maybe Fink should even put the Fink paths at the *end* of PATH instead of the beginning, so it uses whatever the user has in his|her path (at the risk of choosing something bad). Opinions, anyone? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] fileutils missing dep on libgettext3-shlibs kills /usr/bin/gcc
On Aug 28, 2005, at 4:05 AM, Martin Costabel wrote: /usr/bin/env PATH=/usr/sbin:/usr/bin:/sbin:/bin gcc_select Fink now does this, thanks for the advice. Just my €0.02 Or 3¢ Canadian. Darn all you folks with currencies that are worth something... Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] XCode Legacy Tools on ADC
On Aug 23, 2005, at 6:21 PM, Daniel Johnson wrote: An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :) Fink's gcc3.1 package installs into the fink prefix (usually /sw), so it's not as if there's a critical problem with Fink's GCC overwriting Apple's GCC 3.1. It just means a bit of extra compile time and installation space, when they end up installed in parallel. I wouldn't object to synchronizing the version numbers of the GCC 3.1 virtual package and the real package. Currently the virtual one is at version '3.1' and the real one uses the build number '1175', it should be possible to have them both use '1:3.1-1175' for example. Perhaps there is a pressing reason why they need to be different? One problem, however, is keeping these versions in synch. If there's a minor change to the real package, and the revision needs to be bumped, should the revision of the virtual package be bumped too? And how will the virtual package engine know when its revision needs a bump? Another potential problem arises if there's a particular package somewhere that needs specifically the Apple or Fink version of GCC 3.1 (assuming there turns out to be any bug or other difference in one of them). Any ideas how to get around these issues? If it's not reasonably easy to do so, it might be best to just live with the imperfect but working solution we have now, and simply deal with the extra time and space needed to install Fink's gcc3.1 in parallel. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Help in Gnome apps
On Aug 22, 2005, at 2:30 PM, Sébastien Maret wrote: I can't read the help files of Gnome app. I don't really have much to contribute here. Just confirming that this happens, and that I don't know why. Maybe a bug in yelp? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] aqua native software
On Aug 14, 2005, at 1:18 PM, Ben Willmore wrote: I think a better solution would be for Fink detect the version of XCode that is being used, and explicitly make that information available in a % expansion, I don't think it's necessarily a good idea to have such a specific percent expansion. But the great thing about using a shell script as your Compile/InstallScript is that you can set any shell variable you like, so if you want to detect XCode versions that's doable. See the solution Matt Sachs came up with for my osxutils package: InstallScript: #!/bin/sh xcver=$(xcodebuild -version | grep DevToolsCore | \ sed 's/.*DevToolsCore-//' | sed 's/\..*//') if [ -z $xcver ] then echo Couldn't determine xcodebuild version 21 exit 1 elif [ $xcver -lt 620 ] then builddir=build else builddir=build/Deployment fi Just copy that into your .info file, and then you can just do 'install -m 0755 $builddir/whatever %i/bin/'. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Is there a Launchd alternative to daemonic?
On Aug 13, 2005, at 1:28 PM, William Scott wrote: Is there a way for fink to install a Launchd file into /Library/ LaunchAgents for 10.4 packages? Not yet. It would not be terribly hard however to 1) Make a version of Daemonic that uses launchd instead of startup items but is otherwise entirely compatible, and/or 2) Create a new syntax for installing launchd plist files. If there's not already a command line tool to enable/distable a launchd daemon, that would be needed as well. Anybody who wants to work on either of these is welcome. As a follow-up, would it be permissible to have a /sw/etc/profile.d/ foo.(c)sh file that has a line in it like launchctl load /sw/path/to/my/package/LaunchAgent ? You want to scan the LaunchAgents every time you open a shell!? There must be a better way than that. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Where is info2 format documented?
On Aug 6, 2005, at 10:55 AM, Kevin Horton wrote: 1. These examples suggest that the info2 portion can be imbedded in a regular .info file. I.e. I don't need to have the Info2: at the top of the file. But, if I look at the .info files on my HD, I can only find the Info2: at the top of the file. Does the whole info file need to be inside the Info2 block? Hi Kevin, Info2 (and any future Info3) should wrap the entire contents of the .info file, yes. The reason for this is that if we ever change the format of .info files in a non-backwards-compatible way, we want older versions of Fink to at least be able to detect I won't be able to understand this. If Info2 is right at the beginning, then it's guaranteed that every version of Fink will be able to notice it without getting confused by syntax it doesn't understand. 2. I can only use the %type_raw[] and %type_pkg[] pseudo-hashes inside the info2 portions of the .info file. Is this correct? You can only use them in a .info file that's wrapped by Info2. You can't have both a Info2 and non-Info2 portion of the same .info file-- it either wraps the whole thing, or it's not there at all. 3. The only new capability that using info2 adds is the ability to use %type_raw[] and %type_pkg[] pseudo-hashes. Is this correct? Pretty much. Technically, you only need Info2 if you're going to use % type_* in the Package field, but there's not much you can do with them otherwise. Sorry for the confusion, we'll try to make things clearer in the future. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] libggetext3
On Aug 4, 2005, at 6:05 AM, Max Horn wrote: Alas, libggetext3 isn't in stable (yet). My question: Are there plans to move it to stable soon? Max, Because libgettext3 and gettext-dev conflict, the Fink dependency engine has to be able to switch back and forth between them when build other packages. A reliable version of this swapping code was only recently finalized, and will be in fink 0.24.9. As soon as that's in stable, libgettext3 can go to stable as well. I'd like to release 0.24.9 to unstable very soon. There's just one other bug-fix going into 0.24.9, that should enable Essential packages to be SplitOffs, and I'm waiting for cirdan to make sure that works. Then it's just some testing and release. A couple weeks after it's been in unstable, if there are no big problems, we'll push it to stable. Gist of that is, in about two or three weeks I expect you'll see libgettext3 in stable. If you'd like things to go faster, you can help test :-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Use-binary-dist flakiness
On Aug 4, 2005, at 7:12 PM, Martin Costabel wrote: This one comes from the Installed-Size: field in the DEBIAN/ control file. apt-get compares package versions not only by their version-revision number, but also by a VersionHash number which is computed by taking into account several fields of the control file (in apt-pkg/deb/deblistparser.cc), in particular the Installed-Size field. Therefore two copies of the same package with the same version, but different Installed-Size values are considered different, and in the apt-cache commands dump, show, showpkg they are listed as separate versions. Thank you for figuring out this much, it should help a lot :-) If the problem is that apt considers the .deb on the server and the .deb on my hard drive to be different, one thing that confuses me is why we only see this problem in one direction. IE: Apt will download a package to replace the one I have installed via Fink, but I've never seen apt install a .deb on my disk to overwrite a downloaded one. Is there something special about one or the other situation? Perhaps apt only gets confused if it doesn't see the .deb on your disk at all, for example if you haven't run scanpackages in a while? That would explain why I don't see this error much anymore. If I understand correctly how fink determines if a package is apt- gettable, it can trip over the problem with different Installed- Size fields, too: It looks at the output of apt-cache dump and if the remote version has a different Installed-Size from the locally installed version, the dump shows the same version with several different File: fields; if the last one of these is /sw/var/lib/ dpkg/status, the version is marked as not apt-gettable, although the version may exist on the remote server. I don't understand, however, how this can happen for a package version that is not yet locally installed, which is where I am seeing this happen. Perhaps something to do with the apt cache files in /sw/var/cache/apt/ installed by the Fink installer. I'll try looking into this. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] gfortran package
Martin, I'm sorry if we came off as brash and inconsiderate. I definitely was not advising that we shouldn't package gfortran 4.1-CVS out of ideology, or blindly following rules. Hopefully my explanations here can allay your concerns. First, I agree with you that every package should have representation in Fink. If there was no gfortran in Fink, I would want one. But we already have gfortran as part of gcc4 4.0.1. The question so far as I understand it is what version should be in Fink, the released 4.0.1 or the pre-release CVS snapshots from 4.1. Sometimes we do release CVS snapshots, and I don't think there should be a policy snapshots are never, ever ok. There are plenty of cases where pre-release software should clearly be in Fink: * Other packages, which we want in Fink, depend on unreleased features. * There's a critical bug in the last release version, and it's impossible to backport a fix. * There are important new features/bugfixes in unreleased versions, and there's no prospect of a new release any time soon. * Only the snapshots actually work, older versions are broken. But when it comes to including pre-release software, we face the strong possibility that things aren't ready for release (hence the name). This is why we don't have daily CVS checkpoints of GTK+ for example. We already have a working, reasonably stable package. And we can be pretty sure there will be a new release in a few weeks or months, so the new features will get to users. It's not worth it to break GTK+ every time some committer to their CVS repository screws up. Basically, we don't want to turn our users into unwitting beta- testers when they update-all. The arguments for including gfortran 4.1-CVS all seem to have better solutions than putting 4.1-CVS in Fink unstable, here are the ones I've seen: - To practice gfortran packaging, so Fink can get 4.1 quickly after it is released. This is what experimental is for! - So GCC can allow users to test gfortran 4.1 snapshots. This can be done without making every Fink user beta-test, by telling users who actually want test 'download this .info file, put it in your local finkinfo dir and type fink update gfortran'. Now I don't know much about Fortran or gfortran development, so maybe I've completely missed something. It's possible that there won't be a gfortran 4.1 release for two years, or that the gfortran in Fink is currently unusable. So if I've misunderstood anything, kindly correct me and we'll get gfortran 4.1-CVS into Fink. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Treatment of virtual packages, Version 2
On Jul 30, 2005, at 3:24 PM, Alexander Hansen wrote:IMO we shouldn't have 'bar' provide 'foo' as well as have a separate 'foo' package. This is a continual source of chaos. There are many many packages right now that do this. Major reasons are: variants/ssl, old packages that used to be separate but are now integrated into another package, system-* packages that include the functionality of real packages.I wrote a little script that produces a list of all these cases, list and script are attached. Note that some packages seem to explicitly provide themselves, ie:Package: fooProvides: fooI can't for the life of me understand what this could hope to accomplish, it seems very redundant. I suspect it is a packaging error.Dave#!/usr/bin/perl
use warnings;
use strict;
use POSIX qw(strftime);
use Fink::Services qw(read_config sort_versions);
use Fink::Package;
(my $basepath = `which fink`) =~ s/bin.*//s;
read_config($basepath/etc/fink.conf);
#open OLDERR, STDERR;
#close STDERR; # stop indexing output
Fink::Package-require_packages;
#open STDERR, OLDERR;
#close OLDERR;
my @packages = Fink::Package-list_packages;
my @mine;
for my $pkg (sort @packages) {
my $po = Fink::Package-package_by_name($pkg);
if (scalar(@{$po-{_providers}}) scalar($po-list_versions)) {
my @versions = sort_versions $po-list_versions;
my @providers = sort { $a-get_fullname cmp $b-get_fullname }
grep { $_-get_name ne $pkg } $po-get_all_providers;
print $pkg\n;
print Versions:\n;
for my $v (@versions) {
printf %-10s - %s\n, $v,
$po-get_version($v)-get_info_filename;
}
print Providers:\n;
for my $p (@providers) {
printf %-25s - %s\n, $p-get_fullname, $p-get_info_filename;
}
unless (@providers) {
printf One of this package's versions provides itself!?\n;
}
print \n;
}
}
babel
Versions:
1.6-5 - /sw/fink/dists/unstable/main/finkinfo/sci/babel.info
Providers:
openbabel-1.100.2-11 -
/sw/fink/dists/unstable/main/finkinfo/sci/openbabel.info
bitchx
Versions:
1.0c19-31 - /sw/fink/dists/stable/main/finkinfo/net/bitchx.info
1.0c19-32 - /sw/fink/dists/unstable/main/finkinfo/net/bitchx.info
Providers:
bitchx-gtk-1.0c19-31 -
/sw/fink/dists/unstable/main/finkinfo/net/bitchx-gtk.info
bitchx-gtk-ssl-1.0c19-31 -
/sw/fink/dists/unstable/crypto/finkinfo/bitchx-gtk-ssl.info
bitchx-ssl-1.0c19-32 -
/sw/fink/dists/unstable/crypto/finkinfo/bitchx-ssl.info
blackbox
Versions:
0.65.0-12 - /sw/fink/dists/unstable/main/finkinfo/x11-wm/blackbox.info
Providers:
blackbox-rootless-0.65.0-1 -
/sw/fink/dists/unstable/main/finkinfo/x11-wm/blackbox-rootless-0.65.0-1.info
blackbox-taskbar-0.62.1-22 -
/sw/fink/dists/unstable/main/finkinfo/x11-wm/blackbox-taskbar.info
bonobo-activation2
Versions:
2.6.2-9- /sw/fink/dists/stable/main/finkinfo/gnome/libbonobo2.info
2.10.0-1 - /sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info
Providers:
libbonobo2-2.10.0-1 -
/sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info
libbonobo2-2.6.2-9-
/sw/fink/dists/stable/main/finkinfo/gnome/libbonobo2.info
bonobo-activation2-shlibs
Versions:
2.6.2-9- /sw/fink/dists/stable/main/finkinfo/gnome/libbonobo2.info
2.10.0-1 - /sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info
Providers:
libbonobo2-shlibs-2.10.0-1 -
/sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info
libbonobo2-shlibs-2.6.2-9 -
/sw/fink/dists/stable/main/finkinfo/gnome/libbonobo2.info
cdda2wav
Versions:
1.11a39-2 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-1.11a39-2.info
Providers:
cdda2wav-beta-2.0.1a19-1 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-beta.info
cdrecord
Versions:
1.11a39-2 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-1.11a39-2.info
Providers:
cdrecord-beta-2.0.1a19-1 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-beta.info
cdrtools
Versions:
1.11a39-2 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-1.11a39-2.info
Providers:
cdrtools-beta-2.0.1a19-1 -
/sw/fink/dists/unstable/main/finkinfo/utils/cdrtools-beta.info
cvs
Versions:
1.11.5-1 - /sw/fink/dists/unstable/main/finkinfo/devel/cvs-1.11.5-1.info
1.11.17-1 - /sw/fink/dists/stable/main/finkinfo/devel/cvs.info
1.11.20-1 - /sw/fink/dists/unstable/main/finkinfo/devel/cvs.info
Providers:
cvs-proxy-1.11.5-1-
/sw/fink/dists/stable/main/finkinfo/devel/cvs-proxy-1.11.5-1.info
db41-shlibs
Versions:
4.1.25-22 - /sw/fink/dists/stable/main/finkinfo/libs/db41.info
Providers:
db41-ssl-shlibs-4.1.25-22 -
/sw/fink/dists/stable/crypto/finkinfo/db41-ssl.info
db42-shlibs
Versions:
4.2.52-16 - /sw/fink/dists/stable/main/finkinfo/libs/db42.info
Providers:
db42-ssl-shlibs-4.2.52-16 -
/sw/fink/dists/stable/crypto/finkinfo/db42-ssl.info
dcmtk
Versions:
3.5.2-11 -
Re: [Fink-devel] Treatment of virtual packages, Version 2
One confusing thing is with 'fink remove'. If there's an actual package 'foo' and also a package 'bar' which provides 'foo', what should 'fink remove foo' do? 1) Remove just foo, if it's installed? 2) Remove foo and bar if either are installed? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] gfortran package
On Jul 30, 2005, at 7:21 AM, Max Horn wrote: Fink is not (!) supposed to be a test-bed for an unreleased compiler. It is easy enough to build gcc from cvs. Yes, exactly. Fink is a distribution, not a testing system. There's no reason that fink (lowercase, the package manager) can't be used for testing, if that's useful to you, but in that case you should put the .info/patch files in experimental or your own private distribution. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: fink/perlmod/Fink ChangeLog,1.1072,1.1073 Package.pm,1.145,1.146
On Jul 29, 2005, at 11:38 AM, TheSin wrote: it won't be cause now if a Info2 is added that has spacing it'll break parsing on older finks. We simply can not allow spaces in Info2, without using Info3. Good point! Ok, Info3 then. Flame away! :-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: fink/perlmod/Fink ChangeLog,1.1072,1.1073 Package.pm,1.145,1.146
On Jul 29, 2005, at 1:55 PM, Daniel Macks wrote: Apply this python method to all fields, not just Info3 (pass $infon read_properties_var and do it in the parser). Ok, done. With this code, Python scripts in CompileScript, and indented shell heredocs and all kinds of stuff that was hard and ugly before is now nice. See my nutty example: test.info Description: Binary data The only thing to keep in mind is that if you're using whitespace- removal features, MIX SPACES AND TABS WITH GREAT CARE. In fact, I recommend you pick either spaces or tabs and stick to it. Because this will break: Info3: PrecededBySpaces: foo PrecededByTab: bar ... This issue can be fixed if we get rid of RFC-822 :-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] pilot-link9-0.11.8-32
On Jul 22, 2005, at 10:34 PM, Mark Marin wrote: mv: rename /sw/src/fink.build/root-pilot-link9-0.11.8-32/sw/lib/ python2.3 to /sw/src/fink.build/root-pilot-link9-py23-0.11.8-32/sw/lib/ python2.3: No such file or directory This is usually indicative of a failure earlier in the build. Please check farther up the log. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] New fink release, testing needed
On Jul 26, 2005, at 7:47 PM, Kyle Moffett wrote: I think I remember that it used to create/update apt-get package lists for local filesystem repositories, so that when running dselect you can see what deb files are on the local filesystem, even if they aren't installed at the moment. As akh pointed out, fink scanpackages does this now. Note that if you use Fink from CVS HEAD, and install the package apt-ftparchive, scanpackages runs much faster than it used to--but for some reason we left this feature out of 0.24.8, I'm not sure why. Personally I much prefer aptitude to deselect, even when not using it to just install packages, because it allows one to mark packages as installed only due to dependency and it will automatically remove them when the depending package goes away or is upgraded. I use 'debfoster' for this. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] New fink release, testing needed
Hey folks, We're about to release fink 0.24.8. This is a bit of a bigger point- release than usual, because a bunch of features from the future 0.25 have been backported, so we'd like to get a few days of testing on - devel before release. To try it out, you can access the branch 'branch_0_24' in CVS, or just download a tarball here: http://vasi.webhop.org/files/fink/ source/fink-0.24.8pre.tgz . Unpack, cd into the directory, and run './ inject.pl'. Here are some of the new features, full changelog is at http:// vasi.webhop.org/files/fink/fink-0.24.8-ChangeLog : * 'fink rescan' is deprecated because nobody knows what it's for. If you know, tell us! * Dpkg and apt lockwait: if you're running two instances of fink, and they both try to run dpkg or apt, breakage will no longer occur. * Spotlight protection: fink offers to disable spotlight indexing on your build directory (10.4 only). * Prebinding disabled on Tiger. * Bug in Repair Permissions that can cause compiles to fail is automagically fixed. * 10.4.2 officially supported, 10.2 deprecated. * Bootstrap .info files and mirrors updated: bootstrap with XCode 2.1 works again. * Removing the last versioned perl module now does UpdatePOD properly. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] New fink release, testing needed
On Jul 25, 2005, at 7:33 PM, Randal L. Schwartz wrote: Dave * 'fink rescan' is deprecated because nobody knows what it's Dave for. If Dave you know, tell us! I've used it as a ritual turn east and pray action when I've gone in and hacked my local .info and .patch files. Is it no longer needed? Hi Randal, Usually fink should detect and update your index automagically. If for some reason it doesn't, the way to fix it is 'fink index'. As far as I can tell from the current code, 'fink rescan' will NOT fix this problem. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/base tar.info,1.8,1.9
On Jul 20, 2005, at 4:56 AM, Martin Costabel wrote: I can understand that one would require packages to have *explicit* dependencies on essentials, as a preparation to eventually un- essentialize some of these, but *implicit* dependencies on essentials seems to be nonsensical. They are essential, so they are always there. So what's the sense of this? Martin, These 'implicit dependencies' are the *mechanism* that fink uses to ensure that they're always there. Our treatment of essential packages currently has a couple of, uh'surprising features'...so I'll be looking at changing some things. One of the changes under consideration is stopping these implicit dependencies, but this could break a lot of packages, so if we do this it might be best to start during construction of the 10.4 tree. Alternatively, maybe we could get buildfink to check for us how much would break this way, I'll talk to msachs about that. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Fwd: Compiling pwlib on 10.4 (Tiger)
On Jul 18, 2005, at 10:42 AM, Kyle Moffett wrote: virtual thunk to std::basic_istreamchar, std::char_traitschar ::~basic_istream() If you do a 'nm -m' on libstdc++, that symbol is in section (__TEXT,__textcoal_nt), which means it's a 'coalesced' symbol. I'm not sure if this is relevant, but I do know that we've encountered a number of problems with this Apple 'innovation'. Unfortunately, I don't remember quite what goes wrong with coalesced symbols or how to fix it, hopefully somebody else has a better memory than mine. I suspect that if you can get your package building with g++ 3.3 (or even 4.0!), that would make the problem go away. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] build error: directory
On Jul 10, 2005, at 9:36 PM, Jesse Alama wrote: When the file emacs-wiki_2.68.orig.tar.gz, which is downloaded from the debian, is unpacked it creates the directory `emacs-wiki'. Judging from the final error message, it seems that fink expects the unpacked file to be called something else, though, namely `emacs-wiki_2.68.orig'. Yes, you need to use a SourceDirectory field. Please see its entry in the packaging manual. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] gtk+2 strangeness.
On Jul 8, 2005, at 11:43 PM, Corey Halpin wrote: (gdb) bt #0 0x8fe0878c in __dyld_is_library_loaded_by_name () #1 0x8fe02e38 in __dyld_load_library_image () #2 0x8fe0642c in __dyld_load_images_libraries () #3 0x8fe04720 in __dyld_map_bundle_image () #4 0x8fe12ec8 in __dyld__dyld_link_module () #5 0x9003fc88 in NSLinkModule () #6 0x9011f4fc in loadModule () #7 0x9011f884 in dlopen () #8 0xbe90 in g_module_open () #9 0x2d80 in query_module () #10 0x2c2c in main () #11 0x263c in _start (argc=1, argv=0xbb10, envp=0xbb18) at /SourceCache/Csu/Csu-47/crt.c:267 #12 0x8fe1a278 in __dyld__dyld_start () Hey Corey, I'm kinda lunging in the dark here, but it could be useful to find out which dlopen is causing the crash. Could you set a breakpoint action to print that? This should work: $ gdb gdk-pixbuf-query-loaders (gdb) break dlopen (gdb) commands x /s $r3 continue end (gdb) run Also, try running otool on that loader, just for the hell of it :-) Reason I'm asking is 1) to detect if you have any external libraries linked in by accident and 2) to see if it can explain the 'warning: Unable to read symbols from N?'. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: [Fink-users] New 10.2-gcc3.3 Packages?
On Jul 7, 2005, at 9:49 AM, Dan Sommers wrote: I must be the only one here still running fink on Jaguar, so I have recently borrowed some info/patch files from the 10.3 tree on SourceForge, copied them to my /sw/fink/dists/local tree, and installed them, and they seem to work. Specifically, I have installed msmtp- ssl, pysqlite, and rubber this way. Is anyone else at all interested? If so, what's the best way to go about it? Should I just submit the packages anyway with SourceForge's package tracker, or would that just be clutter now that the rest of the world has moved on to Tiger No, don't submit via the tracker, it's crowded enough without unsupported packages. If you want to put together a fink-legacy team to take care of old trees, that's fine with me, as long as it involves at least one Fink committer so we can ensure some level of quality. That's just my position though, I have no idea what everyone else thinks. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] 10.4 tree
On Jul 5, 2005, at 10:58 PM, Philip Lamb wrote: Obviously we have 10.4-transitional using g++-3.3, but how is Fink going to enforce a complete rebuild of c++-based packages for users under 10.4? Another issue is that we will potentially have packages which cannot link to anything pre gcc4.. but how will these packages be able to specify this in the requirements? The epoch field?? If we do exactly what we did last time, this is how it will go: 1) Every package that uses C++ must have GCC: 3.3 in 10.4- transitional and GCC: 4.0 in 10.4. 2) All these packages must have their revision bumped in 10.4 by some arbitrary amount (10? 100?) so that the revision in 10.4 will always be higher than 10.4-transitional. This way update-all will cause them to rebuild. 3) All packages which depend on GCC: 4.0 packages must version those dependencies. So if the first version of foo in 10.4 is 3.1-11, then 'Depends: foo (= 3.1-11)'. This forces packages to build in order. The upside of this is it's not extremely complicated, and mostly works. The downsides are: - If a user upgrades from 10.4-transitional to 10.4, and doesn't update-all, things will break sooner or later. Eg: Both bar and zot depend on foo, all use C++. User upgrades to 10.4, and later does 'fink update bar', this causes foo to be updated. But now zot is broken. - Actually bumping all the revisions and versioning all the Depends can be a lot of work if done manually, and isn't trivial to script. - If we keep 10.4-transitional, packages that are upgraded there can become newer than the rev-bumped packages in 10.4. For all those considering wild new schemes, here's your chance to put them forward. :-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Help needed with g++ handling
Hi Michèle, I'm glad my email was helpful to you. The SetCXX: c++ and SetCC: cc that you used in cssed accomplish nothing, but they're also harmless. So you can leave them in or remove them, it's up to you. So, it was here till the beginning, could I remove it in all trees? I mean this is already enough complicated for me, to put things that do nothing. I'm honestly not sure why you put SetCC and SetCXX in cssed.info in the first place, so I don't know whether you should or should not remove them. It could be that some version of cssed coulnd't detect the compiler properly or something? *shrug* You'll have to try to remember. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Use-binary-dist flakiness
On Jun 29, 2005, at 8:07 AM, Martin Costabel wrote: Using a local server for unstable debs, I have a long-standing quibble with apt-get: It often doesn't understand that a package is already installed and apt-get dist-upgrade downloads and installs many packages, sometimes hundreds of packages, whose exact same version is already installed. I have complained about this on the lists and have a bug tracker item open, but apparently no one else understands this either, although it has been observed by others already years ago, at least every time a new bindist comes out. Martin, We know that this happens, and it kinda sucks. But I've never been able to figure it out exactly. I usually end up accidentally letting an apt-get upgrade finish, and then the problem goes away. Since I don't know how to reproduce it, it just leaves me kinda confused and without any way to test further. If anybody can reproduce it consistently, please tell me how so I can debug it. I have a symmetrical problem with fink --use-binary-dist: It very often, and apparently randomly, refuses to use the binary dist, although the package it is going to install does exist there. [snip] I have *not* experienced this problem, I'd like some more information. Note first that the --use-binary-dist option to fink (or in fink.conf) will only get packages from the bindist that exist BOTH as .info files and in the bindist. This restriction makes things easier on Fink and should generally not be a problem, but it may be the cause of your issue. Please verify! If this is not your problem, could you please tell your users that if they observe fink starting to buildthings at this stage instead of downloading, to stop it immediately, run a few commands, and send you the output; that way we can look at what's going on. Commands that would be useful are: uname -a fink -V find /sw/fink/dists/ -name fink.info | xargs grep Version apt-cache policy fink And any others you can think of including. Hopefully we can figure out what's going on. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Help needed with g++ handling
Hi Michèle, It seems you're a bit confused, understandable given the GCC situation. Hopefully this mail can make things clearer, it's a bit long so I've written it in sections. Also, you may want to read the new section in the packaging manual: http://fink.sourceforge.net/doc/ packaging/compilers.php 1. COMPILER NAMES On a 10.4-transitional system, we want all C++ packages to use the 3.3 ABI if possible, so fink arranges that c++, g++, c++-3.3 and g+ +-3.3 are all the *same thing*. Fink also arranges by default that CXX = g++-3.3 . Note that on 10.4 (non-transitional), c++, g++, c++-4.0 and g++-4.0 will all be the same thing, and CXX will be g++-4.0. In other words, on both distributions you can just use c++, g++ or CXX normally and the correct G++ version will be used. So you see, SetCXX: c++ does nothing at all, it just uses the same compiler as the normal CXX. When is SetCXX useful then? Primarily if you have to force a certain version, eg for a package that requires 3.3 you can use SetCXX: g+ +-3.3. But unless this is truly necessary--and it usually isn't-- don't use it. The SetCXX: c++ and SetCC: cc that you used in cssed accomplish nothing, but they're also harmless. So you can leave them in or remove them, it's up to you. 2. THE GCC FIELD The GCC field only very rarely affects the compilation of a package. It currently does two things: i. It tells Fink to make sure that gcc_select is on the most recent value. This feature is pretty rarely encountered, not very necessary anymore, and kind of confusing, so you can ignore it and pretend you never read this. Stick your fingers in your ear and sing La la la, I can't hear you :-) ii. This is the important part. GCC informs developers that this package uses C++, which is important to know for ABI transitions. Fink may use this information at some time in the future, but doesn't really use it yet. So the GCC field is more descriptive than instructive. If your package won't compile, changing the GCC field won't help, it's about as effective as changing Homepage. Instead you use GCC just to describe your package, to indicate that it uses C++ code. One pretty quick way to test a package for C++ code is with the script that I posted about yesterday. You can get it here: http://cvs.sourceforge.net/viewcvs.py/*checkout*/fink/experimental/ vasi/scripts/gcc-field and then run 'gcc-field cssed', and it will tell you that Everything looks OK!, which means cssed needs to keep the GCC: 3.3 field that it currently has, since it uses C++. 3. LINKING C AND C++ One last reason you may be confused is that there is sometimes (but not always) a bug that occurs when linking C++ and C code on account of C++ using version 3.3 and C using version 4.0. When you link C and C++ code together, you must use the C++ compiler since C doesn't know about the stdc++ runtime library. But g++-3.3 (which is the same as g+ + and c++ for fink packages) doesn't know about certain new gcc-4.0 features. If your packages doesn't experience a problem linking C and C++ code together, then you don't have to worry about this. On the other hand, if it does, you'll see this: ld: Undefined symbols: _fprintf$LDBLStub ... In that case, you need to add -lSystemStubs to the compilation command. Happily, cssed doesn't show this bug, so you don't need this. 4. CSSED Just to recap... Basically, cssed.info is fine as it is. It does indeed use C++ code, so you have to have GCC: 3.3, which is already there. It doesn't have the SystemStubs bug, so you don't have to worry about that. It includes SetCXX: c++ and SetCC: cc, which basically do nothing, so you can leave that in or take it out, either way is fine. Hopefully this hasn't made things even more confusing, I hope it makes our compiler situation more understandable. If there's still anything that's not clear, please ask and I'll try to clarify. Toodles, Dave PS: If it's ok with everyone, once gmane have archived this email, I'll link to it from the Compilers page in the packaging manual. PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] soap-lite-pm
On Jun 28, 2005, at 8:28 AM, Chris Dolan wrote: The /sw/bin files should go in a -bin splitoff. See spreadsheet- writeexcel-pm.info for a simple example. Note that there should perhaps also be a -man splitoff. On Jun 27, 2005, at 5:13 PM, Koen van der Drift wrote: During the installation of soap-lite-pm586, I got an error for some conflicting files that were already installed by soap-lite- pm581: /sw/bin/SOAPsh.pl /sw/bin/SOAPsh.pl sw/bin/XMLRPCsh.pl Hi Koen, A slightly better solution than just a -bin splitoff may be to have versioned binaries. So soap-lite-pm586 would contain %p/bin/SOAPsh-586.pl, and soap-lite- pm581 would contain %p/bin/SOAPsh-581.pl, allowing both sets of binaries to be installed at the same time. If you want the user to be able to use shorter names, you can *also* have a -bin splitoff. Then soap-lite-pm586-bin would contain /sw/bin/ SOAPsh.pl as a symlink to SOAPsh-586.pl, and ditto with pm581-bin, so that a user could use a shorter name for the programs. Of course the - bin packages have to Conflicts/Replace each other. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] GCC ABI recompiling issues
On Jun 27, 2005, at 6:24 PM, Peter O'Gorman wrote: If your app/library does not use any c++ api then it does not need to be rebuilt. You can use Ben's idea to check this. nm -g app out1; nm -g app | c++filt out2; cmp out1 out2 I have a script I've been using to check my packages this way. It's not perfect, it assumes that every C++-using-package should have the most recent GCC: field, when in fact some packages may have a good reason to use an old one. But aside from that, I think it's useful. It's sitting in experimental/vasi/scripts/gcc-field. You can invoke it like this: gcc-field -m maintainer-regex gcc-field package1 package2 dpkg -L | gcc-field - Hope it's useful (and mostly correct). Dave --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] need builder for programm
On Jun 17, 2005, at 4:16 AM, Daniel Macks wrote: On Fri, Jun 17, 2005 at 09:28:59AM +0200, Sebastian Hagedorn wrote: a binary version is probably no good, because it would depend on libraries that may not be there. gtk is not normally available on a Mac. Building it static would avoid needing non-standard libs. OTOH, Fink's glib package only provides the dynamic library so I can't test it. If you make it into a .app bundle, the bundle can contain the required shared libraries using the @executable_path install name. You can see http://nicotine-app.sourceforge.net/cgi-bin/wiki.pl? Nicotine_Build_Instructions for the way I built one such bundle, though the instructions may be a bit dated by now. Perhaps someday I'll write a script to mostly automate going from a Fink package to a .app, it could be useful. But if anybody else gets there first I won't complain ;-) Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] openssl-linked packages: need new license type?
On Jun 14, 2005, at 4:51 AM, Daniel Macks wrote: OTOH, we could generalize the solution away from fink's openssl linkage policy and just add a new Restrictive/Source-Distributable license type. I have no doubt that some of the other Restrictive packages may allow souce redistribution but (for example) not binary redistribution, or some other wacky licensing terms that would fit here also. I prefer this option. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] '$MACOSX_DEPLOYMENT_TARGET mismatch: now 10.4 but 10.3 during configure' error compiling clearsilver with python2.4
On Jun 12, 2005, at 9:03 AM, Jeremy Higgs wrote: error: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.4 but 10.3 during configure make[1]: *** [neo_cgi.so] Error 1 The compile continues, but the file (neo_cgi.so) is not compiled, and therefore not installed... which is a bit of a problem. Does anyone know how to fix this? The MACOSX_DEPLOYMENT_TARGET variable is not set anywhere in the package by me, so I don't know what's causing it to think that it was set to 10.3 earlier... This problem seems to happen because the python2* packages write the current MACOSX_DEPLOYMENT_TARGET to %p/lib/python2.3/config/Makefile and the python build utilities use this value when compiling modules. This means that if you have a python24 from 10.3 (from the bindist or by upgrading 10.3 = 10.4), there will be a mismatch between what python thinks MACOSX_DEPLOYMENT_TARGET should be and what it actually is. The immediate fix is to 'fink rebuild python24'. So that users don't encounter this bug, it might be smart to bump the revision for python2* on Tiger to force rebuilds. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Fink package jove failing with --build-as-nobody
On Jun 10, 2005, at 1:06 AM, Blair Zajac wrote: Looking at the log, it's doing a chown to root in the temporary install directory: Hi Blair, Matthew wrote: --build-as-nobody is needed to be able to create bindists automatically and safely, and we're hoping to switch it over to be the default at some point in the future, so it would be nice to fix this if you could. And that's pretty much the explanation. Fink will be much safer to run, especially automatically, if we manage to get as many packages as possible to build as non-root. As it is, if Fink is building without --build-as-nobody then it's root and anything it puts in %i should be root already, no need to chown. If it's building *with* --build-as-nobody, then it will chown - R %i automatically. So in either case, a chown to root is unnecessary. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Running your own Binary Distribution Server
On May 31, 2005, at 11:36 PM, William Scott wrote: ccp4: Depends: ccp4lib (= 5.0.2-200) but it is not going to be installed Depends: ccp4lib-shlibs (= 5.0.2-200) but it is not going to be installed Depends: darwin (= 8-1) but 7.7.2-1 is to be installed Every Fink package has a dependency on the version of the kernel it was built with, for technical reasons. This means that if you want to have both 10.3 and 10.4-transitional users using the same apt repository, you have to build the packages with 10.3. (It may be possible to make Tiger build 10.3 packages using some chroot trickiness, but I honestly don't know how reliable that would be.) Alternatively, you can have two separate repositories for 10.3 and 10.4-transitional. On May 31, 2005, at 7:43 PM, Dave Vasilevsky wrote: By the way, if you would like to have 'fink scanpackages' run many times faster, you can run fink from CVS HEAD and install the package apt-ftparchive. The more testers the merrier :-) This sounds good. How do I get it though? (Sorry to be stupid. I have cvs access for fink.) To get Fink from CVS HEAD, follow the instructions under Updating the Package Manager on this page http://fink.sourceforge.net/doc/ cvsaccess/index.php . Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Fink Build Status; QA Proposal
On May 31, 2005, at 10:55 PM, Michèle Garoche wrote:Le 31 mai 2005 à 23:48, Matthew Sachs a écrit :The second build will use 10.4-transitional and not try to force 4.0, and will build the packages as 'nobody' instead of 'root'.That would be good, because I've begun on 27th May and only 1120 packages have been built at the time being mostly because I should provide my password many times. Even when fink builds as 'nobody', the fink program still runs as root for everything except building. I think you should run buildfink as root, so when it calls fink it never has to ask for a password.Just a question, could it be that building as nobody changes the way some packages are built, i.e. some packages would not compile and some other ones would compile contrary to that would have happened when building as root?I guess it's possible that a few packages will build incorrectly. But most likely a package that needs root will fail (ie: when it tries to use chown). Part of the purpose of this build is to catch the packages that fail without root.It will be interesting also to have all variants of a package systematically built, if possible at all, but with a possibility to exclude some variants if they are known not to compile at a certain time (I think of ssl variants for example).I believe buildfink already does this.Another one would be to get the graph of each dependency, because the graph of all dependencies is not always easily readable.If/when we ever have an unstable bindist, 'apt-cache dotty' should do this. But most packages have so many recursive dependencies that it's still hard to visualize.Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Stopping Spotlight
On May 25, 2005, at 9:55 AM, Hanspeter Niederstrasser wrote: Will this be %p/src/foo-%v-%r.build or %p/src/fink.build/foo-%v-%r? The second one. Packages will build in %p/src/fink.build/%f and will install in %p/src/fink.build/root-%f . I'm mostly just thinking that doing %p/src/fink.build/ everythinghappensinhere just leads to an extra directory nest when all that seems to be needed from the description is appending .build to the build and install directories. We considered appending .build to the subdirectories like this. However, some packages may expect to build in a directory named %f and could break. On the other hand, Buildpath is known to be relocatable already, so this seemed to be the safer solution. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Re: Stopping Spotlight
On May 25, 2005, at 10:43 AM, Kinako wrote: Adding sw into /System/Library/Find/SkipFolders might work. In my testing it doesn't. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Stopping Spotlight
Hi folks, Some of you have already noticed Spotlight indexing /sw/src, which makes builds slow. For various reasons the solutions suggested so far aren't ideal[1], but msachs found out for us that directories with the *.build do not have anything inside them indexed. So we're going to try moving the default buildpath from %p/src to %p/ src/fink.build . If we decide to release Fink with this change, those using the default buildpath will use the new one automatically. If you have a custom build path, Fink will warn you that this might be slowing down your builds, and offer to append .build--if you decline, Fink will never bother you about it again. I'll be committing the changes to fink HEAD just after sending this. msachs is going to run another complete build, so that should help find any problems. I don't think there are any other situations where fink is badly impacted by Spotlight. I suppose if you do a lot of installing/ removing that could cause problems. The new incremental indexing in HEAD creates lots of files, however that's apparently not a problem so long as there's no mdimporter. But if there are other places where we'd like to disable Spotlight, we've got a reasonable strategy now. Comments would be appreciated. Dave [1] The solutions involved modifying files in /.Spotlight-V100. But Spotlight doesn't notice changes to the relevant files right away, build paths on different volumes are harder to deal with, and munging plists isn't fun. PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] gdk-pixbuf-0.18.0-12
The issue should be fixed now. Apparently the original issue (that I fixed in a broken way) was originally because of an earlier fink patch, I just took out the broken part of that and removed both mine and Martin's later fixes. Thanks for your help Martin. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] missing patch file does not give an error
[snip patchscript options] Another option, which doesn't require changes to hundreds of packages, is to require bash 3.0 and use the pipefail option for PatchScripts: bash-3.00$ false | true; echo $? 0 bash-3.00$ set -o pipefail bash-3.00$ false | true; echo $? 1 Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Autoconf 2.5 on Tiger
Getting this error while installing/building autoconf: /sw/bin/install -c -m 644 ./standards.info /Library/Fink/src/root- autoconf2.5-2.59-6/sw/share/info/standards.info cd doc make html texi2html -split_chapter ./autoconf.texi ** Unknown command [EMAIL PROTECTED]' (left as is) (l. 8) ** Unknown command [EMAIL PROTECTED]' (left as is) (l. 15550) ** Unknown command [EMAIL PROTECTED]' (left as is) (l. 15585) ** Unknown command [EMAIL PROTECTED]' (left as is) (l. 15633) ** Unknown command [EMAIL PROTECTED]' (left as is) (l. 15641) texi2html -split_chapter ./standards.texi install -d -m 755 /Library/Fink/src/root-autoconf2.5-2.59-6/sw/ share/doc/autoconf2.5/html install -m 644 doc/*.html /Library/Fink/src/root-autoconf2.5-2.59-6/ sw/share/doc/autoconf2.5/html/ install: cannot stat `doc/*.html': No such file or directory ### execution of install failed, exit code 1 It seems the .html files are going in doc/standards/*.html instead of doc/*.html. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Autoconf 2.5 on Tiger
On May 2, 2005, at 5:25 AM, David R. Morrison wrote: OTOH, fink's texi2html package has deliberately not been updated to this newest version. So BuildDepends: texi2html should cure the problem for now. There's a problem with this. Fink's texi2html uses #!/sw/bin/perl . But I'm using system-perl586, so I don't have a /sw/bin/perl. This is detected by 'make', so it uses the OS X texi2html instead. So this raises the questions: Is it ok to use /sw/bin/perl as an interpreter? And if it is, how are people using system-perl* supposed to deal with it? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: [fink-seed] findutils problem
Hey guys, I'm not sure why nobody's asking me about this, given that I'm the maintainer. In 10.3/unstable I've already put findutils 4.2.20 rev 2, which fixes this issue in my testing. I don't yet have a Tiger system working, so if somebody would like to test my fix and then commit the fixed version that would be fine by me. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] variants and patching
On Apr 24, 2005, at 8:57 AM, Koen van der Drift wrote:
For a package I maintain only one of the variants needs to be patched.
How can I add that in the .info file?
Probably the best way is to use a PatchScript:
PatchScript:
#!/bin/sh -ev
if [ %type_raw[-foo] = -foo ]; then
patch -p1 %a/%{Ni}.patch
fi
Do we currently have a policy for multiple patch-files? Eg: If your
package 'foo' already has a 'Patch: %n.patch' for all cases, but one
variant 'bar' needs a supplemental patch, what should be done? The
options I can think of are:
1) Have a %a/foo-bar.patch in CVS, which is applied in a PatchScript.
2) Have your regular patch-file, in addition to patching normal files,
also add the secondary patch-file into the package build dir. Then just
apply it with 'patch -p1 foo-bar.patch' in the PatchScript.
3) Try really, really hard to make everything dependent on, say, env
vars or -Ddefine's, so that a supplementary patch isn't needed.
Any preferences?
Dave
PGP.sig
Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 19, 2005, at 1:12 AM, Matthew Sachs wrote: In further testing, however, it seems that it also works with g++-3.3 on Tiger and no -fabi-version on Panther without the SDK. I've asked my coworkers for clarification on why we should be using the SDK in this situation. Ok guys, I've talked with msachs some and apparently this actually works for him: (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC=g++-3.3 Previously drm said this didn't work, so I'd like some more testing. Hopefully I had just explained things badly to drm and it really does work. Those with seeds can try the commands above. Or just in Tiger, do: g++-3.3 -o break.o break.cpp; nm -m break.o | c++filt | grep typeinfo If you get a bunch of 'datacoal' stuff, it's working. PLEASE TEST if you can, I'd like to be sure this actually works. If this does work, then GCC 3.3 on Tiger can link to GCC 3.3 on Panther so long as -fabi-version is not used. But GCC 4.0 still cannot link to anything build without -fabi-version on Panther. So one (new!) option is for 10.4-transitional to enforce g++-3.3 for C++ packages, and for neither 10.3 nor 10.4-transitional to use a -fabi-version flag. Advantage is thaty Fink users would be able to update fairly seamlessly as planned, nothing much should need rebuilding to move to Tiger. C-only packages can still use gcc-4.0. Later we could move to 10.4 (non-transitional), doing the GCC 4.0 switch *and* the ABI 2 switch all at once for C++ packages. Or we could have some sort of piece-meal switch over, either package by package or based on some kind of auto-detection--that can be decided later. The second option is to just move everybody to gcc-4.0 with ABI 1, make everybody rebuild everything. And then later move to ABI 2, and make everybody rebuild the C++ stuff again. Advantage is that the current 10.4-transitional tree ought to be fine for this. Third option is to make a clean break (see Chris's solution), and go straight to 4.0 and ABI 2. Advantage is not having a transitional tree to maintain. Disadvantage is packages that don't work with the new GCC or ABI are in trouble. So what do we think? I suggest that -core figure this out quickly, I'd rather have my favourite option not chosen but at least have a common goal to work towards, given the time constraints. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. Code is here: http://www.opensource.apple.com/darwinsource/November2004GCCUpdate/ gcc_os-1671/gcc/c-common.c I've looked at the source some. Looks like there's no way at all to pass -fabi-version=-1 to gcc, it doesn't like the non-digit '-'. Silly tricks like passing 2**32-1 don't work either. If anybody can figure out some way (however hacky) to specifically tell GCC to use -1, that may solve our problem. The ONLY change that -fabi-version=1 makes (at least on Panther) is apparently the typeinfo bug that has been discovered. The bug does not occur if -fno-rtti is passed, but of course then programs that use RTTI don't work. Not much code uses typeid or dynamic_cast, so passing -fno-rtti could be a *very temporary* workaround for us, but programs that do need RTTI just won't work. (Unfortunately, if code uses RTTI and it's not enabled, there's no compile-time error, it just fails at runtime.) Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I got an answer on this; you'll need to use the 10.3.9 SDK for this to be guaranteed to work. I suspect that the non-Apple-guaranteed probability of them working together all the time very closely approaches 1. I wrote a very small test case for the RTTI issue, it's at http://vasi.webhop.org/files/misc/breakgcc.tgz . It's already half-built, under Panther. If anybody wants to test with 'make CC=gcc3.3' on Tiger, that would let us see whether we'd hit this issue in a 3.3 - 3.3 Tiger transition. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 19, 2005, at 12:09 AM, Peter O'Gorman wrote: Ah, how silly of me, of course I need to specify g++-3.3 on tiger. That or pass -fabi-version=1. Sorry for the confusion! My intro to this kinda sucked before, so according to what we know now, these are some examples of what should work and what should not. 1. On Panther, fabi-version=1 can't link to programs with the default fabi-version=-1, so this should break: (Panther) make clean; make CC_LIB=g++ CC='g++ -fabi-version=1' 2. On Panther, you can link everything with fabi-version=X, or everything without. Similarly on Tiger. So these should work: (Panther) make clean; make CC_LIB=g++ CC=g++ make clean; make CC_LIB='g++ -fabi-version=1' CC='g++ -fabi-version=1' (Tiger) make clean; make CC_LIB=g++ CC=g++ make clean; make CC_LIB=g++-3.3 CC=g++-3.3 (etc) 3. On Tiger, the default for fabi-version appears to be 1 (not -1), so these should work: (Tiger) make clean; make CC_LIB=g++-3.3 CC='g++-3.3 -fabi-version=1' Note that this broke on Panther! (Panther) make clean; make CC_LIB='g++-3.3 -fabi-version=1' (Tiger) make CC='g++-3.3 -fabi-version=1' And these should break: (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC=g++-3.3 (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC='g++ -fabi-version=1' That last example is the critical one, since it means that the way things are currently built on Panther cannot be linked to on Tiger! *grumble* Note that I don't actually have Tiger to build on, so my results here are based on previous tests. I'd appreciate if someone could verify these, especially that last example, since I clearly had not explained things particularly well before. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 6:21 PM, TheSin wrote: if upgrading from 10.3 - 10.4 will will need to set abi-version to 0 I'm not sure but I think this will work. I strongly suspect this will not work. -fabi-version=0 is equivalent to -fabi-version=the maximum supported ABI version for this g++. So on g++-3.3 it's like 1, and on gcc 4 it's like 2. Clearly passing 1 on Panther and 2 on Tiger will not be inter-compatible. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] the gpl and openssl
On Mar 16, 2005, at 2:39 PM, Lars Rosengreen wrote: Yes, I think we do. I'll try to construct a list of packages that may be affected. Thanks Lars. I guess once we have this, for each package we'll need to: - Notify the upstream developers that they're sitting on a time bomb. :-) - Do one of the following, in order of preference: * Get permission from the upstream devel to link with OpenSSL * Link the package against OpenTLS * Link the package against the system OpenSSL (BuildConflict with Fink's version) * Remove the package from the bindist, possibly from unstable too. Any other options? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] buildconflicts, buildlock
On Feb 26, 2005, at 6:08 PM, David R. Morrison wrote: OK, in my opinion, this behavior as reported by Robert indicates that the buildlock system is not yet working as it should. It's working fine, it's catching a bug in Fink right away rather than later. :-) Fink is supposed to be able to switch back and forth among db3 vs. db42, or ncurses5 vs. libncurses5. So shouldn't we be trying to restore the dependencies of the buildlock package, instead of just refusing to install it? Fink never did this properly. In one invocation, it can accomplish precisely ONE switch between replaceable packages, and sometimes it even does that wrong. At least now we're not letting it pass when it could cause an error. (For example, we could add each new deb to the scanpackages database just after it's built, and then ask apt-get (rather than dpkg) to install the buildlock... which would put back a .deb that just got removed, presumably.) That's one idea. I was under the impression that Justin's shlibs changes in post-0.24 would be re-calculating dependencies before and after each build, which is another way to solve this issue. Am I right or wrong about that? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: [Fink-beginners] undefined value as filehandle reference at /sw/lib/perl5/Fink/Package.pm line 36
On Feb 25, 2005, at 10:24 AM, Daniel Macks wrote: open APTDUMP, $basepath/bin/apt-cache dump | Perl usually discourages this form, since if someone could convince $basepath to bstart with it might do bad things. Why not stick with this? open APTDUMP, -|, $basepath/bin/apt-cache dump; Still not super (since ugly basepaths with spaces can still fail), but a bit better and it works with both perls. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] popt and BuildDependsOnly policy
Hi folks, Thanks to tonyarnold, the 'popt' package should no longer be required for packages that use popt-shlibs to have proper localization. Packages that Depend on popt despite it being BuildDependsOnly should no longer do so. So if you see fink warn about a package depending on popt, please fix the offending package. Thanks, vasi PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Perl variants -- problem and proposed solution
Hi folks, While I agree with dmacks that we can't really automate this, I still think it's important to deal with. I think that if we support a perl version, we ideally want every variant to support that version. There are a few ways this could be accomplished: 1. Usually it's not considered especially polite to modify another maintainer's package. I think we should explicitly say that adding a new perl variant to another maintainer's package is ok, if it doesn't require any non-trivial changes. 2. We may want to have a policy that all perl packages with variants should be tested with all supported perl versions, assuming dependencies allow it. Or, we could require this only on entry to stable. 3. If there are any people who particularly care about a certain perl version, we could have a perl-testing group of some sort. Or we could just have things ad-hoc like they are now :-) . Any comments? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] PatchScript: how to handle broken pipes
On Jan 28, 2005, at 1:31 AM, Daniel Macks wrote: If we ever rework our patchfile system, we could give percent-expansions to the filenames and then only define those % keys if the file actually existed. Yes, we ought to do that. As an ugly hack in the meantime, why not read STDERR and look for the string '.patch: No such file or directory' ? I highly doubt that would occur in any case that doesn't constitute an error. It will break in the future if the shell's (or sed's) error message ever changes, but we can add a test case in fink so we'll at least notice if that happens. And hopefully by then we'll have a better solution in place. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Providing default /sw/var/lib/debfoster/keepers with base-files package?
On Jan 20, 2005, at 8:02 PM, Daniel Macks wrote: If a user is not carfull the system might end up unusable due to e.g. a missing apt while running with UseBinaryDist. That's not an unusable state, since fink will merely issue a please install the apt pkg warning. But anyway... I think what was meant was using the binary distribution (ie: exclusively apt-get, no use of fink-the-program at all). Quite a number of users don't even have the DevTools installed, but just apt-get packages via the CLI or FinkCommander. If they lose apt, they're pretty screwed. You or I might know we could go to the Fink bindist on the web, download the .deb for apt, and re-install it via dpkg; but the average user wouldn't. Perhaps this is an argument for making apt essential? If a significant portion of the user base is stuck should apt ever be removed, it seems to be pretty essential in the English sense of the word. Is there a technical reason that it isn't essential? If debfoster uses apt, then debfoster should Depends:apt, since apt is not an Essential pkg (nor should it be IMO). That's a pretty fundamental packaging issue. The problem is not that debfoster requires apt (it technically doesn't require it, though the default configuration does). Rather, the issue is that apt is nearly-but-not-quite essential for fink, so removal is allowed even though it may be a big problem for some users. And that debfoster seems to be removing some actually essential packages, too. I don't know exactly how debfoster uses this keepers file, but assuming it's the live list of intentionally installed pkgs, gotta be very careful how to handle upgrades. The list of Essential files can change...don't want to don't want to overwrite a live datafile. This is true. I think it's better to look at debfoster's facilities. The default debfoster.conf has 'UseEssential = yes', which should stop debfoster from removing essentials. So why are we seeing them being removed? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Providing default /sw/var/lib/debfoster/keepers with base-files package?
On Jan 20, 2005, at 8:02 PM, Daniel Macks wrote: If a user is not carfull the system might end up unusable due to e.g. a missing apt while running with UseBinaryDist. That's not an unusable state, since fink will merely issue a please install the apt pkg warning. But anyway... I think what was meant was using the binary distribution (ie: exclusively apt-get, no use of fink-the-program at all). Quite a number of users don't even have the DevTools installed, but just apt-get packages via the CLI or FinkCommander. If they lose apt, they're pretty screwed. You or I might know we could go to the Fink bindist on the web, download the .deb for apt, and re-install it via dpkg; but the average user wouldn't. Perhaps this is an argument for making apt essential? If a significant portion of the user base is stuck should apt ever be removed, it seems to be pretty essential in the English sense of the word. Is there a technical reason that it isn't essential? If debfoster uses apt, then debfoster should Depends:apt, since apt is not an Essential pkg (nor should it be IMO). That's a pretty fundamental packaging issue. The problem is not that debfoster requires apt (it technically doesn't require it, though the default configuration does). Rather, the issue is that apt is nearly-but-not-quite essential for fink, so removal is allowed even though it may be a big problem for some users. And that debfoster seems to be removing some actually essential packages, too. I don't know exactly how debfoster uses this keepers file, but assuming it's the live list of intentionally installed pkgs, gotta be very careful how to handle upgrades. The list of Essential files can change...don't want to don't want to overwrite a live datafile. This is true. I think it's better to look at debfoster's facilities. The default debfoster.conf has 'UseEssential = yes', which should stop debfoster from removing essentials. So why are we seeing them being removed? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] lifetime of static variables
On Dec 22, 2004, at 2:24 AM, Martin Costabel wrote: Is this different from using the -single-module linker flag? The latter is often recommended for problems with static initializers. According to Apple, it's exactly the same thing: http://developer.apple.com/releasenotes/DeveloperTools/ CompilerTools.html . I guess when I looked into the issue for arts way back during the KDE port it was before they added the -single_module flag. For the benefit of anybody who needs to search for this later: To deal with static initializers not running on OS X due to lazy linking, executables: link with -Wl,-bind_at_load libraries: link with -single_module Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] lifetime of static variables
On Dec 16, 2004, at 9:17 PM, Mark Treiber wrote: I'm in the middle of updating my quantlib package and the test suite is producing a failure that doesn't occur on any other platform. Basically are there any known issues with the lifetime of static variables with the november gcc update? Mac OS X has always had issues with static variables in C++. Some programs depend on all static variables being init'ed on startup, but on OS X they are only init'ed when the module (.o) is actually used. This is a problem if a module's being used depends on its initializers, ie: static int Foo::ID = Bar.registerForUse(FooFactory()); If this is the problem you're seeing, there's a fix (basically link the .o's together into one module, then link that into the lib, I think KDE still uses this fix). If it's something else, try giving more details and we'll see what can be done. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] lifetime of static variables
On Dec 21, 2004, at 11:25 AM, David Fang wrote: I've been using patterns like the code above in my own traits classes with static members. I've found that linking all the object files into one (via libtool convenience library) wasn't sufficient to force the linker to link in the modules' static initializers. There are two ways this can be done. The simple way is to not use libraries where possible--just link all your .o files into an executable and pass gcc -Wl,-bind_at_load . The more complicated way--which works for libs too--is to use an intermediate .o file. Here's a modified example from KDE (which I stole from Apple's Jam files for an old version of Project Builder): gcc -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o combined.o my.o module.o files.o gcc -dynamiclib -o libfoo.dylib combined.o [other flags for lib] I the problem I was observing was that the linker didn't infer that certain modules were used when in fact, they were. (Is there some call-graph analysis gone wrong?) Nope, it's just an attempt at optimization. If the linker waits for a module to be asked for, it can save loading non-needed modules. There's no standard that says the linker has to load everything at init. As far as I'm aware, no linker analyses your program much to see if modules must be loaded--they either just load everything at init, or don't load anything until it's asked for. Linux distros are starting to play around with various degrees of lazy linking now, so I wouldn't be surprised if they start running into issues like this some day. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Mozilla and Xorg
Hi folks, As some of you have noticed, Mozilla will not build with Xorg. This is because it uses a new version of freetype which removed a formerly deprecated API. I have a version of mozilla in my experimental dir that is patched to use the replacement API. It should build with Xorg, and it *may* build with other X11 implementations since the replacement API was added some time before the deprecated one was removed. If you use a non-Xorg X11, please test building mozilla from my exp dir, and report the results to the list. Dave PGP.sig Description: This is a digitally signed message part
