You can subscribe to this list. Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 System: G4/867 single processor (one might have guessed some flavor of PowerPC since mplayer and Macintels don't get along OS: 10.5.1 The issue isn't restricted to the altivec variant.

• Suggestion: Include Zsh Completion Into Distribution Packages

If the rvm install script complains about certificates you need to follow the displayed instructions. Single-User Install Location: ~/.rvm/ If the install script is run as a standard, non-root user, RVM will install into the current users's home directory.

It seemingly doesn't detect X11 (Apple's + the XQuartz 2.1.3 update):. Checking for X11 headers presence.

Yes (using /usr/X11/include) Checking for X11 libs presence. Not found (check if the dev(el) packages are installed) Checking for X11. No The test in configure is if test -d '$I' && ( test -f '$I/libX11.so' test -f '$I/libX11.a' test -f '$I/libX11.dll.a' ); then This worked in Tiger, because a static libX11.a was available. In Leopard, only the dynamic libX11.dylib exists.

The test should be patched to look for dylibs instead of so's and dll's. BEGIN PGP SIGNED MESSAGE- Hash: SHA1 System: G4/867 single processor (one might have guessed some flavor of PowerPC since mplayer and Macintels don't get along OS: 10.5.1 The issue isn't restricted to the altivec variant. It seemingly doesn't detect X11 (Apple's + the XQuartz 2.1.3 update).

Checking for X11 headers presence. Yes (using /usr/X11/include) Checking for X11 libs presence. Not found (check if the dev(el) packages are installed) Checking for X11.

Checking for GUI. Yes Error: X11 support required for GUI compilation Check 'configure.log' if you do not understand why it failed.

The configure.log isn't very illuminating here: Checking for X11 headers presence Result is: yes (using /usr/X11/include) ########################################## Checking for X11 libs presence Result is: not found (check if the dev(el) packages are installed) ########################################## Checking for X11 Result is: no ########################################## I do indeed have the X11User and X11SDK packages. My full build log is posted at I'd be curious if others are seeing the same behavior (those of us who are still too poor to buy shiny Macintels;-) ). If so, then maybe mplayer. and anything that Depends on it should be tagged as 10.4-only. I found this while I was trying to test a package from the submissions tracker, and I'd tell the submitter to tag it.BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - iD8DBQFHoPJJB8UpO3rKjQ8RAsXnAJ9EAG0ugvI3d6YoDWw5bE9SRtkQUgCfZ4sL PqpeAX8NHqWK97JqEiMNIWM= =nJ6c -END PGP SIGNATURE.

Reed wrote: The question is, is there a right way? If you just install the completion rules anyway, a subsequent attempt to install bash-completion will complain about the existing files. If you don't install them unless the package is there, then a subsequent installation means you don't get the custom rules for daemonic. Which means that the packages essentially have to be installed in a particular order, even though there's no actual dependency. No, this is not what happens. Fink packages only complain about what other packages install if they are trying to install the same.files.

And in such a case, the order of installation does not matter, unless one of them has a 'Replaces' field and the other one doesn't. If two packages install the same.directories., there is no conflict. And this is what happens here. Both packages install the directory /sw/etc/bashcompletion.d, but there is no common file. Attachments: I suspect the daemonic package added some helpful custom completions for the daemonic command, which is a nice thing to do. But making the package dependent on bash-completion is clearly the wrong way to do it. The question is, is there a right way?

If you just install the completion rules anyway, a subsequent attempt to install bash-completion will complain about the existing files. If you don't install them unless the package is there, then a subsequent installation means you don't get the custom rules for daemonic.

Which means that the packages essentially have to be installed in a particular order, even though there's no actual dependency. On Tue, Jan 29, 2008 at 03:42:23PM -0800, William Scott wrote: Hi Daniel et al: I just noticed this too.

Why does daemonic get installed if there are no dependencies, and why does it need a completion system for an interactive shell? In my case, I imagine daemonic got installed because it's required by other packages that I use, like ssh and anacron. I can't answer your second question. Also, when I made a set of files to augment the zsh completion system, I was told I had to make it depend on fink's zsh package. Why doesn't bash-completions depend on fink's bash?

(Just curious. Nothing more.) I know nothing about zsh and zsh-templates (or about Fink's policy on such matters), but the bashcompletion scripts do work with 10.4.11's bash (2.05b), at least, and in fact they go to a fair amount of trouble to figure out which version of bash they're using and adjust their behavior accordingly. Gary K Olson wrote: I used rsync-selfupdate today from a US mirror to get libiconv-1.12-3 and updated qt4-x11 info and patch files to successfully compile and install the libiconv, qt4-x11 and lyx-qt on 10.5.1 iBook G4.

I believe that the early success on my G5 may have been done with Rick's original test files that he posted on his web site and not the new info and patch files. However, today's success with the G4 was done through the rsync update. Following the list thread, I hope my earlier entry today did not confuse matters. Apparently, at least some of US mirrors must have correct new info and patch files? Gary K Olson That's right. Your early success was certainly not inconsistent with the problem-libiconv would build differently depending on whether it was being built cleanly or as an upgrade.

If you're a LyX user, I've updated lyx-qt to the current upstream version. I used rsync-selfupdate today from a US mirror to get libiconv-1.12-3 and updated qt4-x11 info and patch files to successfully compile and install the libiconv, qt4-x11 and lyx-qt on 10.5.1 iBook G4. I believe that the early success on my G5 may have been done with Rick's original test files that he posted on his web site and not the new info and patch files. However, today's success with the G4 was done through the rsync update. Following the list thread, I hope my earlier entry today did not confuse matters. Apparently, at least some of US mirrors must have correct new info and patch files?

Gary K Olson. On 30 Jan 2008, at 00:30, Enrico Costanza wrote: Jean-Francois Mertens wrote: Enrico Costanza wrote: Failed: phase compiling: libx264-57-shlibs-0.0.20071214-1 failed In particular, this is the error that I get:. ld: common/i386/pixel-sse2.o has external relocation entries in non-writable section (TEXT,text) for symbols: x264pixelsadx48x8mmxext Selfupdate. This was recently fixed by the maintainer.

Thanks for the answer, but that does not work. I had tried before posting, and again after receiving your email.unless I am doing something stupid: fink selfupdate fink update-all (they both tell me that there are 0 packages installed) Wait then a bit more till your rsync mirror shows rev 2 JF. On 30 Jan 2008, at 00:30, Enrico Costanza wrote: Jean-Francois Mertens wrote: Enrico Costanza wrote: Failed: phase compiling: libx264-57-shlibs-0.0.20071214-1 failed In particular, this is the error that I get:. ld: common/i386/pixel-sse2.o has external relocation entries in non-writable section (TEXT,text) for symbols: x264pixelsadx48x8mmxext Selfupdate. This was recently fixed by the maintainer. Thanks for the answer, but that does not work.

I had tried before posting, and again after receiving your email.unless I am doing something stupid: fink selfupdate fink update-all (they both tell me that there are 0 packages installed) your error msg shows 'libx264-57-shlibs-0.0.20071214-1'. Cvs log shows revision 2 as of 'date: 2008/01/29 22:06:16'; it is to that one I referred. Possibly you have to wait till your rsync mirrors catch up.

Hi Daniel et al: I just noticed this too. Why does daemonic get installed if there are no dependencies, and why does it need a completion system for an interactive shell? Also, when I made a set of files to augment the zsh completion system, I was told I had to make it depend on fink's zsh package. Why doesn't bash-completions depend on fink's bash?

(Just curious. Nothing more.) Bill On Tue, 29 Jan 2008, Daniel Macks wrote: On Tue, Jan 29, 2008 at 05:14:01PM -0500, Daniel Macks wrote: On Tue, Jan 29, 2008 at 09:31:01PM +0000, Viv Kendon wrote: In fact, I managed to remove daemonic (don't know how it originally got installed) and then bash-completion. I got the following warning though: Removing bash-completion. dpkg - warning: while removing bash-completion, directory `/sw/etc/bashcompletion.d' not empty so not removed. Which suggests removing daemonic didn't remove whatever it put in there.a little untidy of it, no? Just for confirmation that there aren't two unrelated plagues herewhat file(s) are in /sw/etc/bashcompletion.d? Ah yes, daemonic has tagged bashcompletion.d/daemonic as a 'configuration/preferences file', so by default that file persists even after daemonic is removed.

That's a good mechanism (so that locally applied configs and prefs don't get nuked every time package is upgraded), but we don't have good guidelines on what specific kinds of files to tag this way. If you 'purge' instead of 'remove' a package, the ConfFiles get deleted also.

Dan - Daniel Macks dmacks@. Jean-Francois Mertens wrote: Enrico Costanza wrote: Failed: phase compiling: libx264-57-shlibs-0.0.20071214-1 failed In particular, this is the error that I get:. ld: common/i386/pixel-sse2.o has external relocation entries in non-writable section (TEXT,text) for symbols: x264pixelsadx48x8mmxext Selfupdate. This was recently fixed by the maintainer. Thanks for the answer, but that does not work. I had tried before posting, and again after receiving your email.unless I am doing something stupid: fink selfupdate fink update-all (they both tell me that there are 0 packages installed) Thanks, Enrico.

Hi All, I am using osx 10.4. I have a fresh installation of fink, and I use X11 from Apple. On Tue, Jan 29, 2008 at 05:14:01PM -0500, Daniel Macks wrote: On Tue, Jan 29, 2008 at 09:31:01PM +0000, Viv Kendon wrote: In fact, I managed to remove daemonic (don't know how it originally got installed) and then bash-completion. I got the following warning though: Removing bash-completion. dpkg - warning: while removing bash-completion, directory `/sw/etc/bashcompletion.d' not empty so not removed.

Which suggests removing daemonic didn't remove whatever it put in there.a little untidy of it, no? Just for confirmation that there aren't two unrelated plagues herewhat file(s) are in /sw/etc/bashcompletion.d? Ah yes, daemonic has tagged bashcompletion.d/daemonic as a 'configuration/preferences file', so by default that file persists even after daemonic is removed. That's a good mechanism (so that locally applied configs and prefs don't get nuked every time package is upgraded), but we don't have good guidelines on what specific kinds of files to tag this way. If you 'purge' instead of 'remove' a package, the ConfFiles get deleted also. Dan - Daniel Macks dmacks@. On Tue, Jan 29, 2008 at 09:31:01PM +0000, Viv Kendon wrote: In fact, I managed to remove daemonic (don't know how it originally got installed) and then bash-completion.

I got the following warning though: Removing bash-completion. dpkg - warning: while removing bash-completion, directory `/sw/etc/bashcompletion.d' not empty so not removed. Which suggests removing daemonic didn't remove whatever it put in there.a little untidy of it, no? Just for confirmation that there aren't two unrelated plagues here, what file(s) are in /sw/etc/bashcompletion.d? Dan - Daniel Macks dmacks@. On Tue, Jan 29, 2008 at 09:31:01PM +0000, Viv Kendon wrote: In fact, I managed to remove daemonic (don't know how it originally got installed) and then bash-completion. I got the following warning though: Removing bash-completion.

dpkg - warning: while removing bash-completion, directory `/sw/etc/bashcompletion.d' not empty so not removed. Which suggests removing daemonic didn't remove whatever it put in there.a little untidy of it, no? That's not necessarily daemonic's responsibility. Other packages put things into /sw/etc/bashcompletion.d as well. On my system, both the daemonic and darcs packages have files in there.

On Sun, 27 Jan 2008, Martin Costabel wrote: Richard Cobbe wrote: First, it appears that the daemonic package depends on bash-completions; this is presumably why fink installed the bash-completions package. I certainly didn't explicitly ask for bash-completions. Now'dpkg -L daemonic' explains why this dependency exists; daemonic puts a file in /sw/etc/bashcompletion.d and thus needs that directory to exist. But It does not need that directory to exist. It creates it anyway and can very well place things inside even if the bashcompletion package is not installed. I agree that one could consider this a bug in the daemonic package to impose the bashcompletion package on people who don't want it, in particular considering that the daemonic package itself is often installed as a dependency that is not really needed. I am CCing the author of this (very recent) addition to daemonic.

Another plea for the removal of this unrequested package from dependencies. I was wondering what had happened, and, since its appearance more or less coincided with my Leopard upgrade, hadn't worked out that it wasn't due to that. In fact, I managed to remove daemonic (don't know how it originally got installed) and then bash-completion.

I got the following warning though: Removing bash-completion. Dpkg - warning: while removing bash-completion, directory `/sw/etc/bashcompletion.d' not empty so not removed. Which suggests removing daemonic didn't remove whatever it put in there.a little untidy of it, no?

Thanks, - Viv - Dr Viv Kendon Quantum Information Physics & Astronomy University of Leeds. It sounds like the macbook pro isn't running 'fink scanpackages' after each build, and so the local package information isn't getting passed on to apt. Older versions of fink required you to set a fink.conf flag to do so, but that seems no longer to be the case for what I'm running (0.28.0). Mattia Vaccari wrote: On a related note, I cannot make sense of an oddity I discovered in fink binary distribution management. I've got an intel-based imac and a macbook pro running the latest tiger+xcode+finkcryptounstable (and using the very same fink mirrors) but the lists of binary packages available for install in the two systems appear to be different, with more up-to-date packages available on the imac than on the macbook pro. The available source packages are invariably the same, though. Any clue why this could be!?

Examples of little differences follow scilab has got NO binary on the macbook pro but has got 4.1.1001 binary on the imac, both have got 4.1.2-1002 source, octave has got 2.9.12-4 binary on the imac but none on the macbook pro, and so on Cheers - Mattia. On a related note, I cannot make sense of an oddity I discovered in fink binary distribution management. I've got an intel-based imac and a macbook pro running the latest tiger+xcode+finkcryptounstable (and using the very same fink mirrors) but the lists of binary packages available for install in the two systems appear to be different, with more up-to-date packages available on the imac than on the macbook pro. The available source packages are invariably the same, though. Any clue why this could be!?

Examples of little differences follow scilab has got NO binary on the macbook pro but has got 4.1.1001 binary on the imac, both have got 4.1.2-1002 source, octave has got 2.9.12-4 binary on the imac but none on the macbook pro, and so on Cheers - Mattia Martin Costabel wrote: Steffen Schmidt wrote: thanks for the hint - now at least I see that all packages prior to the latest one are found on the binary distro server. That's really weird - I tried fink selfupdate on the client several times plus fink scanpackages on the server - still the latest packages are not available.

Hmm, it looks like Packages.gz in e.g. Unstable/main/binary-darwin- i386 hasn't been changed since mid December - there are a lot of Packages.gz.something though but none of them contain the new package entries. Run 'sudo apt-get update' on the client. This used to be run by 'fink selfupdate' automatically, but it isn't any more on 10.5. I am pitching this to fink-core, because it is a bug in the latest fink for 10.5. On 10.4, the latest fink-0.27.10-31 still runs apt-get update after fink selfupdate, on 10.5 fink-0.27.10-42 doesn't. Martin Costabel wrote: Kevin Horton wrote: For some reason, the new libiconv 1.12-1 that arrived via selfupdate a few hours ago differs quite substantially from the libiconv 1.12-3 that Benjamin offered for testing.

Suggestion: Include Zsh Completion Into Distribution Packages

That's not what we all have been testing. And we didn't notice, because we had 1.12-3 installed and so did not get 'upgraded' to 1.12-1. Indeed, it turns out that when copying the final version over, I should have svn up'd first. I had been doing the testing on my 10.4 box, but I released to unstable from my 10.5 box, which had an older version.:( Fixed in unstable.