Re: [Fink-devel] icewm-1.3.6-1 fails to build on 10.5/i386
On Thu, 16 Sep 2010 07:08:44 -0400, Hanspeter Niederstrasser wrote: 10.5/i386/Apple's X11: > > g -fpermissive -Wall -Wpointer-arith -Wwrite-strings > -Woverloaded-virtual -W -fno-exceptions -fno-rtti -Os -pipe -MD > -I/sw/include-DHAVE_CONFIG_H -DLIBDIR='"/sw/share/icewm"' > -DCFGDIR='"/sw/etc/icewm"' -DLOCDIR='"/sw/share/locale"' -DKDEDIR='""' > -DPACKAGE='"icewm"' -DVERSION='"1.3.6"' -DHOSTOS='"Darwin"' > -DHOSTCPU='"i386"' -DEXEEXT='""' -DICEWMEXE='"icewm"' > -DICEWMTRAYEXE='"icewmtray"' -DICEWMBGEXE='"icewmbg"' > -DICESMEXE='"icewm-session"' -DICEHELPEXE='"icehelp"' > -DICEHELPIDX='"/sw/share/doc/icewm/icewm.html"' `pkg-config > gdk-pixbuf-xlib-2.0 --cflags` -I/sw/lib/xft2/include > -I/sw/include/freetype2 -I/sw/include -I/sw/lib/fontconfig2/include > -I/usr/X11/include -I/usr/X11R6/include -I/sw/include/glib-2.0 > -I/sw/lib/glib-2.0/include -I/sw/include -I/sw/include/gtk-2.0 > -I/sw/include -c ywindow.cc > ywindow.cc: In member function 'void YDesktop::updateXineramaInfo(int&, > int&)': > ywindow.cc:1882: error: 'XRRScreenResources' was not declared in this scope > ywindow.cc:1882: error: 'xrrsr' was not declared in this scope > ywindow.cc:1883: error: 'XRRGetScreenResources' was not declared in this > scope > ywindow.cc:1887: error: 'XRRCrtcInfo' was not declared in this scope > ywindow.cc:1887: error: 'ci' was not declared in this scope > ywindow.cc:1887: error: 'XRRGetCrtcInfo' was not declared in this scope > ywindow.cc:1904: error: 'XRROutputInfo' was not declared in this scope > ywindow.cc:1904: error: 'oinfo' was not declared in this scope > ywindow.cc:1904: error: 'XRRGetOutputInfo' was not declared in this scope > make[1]: *** [ywindow.o] Error 1 > make: *** [base] Error 2 > ### execution of make failed, exit code 2 > ### execution of /var/tmp/tmp.4.Ydnq2d failed, exit code 2 > > Google says those are Xrandr.h things, which I do have in > /usr/X11/include/X11/extensions/Xrandr.h (v 1.9 2002/09/29 according the > the CVS tag on top of the file). > > Found this as well: > http://sourceforge.net/tracker/?func=detail&aid=2677667&group_id=31&atid=100031 I forgot how confusing the xrandr situation is on OS X:( Different versions, and at least one x11 provider (10.4/apple's maybe) has an xrandr that lies about its own version. I committed %r=2 for 10.[45] that has --disable-randr (vs a separate high %r for 10.6 with it not-disabled). That "seems like it might work", in that on 10.6 it still builds successfully but does not appear to use xrandr at compile-time. That's about as far as I can take it, others feel free to hack and fix. dan -- Daniel Macks dma...@netspace.org -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Angband Won't Build As Nobody
On Sun, 12 Sep 2010 09:33:39 0200, Max Horn wrote:
> Here is one idea: Maybe we could insert our own custom chmod/chown
scripts into the PATH used for building packages, with suid flag set,
so that they can invoke the original chmod/chown with the appropriate
rights. Of course that punches a hole into the "non-root" approach, but
a relatively small one (as long as we don't do --b-a-n to prevent
security holes, this is not a big issue, anyway).
> We could also try to avoid that hole by filtering the path
arguments passed to our chmod/chown/chgroup commands, to only accepts
paths inside the build dir (or even only in the install dir). For that,
in turn, some care would have to be taken to make sure callers can't
"punch out" by using clever combos of ".." and symlinks. That could be
done by using "readlink -f PATH" on each of the paths passed to the
chmod util before matching it against the /sw/src/fink.build/%n-%v-%r
prefix (or whatever the build dir is set to).
Wouldn't a suid'ed "chown" allow any user to seize ownership of any
file anywhere on the filesystem? Would have to be *very* careful to
sanitize the allowable targets. But even still, it would allow some
random user on a shared machine to take ownership of files in a build
dir during the build process, and therefore own live files in /sw. Only
safe way to have this sort of feature would be to have the suid-chown
verify that the real user running it is fink-bld. If only the
--build-as-nobody user can use it and nobody (except root) can become
that user, we're essentially as safe as only allowing root to do chown.
In addition to chown and chmod, we'd need install (its -o and -g flags
always trip --build-as-nobody in imake projects) and chgrp.
A second part of the process would have to involve changes to existing
--b-a-n functionality: the reversion of builddir to root. Currently
(approximately), --b-a-n switches to fink-bld for InstallScript and
related actions, then 'chown -R root:admin $builddir' so that it is
back to the normal state for live filesystem files. If we have chown'ed
files to (for example) games, that would wipe the ownership anyway.
Instead would have to replace the chown -R with one that only acted on
files still owned by fink-bld (and separate similar control group). Not
un-doable ('find' or a perl-equivalent implementation), just a TODO
reminder.
dan
--
Daniel Macks
dma...@netspace.org
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Help kill old automake by testing gettext build
The only thing that uses automake1.5 anywhere in stable or unstable is...old gettext. That lib is still used by a bunch of packages (and we have to keep it per Shlibs Policy anyway), so I need help testing the update for it to newer automake. That would be gettext.info in my CVS exp. I went with automake1.9 because akh said "1.9 seems conservative upgrade", so there we are. To test, build the one from unstable (== stable at this time) on your platform (OS X 10.[56], any arch) with -l (to save log of build). Then redo with my exp one and compare the logs. I'm expecting no differences in configure detection, maybe a few less autotools warnings, a pair of warnings about AM_* symbols (see .info DescPort), and no differences in compile and install commands or results. dan -- Daniel Macks dma...@netspace.org -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [Fink-users] EMBOSS: dependency problems on X86_64
On Tue, 24 Aug 2010 21:07:03 -0400, Alexander Hansen wrote: > On 8/24/10 8:34 PM, Hanspeter Niederstrasser wrote: > > On 8/24/10 6:46 PM, Scott R. Santos wrote: > >> > >> 2) I now get the following error when I try to update EMBOSS on > X86_64 systems (didn't happen before the new plplot was introduced > and guess "wxmac28-shlibs" isn't available for this platform; I > consider this another reason to have a "vanilla" version of EMBOSS > available via fink): > >> > >> srsan...@scott-r-santoss-macbook-pro:~$ fink update-all > >> Information about 9342 packages read in 0 seconds. > >> Can't resolve dependency "wxmac28-shlibs" for package "libplplot10-shlibs-5.9.6-1" (no matching packages/versions found) > >> Exiting with failure. > > > > According to this page > > <http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard> > > the current Fink version (2.8.x) can't be made to work as x86_64 (uses > > Carbon). However, it seems that the latest upstream version is 2.9.1 > > (recently released) and earlier news suggests that version should do > > 64bit OS X. > > Until such time as this makes it into Fink, unless somebody has another > idea, I think we need to pull plplot, emboss ... from the 10.6/x86_64 tree. plplot only uses wxmac as a plugin/device-driver, so it could be packaged separately if someone actually wants it for something. Meanwhile, I'll disable it core plplot libs so at least *that* stays portable. dan -- Daniel Macks dma...@netspace.org -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] AWOL Maintainer: blair christensen
- Forwarded message from Mail Delivery Subsystem - Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) The original message was received at Sun, 13 Jun 2010 16:48:34 -0400 from localhost.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - - Transcript of session follows - ... Deferred: Connection timed out with devclue.com. Message could not be delivered for 5 days Message will be deleted from queue Arrival-Date: Sun, 13 Jun 2010 16:48:34 -0400 Final-Recipient: RFC822; bl...@devclue.com Action: failed Status: 4.4.7 Remote-MTA: DNS; devclue.com Last-Attempt-Date: Fri, 18 Jun 2010 17:43:54 -0400 - Anyone had any contact lately or know any recent activity/history of his packages: perl6-say-pm pod-pseudopod-pm rpc-xml-pmXXX dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fontconfig2-dev: Error installing gtk+2 BuildDepends in Fink 10.6.3/x86 stable
On Sun, Jun 13, 2010 at 03:23:12PM -0400, Alexander Hansen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 6/13/10 2:10 PM, Charles Lepple wrote: > > I was trying to test a new revision of gtkwave under 10.6/stable (32- > > bit), and I get the following when building the gtk/glib dependencies > > for the first time: > > > > $ nice fink -l -m install gtkwave > > Password: > > Scanning package description files.. > > Information about 3646 packages read in 1 seconds. > > Running in Maintainer Mode > > Validating package file /sw/fink/dists/local/main/finkinfo/gnome/ > > gtkwave.info... > > Package looks good! > > The package 'gtkwave' will be built and installed. > > Reading dependency for gtkwave-3.3.7-2... > > Reading build dependency for gtkwave-3.3.7-2... > > Reading build conflict for gtkwave-3.3.7-2... > > The package 'glib2-shlibs' will be built and installed. > > Reading dependency for glib2-shlibs-2.20.5-2... > > Reading build dependency for glib2-shlibs-2.20.5-2... > > Reading dependency for glib2-dev-2.20.5-2... > > Reading build conflict for glib2-shlibs-2.20.5-2... > > The package 'gtk+2-shlibs' will be built and installed. > > Reading dependency for gtk+2-2.16.6-3... > > Reading build dependency for gtk+2-2.16.6-3... > > Reading dependency for gtk+2-shlibs-2.16.6-3... > > Reading dependency for gtk+2-dev-2.16.6-3... > > Reading dependency for gtk+2-shlibs-2.16.6-3... > > Reading build dependency for gtk+2-shlibs-2.16.6-3... > > Reading build conflict for gtk+2-2.16.6-3... > > Reading build conflict for gtk+2-shlibs-2.16.6-3... > > The package 'liblzma-shlibs' will be built and installed. > > Reading dependency for xz-4.999.9-3... > > Reading build dependency for xz-4.999.9-3... > > Reading dependency for liblzma-shlibs-4.999.9-3... > > Reading dependency for liblzma-4.999.9-3... > > Reading dependency for lzma-4.999.9-3... > > Reading dependency for liblzma-shlibs-4.999.9-3... > > Reading build dependency for liblzma-shlibs-4.999.9-3... > > Reading build conflict for xz-4.999.9-3... > > Reading build conflict for liblzma-shlibs-4.999.9-3... > > The package 'shared-mime-info' will be built and installed. > > Reading dependency for shared-mime-info-0.51-1... > > Reading build dependency for shared-mime-info-0.51-1... > > Reading build conflict for shared-mime-info-0.51-1... > > The package 'atk1' will be built and installed. > > Reading dependency for atk1-1.26.0-2... > > Reading build dependency for atk1-1.26.0-2... > > Reading dependency for atk1-shlibs-1.26.0-2... > > Reading build conflict for atk1-1.26.0-2... > > The package 'cairo' will be built and installed. > > Reading dependency for cairo-1.8.10-2.1... > > Reading build dependency for cairo-1.8.10-2.1... > > Reading dependency for cairo-shlibs-1.8.10-2.1... > > Reading build conflict for cairo-1.8.10-2.1... > > The package 'fontconfig2-dev' will be built and installed. > > > > WARNING: The package fontconfig2-dev Depends on system-xfree86-dev, > > but system-xfree86-dev only allows things to BuildDepend on it. > > > > Failed: Please correct the above problems and try again! > > > > $ fink --version > > Package manager version: 0.29.12 > > Distribution version: selfupdate-rsync Sun Jun 13 12:27:00 2010, 10.6, > > i386 > > > > I am using the stock X11 that came with 10.6.x, plus whatever the > > latest updates are. Let me know if, for some reason, I should be using > > another package of XQuartz instead. > > God, no! That installs in /opt/X11 (or something) on 10.6, anyway, so > hopefully no Fink packages actually find it. > > > > > Looks like someone else ran into this: > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=2966606&group_id=17203&atid=117203 > > > > And, of course, they put a totally useless title to the bug, and nobody > is reading the bug tracker right now. > > > I don't really need the "-m" switch for the dependencies, but it would > > probably be good to have this work out-of-the-box. > > > > > > I'd recommend migrating the current/unstable fontconfig over--it doesn't > carry the same Depends issues. Unfortunately, it also Depends: > dpkg-base-files, which is unstable-only, and that in turn Depends on an > unstable-only dpkg revision. dpkg-base-files is not migrated yet because nobody has finished fixing kde to compensate
[Fink-devel] Fixing libiconv (build-test needed)
Could someone(s) test the libiconv in my cvs exp? Goal: compare build transcript: 1) with fink libiconv-dev installed, 2) without libiconv-dev, 3) without libiconv-dev *and with /usr/include/iconv.h and /usr/lib/libiconv.dylib (and .la if present) moved away. Need to make sure we aren't getting circular dependency and aren't mixing system with internal lib/headers of same name. Clean on 10.4, need checked on 10.6/32 and 10.6/64 http://fink.cvs.sf.net/viewvc/*checkout*/fink/experimental/dmacks/finkinfo/libiconv.info?revision=1.2 http://fink.cvs.sf.net/viewvc/*checkout*/fink/experimental/dmacks/finkinfo/libiconv.patch?revision=1.1 dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] http://pdb.finkproject.org/pdb/package.php/sendfile
On Sat, Jun 12, 2010 at 12:54:17PM +0200, Ulli Horlacher wrote: > > I am the author of sendfile. > > I see access to the sendfile homepage through > http://pdb.finkproject.org/pdb/package.php/sendfile (Referer) > > On your webpage you write about "sendfile 2.1a", but the stable release is > sendfile-2.1b - for more than 10 years. > > The sendfile homepage has moved from > http://www.belwue.de/aktivitaeten/projekte/saft/index-us.html > to > http://fex.rus.uni-stuttgart.de/saft/sendfile.html I just updated the package per new version and changed URLs. > But sendfile has a much better successor: F*EX > http://fex.rus.uni-stuttgart.de/ > > Maybe you are interested. Love to have it! All we need is someone to submit a package .info file. The existing package, as you saw on the webpage, has no current maintainer:( dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] 32-bits apps in the 64-bit branch
On Thu, Jun 10, 2010 at 06:24:59PM +0200, Jean-Fran?ois Mertens wrote: > > On 10 Jun 2010, at 17:34, Alexander Hansen wrote: > > > On 6/10/10 11:28 AM, Pepe Barbe wrote: > >> Hello, > >> > >> I am trying to update the sleepwatcher. This package links against > >> carbon so it is 32-bits only. I would like to make the package so > >> that it could be installed also from within the 64-bit branch, but > >> I don't what is the policy in this regard. > > > > I believe that if it won't build in the 64-bit tree, then it is not > > allowed to exist in that tree. > > Just built it on 32bit, to see. > The pkg links ONLY against the system; so with > SetCC: /usr/bin/cc > should "build in the 64-bit tree" _ though not in 64-bit mode ... > And nothing can link against it ... > So _ is there a policy for such cases ? Sounds reasonable. Unrelatedly, while fixing that package, the following is a little problem: install -o root -g wheel -m 755 rc.sleep %i/etc/ install -o root -g wheel -m 755 rc.wakeup %i/etc/ because it prevents --build-as-nobody from being used. By default (either with or without --b-a-n) all files are installed owned by root:admin. If that's acceptible for these rc.* files, then you can omit the -o and -g games here. If you really need them group=wheel, better would be to omit -o/-g here and have a 'chgrp' command in PostInstScript--and definitely a DescPackaging note about this group requirement so others can figure out why there are non-standard ownership flags and/or build-unusual-actions here. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] geeqie appears to need a BuildDepend on getoptbin
On Thu, Jun 10, 2010 at 07:04:44AM -0400, Alexander Hansen wrote: > > The failure mode when /usr/bin/getopt is used on 10.5 or 10.6 is: > > ... > if [ -x "/sw/bin/gnome-doc-tool" ]; then \ > "/sw/bin/gnome-doc-tool" html -o html ./docbook/GuideIndex.xml > ; \ > else \ > echo "gnome-doc-tool not found, html is not built" ; \ > fi > getopt: illegal option -- s [...] > With getoptbin installed, the build succeeds. Looks like it's gnome-doc-tool in general (or at least "in ways not specific to geeqie"), so added as Depends to gnome-doc-utils. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] abstract method called directly! error
On Sun, Jun 06, 2010 at 07:16:05AM -0400, Koen van der Drift wrote:
> Hi,
>
> I am getting the following error with one of my perlmodules:
>
> make test || exit 2
> PERL_DL_NONLAZY=1 /usr/bin/perl5.8.8 "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/compat/*.t
> abstract method called directly! at /sw/src/fink.build/tap-parser-
> pm588-0.54-1/TAP-Parser-0.54/blib/lib/TAP/Parser.pm line 1189
> TAP::Parser::__ANON__() called at /sw/src/fink.build/tap-parser-
> pm588-0.54-1/TAP-Parser-0.54/blib/lib/TAP/Parser.pm line 240
> TAP::Parser::next('TAP::Parser=HASH(0x891714)') called at /sw/lib/
> perl5/5.8.8/TAP/Harness.pm line 548
> TAP::Harness::_aggregate_single('TAP::Harness=HASH(0x8111cc)',
> 'TAP::Parser::Aggregator=HASH(0x810fbc)',
> 'TAP::Parser::Scheduler=HASH(0x892c94)') called at /sw/lib/perl5/5.8.8/
> TAP/Harness.pm line 638
> TAP::Harness::aggregate_tests('TAP::Harness=HASH(0x8111cc)',
> 'TAP::Parser::Aggregator=HASH(0x810fbc)', 't/000-load.t', 't/010-
> base.t', 't/020-regression.t', 't/030-grammar.t', 't/040-parse.t', 't/
> 050-bailout.t', 't/060-errors.t', ...) called at /sw/lib/perl5/5.8.8/
> Test/Harness.pm line 152
> Test::Harness::_aggregate_tests('TAP::Harness=HASH(0x8111cc)',
> 'TAP::Parser::Aggregator=HASH(0x810fbc)', 't/000-load.t', 't/010-
> base.t', 't/020-regression.t', 't/030-grammar.t', 't/040-parse.t', 't/
> 050-bailout.t', 't/060-errors.t', ...) called at /sw/lib/perl5/5.8.8/
> Test/Harness.pm line 134
> Test::Harness::_aggregate('TAP::Harness=HASH(0x8111cc)',
> 'TAP::Parser::Aggregator=HASH(0x810fbc)', 't/000-load.t', 't/010-
> base.t', 't/020-regression.t', 't/030-grammar.t', 't/040-parse.t', 't/
> 050-bailout.t', 't/060-errors.t', ...) called at /sw/lib/perl5/5.8.8/
> Test/Harness.pm line 166
> Test::Harness::runtests('t/000-load.t', 't/010-base.t', 't/020-
> regression.t', 't/030-grammar.t', 't/040-parse.t', 't/050-bailout.t',
> 't/060-errors.t', 't/070-streams.t', 't/080-aggregator.t', ...) called
> at /sw/lib/perl5/5.8.8/ExtUtils/Command/MM.pm line 62
> ExtUtils::Command::MM::test_harness(0, 'blib/lib', 'blib/arch')
> called at -e line 1
> at /sw/src/fink.build/tap-parser-pm588-0.54-1/TAP-Parser-0.54/blib/
> lib/TAP/Parser.pm line 1189
> make: *** [test_dynamic] Error 25
> ### execution of make failed, exit code 2
> ### execution of /var/tmp/tmp.5.2kv8XB failed, exit code 2
> Removing runtime build-lock...
> Removing build-lock package...
> /sw/bin/dpkg-lockwait -r fink-buildlock-tap-parser-pm588-0.54-1
> (Reading database ... 161098 files and directories currently installed.)
> Removing fink-buildlock-tap-parser-pm588-0.54-1 ...
> Failed: phase test: error (2)
That error is a self-test failure, not actually a perl error (though
it sure sounds like it!) It's apparently triggered when a child-class
fails to define its own method that the base-class declares as a "must
override in child" (calling the child falls through to the parent
because child doesn't have its own).
According to CPAN search, TAP::Parser is now (not sure as of how
recently) part of the Test::Harness distro, and the Tap::Parser docs
say the goal of that package was to eventually migrate into
Test::Harness. Do we still need a stand-alone actual tap-parser-pmXXX
for that module or should that package become an obsolete dummy bundle
that just depends on test-parser-pmXXX?
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc45 build fails on two 10.6 64-bit machines
On Wed, Jun 02, 2010 at 09:05:34PM -0400, Jack Howarth wrote:
> On Wed, Jun 02, 2010 at 08:47:54PM -0400, Alexander Hansen wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 6/2/10 8:43 PM, Jack Howarth wrote:
> > > On Wed, Jun 02, 2010 at 08:36:58PM -0400, Alexander Hansen wrote:
> > > On 6/2/10 8:26 PM, Jack Howarth wrote:
> > >>>> On Wed, Jun 02, 2010 at 08:04:20PM -0400, Benjamin Reed wrote:
> > >>>> On 6/2/10 7:55 PM, Jack Howarth wrote:
> > >>>>>>> One possible workaround might be to change gcc45.info
> > >>>>>>> to reduce the number of parallel builds so that the
> > >>>>>>> load sensitivity is reduced. So instead of using...
> > >>>>>>>
> > >>>>>>> num_cpu=$(echo `sysctl -n hw.ncpu`)
> > >>>>>>> make -j $num_cpu
> > >>>>>>>
> > >>>>>>> we would reduce num_cpu by one if greater
> > >>>>>>> than one so that the build is either serial
> > >>>>>>> or leaves a free core whenever building in parallel.
> > >>>>>>> This won't 'fix' the problem but it might make
> > >>>>>>> it less likely.
> > >>>>
> > >>>> So if GCC's build is not repeatably compatible with -jN, then it
> > >>>> should probably not be doing it by default. :P
> > >>>>
> > >>>>> This is a recent regression upstream. The question is do you
> > >>>>> penalize all users with multiple core machines for those
> > >>>>> unlucky users running two cores at high load? As I said before,
> > >>>>> a rational (and less extreme) workaround would be to leave
> > >>>>> a free core available to reduce the load on the machine.
> > >>>>> I build gcc trunk nightly and have never seen this failure
> > >>>>> on a dual quad.
> > >>>>> Jack
> > >>>>
> > >>>>
> > >>>>
> > >
> > > I'll point out that I had my single instance of this failure on a
> > > single-core powerpc, and had no such problem building on a two-core
> > > Macbook under load.
> > >
> > >> Are you sure you're not confusing the issue with...
> > >
> > >> cp %b/gcc/config/darwin-sections.def
> > >> %i/lib/gcc4.5/lib/gcc/%m-apple-darwin${darwinvers}/%v/plugin/include/config
> > >
> > >> on powerpc? I suspect these are totally different problems. The compiler
> > >> plugin support apparently isn't installing the plugin header directory
> > >> on powerpc-apple-darwin. As I mentioned before, this cp comamnd can be
> > >> skipped on powerpc because there will never be a dragonegg compiler
> > >> plugin for powerpc (only i386 and x86_64 darwin).
> > >
> > >
> > I'm not confusing anything. I mentioned earlier in this thread that I
> > had an instance of _this_ problem:
> >
>
> So that implies that the parallel build on even a single job
> can trigger the problem. Definitely there is little reason to
> parallel build on a single core so we could limit the parallel
> builds to machines with more than two cores for safety.
In general, using more -j than core on one/few-core systems actually
does increase overall build speed. It lets the the build process take
advantage of (for example) I/O in one thread while heavy CPU in
another. Saturate multiple resources rather than having one mostly
idle waiting for another. No idea if there is a limit beyond which it
no longer helps ("always something wanting disk" or "not enough
parallel-izable tasks without queuing for disk").
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Automatic hiding of /usr/local
One of the side effects of fink-package-precedence is that /usr/local
becomes more of a visible problem. Well, it was always a problem, but
now it becomes a build-time crash rather than a silently-lurking
time-bomb). There are lots of legitimate reasons users may have
/usr/local stuff, but no good technical way to hide it from the
compiler.
We've previously considered and rejected the idea of *automatically*
moving /usr/local (or at least include/ and lib/) out of the way
during fink build operations because it's an "out of /sw" effect that
might affect other work the user is doing, and if the build fails, the
directories might not get put back in their original place.
Murr suggested a fink *option* to do it. I agree it's a nice feature.
Some ideas he and I kicked around include having fink warn if
/usr/local stuff is detected, and having a fink.conf opt-in control
that does the rename-while-build-then-restore. And vasi's "Finally"
feature (used by the BuildConflicts swappy and Buildlock removal
processes) to restore seems to provide a way to restore the moved dirs
even in most cases when the build fails. My only concern is for
parallel build operations ('fink build a' and 'fink build b' in
separate windows)...need to make sure the restore only happens when
*all* builds are finished, which may also not be the same build that
did the move originally.
So...thoughts about a boolean fink.conf:HideUsrLocal flag, where TRUE
means rename/restore and FALSE/UNDEFINED means issue warning?
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] log-log4perl-pm588-1.01-1 self-test failure
On Fri, May 21, 2010 at 12:12:31PM -0400, Alexander Hansen wrote: > On 5/20/10 7:27 PM, Daniel Macks wrote: > > 10.4/ppc, everything up-to-date unstable: > > > > t/048lwp.t ... 1/3 > > # Failed test at t/048lwp.t line 41. > > # '' > > # doesn't match '(?-xism:GET file:/tmp/foobar)' > > > > # Failed test at t/048lwp.t line 86. > > # '' > > # doesn't match '(?-xism:LWP/UserAgent.pm-\d+)' > > # Looks like you failed 2 tests of 3. > > t/048lwp.t ... Dubious, test returned 2 (wstat 512, 0x200) > > Failed 2/3 subtests > > > > Same result on the -pm586 package. > > Also the same on 10.5.8/i386 Fix committed. Maintainer: this package is still out-of-date (there is a newer version on CPAN), but at least this old version compiles now. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] openexr split
On Fri, May 21, 2010 at 09:31:08PM -0400, Benjamin Reed wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > OpenEXR has been split into 2 packages, openexr and ilmbase. Luckily, > they're static only, but I just wanted to give a head's up that I'll > need to change the BuildDeps on your packages for them to build against > the newer OpenEXR. If that's not OK, let me know, otherwise I'll change > them some time this week... :) Go for it. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] log-log4perl-pm588-1.01-1 self-test failure
10.4/ppc, everything up-to-date unstable: t/048lwp.t ... 1/3 # Failed test at t/048lwp.t line 41. # '' # doesn't match '(?-xism:GET file:/tmp/foobar)' # Failed test at t/048lwp.t line 86. # '' # doesn't match '(?-xism:LWP/UserAgent.pm-\d+)' # Looks like you failed 2 tests of 3. t/048lwp.t ... Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Same result on the -pm586 package. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] ATK and GTK
On Sat, May 15, 2010 at 09:19:06PM -0400, Alexander Hansen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 5/15/10 5:19 PM, David Lowe wrote: > > I'm nearly through [i think] with the freeciv-gtk2 package. There is a > > remaining issue that i'm not sure the best way to handle. Upstream lists > > ATK as a dependency, yet it gets stripped out with "SetLDFLAGS: > > -Wl,-dead_strip_dylibs". When i inquired about this on the freeciv-dev > > list, i was told: > > > >> However, freeciv does not use atk directly. Rather, gtk lists (or at > >> least used to list) it as its dependency. > > > > So apparently ATK is a dependency for all GTK programs? > > > > Sent from my MacBookPro > > That used to be the case, anyway: anytime you depended on gtk+2, you > also needed atk1, glib2, and some other libraries. I'm not sure whether > that's changed in the latest Fink/unstable gtk+2 or not. You still need a bunch of other things when you use gtk. Assuming "you use gtk" via pkg-config, which is the way gtk publishes the platform correct flags anyway:) Using -dead_strip on a binary FOO prunes libs that are not actually used to resolve symbols called from FOO. But it happens *after* FOO is compiled with a full (as published by dependencies) set of libraries (i.e., link 'em all, then remove the useless ones). That cuts down the Depends (runtime requirements) but still means you need the full BuildDepends (in order to have the published flags work at compile-time). Generally speaking, using gtk+2-dev entails pkgconfig (in order to publish flags), glib2-dev, atk1, cairo, glitz, fontconfig2-dev, freetype219, pango1-xft2-ft219-dev, x11-dev, and maybe pixman and/or libgettext8-dev. Take a look at the various gnome packages to see some standard incantations (minimum versions for self-consistent stable gnome release level, etc.) dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink -m fix for gcc4x
On Thu, May 06, 2010 at 08:20:33PM +0200, Max Horn wrote: > > Am 06.05.2010 um 15:33 schrieb Alexander Hansen: > [...] > > > The trailing _STUB isn't handled by the test, which looks for DYLIB > > surrounded on either side by whitespace. > > Indeed. So, should the validator code be augmented to handle DYLIB_STUB, too? > It would be easy enough to do. Yes, please do it. Validator is supposed to be pretty strict, but even if this is just a warning not error (per someone's earlier email) it should be accepted if it's allowed and sane and proper here. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] wxgtk2.8-2.8.10-22 breakage?
On Tue, May 04, 2010 at 11:16:50PM -0400, Jack Howarth wrote: >Does anyone understand this breakage in wxgtk2.8-2.8.10-22 > under x86_64 fink? I am seeing... Sounds like the "Fwd: wxgtk2.8-2.8.10-22 in gnuplot (Snow Leopard, Fink 64 bit)" thread on fink-devel from a few days ago. Maintainer says he's testing the fix therein. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
On Mon, May 03, 2010 at 08:20:25AM -0400, Hanspeter Niederstrasser wrote: > On 05/01/2010 9:22 AM, David R. Morrison wrote: > >>> 1) Should packages marked as Restrictive be able to check mirrors if > >>> they can't find the source upstream? > >> > >> If the sources are legally redistributable and therefore mirror-able, > >> that sounds reasonable. > > > There are definitely cases in which no permission to distribute source > > has been given. That's why, when we set up distfiles, we extended the > > policy on non-distribution to include "not mirrored on our distfiles > > servers". > > Right, but this currently covers both no-binary-distribution and > no-binary-or-source-distribution licenses. Which is why I suggested > having a new Restrictive subvariant to allow the former license to be > have source mirroring by Fink. This also comes back to the first > suggestion in my original post: let the package search in mirrors for > the source, even if it's marked restrictive. If it really is > restricted, the distfiles backends will not mirror it and the package > fetch will 404 anyway. If it is available because of a non-restricted > variant (or say upstream gave permission to have it mirrored), then it > works. (this assumes distfiles is set up correctly vis a vis license > restrictions, and that distfiles and fink don't use the same code to > fetch sources) > > I realize that this takes coding, and I don't know Perl so I am in no > position to provide patches (or expect/demand immediate fixes from > others) so I'm looking at this more from a user experience point of > view, where sources can and frequently do disappear, usually through > download server reorganization, and that it can be frustrating for the > user For known cases where we have a source mirrored for "some other reason than the package itself" (i.e., some other package, or we somehow else picked in sometime in the past) and the proper upstream source goes away, can just change the .info Source to mirror:master: and it will go directly there. Not automatic (requires being told of problem and committing a fix), but solves the specific case. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] GObject introspection
On Mon, Apr 26, 2010 at 10:12:40AM -0400, Daniel Macks wrote: > On Mon, Apr 26, 2010 at 03:23:30PM +0400, Alexey Zakhlestin wrote: > > Hi. > > > > Is anyone working on gobject introspection? > > Seems like a lot of libraries need it these days (and even more will need > > it soon). > > > > I can create packages for these, but if it's in someones queue already I > > can wait :) > > > > I need introspection support enabled for libgda (libgda 4.0.8 added > > introspection support) and am going to use it for creating midgard-project > > packages, which depend on libgda. > > [...] it will need serious work [...] gobject-introspection-0.6.10 build fails. Looks like its internals only know how to use ldd (the linux/ELF dynamic-link scanner) not otool (darwin's moral equivalent). The ability to read library linking information seems pretty important for an introspection tool, so this may be hopeless on OS X for now. Here's the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=606686 The action seems to be in giscanner/shlibs.py, where a parser needs to be created for the output of 'otool -L'. Anyone's help welcome here... dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] %N-shlibs (>= %v-%r)
On Wed, Apr 28, 2010 at 09:44:02AM -0400, Alexander Hansen wrote: > On 4/28/10 9:22 AM, Jack Howarth wrote: > > One piece of legacy coding left in the gcc4x packages > > which perplexes me is the use of... > > > > %N-shlibs (>= %v-%r) > > > > instead of... > > > > %N-shlibs (= %v-%r) > > > > for the Depends field of the main gcc4x package. Was there > > a bug in fink at some point that required the use of >= > > rather than =? I was going to change that as well but > > wanted to make certain there wasn't some obscure reason > > for that particular conditional. > > Jack > > > Convenience, possibly. The bug hasn't gone away. > > If the main package has Depends: %N-shlibs (= %v-%r), if a user has the > main and -shlibs installed they can't update to a new version-revision > in one step. The build will be performed, but fink won't install the > update: the new -shlibs has to go in first, and the old main package > will complain because of the %v-%r mismatch. But afterwards apt-get is > perfectly happy to figure out how to do the upgrade. > > I'd argue that (= %v-%r) is a safer option. I think fink's SysState fixed that bug. If you have installed the pair with %N:Depends:%N-shlibs(=%v-%r) and you "fink update %N-shlibs" to a newer version or revision, fink should recognize that 1) this will break the dependency of the installed %N, and 2) that simultaneously updating %N will solve he problem, and so do it that way. It may not be able to handle looking more deeply into the dep tree and it might not work if %N and %N-shlibs are not in the same .info file (two splitoffs, or one splitoff of another)...can't remember how robust the thing is. For libraries, the = actually prevents breakage of symlinks. For example, foo1-dev has libfoo.dylib->libfoo.1.0.1.dylib, with libfoo.1.dylib (the install_name) and libfoo.1.0.1.dylib in foo1-shlibs. Now comes a new package version (same install_name) that has libfoo.1.0.2.dylib istead of libfoo.1.0.1.dylib. "Just" updating the -shlibs package (allowed by a >= dependency) breaks the libfoo.dylib symlink, which also breaks building of any package that "BuildDepends:foo1". Using = means they stay in sync. Using = also means the .h and other compile-time files and tools are perfectly (self-consistent set) matched to the .dylib. I don't know what happens if gcc (the front-end programs) from one %v of a gcc suite are used with the libraries (-shlibs package) from a different one. No idea if there are symlinks and other pointers that break (recent libtool2 uses libfoo.dylib->libfoo.1.dylib not ->.1.0.whatever). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Wed, Apr 28, 2010 at 09:15:18AM -0400, Jack Howarth wrote: > Daniel, >Why do you say that 'info /sw/share/info/gcc-fsf-4.5' is > need? With my currently proposed packaging a simple > 'info gcc-fsf-4.5' is sufficient to find the renamed info > file in /sw/share/info with or without the main gcc45 > symlink package installed. As mentioned several email ago, xrefs from one .info to another. For example, in the "gcj" info page in the "Invoking gcj" node is a link to the "Option Summary" node of the "gcc" info page. You have gcj at gcj-fsf-4.5 and gcc at gcc-fsf-4.5. If I don't have gcc4.5 installed, then I only have gcc-fsf-4.5 (not gcc) and the link is broken. If I have gcc4.4 (or any "other than 4.5 gcc") installed, then the link goes to *that* gcc, not the 4.5 one (i.e., gcj-fsf-4.5 is sending me to a symlink to gcc-fsf-4.4 rather than gcc-fsf-4.5). That's the problem I'm trying to solve. If the documentation isn't self-consistent (from the perspective of the reader), it's not useful/usable. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Wed, Apr 28, 2010 at 12:51:36AM -0400, Jack Howarth wrote: > Daniel, >I noticed that when --program-suffix=-fsf-4.5 is invoked > that the man1 and man3 manpage names are automatically appended > with the -fsf-4.5 suffix but not the info pages. I figured this > was an omission so I completed the renaming for man7 and the > info pages. Also, now that multiple gcc4x-compiler packages can > co-exist, won't it be confusing if each has the same > info file names (without a -fsf-4.x suffix)? In that case, > how would the user be sure that that correct copy of > gcc-4.info which they are being shown is the one from > the particular version of gcc that they are trying to > work with. With info files having the -fsf-4.x suffix > there can be no such confusion. > Jack > ps In particular, say the user needs a gcc 4.5 info > page to read about the LTO options. We need to make > certain that the correct one can be easily selected. 'info /sw/lib/gcc4.5/info/gcc' or some similar command. Just like he would need 'info /sw/share/info/gcc-fsf-4.5'. I didn't change the "unversioned" names (symlinks) in /sw/share/info, so installing the gcc4.5 package (which contains them) would still allow 'info gcc' to give the self-consistent ones for gcc4.5. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 11:00:11PM -0400, Daniel Macks wrote: > On Tue, Apr 27, 2010 at 03:35:06PM -0400, Jack Howarth wrote: > > > > # Rename info files with -fsf-4.5 suffix. > ># Add symlinks for info files under old names. > > SplitOff2: << > > Package: %N-compiler > > Files: << > > share/info/*-fsf-4.5.info > > << > > << > > InfoDocs: cp-tools-fsf-4.5.info cpp-fsf-4.5.info cppinternals-fsf-4.5.info > > gcc-fsf-4.5.info gccinstall-fsf-4.5.info gccint-fsf-4.5.info > > gcj-fsf-4.5.info gfortran-fsf-4.5.info libgomp-fsf-4.5.info > > I'm not sure there is a use in having *-fsf-4.5.info files. They are > not indexed and generally visible unless the gcc4x package is > installed (InfoDocs entries). And although they can be accessed if you > know their special name, they contain hyperlinks to each other that do > not know about these special names (for example, a link in gcj-fsf-4.5 > for "gcc" likely points to gcc not gcc-fsf-4.5). Instead, you could > put all the files *with their original filenames* (so xref's don't > break) in a directory named for the package. For example, > %p/lib/gcc4.5/info (living in the -compilers splitoff package). The > xrefs would resolve self-consistently among this specific gcc version > because they are pointing to the correct filename "in the same > directory". Bonus: you can just change --infodir= instead of having to > do a manual loop over all the filenames to move them. Bonuser: two fewer places you have to enumerate actual filenames (fewer things to deal with manually). --infodir means you omit this: # Rename info files with -fsf-4.5 suffix. and this: # Add symlinks for info files under old names. infofiles="cpp gcc" for infofile in $infofiles ; do ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile-4.info done infofiles="cp-tools cppinternals gccinstall gccint gcj gfortran libgomp" for infofile in $infofiles ; do ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile.info done becomes something like this: # Add symlinks for info files under old location. mkdir %i/share/info for infofile in `cd %i/lib/gcc4.5/info; ls`; do ln -s %p/lib/gcc4.5/info/$infofile %i/share/info/$infofile done dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 03:35:06PM -0400, Jack Howarth wrote: > > # Rename info files with -fsf-4.5 suffix. ># Add symlinks for info files under old names. > SplitOff2: << > Package: %N-compiler > Files: << > share/info/*-fsf-4.5.info > << > << > InfoDocs: cp-tools-fsf-4.5.info cpp-fsf-4.5.info cppinternals-fsf-4.5.info > gcc-fsf-4.5.info gccinstall-fsf-4.5.info gccint-fsf-4.5.info gcj-fsf-4.5.info > gfortran-fsf-4.5.info libgomp-fsf-4.5.info I'm not sure there is a use in having *-fsf-4.5.info files. They are not indexed and generally visible unless the gcc4x package is installed (InfoDocs entries). And although they can be accessed if you know their special name, they contain hyperlinks to each other that do not know about these special names (for example, a link in gcj-fsf-4.5 for "gcc" likely points to gcc not gcc-fsf-4.5). Instead, you could put all the files *with their original filenames* (so xref's don't break) in a directory named for the package. For example, %p/lib/gcc4.5/info (living in the -compilers splitoff package). The xrefs would resolve self-consistently among this specific gcc version because they are pointing to the correct filename "in the same directory". Bonus: you can just change --infodir= instead of having to do a manual loop over all the filenames to move them. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 10:40:35PM +0200, Martin Costabel wrote: > Jack Howarth wrote: > > JF, > > Okay. Untested gcc45-x86_64.info with a gcc45-compiler > > splitoff. Still needs the libffi update-alternatives. > > To me, this one looks OK (untested, of course), contrary to the > description in one of dmacks' latest messages (the one with *1, *2 etc), > which even after reading it 3 times still looks really backwards. Crapola yeah, cut'n'pasted the wrong line! "compiler in lib/gcc4.x *1" is what should have gone in gcc4x-compiler. Glad the convoluted explanation was clear enough that at least the other screwup was noticed:( dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 12:50:43PM -0400, Jack Howarth wrote: > On Tue, Apr 27, 2010 at 06:20:41PM +0200, Jean-Fran?ois Mertens wrote: > > > > On 27 Apr 2010, at 18:07, Jack Howarth wrote: > > > >> On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-Fran?ois Mertens wrote: > >>> > >>> On 27 Apr 2010, at 17:43, Jack Howarth wrote: > >>> > >>>> To recap, the problem with using a single package with split-off > >>>> strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ > >>>> Replaces on the older gcc4x packages which have overlapping files. > >>>> This is because the older gcc4x packages can't know that they are > >>>> are able co-exist with the newer gcc4x package and will Conflict > >>>> with > >>>> it. > >>>> This causes dependency failures for fink in the absence of an > >>>> explicit > >>> > >>> Jack _ I told you since the beginning (Re: co-existing gcc4x > >>> packages, > >>> april 25) that it would be much simpler to keep the name gcc45 for > >>> the > >>> splitoff containing the symlinks _ This way, no need to bother other > >>> pkgs, and you > >>> avoid the trouble you mention.. > >>> > >>> Jean-Francois > >> > >> JF, > >> Isn't that going to be considered a massive violation of fink > >> policy for shared library packages? > > I don't see why.. > >> It's sort of like using > >> update-alternatives for manpages and info files. > > http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg19967.html > > > ??? > >> It can be done > >> but many here will find it more repulsive than having package > >> maintainers update the BuildDepends. > > Again, I don't see why .. > > http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#sharedlibs > > The approach you describe has never been implemented before and I > wouldn't want to be the first unless the core maintainers were okay with it. It's approximately how perl is set up. We have perlXXX as the mutually-exclusive (generic filenames in default locations) package, with perlXXX-core as the concurrently-installable (files or directories named specifically for the "XXX") back-end. Other packages that are specific to a certain perl version have a dependency on the perlXXX-core they want and access it as (for example) bin/perlX.X.X. A package that would really need "bin/perl, as a certain perl version" would have a dependency on perlXXX itself. (other concerns snipped, some addressed others in agreement per my other email a few minute ago--things are laggy here:(. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-Fran?ois Mertens wrote: > > On 27 Apr 2010, at 17:43, Jack Howarth wrote: > > > To recap, the problem with using a single package with split-off > > strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ > > Replaces on the older gcc4x packages which have overlapping files. > > This is because the older gcc4x packages can't know that they are > > are able co-exist with the newer gcc4x package and will Conflict > > with it. > > This causes dependency failures for fink in the absence of an explicit > > Jack _ I told you since the beginning (Re: co-existing gcc4x packages, > april 25) that it would be much simpler to keep the name gcc45 for > the splitoff containing the symlinks _ This way, no need to bother > other pkgs, and you > avoid the trouble you mention.. That is the same layout/solution I was suggesting, which I think Jack read backwards from the way I tried to describe. For example: Currently: gcc4x: Conflicts/Replaces all other gcc4x Depends: gcc4x-shlibs contents: compiler in lib/gcc4.x/ *1 info/manpages in share/ *1 symlinks from bin/ to lib/gcc4.x/ *2 splitoff:gcc4x-shlibs *1 are the generic-name/collisions among different gcc4x that prevent concurrent installation. It's the "default compiler in the standard visible location". *2 are the actual compilers, in a subdir that is specific/named for each different gcc4x package I and I think jfm are suggesting moving *2 into a new package. gcc4x: Conflicts/Replaces all other gcc4x Depends: gcc4x-compiler contents: compiler in lib/gcc4.x *1 info/manpages in share *1 splitoff:gcc4x-compiler Replaces: gcc4x *3 Depends: gcc4x-shlibs contents: symlinks in bin to lib/gcc4.x splitoff:gcc4x-shlibs *3 is so that user can upgrade cleanly from the old gcc4x package...allows new package to overwrite same-named files in old package that are now supposed to be in new/different package. Packages that currently have a dependency on gcc4x and rely on that to supply a compiler in bin/ (i.e., the default PATH), well, that's still true. And the manpages and texinfo files that are in the default doc sets are in that same package. All the "default" stuff is a self-consistent set in a single package. Obviously you can't "default" to more than one gcc4x at a time... But now, all the gcc4x-compiler packages are the actual compilers, and because they are each in their own subdir in lib/, they can all be installed concurrently. If a package really wants to, it can access them there (adjusting its PATH or using absolute pathname to ignore the default PATH and therefore not caring what gcc4x "default" package--if any--is installed). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Could not resolve inconsistent dependencies
On Mon, Apr 26, 2010 at 10:49:03AM -0400, Jack Howarth wrote:
>I should also have added that when I tried to
> add...
>
> Conflicts: gcc42 (<= 4.2.4-1002), gcc43 (<= 4.3.4-1000), gcc44 (<=
> 4.4.2-1000), gcc45 (<= 4.5.0-1000)
>
> alone to the main gcc46 package, this produced the error...
>
> fink install gcc46
> Password:
> Information about 8703 packages read in 2 seconds.
> The following package will be installed or updated:
> gcc46
> Reading buildlock packages...
> Could not resolve inconsistent dependencies!
>
> Fink isn't sure how to install the above packages safely. You may be able to
> fix things by running:
>
> fink scanpackages
> sudo apt-get update
> sudo apt-get install gcc46=4.5.999-20100423
>
> Failed: Fink::SysState: Could not resolve inconsistent dependencies
>
> I think having this work in fink is the only way to solve
> the problem of converting from a two-way to a three-way split for
> gcc4x. Since the old two-way packages won't know that the gcc4x
> main package from the newer three-way packages doesn't conflict,
> we have to have...
>
> Conflicts: gcc42 (<= 4.2.4-1002), gcc43 (<= 4.3.4-1000), gcc44 (<=
> 4.4.2-1000), gcc45 (<= 4.5.0-1000)
>
> in both the gcc4x and gcc4x-bin split-off for the new three-way
> packages (such that the older gcc4x packages are always
> deinstalled when either the gcc4x or gcc4x-bin packages of
> the new three-way split is installed.
>Any idea why adding the Conflict to gcc4x in the new three-way
> confuses fink so badly (instead of just forcing the older gcc4x
> package to deinstall)?
Conflicts:foo only forces-out foo if foo is also listed in Replaces.
One cleaner solution would be to have the gcc4x packages remain the
directly-available binaries (generic names in PATH) and put the
hidden/buried ones in a new package-name ("gcc4x-compiler"?). That way
the gcc4x would remain mutually-exclusive and the same "they all
conflicts/replaces each other" as now, so no new upgrade headache for
the new layout. Someone previously mentioned that this approach would
also avoid having to fix every existing package that expects a
dependency on gcc4x to supply the compilers in PATH. What is the
advantage to any advantage to changing that expectation by switching
to the the gcc4x-bin layout idea as you have envisioned?
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] GObject introspection
On Mon, Apr 26, 2010 at 03:23:30PM +0400, Alexey Zakhlestin wrote: > Hi. > > Is anyone working on gobject introspection? > Seems like a lot of libraries need it these days (and even more will need it > soon). > > I can create packages for these, but if it's in someones queue already I can > wait :) > > I need introspection support enabled for libgda (libgda 4.0.8 added > introspection support) and am going to use it for creating midgard-project > packages, which depend on libgda. It's been on my back-burner for a long time, never had a need for it and upstream kept breaking things because shared-library tools on OS X are different than on linux. I can take a look in a couple of days--I'm nearly finished the GNOME2.28 sweep. Feel free to get started on it though...I don't actually know its current state or viability. If it works out-of-the-box for, may as well submit a package and save me some time; if it doesn't work easily, at least I'll know that it will need serious work (and/or you might have some good solutions, I don't have any need to own this package:) dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] libffi-3.0.9-2 self-test failure 10.4/ppc
Test Run By root on Tue Apr 20 11:18:54 2010 Native configuration is powerpc-apple-darwin8.11.0 === libffi tests === Schedule of variations: unix Running target unix Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/build.build/libffi-3.0.9-2/libffi-3.0.9/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sw/build.build/libffi-3.0.9-2/libffi-3.0.9/testsuite/libffi.call/call.exp ... FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0 res: 5 7.0 res: 4 , should match 7.0 ? res: 4 ? 7.0 ? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is -0.0 res: 5 7.0 res: 4 , should match 7.0 ? res: 4 ? 7.0 ? res: 4 FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is -0.0 res: 5 7.0 res: 4 , should match 7.0 ? res: 4 ? 7.0 ? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is -0.0 [... and many more] === libffi Summary === # of expected passes1614 # of unexpected failures10 # of expected failures 10 # of unsupported tests 15 Previous version (3.0.5-1) had no failures. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
On Sun, Mar 21, 2010 at 05:35:37PM +0100, Vincent Beffara wrote:
> > Ooh wait, is "ipe" the headers used for building against the
> > "ipeX-shlibs" package? If so, the headers package must never change
> > which -shlibs it's associated with. Otherwise, other packages that
> > want to use ipe won't be able to control or know which library they
> > get.
>
> No, 'ipe' is a GUI for drawing figures. It relies on a shared library
> which it is essentially the only package to use, but can be used to
> extend it through plugins ('ipelets'). There are headers associated to
> it, which I will of course put in ipe7-dev. A plugin package would
> depend on the ipe7-shlibs package and build-depend on ipe7-dev (and the
> plugin would be very likely to need deep rewriting should the major
> version ever increase).
Excellent!
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
On Sun, Mar 21, 2010 at 04:49:11PM +0100, Vincent Beffara wrote: > > > For consitstency, I chose to use libipe.7.dylib as install_name > > > and so ipe7-shlibs as corresponding package name. The actual > > > software does not really do anything about it (without a patch the > > > install_name ends up being ../../build/src/libipe.so.5.0.10 or > > > something like that). > > > > I'd recommend being consistent with _upstream_ then, and setting the > > install_name as libipe.5.dylib. > > Ooops, I meant libipe.so.7.0.10 of course ! > > > > BTW, if ipe7-shlib is a splitoff of ipe, and there is an upgrade of > > > ipe upstream with a different major version, and I end up having > > > ipe8-shlibs as a splitoff of a new version of ipe, then nobody can > > > build ipe7-shlibs anymore, which sounds a little bad. So I will go > > > for ipe7 as package name. > > > > No, it should still be possible to build ipe7-shlibs. One way to do it > > is to have the version number on the .info file. > > Ah, I hadn't thought of that. So I do ipe7.info declaring ipe (with > version 7.x.y) and ipe7-shlibs as a splitoff, and if ever necessary > I will do ipe8.info declaring ipe again (with version 8.x.y) and > ipe8-shlibs as a splitoff, and Fink will not be confused by two > descriptions of ipe in two different files. That makes a lot of sense, > actually. Ooh wait, is "ipe" the headers used for building against the "ipeX-shlibs" package? If so, the headers package must never change which -shlibs it's associated with. Otherwise, other packages that want to use ipe won't be able to control or know which library they get. imagemagick is an interesting example because it has a set of runtime programs in a package whose name never changes (because "which library those programs use" is hidden from the user of the programs) and then separate headers and libraries packages, whose names are tied to each other and do change when the install_name does. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
On Fri, Mar 19, 2010 at 12:19:47PM -0400, Alexander Hansen wrote: > On 3/19/10 11:42 AM, Vincent Beffara wrote: > > > > - about the package name. I would be tempted to simply use 'ipe' with > > version 7.0.10 but 'ipe7' is an option as well, which would match the > > previous one. What is the policy on that, if there is one ? > > > > The original package is named 'ipe6' because it builds shared libraries > as well (ipe6-shlibs). I'd recommend making the library package > ipe7-shlibs for consistency, but you're welcome to call the main package > "ipe". More critically, what is the install_name of the library? If it is still libipe.1.dylib (same as ipe6) then package-name remains the same. If it changes, package-name must change. No clue why ipe_6_ was chosen for _1_.dylib, but now we're stuck with that for it, and you can make your own choice about what new package-name to use if that filename will be different. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Help test new gnome with fontconfig and friends
I've got GNOME2.28 nearly ready to go to unstable. One major set of changes is that it revives fink's own fontconfig2 library (vs falling through to x11's) and makes fink's xft2 shared (had been static-only). This should solve a weird issue where packages tended to link to x11's xft2 and/or fontconfig (which link to x11's freetype) but also link to fink's freetype. So now it's possible to use fink-supplied libs self-consistently starting at freetype and going all the way up the dep tree. And gnome core libs strictly enforce that in themselves. Now that .la data is cleared, making these newly invoked in low-level deps does not propagate all up the tree (no additional or different inherited builddepends), so nothing that wasn't broken before should become suddenly broken. Also as a result of .la cleaning is a general reduction of builddepends to only those that are actually directly used, which should make users and packagers of gnome-based packages slightly happier. All packages are also checked to make sure they weren't relying on that .la data (upstream sloppiness in linking), so some existing build failures in stable/unstable are fixed. This is totally untested on 10.[56], i386, or x86_64 and I don't know how (if at all) the fontconfig2 or xft2 packages need to be adjusted for these OSX's x11 variations. Please test and let me know! cvs -d:pserver:anonym...@fink.cvs.sourceforge.net:/cvsroot/fink co experimental/dmacks/finkinfo/gnome-2.28 dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] db44 vs. db47 vs. db48
On Tue, Mar 16, 2010 at 11:29:24AM +0100, Max Horn wrote: > Am 15.03.2010 um 23:58 schrieb Daniel Johnson: > > > > As a follow up, I checked to see what db* is being used. [...] > As for the rest: It sure would be nice if more of those could be converted to > newer versions. > > > > db3: > > wsmake Mine. Would need hacking to get buildable with current db4* API. Long-dead upstream. If that's the blocker, I have no objection to Distribution:10.4,10.5 restriction. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libgettext3 vs. libgettext8: Which one to use?
On Tue, Mar 16, 2010 at 11:39:35AM +0100, Max Horn wrote: > [...] > > E.g. our old "gettext" package is not even marked obsolete, and if I was > looking for gettext, well, it would be the first thing for me to see... :) > Don't get me wrong, I am not asking for it to be marked as such. I just want > to point out that it's not trivial for a maintainer to figure out that they > shouldn't use it. Nit: "an old libversion" is not a candidate for the fink-obsolete-packages mechanism because nothing literally and transparently replaces it. But could definitely add DescUsage (that nobody probably reads). > IMO we have a small communication problem there. We want people to make a > switch, but we are not loudly telling them to do so. Granted, I don't believe > we'll see a huge rush of maintainers changing their packages, but if we > aren't even trying to get them to do this, we can't complain when they aren't > doing anything :-). > > So, how about adding a Wiki page / a page in the packaging docs, which tells > people to use libgettext8 "when appropriate", or at least libgettext3, and to > avoid gettext? > Maybe there are more packages, and then they should be mentioned there, too? > I am willing to write such a page, if it is deemed a good idea. I'd tend to > put it on the wiki, at least at first, so that people can edit the text until > it's good. Yes yes! I'm sure there are other "best practices for maintainers" passed down via the #fink minstrels and that should be written down somewhere. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink-obsolete-packages annoyance
On Tue, Mar 16, 2010 at 11:43:31AM +0100, Max Horn wrote:
> Am 15.03.2010 um 17:41 schrieb Daniel Macks:
> >>Max:
> >>
> >> The other alternative would be to implement the ancient idea of an
> >> "RuntimeDepends" (or "InstallDepends", or whatever) field. I.e. a field
> >> which is kind of the complement of BuildDepends: Any dependencies
> >> declared in it only count when installing the package, but do *not* count
> >> towards build dependencies.
> >> Then, fink-obsolete-packages could be a RuntimeDepends. I vaguely recall
> >> that in the past, we had other cases which might benefit from such a field
> >> (and the analogous RuntimeConflicts / InstallConflicts field), although
> >> the details elude me right now.
> >> It would be quite easy to add this field, but the fact that it doesn't yet
> >> exists might indicate that it's a bad idea for some reason I am not seeing
> >> right now, or that it's simply not useful enough to warrant adding it (and
> >> thus bloating the .info syntax further).
> >
> > I still love this feature idea--always seemed like a very rare need to
> > have it though (this is one of the few I can think of where we have a
> > runtime requirement that isn't also a buildtime one). There are some
> > hooks in the engine already for it (related feature: actual Shlibs
> > dependency support), but I assume that because it hasn't been used
> > other things have been changed and may need hacking to respect it.
>
> So... if somebody were to write a patch which adds RuntimeDepends, it would
> have a fair chance of being accepted?
> Of course, in order to use the field, one would have to also add a Depends on
> the appropriate fink version, and hence wait some time till that version is
> available everywhere, but you gotta start it at some point, right? :)
Right. There's a generic validator test for this sort of thing too
("require a dependency on a certain minimum fink if some condition is
met") so it will be easy (assuming maintainers run val:) to make sure
the dep is set if the feature is used. Analogous example: PatchFile.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libgettext3 vs. libgettext8: Which one to use?
On Mon, Mar 15, 2010 at 11:07:05AM -0400, Alexander Hansen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 3/15/10 10:58 AM, Max Horn wrote: > > > > Am 15.03.2010 um 15:42 schrieb Alexander Hansen: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 3/15/10 10:39 AM, Max Horn wrote: > >>> Hi there, > >>> > >>> can somebody advise me on libgettext3 vs. libgettext8 -- in particular, > >>> for new packages (and when revising existing packages of mines), should I > >>> stick with libgettext3, or are we going to gradually migrate to > >>> libgettext8 ? Is there any kind of policy on this? I searched for this > >>> but could find nothing, so any pointers would be appreciated. > >>> > >>> > >>> Cheers, > >>> Max > >> > >> There's nothing formal that I know about. I think the current practice > >> is now to update to libgettext8, when appropriate, and to have new > >> packages use it (again, when appropriate), so that we can gradually > >> deprecate gettext3. > > > > And what does "when appropriate" mean? > > The package builds. And also that we aren't doing sweeps and making updates *just* for this issue (rev-up and force rebuild to migrate), but rather when updating packages for some other reason, "may as well also switch" at that point. For example, next gnome-core suite will be completely libgettext8. > > Otherwise, I don't think it'll happen in the next couple years. For > > example, I only noticed the existence of libgettex8 by chance. So if we > > don't announce it to our package devs, they hardly will attempt to make the > > transition, right? :-) We still have a lot of packaging using the old-old "gettext" too:( Many of those are not being carried beyond 10.5, but others... This would be a good heuristic to check for long-abandoned packages that might be bit-rotten or in need of a quick update for many reasons. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink-obsolete-packages annoyance
On Mon, Mar 15, 2010 at 03:49:16PM +0100, Max Horn wrote: > Hi there, > > so last night I finally made the move from OS X 10.5 to 10.6. As part of > that, I reinstalled Fink from scratch. This went mostly fine, but there were > a couple of annoyances, one of which I want to describe here: > > Several packages, among them libcurl4 and coreutils (maintainers CCed), > forced me to install the fink-obsolete-packages package -- even though I > installed nothing that was obsolete. The reason for this is of course that > these packages have obsolete splitoffs, which depend on > fink-obsolete-packages and hence pull in fink-obsolete-packages. > > This is not very nice, IMO. For me personally it's easy to determine that the > dependency on fink-obsolete-packages is only an unwanted side effect and I > just removed it after those packages installed. But for users in general, > this seems like a negative experience... they install a brand new package and > suddenly see something about obsolete stuff being installed. Not nice :/. > > I am not sure what the best way is to resolve this, but I hope that it can be > resolved ... one idea that comes to mind is forbidding splitoffs to depend on > fink-obsolete-packages, i.e. enforcing a policy where either all splitoffs > (including the master splitoff) in an .info file depend on > fink-obsolete-packages, or none. In this particular case that would mean that > the obsolete splitoffs needs to go to separate .info files. That seems easy > enough to do, however, I am not sure whether this couldn't cause some other > weird dependency side effects, when upgrading from old package versions... Lots of weird dependency problems (usually upgrade deadlocks) have happened when I tried that in some places. One common case is an existing foo:depends:foo-split(=%v-%r) when foo-split becomes obsolete and moves from foo.info to foo-split.info. Fink seems smart enough to do atomic update of multiple packages in a single .info. But in separate .info, if foo-split is in the upgrade pile first it will fail because upgrading it would break the existing dep of foo on it. dan > The other alternative would be to implement the ancient idea of an > "RuntimeDepends" (or "InstallDepends", or whatever) field. I.e. a field which > is kind of the complement of BuildDepends: Any dependencies declared in it > only count when installing the package, but do *not* count towards build > dependencies. > Then, fink-obsolete-packages could be a RuntimeDepends. I vaguely recall that > in the past, we had other cases which might benefit from such a field (and > the analogous RuntimeConflicts / InstallConflicts field), although the > details elude me right now. > It would be quite easy to add this field, but the fact that it doesn't yet > exists might indicate that it's a bad idea for some reason I am not seeing > right now, or that it's simply not useful enough to warrant adding it (and > thus bloating the .info syntax further). I still love this feature idea--always seemed like a very rare need to have it though (this is one of the few I can think of where we have a runtime requirement that isn't also a buildtime one). There are some hooks in the engine already for it (related feature: actual Shlibs dependency support), but I assume that because it hasn't been used other things have been changed and may need hacking to respect it. Conflicts actually is not parallel to the Depends behavior: Conflicts is only a runtime thing, not implicitly also included in BuildConflicts. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] db44 vs. db47 vs. db48
On Mon, Mar 15, 2010 at 03:55:15PM +0100, Max Horn wrote: > > This is certainly not a huge issue, but I still found it quite disturbing. Do > I really need db44(-aes), db47(-aes) and db48(-aes) all at the same time? > Hrmm... So I looked a bit, and discovered the following: > > * svn, libaprutil.0-* (and python26) depend on db47(-aes) > and svn depends on libapr.0-dev > > * cyrus-sasl2 and openldap24 depend db48-aes > and svn depends on cyrus-sasl2-dev and openldap24 [...] > * python25 depends on db44(-aes) > and unfortunately xchat depends on python25 > > I'll look into changing xchat to allow newer python, thus hopefully taking > care of the db44 part. > > But maybe we can also change our python25 to use db44? Can we change [...] > python26 to use db48 instead of db47? python25.info DescPackaging:Cannot use db47 (or higher) python26.info:DescPackaging:Cannot use higher than db47 There are interface changes of some sort. I don't think anyone's looked more deeply than trying and failing to compile. > Can we change svn, libaprutil.0, [...] to use db48 instead of db47? I talked to thesin a week or two ago, he said he was working on a new round of libaprutil and relates packages. I assume svn simlpy inherits whatever apr has. > I am not sure whether this would cause binary compatibility issues; but if it > is sanely possible, it would be preferable to use a single db4x version for > all these packages, wouldn't it? Two-level namespace *should* encapsulate things within each lib, but if one lib passes a struct or database to another, there could be problems. With the loss of .la data (due to deleting those files or installing dpkg-base-files) there is less propagation of library dependencies that are not actually used, so it's possible that (for example) svn doesn't need db4* at all itself. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Framework linker flag in Compile script
On Tue, Mar 02, 2010 at 06:40:46PM +0900, mpsuz...@hiroshima-u.ac.jp wrote:
> Dear Peter,
>
> On Wed, 24 Feb 2010 10:02:32 -0600
> "Peter O'Gorman" wrote:
> >On 02/24/2010 02:42 AM, suzuki toshiya wrote:
> >> B. What should be fixed is GNU libtool, not library packages.
> >>
> >> There would be an opinion: the current GNU libtool behaviour:
> >> - "-framework XXX" is copied to .la file.
> >> - "-Wl,-framework,XXX" is NOT copied to .la file.
> >> is inconsistent, if this inconsistency is the reason to
> >> change from "-Wl,-framework,XXX" to "-framework XXX",
> >> what should be fixed is primarily GNU libtool inconsistency,
> >> changing in the side of library package is not good idea.
> >
> >If it is your package, and you know that you're going to use
> >libtool-2.2.x, then don't quote the -framework XXX flag with -Wl, and it
> >will get put into the .la file.
> >
> >>
> >> # Although I've not discussed with GNU libtool maintainers
> >> # about this issue, I don't hesitate to write a patch for
> >> # consistent behaviour.
> >
> >Feel free to post a patch to libtool-patc...@gnu.org (please post a
> >patch against the current development version, which you can either
> >fetch from git or the daily snapshot, see
> >http://www.gnu.org/software/libtool for info on both. I believe there is
> >currently a test case for -framework flag handling, so if you do post a
> >patch, please also expand on the test case. I will review and commit the
> >patch if appropriate.
>
> Thank you for comment. Just I've submitted a patch to pick
> "-framework" options from -Wl, and -Xlinker flags. I think
> I received no comment from the viewpoint of Fink maintainers.
> I want to hear the comments about my proposal checking the
> content of "-Wl," quoted flags.
>
> http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg1.html
>
> Although I noted an opinion requesting the consistent behaviour
> between raw "-framework" versus quoted "-Wl,-framework",
> there can be an objection like:
>
> The latest GNU libtool's handling of raw -framework is good,
> but more longer time is needed to be populated broadly and
> agreed to be safe (e.g. Fink still provides freetype-2.1.4
> binary package, the version released on 2003). The preference
> to -Wl, quoted flag is based on its transparency. The proposed
> patch breaks its transparency (and disturbs long time testing),
> so it is not useful but harmful.
>
> I want to hear the comment from Fink maintainers about the
> detailed parsing of -Wl, quoted flags by GNU libtool.
What does this have to do with fink?
Fink just wants things to Work(tm), and our maintainers able to cope
with whatever packages do. We don't write libtool, we don't patch
libtool locally, we don't have fink-specific behavior. Fink is just a
perl-script that calls system("./configure --prefix=/sw && make") and
such. As idiosyncratic as libtool can be, it's easy to use it and get
something that works as long as the author of the package fink is
compiling actually uses libtool per its manual and doesn't subvert its
magic. If those authors are not using things "correctly for whatever
libtool they are distributing", that's their bug; fink folks just
whine about "they are distributing something broken" and hack around
it without really distinguishing blame to libtool vs the author who is
mis-using libtool.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] PostRmScript
On Tue, Mar 02, 2010 at 10:56:41AM +0900, BABA Yoshihiko wrote: > Hi, > > I added a line to qgis-mac.info: > PostRmScript: rm -rf %p/Applications/qgis%v.app > But this does not seem a good solution to me. > > I do this because, after I use qgis for a while, when I try to remove > qgis-mac, the .app directory stays for some files not supplied by the .deb > file. > This is perhaps because, as I used qgis, it modifies the contents of > qgis%v.app. (I know it is better if I could use /sw/var or something) What specific files is it finding there? Sometimes there is a way to supress them or else to have them created during InstallScript (i.e., be part of the .deb). > Another problem is, when I do `fink reinstall qgis-mac', I guess because of > PostRmScript, fink thinks it successfully installs qgis-mac, but it > disappears. According to the Debian package-script docs, postrm does run during an upgrade/reinstall (because the old/previous one is being rm'ed). There may be a way to distinguish upgrade/reinstall from actual "just remove". > I wonder if my PostRmScript is acceptable, or I should find a better way. No, because as you said, it doesn't work:) You could PreRmScript to remove the specific files that aren't in the .deb. By the time the removal happens, they are gone, so there are no "stray" (not owned by .deb) files. But this is really a hack. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How to Handle Version Numbers
On Sat, Feb 20, 2010 at 12:50:24PM -0800, David Lowe wrote: > On 17 Feb, 2010, at 7:09 PM, David Lowe wrote: > > > The version number i have used is "2.2.0-RC1", which is faithful to the > > upstream version. Obviously i need to be less faithful, but what is the > > suggested way to handle this? Would "2.2.0-rc1" cause any problems? > > I seem to run into a bit of bind. Changing from *RC1 to *rc1 allows > the info file to pass the maintainer validation test, but now the tarball > can't be fetched. Sourceforge is giving a 404 error when looking for > "freeciv-2.2.0-rc1.tar.bz2", it has "freeciv-2.2.0-RC1.tar.bz2". > > What i find even weirder is that i have the tarball already sitting in > my FetchAltDir [~/Downloads] and fink seems to only want to download a new > copy. Just for kicks, i renamed my local copy to be all lower case, but fink > keeps starting up curl. I'm using the Journaled/Extended file system, so > case shouldn't matter, right? > > Before i force move the tarball to /sw/src/ is there something else i > should look at? As you stated, the source is called *RC1 not *rc1, so obviously looking for *rc1 won't find a *RC1 file (or vice versa) no matter what directory you put it in. I suspect you are using %v in the Source: field of your .info file. You need to use "whatever upstream calls the source file" in that field (hardcode the version-string with "RC", for example) rather than relying on default if default doesn't match. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How to Handle Version Numbers
Those probably represent three version-segments (0.3501 means 0.35.01), so you would just have to hard-code the version used in the source URL rather than using %v. It's an old perl standard for allowing vstrings to be numerically sortable. dan On Fri, Feb 19, 2010 at 11:02:44AM -0500, Koen van der Drift wrote: > It gets even more interesting with perl modules. For instance for > Module-Build they go from 0.35 -> 0.3501 -> 0.3502 -> 0.36. I'm just > skipping the 0.350x ones, it would be a big mess otherwise :-) > > - Koen. > > > > > On Fri, Feb 19, 2010 at 9:09 AM, Alexander Hansen < > alexanderk.han...@gmail.com> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 2/19/10 12:24 AM, David Lowe wrote: > > > On 18 Feb, 2010, at 10:40 AM, Alexander Hansen wrote: > > > > > >> Or rather, 2.2.0 < 2.2.0-rc1 > > > > > > Oh, i guess i was being a bit myopic there. Thanks for pointing > > out my error. In any case, i wasn't planning on releasing my info file > > until FreeCiv had a final version. I should just be able to force a rebuild > > when that happens, right? > > > > > > On a related note, do i increment the revision number when going > > from 2.2.0-rc1 -> 2.2.0?? Or does the rc version not count since it only > > exists locally??? > > > > > > Sent from my MacBookPro > > > > > > "Watch out for that slicing machine," Tom said offhandedly. > > > > > The revision only matters for a particular version. When you update the > > version the revision can go back to 1. Or you can update it--it's > > pretty much arbitrary, as long as it always increases when the package > > is updated. > > > > The one place where the value really matters is when you need to force > > rebuilds when a user changes OS versions. In that case you'd want the > > 10.6 revision, say, to be quite a bit larger than the 10.5 revision > > (like 100 vs 1) so that the 10.5 packaging can be updated many times > > without overlapping the lowest 10.6 revision. > > > > - -- > > Alexander Hansen > > Fink User Liaison > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.10 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkt+m7IACgkQB8UpO3rKjQ+EngCdEd6vEQ6fFimrihodG54P+uXs > > M8AAnRmxeIkkCns1aqnzsnV+HUEvVQiI > > =5sHU > > -END PGP SIGNATURE- > > > > > > -- > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > ___ > > Fink-devel mailing list > > Fink-devel@lists.sourceforge.net > > http://news.gmane.org/gmane.os.apple.fink.devel > > Subscription management: > > https://lists.sourceforge.net/lists/listinfo/fink-devel > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > http://news.gmane.org/gmane.os.apple.fink.devel > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] How to Handle Version Numbers
On Thu, Feb 18, 2010 at 08:52:24AM -0800, David Lowe wrote:
> On 17 Feb, 2010, at 8:10 PM, Charles Lepple wrote:
>
> > On Wed, Feb 17, 2010 at 10:09 PM, David Lowe
> > wrote:
> >>The version number i have used is "2.2.0-RC1", which is faithful to
> >> the upstream version. Obviously i need to be less faithful, but what is
> >> the suggested way to handle this? Would "2.2.0-rc1" cause any problems?
> >
> > I forget if you are allowed to have an extra '-' (one that is not
> > being used to separate the version from the revision), but you might
> > want to consider how the final version number sorts relative to the RC
> > versions. See this URL:
> >
> > http://www.finkproject.org/doc/packaging/reference.php
> >
> > and search for "dpkg --compare-versions".
>
> Got it, thanks! "2.2.0-rc1" does sort higher than the currently
> available 2.0.5 version,
A related question is what will happen when this thing gets a stable
release? I assume the "2.2.0-rc*" are release-candidates leading up to
an eventual "2.2.0". In terms of sorting, 2.0.0 < 2.2.0-rc1, so if you
use "2.2.0-rc1" now you would have to alter the version of the stable
release ("2.2.0-rel" is a solution I've seen there). Not a problem,
just a heads-up.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Fri, Jan 29, 2010 at 10:09:43PM -0500, Hanspeter Niederstrasser wrote: > Charles Lepple wrote: > > The asciidoc package has a self-contained HTML generator, and "a2x", > > an everything-else generator that depends on Docbook and a number of > > related tools. Currently, the package has a 'Recommends' line for the > > a2x dependencies, but since Fink doesn't process the Recommends line, > > I figured it might be best to split that off into an asciidoc-a2x > > package with proper dependencies. I would also like the splitoff to be > > installed for users who are upgrading from the old unified package. > > > > Should I use "Replaces: asciidoc (<< 8.4.5-3)" in the a2x splitoff, or > > will that confuse the Fink dependency engine? (I seem to have a way of > > finding things that work well with apt/dpkg, but not necessarily with > > Fink.) > > Are you using the word 'splitoff' in the Fink sense of SplitOff within a > parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the > same package libfoo), or describing asciidoc-a2x as a totally separate > package independent of the rest of asciidoc? In the first case, people > building the new 'trim' asciidoc will still end up building asciidoc-a2x > and pulling its dependencies even if they don't install it (a price to > pay with SplitOffs. In the 2nd case, asciidox-a2x would probably Depend > on the new trimmed asciidoc, but the trimmed asciidoc would not care > whether asciidoc-a2x is around. > > A possible solution would be to make a new package (whether a self > standing package or a SplitOff of another depends on your reasons for > doing this) called asciidoc-base, which includes everything that is not > a2x, as well as another package (or splitoff) called asciidoc-a2x, and > then have the newer revision of the package 'asciidoc' Depends on both > those packages. This way someone with the old asciidoc will see the new > version and get both -base and -a2x automatically pulled in by the > dependency engine. New users will get the option of installing just > -base, just -a2x, or both. > > Package: asciidoc > Depends: asciidoc-base, asciidoc-a2x > Splitoff: << >Package: asciidoc-base >Depends: whatever >Conflicts/Replaces: asciidoc (<< 8.4.5-3) > << > Splitoff2: << >Package: asciidoc-a2x >Depends: asciidoc-base (presumably), other stuff >Conflicts/Replaces: asciidoc (<< 8.4.5-3) > << You only want Replaces in those two, not Conflicts, otherwise you have a deadlock during upgrade from old asciidoc: when installing new asciidoc, 1) old asciidoc is totally uninstalled, 2) new components are installed (now that the Conflicts pkg is not present), 3) new asciidoc is installed (now that its Depends are satisfied). But if an external package Depends:asciidoc, step 1 can't happen. > If you want to split a2x off because it pulls in too many random > Dependencies, then make SplitOff2 (-a2x) above be an entire new package > with its own .info file. This way, someone building just asciidoc-base > will not pull in all those dependencies. That sounds like a cleaner solution. Like it or not, fink is substantially a source distro right now, so dependencies of "splitoffs don't need" are still a burden. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Fri, Jan 29, 2010 at 10:58:51PM -0500, Charles Lepple wrote: > On Fri, Jan 29, 2010 at 10:09 PM, Hanspeter Niederstrasser > wrote: > > Charles Lepple wrote: > >> The asciidoc package has a self-contained HTML generator, and "a2x", > >> an everything-else generator that depends on Docbook and a number of > >> related tools. Currently, the package has a 'Recommends' line for the > >> a2x dependencies, but since Fink doesn't process the Recommends line, > >> I figured it might be best to split that off into an asciidoc-a2x > >> package with proper dependencies. I would also like the splitoff to be > >> installed for users who are upgrading from the old unified package. > >> > >> Should I use "Replaces: asciidoc (<< 8.4.5-3)" in the a2x splitoff, or > >> will that confuse the Fink dependency engine? (I seem to have a way of > >> finding things that work well with apt/dpkg, but not necessarily with > >> Fink.) > > > > Are you using the word 'splitoff' in the Fink sense of SplitOff within a > > parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the > > same package libfoo), or describing asciidoc-a2x as a totally separate > > package independent of the rest of asciidoc? > > I'm referring to a Fink SplitOff (same info file). > > > ?In the first case, people > > building the new 'trim' asciidoc will still end up building asciidoc-a2x > > and pulling its dependencies even if they don't install it (a price to > > pay with SplitOffs. > > The dependencies are runtime rather than build-time (that's why I have > gotten away with the Recommends field so far). > > I appreciate the explanation, but I am still curious about the > Replaces field - someone who is using a2x from the old unified package > shouldn't have it disappear out from under them as part of an upgrade > to a split package (independent of whether the split packages come > from the same info file, or two separate info files). Replaces is a file-level thing, it allows one package to overwrite specific files in another already-installed one. It does not cause that other package to be uninstalled unless you also specify Conflicts for it. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Bug in in mc install (10.5) and some others
On Fri, Jan 08, 2010 at 10:17:36AM +0100, Martin Costabel wrote: > Daniel Macks wrote: > []nd is > > > We obviously can't fix the original binary installer > > Read this as: "We have an old tradition of not fixing binary > installers." Nothing obvious there. It was even fixed in the apt repo for apt users, *many* months ago. Unfortunately the tradidion you note is also obvious. Feel free to roll us a bindist and we can work on fixing this problem. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Bug in in mc install (10.5) and some others
On Thu, Jan 07, 2010 at 08:06:19PM -0500, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/7/10 7:50 PM, DJam? Seddah wrote:
> > Hi Augusto,
> >
> > thanks for the tip, it did the trick but one thing which is just
> > killing me is why, why does fink need to recompile every single
> > package I want to install now that I got it updated ?
> > I just cannot understand why if the bug was known, the binary
> > distribution is still carrying the old fink ? Now, I have the feeling
> > on being in my first gentoo week...
> >
> > I know that fink is a communatary project with very few ressources and
> > it has to support I don't know how many configuration so i'm not going
> > to throw any stone to anyone of course, it's just that maybe things
> > shouldn't be that anal when it goes when updating fink : No, not
> > everything has to be recompile because the wrapper was updated...
> >
> > even the -b doesn't change anything..
> >
> >
> > Best anyway, enjoy your brasilian sun, we're freezing out here
> >
> > Djam?
> >
> >
>
> You're free _not_ to use "update-all". Fink will let you update
> packages (and their versioned dependencies) individually. That's one
> way to keep from having to compile a bunch of stuff.
>
> One exception is that a selfupdate with rsync or cvs will force the base
> packages to update; there's not really a way around that.
>
> As for the bug: I don't recall having seen a report of it, so perhaps
> nobody knew about it until now.
The "mc wants old libintl but misssing dependency on it" is old and is
(or at least was) well-known, along with the solution ("install
gettext"). We obviously can't fix the original binary installer, but
IIRC the dependency has been added in all updated distros a lng
time ago. That's why fink provides live distros: we fix bugs as we
find them:)
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem installing sbcl [Bug in dpkg?]
On Tue, Jan 05, 2010 at 09:39:45AM +0100, Martin Costabel wrote:
> Daniel Macks wrote:
> []
> > main/archives.c:tarobject() uses a static buffer to store a filename
> > during installation. Wanna guess the size of fnamebuf[]? Try bumping
> > it to something "much larger". Latest dpkg upstream still has this
> > same hardcoded size.
>
> This may even be legal, seeing that /usr/include/sys/syslimits.h has
>
> #define NAME_MAX 255 /* max bytes in a file name */
>
> I don't know if this number includes the path component or only the
> basename, though. The basename itself, even extended by "-dpkg-new", is
> only 244 characters.
The open(2) manpage says:
[ENAMETOOLONG] A component of a pathname exceeded {NAME_MAX} charac-
ters, or an entire path name exceeded {PATH_MAX} char-
acters.
> As buffer overflows do not always lead to crashes, this would explain
> the sort of non-deterministic behavior of the package.
>
> Anayway, I guess this should be treated as a bug in sbcl. It doesn't
> really need that outrageously named file, which only contains a URL
> redirection, anyway, and does not seem to be linked to by any of the
> other documentation files.
Sounds good to me.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem installing sbcl [Bug in dpkg?]
On Sun, Jan 03, 2010 at 11:09:09PM +0100, Martin Costabel wrote: > Daniel Macks wrote: > [] > >> This looks like dpkg is not able to handle files with a file name longer > >> than 256 characters. On the other hand, I don't understand why this bug > >> only shows up on 10.6/32bit and not on 10.6/64bit nor on 10.5/32bit. > > > > Also doesn't seem to choke on 10.4/ppc. Wonder if there is some static > > buffer used to hold a pathname? I have: > > > > /usr/include/limits.h:#define _POSIX_PATH_MAX 256 > > /usr/include/sys/param.h:#defineMAXPATHLEN PATH_MAX > > /usr/include/sys/syslimits.h:#definePATH_MAX 1024 /* > > max bytes in pathname */ > > > > The "paste" subprocess is in dpkg-deb/extract.c:extracthalf(), where I > > can't decipher the forking and stream processing that is used to read > > the .deb. Try a simpler dpkg-deb modes to make sure this is where it's > > choking: "dpkg-deb -c foo.deb" vs "dpkg-deb -X foo.deb /tmp". I think > > the actual archive reading is done with a system(tar) call, so that > > command (and its platform variations, and different fink-installed > > versions) could be another place to look for the root cause: > > > > dpkg-deb --fsys-tarfile foo.deb > archive.tar > > > > to extract the .deb filesystem archive and then try 'tar -xf > > archive.tar' with various different tar commands. > > All these command-line things work correctly for me. No crash and no > missing files. > > Two more data points: When running "fink install sbcl" or dpkg -k, after > the failure the file with the long name is actually installed. It is the > last one that is installed. The next one would be > Methods-common-to-all-streams.html, but it is not there. If one rune > install again, then the long file exists twice, once with a .dpkg-tmp > extension and once without. This should narrow down the point where the > crash happens. > > There is also a crash report: > > > Exception Type: EXC_CRASH (SIGABRT) > > Exception Codes: 0x, 0x > > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > > > > Application Specific Information: > > __abort() called > > > > Thread 0 Crashed: Dispatch queue: com.apple.main-thread > > 0 libSystem.B.dylib 0x90064732 __kill + 10 > > 1 libSystem.B.dylib 0x90064724 kill$UNIX2003 + 32 > > 2 libSystem.B.dylib 0x900f798d raise + 26 > > 3 libSystem.B.dylib 0x9010d9d9 __abort + 124 > > 4 libSystem.B.dylib 0x900f071c > > release_file_streams_for_task + 0 > > 5 dpkg0x8a6a tarobject + 6277 > > 6 dpkg0x00020a71 TarExtractor + 759 > > 7 dpkg0xbc4c process_archive + 7772 > > 8 dpkg0x997a archivefiles + 1849 > > 9 dpkg0x3748 main + 323 main/archives.c:tarobject() uses a static buffer to store a filename during installation. Wanna guess the size of fnamebuf[]? Try bumping it to something "much larger". Latest dpkg upstream still has this same hardcoded size. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Testing requested: dpkg script wrappers
http://wiki.finkproject.org/index.php/Fink:Global_deb_scripts will be going into unstable for all users in a week unless I hear complaints (feel free to discuss concept or implemenation). This work involves hacks to dpkg itself and some run-as-root perl that can obviously have serious consequences for all users. Here is your chance to look it over (eye the C patch for anything stupid, check the perl regexes and string-quoting for safety with whitespace and other unusual pathnames, etc.) and test it before release. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem installing sbcl [Bug in dpkg?]
On Sun, Jan 03, 2010 at 06:11:55PM +0100, Martin Costabel wrote: > Martin Costabel wrote: > [] > > On 10.6/32bit: Builds but doesn't install > > > >> Unpacking sbcl (from .../sbcl_1.0.34-1_darwin-i386.deb) ... > >> ### execution of /sw32/bin/dpkg-lockwait failed, exit code 6 > >> /sw32/bin/dpkg-deb: subprocess paste killed by signal (Broken pipe) > >> Updating the list of locally available binary packages. > >> Scanning dists/local/main/binary-darwin-i386 > >> New package: > >> dists/local/main/binary-darwin-i386/sbcl_1.0.34-1_darwin-i386.deb > >> Failed: can't install package sbcl-1.0.34-1 > > I have now found where this chokes: It happens when dpkg tries to > install the file > > /sw/share/doc/sbcl/html/sbcl/Method-sb_002dbsd_002dsockets_003asocket_002dmake_002dstream-_0028_0028socket-socket_0029-_0026key-input-output-_0028element_002dtype-_0027character_0029-_0028buffering-full_0029-_0028external_002dformat-default_0029-timeout_0029.html > > If I remove this file in sbcl's InstallScript, then sbcl (1.0.33 and > 1.0.34) installs OK on 10.6/32bit (at least sometimes, at other times it > produces the sb-posix module build failure I have seen also on > 10.6/64bit occasionally). > > This looks like dpkg is not able to handle files with a file name longer > than 256 characters. On the other hand, I don't understand why this bug > only shows up on 10.6/32bit and not on 10.6/64bit nor on 10.5/32bit. Also doesn't seem to choke on 10.4/ppc. Wonder if there is some static buffer used to hold a pathname? I have: /usr/include/limits.h:#define _POSIX_PATH_MAX 256 /usr/include/sys/param.h:#defineMAXPATHLEN PATH_MAX /usr/include/sys/syslimits.h:#definePATH_MAX 1024 /* max bytes in pathname */ The "paste" subprocess is in dpkg-deb/extract.c:extracthalf(), where I can't decipher the forking and stream processing that is used to read the .deb. Try a simpler dpkg-deb modes to make sure this is where it's choking: "dpkg-deb -c foo.deb" vs "dpkg-deb -X foo.deb /tmp". I think the actual archive reading is done with a system(tar) call, so that command (and its platform variations, and different fink-installed versions) could be another place to look for the root cause: dpkg-deb --fsys-tarfile foo.deb > archive.tar to extract the .deb filesystem archive and then try 'tar -xf archive.tar' with various different tar commands. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Gnome Office Stable Tree
On Mon, Dec 28, 2009 at 04:23:03PM +0900, Pierre-Henri Lavigne wrote: > > Good day all, > > I removed and reinstalled fink using the stable tree. > Still on my Power PC 10.4.11. > While installing bundle-gnome-office: > > * Inkscape does not build. Following the error > http://paste.lisp.org/display/92711 That is inkscape-0.46-3. Unstable has 0.46-5, which appears to have several fixes for recent changes to gtk headers (and also some OS X 10.6 fixes). I just migrated the newer unstable package to stable. > * Dependencies issue for Evolution: > Evolution depends on libcal. Libcal is available only in the unstable > tree > I copy paste the info and patch file on local from cvs, and > everything went fine. > I built it and i tested it. Seems to work good :-) I just contacted the maintainer of libical, who has now committed that package to stable. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] About -system packages
On Sun, Dec 20, 2009 at 10:00:20AM +0100, Adrian Prantl wrote: > Hello fellow Finkers, > > sometime ago I made an updated package for the jack audio connection kit > [1,2]. This was for Jack1. There is also Jack2, which is a > multiprocessor-capable backwards-compatible reimplementation [3]. Having > jack2 packaged is quite important because from my observations jack1 > does not work on 10.6. > I believe it would not be possible to package jack2 for fink, as it > installs stuff into /Library/Frameworks and (more importantly) the > Jack.Router into /Library/Audio/Plug-Ins/HAL/. The rest is put into > /usr/local. Can't it be compiled to install somewhere else? Do they not make the sources available? According to their website "License: GNU General Public License (GPL)" dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New libgettext8 package
Max sez: > > So, do we agree that it would be nice to not "build conflict" with > ccache? > > If so, I'd be willing to investigate making it work without the > "ccache" and "distcc" build conflicts. For starters, though, I'd like > to know why this BuildConflict is there in the first place, so that I > can verify whether my changes actually work. In a quick test, simply > commenting out the BuildConflicts did not cause any particular build > issues. The .info file also contains no comments that explain this > build conflict... I have no idea what the specific problem was, or if it is still a problem. You'll have to dig through the cvs commit-messages. But I agree that BCon should be a last-resort solution for when env vars, simple patches, etc can't solve the problem (whatever it is). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [Fink-users] problem with emboss upgrade
On Sun, Dec 06, 2009 at 10:41:15AM -0500, Koen van der Drift wrote:
> Moving this to fink-devel.
>
> I saw that Dan fixed this issue in cvs - thanks!
>
> So if I understand correctly, the problem was that I used %N-plplot6-
> shlibs instead of %N-plplot3-shlibs, is that correct?
Right. The essence of the policy is that there must be a 1:1 mapping
of Shlibs filename entries and the Package name that contains them. If
that filename changes (for example, nucleus.5.dylib ->
nucleus.6.dylib) then the packagename must change
(emboss-nucleus5-shlibs -> emboss-nucleus6-shlibs). During the emboss
upgrade from version 5.x to 6.x, libeplplot.3.dylib kept its same
filename, but the packagename was changed emboss-plplot5-shlibs ->
emboss-plplot6-shlibs, which means those packages fight over who
supplies the file and other packages cannot specify a reliable Depends
entry if they need that file. Collision of runtime files among
multiple packages is bad.
So the package-names of a shared library really have nothing to do
with the upstream source version, but only to do with the specific
library *file* they contain. For convenience, it's become a
best-practice to name the -shlibs package (and its matching -dev) to
contain the same versioning as the that library file. So (once I was
in "make it clean mode, given we already have some breakage" mode) I
used emboss-plplot3-shlibs as the one new consistent place for
libplplot.3.dylib, just like the libnucleus filename number matches
for *its* package, etc.
This is the change we had discussed and I finally did in the early
days of emboss, leading to the DescPort note:
dmacks overhauled splitoff layout so that lib versions can float
against each other
> But I am a bit unsure about the changes that were made in the patch
> file, what are those for?
The .patch change is the other DescPort note, a change that got lost
in some release since I had implemented it:
dmacks added explicit linking to libs that supply symbols used by
the shared libraries here. This prevents things that link against
the shared libraries from having to know to pass additional flags
when the linker requires all symbols be defined.
It's an upstream bug that "probably" has no user-visible effect. But
if it does, the whole fink support team will spend days trying to sort
it out and passing the blame all around. In essence, libeplplot uses
libgd but does not use -lgd when being compiled and does not publish
this information ("need to use libgd when you use libeplplot") in a
useable way. That means any other package that ever wants to use
libeplplot must somehow magically know to load libgd first, or else
suffer a compile-time or run-time error. So I added -lgd. Same for a
few other of these "missing links".
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New libgettext8 package
On Wed, Dec 02, 2009 at 06:39:11PM +0100, Max Horn wrote: > > Am 01.12.2009 um 15:58 schrieb Jean-Fran?ois Mertens: > > > > > On 01 Dec 2009, at 15:18, Charles Lepple wrote: > > > >> On Tue, Dec 1, 2009 at 8:44 AM, Jean-Fran?ois Mertens > >> wrote: > >>> I notice there is buildconflicts for ccache-default : > >>> this breaks the operation of ccache on anything _ fink or not! _ > >>> going > >>> on in parallel.. > >>> An "export CCACHE_DISABLE=1" (instead of the current "env > >>> CCACHE_DISABLE=1", > >>> so as to apply also to the make command, not only the configure > >>> command) > >>> should suffice in principle ... > >> > >> Jean-Fran?ois, > >> > >> After seeing your email, I went back to re-install ccache-default, > >> and > >> it looks like fink did it automatically. I remember seeing the > >> message > >> saying fink was going to temporarily remove it, and I guess it put it > >> back when it was done. > >> > >> Did ccache-default remain uninstalled on your system? > > > > No ; in general, a BuildConlicts gets reinstalled by fink at the end > > of > > the build. > > That's why I mentioned above "things going on in parallel". > > Exactly. I am unhappy whenever a package forces me to uninstall ccache- > default, even if it is only temporary and and it gets reinstalled > later on automatically: It affects all my concurrent build activities, > which is negative. Also, I wonder what happens if I try to "fink > build" two packages *in parallel* (i.e. in different terminals) that > both conflict with ccache-default , esp. if one finishes earlier than > the other ? The first one's attempt to reinstall (i.e., while the second one is still building) will fail because a build_lock_ still exists, not just a fink "remove this before start the process" action. The whole purpose of the buildlock system is to make it safe to run multiple fink instances concurrently. Which adds to the poor user experience in this case because "could not reinstall after building" will cause the first fink process to fail. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] New libgettext8 package
At long last and thanks to jack and can't-even-remember-whom-else, we now have a new libintl. It's core, so I'm playing conservative with availability: tested on 10.4, so that's where we have it so far. If some 10.5 and 10.6 folks on various architectures could comment out the Distribution flag in their libgettext8-shlibs.info and get some (hopefully:) positive reports that it 'fink -m build's, can make it more widely available... dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] pgpenvelope fails on 10.5
On Fri, Nov 20, 2009 at 01:30:13PM +0200, Claus Atzenbeck wrote: > Hello: > > I'm writing this to the mailing list, because it is mentioned as > maintainer of the pgpenvelope. > > ** My settings: > Mac OS X 10.6.2 i386 > Package manager version: 0.29.10 > Distribution version: selfupdate-rsync Fri Nov 20 13:15:57 2009, 10.6, x86_64 > > Installing pgpenvelope fails: > > ~~ > $ fink install pgpenvelope > Password: > Information about 8328 packages read in 0 seconds. > Can't resolve dependency "class-methodmaker-pm5100" for package > "pgpenvelope-2.10.2-302" (no matching packages/versions > found) > Exiting with failure. > ~~ > > I'm wondering whether class-methodmaker-pm588 (which is available) would > works as an alternative. OS X comes with perl-5.10.0, pgpenvelope seems to be designed to use "whatever perl flavour comes with OS X", and the different perl-flavours of *-pmXXX are not generally interchangeable (is why we have them). I just added the -pm5100 variant to several perl modules, including class-methodmaker. Please selfupdate (in a few hours maybe if your rsync mirror is slow) to see if it is now working for you. Note I didn't *test* the program (I'm not a pine person:) but hopefully the dependency mess is fixed. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glunarclock-0.32.4-1
On Thu, Nov 19, 2009 at 07:37:02AM -0600, Chupacerveza wrote: > Daniel Macks wrote: > > Fixed in 0.32.4-2 that I just committed to unstable. Someone else > > please test so we can get it sane(r) in stable ASAP... So... > On 10.6 64-bit: [...] > /sw/bin/dpkg-lockwait -r fink-buildlock-glunarclock-0.32.4-1 We aleady know -1 fails. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glunarclock-0.32.4-1
On Wed, Nov 18, 2009 at 05:48:56PM +0100, Schindler Karl-Michael wrote: > Feedback: not good > > build does not succeed with: > > . > . > . > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/sw/lib/fontconfig2/include > -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 > -I/sw/include/cairo -I/sw/include/pango-1.0 -I/sw/include/glib-2.0 > -I/sw/lib/glib-2.0/include -I/sw/include/pixman-1 -I/sw/include/freetype2 > -I/sw/include -I/sw/include/libpng12 -I/sw/include/panel-2.0 > -I/sw/include/gconf/2 -I/sw/include/libbonoboui-2.0 -I/sw/include/orbit-2.0 > -I/sw/include/dbus-1.0 -I/sw/lib/dbus-1.0/include -I/sw/include/libxml2 > -I/sw/include/libbonobo-2.0 -I/sw/include/libgnomecanvas-2.0 > -I/sw/include/libgnome-2.0 -I/sw/include/bonobo-activation-2.0 > -I/sw/include/gail-1.0 -I/sw/include/libart-2.0 -I/sw/include/gnome-vfs-2.0 > -I/sw/lib/gnome-vfs2.16/gnome-vfs-2.0/include -I/usr/X11R6/include > -I/usr/X11/include -DORBIT2=1 -I/sw/lib/fontconfig2/include > -I/sw/include/libglade-2.0 -I/sw/include/gtk-2.0 -I/sw/include/libxml2 > -I/sw/include -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 > -I/sw/include/cairo -I/sw/include/pango-1.0 -I/sw/include/glib-2.0 > -I/sw/lib/glib-2.0/include -I/sw/include/pixman-1 -I/sw/include/freetype2 > -I/sw/include/libpng12 -I/usr/X11R6/include -I/usr/X11/include -I. > -I./pixmaps -I../screen-exec -DMOON_GLADEDIR=\""/sw/share/glunarclock"\" > -DGNOMELOCALEDIR=\""/sw/share/locale"\" -I/sw/include -g -O2 -c `test -f > 'moondata.c' || echo './'`moondata.c > moondata.c:25:19: error: gnome.h: No such file or directory > In file included from moondata.h:25, > from moondata.c:32: > glunarclock.h:34:35: error: libgnomeui/libgnomeui.h: No such file or directory Fixed in 0.32.4-2 that I just committed to unstable. Someone else please test so we can get it sane(r) in stable ASAP... dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Mon, Nov 09, 2009 at 10:10:27AM -0800, David R. Morrison wrote: > > On Nov 9, 2009, at 9:54 AM, Peter O'Gorman wrote: > > > > > This is the problem fink now has with its Update* fields. Updating > > the files that will be copied may fix some things, but may break > > others. > > > > Maybe we should introduce new fields for the new updates? With names > like ModernizeConfigGuess, ModernizeLibtool ? > > The idea would be that if you want the 2001 version, you use Update* > and if you want the 2009 version, you use Modernize*. IMO more self-documenting (and less ongoing fink-core headache) to have .info explicitly rerun autotools or copy the files from their private stashes. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Mon, Nov 09, 2009 at 09:19:14AM -0600, Peter O'Gorman wrote: > On 11/09/2009 03:11 AM, Martin Costabel wrote: > > > On 10.6/64bit, the 'Update' fields could have a renewed interest, > > because many packages have config.guess versions that guess wrong. In > > fact, does there even exist a config.guess that gives the right answer > > "x84_64-apple-darwin10"? Apple's own version in > > /usr/share/libtool/config/ doesn't. > > > > The config project committed some variation of Jack's patch a while ago, > the config.guess that reports x86_64-apple-darwin on 64 bit > intel mac systems has probably made it into a few released projects by now. Any word on when an automake release will have it? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Freetype 2.3.8.tar.bz2 not existing
On Sat, Oct 31, 2009 at 05:02:47PM -0200, monipol wrote:
> From the bugs tracker. Original report by unknown.
>
> Whilst we mirror that particular tarball ourselves, I'm copying this
> report because there are more recent stable versions of FreeType.
>
> https://sourceforge.net/tracker/?func=detail&aid=2886448&group_id=17203&atid=117203
>
> When trying to download package freetype219-2.3.8-1, fink fails to
> download
> the file freetype-2.3.8.tar.bz2 from any of the mirrors.
>
> After looking at the webpage of freetype's developers
> (download.savannag.gnu.org/releases/freetype) I saw that version
> 2.3.8. was
> buggy and is no longer offered for download. Could this be fixed in the
> freetype package?
To quote our freetype219-2.3.8-2 package internal notes:
# 2.3.9 breaks ABI! (and doesn't bump c_v for new public functions)
That means upgrading will break an unknown (but possibly up to
*every*) existing package that uses it. 2.3.{10,11} perpetuate the
same breakage...freetype devels are well-known around fink to not give
a damn about interface stability or how much damage they do by
breaking it in nearly every minor release. So we might be able to shim
the new version to match (or at least not break upgrade from) old
version, but it will take time.
Do you have specific information about what's buggy in 2.3.8 (maybe we
could import some limited patches from their newer versions)?
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libgegl0.0.0-shlibs-0.0.22-1 fail: 10.6.1 64-bit
On Sat, Oct 31, 2009 at 09:57:41AM -0700, William G. Scott wrote: > > On Oct 31, 2009, at 9:41 AM, Martin Costabel wrote: > > > --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host=%m-apple- > > darwin`uname -r|cut -f1 -d.` > > Thanks. That is what is needed, both for this and gimp2 itself. w00t! Committed. I don't have a 10.6ish machine to test these kinds of things but will accept offers of patches. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] libgettext package layout
With a new libgettext suite in the works, I'm wondering about getting a saner package layout for this lib suite. Here's (1) the current breakdown (gettext3; older gettext appears same): gettext-doc html-format documentation about library and runtime programs gettext-bin runtime programs man-format documentation about library and runtime programs* libgettext3-dev library developer files The * is the crazy part. If we have a separate -doc component, that's where the docs should be. If we have separate library and runtime components, docs specifically for one should not be in the other. So (2) should all doc formats be in the -doc component, or (3) should the -doc component be abolished and the docs placed in the actual component (-bin or -dev) to which they relate? I think the -doc (even with added material from -bin) is on the order of 100K. Is that large enough (or docs useless enough:) that it should be offloaded from the main packages rather than being installed automatically (idea 2)? Since the lib has different versions and the major-version of -bin need not match that of the -dev installed, is it needlessly confusing to have an additional -doc that tries to unify the docs for two separate pkgs (the docs one reads may not apply to the target presently installed)? I'm thinking separate docs for independent items, and so abolishing the -dev (idea 3). Or are we best just ignoring this since inertia of things that aren't badly/visibly broken avoids having to play any games with upgrade routes, Replaces, etc. (idea 1)? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [Fink-beginners] Essential packages incomplete
On Sun, Oct 25, 2009 at 04:39:39AM -0200, monipol wrote: > On 25/10/2009, at 04:01, John Prokos wrote: > > While downloading the essential packages for a new fink install my > > internet connection was terminated, I believe I was on the last few > > kb of the last tarball, Is there a way to keep what I have downloaded > > so far and only download the missing tarball/s from the mirrors? > > > > When I try to use ./bootstrap again it tells me that /sw already > > exists and won't install over it insisting on a fresh install in / > > sw2. I have no idea what terminal commands to execute in order to > > keep what packages I have and fill in the gaps. I have gone over the > > readme and searched on the fink forums but the info seems to only > > apply to postinstall which I obviously haven't gotten to yet. > > > > I am on an expensive connection using a mobile phone, I would like to > > keep the ~24 MB of tarballs I have already managed to download. > > > > I posted this in the fink forums and had no reply. Move those sources somewhere outside of the fink tree (maybe to /usr/local/fink-sources or /home/YOUR_ACCOUNT/Downloads or something). Then when you bootstrap again, give that location when prompted for an additional directory in which fink should look for downloaded tarballs. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] New dpkg feature: global deb scripts
A little thing I've been hacking on'n'off for a while, seems like it
could be a solution to the "10.6 lost its .la" problem. It's a patch
to dpkg that runs a global script as part of the normal
{Pre,Post}{Inst,Rm} process. For example, global postinst could
include a one-liner to sanitize the .la dependency_libs that got
installed.
http://wiki.finkproject.org/index.php/Fink:Global_deb_scripts
Feedback about the concept and help testing would be
appreciated. Especially good would be to test that existing
prepostinstrmscripts still run correctly and if they don't that the
failure is handled the same with vs without this mod.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] ppl-0.10.2-1 failed on 10.6 32bit
Indeed. Fixed in ppl-0.10.2-2. Thanks for the report! dan On Sun, Sep 20, 2009 at 09:47:12AM +0200, Adrian Prantl wrote: > Hello, > > this is probably easy to fix; it seems as if there was a %p instead of > a %i. > > cheers, > Adrian > > make install-am > test -z "/sw/src/fink.build/root-ppl-0.10.2-1/sw/lib/ppl" > || ../../.././install-sh -c -d "/sw/src/fink.build/root-ppl-0.10.2-1/ > sw/lib/ppl" > /bin/sh ../../../libtool --tag=disable-static --mode=install /usr/ > bin/install -c 'libppl_java.la' '/sw/src/fink.build/root-ppl-0.10.2-1/ > sw/lib/ppl/libppl_java.la' > libtool: install: /usr/bin/install -c .libs/libppl_java.jnilib /sw/src/ > fink.build/root-ppl-0.10.2-1/sw/lib/ppl/libppl_java.jnilib > libtool: install: /usr/bin/install -c .libs/libppl_java.lai /sw/src/ > fink.build/root-ppl-0.10.2-1/sw/lib/ppl/libppl_java.la > libtool: install: warning: remember to run `libtool --finish /sw/lib/ > ppl' > make[6]: Nothing to be done for `install-data-am'. > Making install in . > make[5]: Nothing to be done for `install-exec-am'. > test -z "/sw/src/fink.build/root-ppl-0.10.2-1/sw/lib/ppl" || ../.././ > install-sh -c -d "/sw/src/fink.build/root-ppl-0.10.2-1/sw/lib/ppl" > /usr/bin/install -c -m 644 'ppl_java.jar' '/sw/src/fink.build/root- > ppl-0.10.2-1/sw/lib/ppl/ppl_java.jar' > Making install in tests > make[5]: Nothing to be done for `install-exec-am'. > make[5]: Nothing to be done for `install-data-am'. > Making install in demos > Making install in ppl_lcdd > Making install in examples > make[4]: Nothing to be done for `install-exec-am'. > make[4]: Nothing to be done for `install-data-am'. > test -z "/sw/src/fink.build/root-ppl-0.10.2-1/sw/bin" || ../.././ > install-sh -c -d "/sw/src/fink.build/root-ppl-0.10.2-1/sw/bin" >/bin/sh ../../libtool --mode=install /usr/bin/install -c > 'ppl_lcdd' '/sw/src/fink.build/root-ppl-0.10.2-1/sw/bin/ppl_lcdd' > libtool: install: warning: `../../src/libppl.la' has not been > installed in `/sw/lib' > libtool: install: /usr/bin/install -c .libs/ppl_lcdd /sw/src/ > fink.build/root-ppl-0.10.2-1/sw/bin/ppl_lcdd > test -z "/sw/share/man/man1" || ../.././install-sh -c -d "/sw/share/ > man/man1" > /usr/bin/install -c -m 644 './ppl_lcdd.1' '/sw/share/man/man1/ > ppl_lcdd.1' > install: /sw/share/man/man1/ppl_lcdd.1: Permission denied > make[4]: *** [install-man1] Error 71 > make[3]: *** [install-am] Error 2 > make[2]: *** [install-recursive] Error 1 > make[1]: *** [install-recursive] Error 1 > make: *** [install-recursive] Error 1 > ### execution of make failed, exit code 2 > ### execution of /var/tmp/tmp.12.3myp6m failed, exit code 2 > Removing runtime build-lock... > Removing build-lock package... > /sw/bin/dpkg-lockwait -r fink-buildlock-ppl-0.10.2-1 > (Lese Datenbank ... 175939 Dateien und Verzeichnisse sind derzeit > installiert.) > Entferne fink-buildlock-ppl-0.10.2-1 ... > Updating the list of locally available binary packages. > Scanning dists/unstable/main/binary-darwin-i386 > New package: dists/unstable/main/binary-darwin-i386/languages/ > ocaml_3.11.1-1_darwin-i386.deb > Failed: phase installing: ppl-0.10.2-1 failed > > Before reporting any errors, please run "fink selfupdate" and > try again. If you continue to have issues, please check to see if the > FAQ on fink's website solves the problem. If not, ask on the fink-users > or fink-beginners mailing lists, with a carbon copy to the maintainer: > > None > > Note that this is preferable to emailing the maintainer directly, since > most fink package maintainers do not have access to all possible > hardware and software configurations. > > > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ___ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > http://news.gmane.org/gmane.os.apple.fink.devel > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] scipy-core needs updated in stable
On Thu, Sep 10, 2009 at 12:02:49PM -0400, Jack Howarth wrote: > On Thu, Sep 10, 2009 at 11:46:38AM -0400, Benjamin Reed wrote: > > On 9/10/09 11:38 AM, Jack Howarth wrote: > > > > > Benjamin, > > >What about the case where the maintainer himself has already > > > checked in packaging for x86_64 and 10.6 into unstable. Consider... > > > > > http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/sci/fftw3.info?view=log > > > > > for example. It is difficult to see the advantage of waiting a > > > week for something that has already been committed by the maintainer. > > > > Like I said, it's not about advantage, it's about not being a jerk to > > the maintainer and changing their stuff without them at least having a > > chance to respond. > > > > I know you have a hard time with that, since you apparently have no > > concept of "personal space" on the internet, but humor us. The rules > > are not designed to get the maximum package-tude out in the fastest time > > possible, they're there because we're a community of developers > > volunteering our time, and people get really frustrated when other > > people mess with their stuff. It's just the nice thing to do. > > > > A couple of days is not the end of the world. > > Benjamin, >Your concept of personal space also assumes that we have adequate > manpower to maintain fink in a usable state. I would remind you that if I > hadn't pushed through some of the changes I made unilaterally for > x86_64 support in fink we would be no where near having a usable > x86_64 release at this time. If your sensibilities would be less > offended, I would happy to revert all of those changes and resign > all of my packages. We welcome your contributions. We expect that you will not make changes to others' packages without giving them first go at it, because well, *they* are the maintainer of it. They'd probably love your testing, feedback, and help, especially on platforms they may not have, so that things can become available more widely and migrate to stable. However, I agree that it seems rude to do something in the name of someone else (that's explicitly documented in the Maintainer field). Give them the chance to learn from your idea or (and maybe make it even better, or at least implemented in their style) or at least be aware of what is going to happen rather than waking up and finding their stuff changed (and receiving feedback about something they didn't even know happened). Being an underpowered project is no excuse for jumping on the few others who *do* work. Numerous maintainers have repeatedly complained about your behavior in this respect for a long time, and it needs to stop. Fink really needs to be a collaborative and polite project. Do not pre-emptively change any packages that aren't yours. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] stable wish list: fftw, swig, pygtk2-gtk-py2 and its dep.
On Sat, Sep 05, 2009 at 02:39:43PM -0700, William G. Scott wrote: > I'm trying to migrate coot to stable, but several dependencies are in > unstable, so if there is any change of migrating these, I can verify > they work: > > These include current or recent versions (see below) of: > > pygtk2-gtk-py26 > atk1 > freetype219 > glib2 (dev) > gtk+2 You're asking for "gnome2.26", which will migrate as the whole suite of gnome libs and related packages:) That's waiting on resolution of a bit of dbus behavior annoyance: some gnome daemons do not autostart properly. If dbus gets fixed soon, gnome simply gets a tweaked set of dependencies to take advantage of it, and then move to stable. If it does't get fixed within a week or three, it'll go to stable as-is (it's well tested in unstable) and we'll just live with users having to start some things manually if they really want them. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0/zip-3.0 revisited
On Fri, Sep 04, 2009 at 07:03:26PM -0400, Jack Howarth wrote: >I've looked through the sources for zip 3.0 and > unzip 6.0 and my initial impressions appear to be > borne out. They use a weird custom configure script > in concert with Makefile to find the system bzip2 > library on MacOS X without providing an easy way > to redirect the the location of bzip2. We would > have to hack up their configure script to cause > it to look in %p/include. It also seems to want > to use the static libbzip2 in cases other than > darwin (which we don't have in our bzip2 package). > The only other alternative would be to have > the zip and unzip package download the bzip2 > sources in the build directory and use a locally > built copy of libbzip2.a. None of these solutions > really seem worth the effort since it is entirely > unproven that using the system bzip2 will cause > us problems. Martin has already explained one reason. And I explained a second earlier. The problem isn't so much "using system" as "using BCon". dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0-1 and 10.4
Remind me why: > > BuildConflicts: bzip2-dev is a good idea? dan On Thu, Sep 03, 2009 at 06:37:51PM -0500, Robert Wyatt wrote: > This built and installed just fine Jack. > > Jack Howarth wrote: > > This should build fine as a subsitute for the current > > unzip-10.4.info... > > > > > > Package: unzip > > Version: 6.0 > > Revision: 1 > > Distribution: 10.4 > > Maintainer: Fink Core Group > > License: BSD > > Essential: yes > > CustomMirror: << > > Primary: ftp://ftp.info-zip.org/pub/infozip/src/ > > << > > Source: mirror:custom:%n60.tgz > > Source-MD5: 62b490407489521db863b523a7f86375 > > SourceDirectory: %n60 > > BuildDepends: fink (>= 0.24.12) > > BuildConflicts: bzip2-dev > > DocFiles: BUGS INSTALL LICENSE README ToDo WHERE > > Homepage: http://www.info-zip.org/pub/infozip/UnZip.html > > Description: Decompression compatible with pkunzip > > DescDetail: << > > Zip is different from gzip in that it allows packing multiple files into a > > single archive (without the assistance of tar). It is compatible with pkzip, > > pkunzip, and other Windows zip utilities. > > > > This utility is necessary to install several packages in a pure Darwin > > installation, as Darwin does not come with zip/unzip. > > << > > CompileScript: << > > #! /bin/sh -ev > > perl -pi -e 's|-O3 -Wall -DBSD|-O3 -Wall -DBSD -DNO_LCHMOD|g' unix/Makefile > > make -f unix/Makefile macosx D_USE_BZ2=-DUSE_BZIP2 L_BZ2=-lbz2 > > << > > InstallScript: make -f unix/Makefile install BINDIR=%i/bin > > MANDIR=%i/share/man/man1 > > Suggests: zip > > > > # prevent 'struct direntry' name conflict > > PatchFile: %n.patch > > PatchFile-MD5: a7476ebe93118a849634d80f47e25478 > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > http://news.gmane.org/gmane.os.apple.fink.devel > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0-1 and 10.4
On Thu, Sep 03, 2009 at 09:28:59AM -0400, Jack Howarth wrote: > Robert, >Try changing... > > Revision: 1 > > ...to... > > Revision: 100 > > I thought that the variants had to either be of the > same version but a greater revision or have an epoch > if the version in the variant was smaller than the > main package file. So the current unzip-10.4.info > should have been epoched, while the packaging I proposed > just needs a Revision: 100 (unless someone jumps in > and epochs the current unzip-10.4 before we update it). No, just need to make sure the unzip.info revision is raised even higher than unzip-10.4.info (which only needs to be 1 higher than corrent unzip.info) after unzip-10.4.info is upgraded. _If_and_when_core_decides_ to change unzip-10.4.info or unzip.info, we will make sure each distribution's pkg is appropriate and that upgrades work correctly. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] zsh as shell in compilescript on 10.6 breaks 32bit Fink
On Mon, Aug 31, 2009 at 09:42:21AM +0200, Martin Costabel wrote: > After spending time trying to build apbs in SnowLeopard 32-bit Fink, I > have identified a source of breakage, but I have not yet found a good > solution: > > CompileScripts that run in zsh, like apbs which has > #!/bin/zsh -efv > have a good chance to break on 32-bit Fink on SL. The reason is the > following: > > SL has /etc/zshenv, which didn't exist before. This script is always > executed at startup of zsh, and according to man zsh, this behavior > cannot be overridden. Now /etc/zshenv runs /usr/libexec/path_helper, and > this places the system path /usr/bin in front of Fink's path. Does putting ". %p/bin/init.sh" (or whatever the zsh-syntax is) at the beginning of the script body solve it? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [cvs] dists/10.4/unstable/main/finkinfo/base zip.info, 1.1, 1.2
Jack Howarth committed: > Log Message: > non-maintainer update to zip 3.0-1 > > RCS file: /cvsroot/fink/dists/10.4/unstable/main/finkinfo/base/zip.info,v > --- zip.info 20 Jan 2006 20:19:36 - 1.1 > +++ zip.info 30 Aug 2009 22:51:58 - 1.2 > -Version: 2.31 > +Version: 3.0 [...] > +BuildConflicts: bzip2-dev Why did you even bother asking others' opinions if you were going to ignore my explicit response to you *not* to do it that way? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] nuking .la once and for all?
On Sun, Aug 30, 2009 at 11:22:39PM +0200, Martin Costabel wrote: > Jack Howarth wrote: > > Considering that Apple's X11 developers are recommending that > > we tell user to nuke their installations and rebuild everything > > from scratch under Snow Leopard as well as never install .la > > files, why don't we take this opportunity to do just that. It may > > cause some minor breakage in fink unstable (which should be > > easily fixable), but we could modify fink to automatically purge > > any *.la files from the packaged files in the debs created. Sure > > we will need to correct some info file to remove the *.la from > > the file list but that will be trivial. We really should embrace > > this opportunity to purge out *.la files from 10.6 and later > > releases. See below for my thoughts on that proposal. > Is anyone aware of a large-scale test of what happens if we indeed let > libtool build all those *.la files and then simply remove them, despite > each one of them screaming > > # Please DO NOT delete this file! > # It is necessary for linking the library. > > ? Are there situations where they are really useful or perhaps even needed? I think (please chime in here pogma!) they're used by libltdl when it opens libs at runtime. I assume that falls back to opening the lib, but the .la contains the install_name and other synonymous files, so it might be more reliable. I don't know if libltdl uses the dependency info to assist in opening the lib for loaders or loadees that are not fully linked against all dependent libs to resolve symbols. I don't know how libltdl (if no .la present) figures out whether to try a .dylib or a .so. They're used when libtool is used to link against the lib to propagate linking against indirect/dependent libs. I think this is a poor thing to be doing, since it introduces lots of un-necessary linking, which results in lots of extraneous dependency propagation. Some packages now blank the dependency lines in the .la to avoid that mess. Not propagating these subdep links (either blanking dep lines in .la or nuking .la altogether) makes it harder to trace builddepends of packages that use pkgconfig to propagate dependent -I flags. It's probably worth the extra effort to do that tracing correctly instead of side-effect of otherwise-useless linking. They're useful when static-linking an executable or when some intermediate-level lib is available static-only. The .la should propagate the subdependencies of directly linked libs. IMO, static-linking is rarely used by users and many of our libs don't provide .a anyway, so this is not a good reason alone to keep things. > BTW, just for laughs: Those *.la-phobic Apple developers didn't quite > manage to get rid of them: They nuked the standard ones that really hurt > many previously-built dev packages, like libexpat.la, libiconv.la, > libxml2.la, but they didn't look in all subdirectories of /usr/lib. The > result is that the number of *.la files below /usr/lib increased from 75 > (10.5) to 124 (10.6). Debian is moving towards scrapping them in two steps. In the next major release cycle, they're keeping .la but blanking their dependency lines. In the subsequent release cycle, they're eliminating the .la entirely. I don't think that's any better than just nuking them right away, since we always get in trouble when we assume users keep up-to-date regularly and that they don't use fink as a basis for external things that contain propagated .la references. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0-1/zip-3.0-1
On Thu, Aug 27, 2009 at 12:03:24AM -0400, Jack Howarth wrote: > Daniel, > The bzip2 support is linked into the zip and > unzip binaries with the libbzip2 shared library. > I am agnostic on which one we use except we need > to look carefully at how the build is getting > the bzip2 headers. I think my current packaging > that uses the system bzip2 will be okay if we > add a "BuildConflicts bzip-dev" to make sure it > doesn't grab the fink headers. BuildConflicts is fragile and in my mind (and per users' experience) not an acceptible solution when an alternative and more robust solution is available. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
On Sat, Aug 29, 2009 at 09:58:06AM -0400, Alexander Hansen wrote: > This isn't any different than the usual issues we've had on 10.5, when > you get down to it. System updates cause regressions with respect the > libraries in Xquartz, and Xcode updates regress the headers and libtool > archives (not to mention just clobbering them outright). [...] > What would solve this problem, in my opinion, would be > > 1) More virtual packages, corresponding to libraries from X11 > 2) Getting automatic shlibs resolution working. That won't help because the X11 updates are outside of fink's control. Installer.app doesn't know and doesn't care if it downgrades or removes a certain dylib and in the process breaks a fink package's dependency on that newer one. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0-1/zip-3.0-1
On Wed, Aug 26, 2009 at 11:00:15PM -0400, Jack Howarth wrote: > I was following the debian rules approach to building > both unzip-6.0 and zip-3.0. What version of bzip2 does > 10.4 have? If it doesn't have 1.0.5 that might be a > good reason to use the fink bzip2. Otherwise, I can > remove that part of the packaging. Wait, maybe I misunderstood what you are doing. I read "The new packaging is modified to build the bzip2 support in both packages" to mean it uses a bzip that is part of zip itself (internal rather than relying on external lib at all). If it uses external lib, then I completely support using fink's lib rather than apple's for many reasons. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unzip-6.0-1/zip-3.0-1
On Wed, Aug 26, 2009 at 10:16:27PM -0400, Jack Howarth wrote: > I have uploaded updated packages for unzip-6.0-1 and > zip-3.0-1 onto fink tracking... > > https://sourceforge.net/tracker/?func=detail&aid=2845288&group_id=17203&atid=414256 > https://sourceforge.net/tracker/?func=detail&aid=2845287&group_id=17203&atid=414256 > > Can we try to get these into fink unstable soon? The new packaging is > modified to > build the bzip2 support in both packages. What's the advantage to building own bzip2 (I assume the alternative being to link fink's libbz)? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4, gcc42 and gcc43
On Tue, Aug 25, 2009 at 08:54:21PM -0400, Jack Howarth wrote: >I have added... > > Distribution: 10.4 > > to gcc4 and... > > Distribution: 10.4, 10.5 > > to gcc42 and gcc43 in fink unstable to > prevent users from trying to use these > packages under 10.6. While we could try > backporting all of the changes I had > committed to gcc 4.4 for darwin10 > compatibility, it might be easier to > just push the migration of packages > forward to gcc44. Many people have been working on that on-and-off for a few weeks. Here was from my scan for gcc<44 in unstable/ a few weeks ago: crypto/octave-forge.info # crhappin's devel/gclasspath.info # weird packaging issue...can perpetuate with gcc44? graphics/pdftk.info # deeply incompatible beyond gcc42 libs/cfitsio.info # bmaret's sci/dx.info # can't be updated beyond gcc42? sci/freefem++.info # martin's sci/lpsolve-octave.info # jfm's sci/molden.info # jack's sci/mopac7.info # jack's sci/mpb.info # maintainer email bounced? sci/plplot.info # unmaintained (also needs update to py26/GNOME2.26) sci/r-base.info # monipol talking to maintainer sound/ocp.info # jack's (that "jack" is Jack Fink, not Jack Howarth) dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gopenmol issues
On Sun, Aug 02, 2009 at 07:45:10PM -0400, Jack Howarth wrote: > The current gopenmol packaging fails to build here > on x86_64 fink due to the absence of... > > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib > > on the ConfigureParams line. Also, the package even when > built on x86_64 fink doesn't run properly due to incompatibilities > in the code with tcl/tk 8.5 so this package should only build > on the i386 and powerpc architectures that still use tcl/tk 8.4. Done both. Thanks! dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink alpine 1.13
On Thu, Jul 30, 2009 at 11:36:22PM +0200, Sven de Vries wrote: > Hi, > > > IIRC, new alpine needs openssl098 whereas OS X comes with openssl097. > > that's a bit surprising to me, since: > > *Alpine-2.0 has been out since around august 2008. and on the alpine > web-page, i can't find any reference to a more recent version. openssl098 first landed in fink in June 2008 as version 0.9.8g, so openssl098 was clearly available for alpine developers to start using by their release months later. > *also, alpine-2.0-1 was building fine and running fine on my 10.5.7 MBP. > (and picking up the ssl-stuff from /System/Library/OpenSSL/) The switch to using fink's paths pointing to fink's openssl098 was done to resolve this bug: http://permalink.gmane.org/gmane.os.apple.fink.general/28869 The BIO_method_type symbol, used directly by alpine-2.00 sources, is not present in openssl097 (not in fink's package of it nor in the one that comes with OS X 10.4 or 10.5). Therefore I don't see any possible way for alpine to compile unless it links against an openssl that supplies the required symbol. Either your system openssl is more feature-ful than mine (possible) or while you think the paths were set a certain way, you weren't *actually* linking against apple's at all--one of the difficulties in getting flag orders correct is that one can get mixtures of linking the same lib and headers from multiple places. The solution that makes alpine usable for all our users it to cleanly use fink's openssl098. That makes a simple package with Depends that are sane and self-consistent. You are welcome to hack the package to build your own local copy with whatever options you prefer, using whatever less-than-current version of whatever libs at whatever paths you like--you seem to already know the .info file layout and settings in it that give the behavior you want. I think htodd's decision to have the package be tuned to be buildable (vs reproducibly not, for many users) is a wise choice, at minimal pain for end-users. I would also note that many other fink packages also use fink's openssl (and presumably all want their certs in the same fink place), so you annoyance at alpine in particular is mis-aimed...it's just the first place you have encountered a package that needs it (and a change that is easy for you to adjust to). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink alpine 1.13
IIRC, new alpine needs openssl098 whereas OS X comes with openssl097. dan On Wed, Jul 29, 2009 at 07:08:36AM -0700, Hisashi T Fujinaka wrote: > Let me look into this. I'm not using alpine for ssl at the moment. > > Alpine will NOT compile with system ssl on released versions of OS X. > I'm not sure if Apple changed their OpenSSL, but I've spent too much > time on this already. I'm not curious enough to find out. > > On Wed, 29 Jul 2009, Sven de Vries wrote: > > > Dear Mr. Fujinaka, > > > > thank you very much for maintaining alpine of fink. > > > > however, with the update yesterday to 1.13, it seems my alpine nolonger > > find > > the tls/ssl certificates it needs. > > > > upon looking at the source-diff between cvs 1.13 and cvs 1.8, > > it seems that > > --with-openssl=%p/lib/system-openssl > > was replaced by: > > --with-openssl=%p/lib > > > > could this be the reason that my alpine no longer finds the certificates > > (that for previous versions i had to put into /System/Library/OpenSSL)? > > > > Also, for the future, is it just a temporary feature that not the > > system-openssl is used, or if it is the future: do you know by any chance > > where I should put the certs for alpine? > > > > Thank you for maintaining alpine! > > best > > Sven de Vries > > > > -- > Hisashi T Fujinaka - ht...@twofifty.com > BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > http://news.gmane.org/gmane.os.apple.fink.devel > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-devel -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [fink-core] Updated dpkg and gettext packages
On Fri, Jul 24, 2009 at 08:08:26AM +0200, Sjors Gielen wrote: > > PS: I think someone told me I needed to make a glib-bootstrap too, but > upon further investigation I couldn't find out why. Does anybody see / > remember why? If glib2-dev is installed, the gettext-tools build process apparently detectes it links some of the binaries against it. That's why our existing gettext-tools-0.17 package specifies Depends:glib2-shlibs and BuildDepends:glib2-dev dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Updated dpkg and gettext packages
build-dependency,
> therefore matches the policy. Later in the bootstrap queue, dpkg-
> bootstrap is used to install gettext-tools and gettext8-dev so the
> real, complete dpkg can be built correctly. From that moment on,
> gettext-tools and gettext8-dev and their dependencies can be removed,
> they are only necessary for that one build.
>
> Having a rule "all depends and build-depends need to be essential" and
> sticking to it, no exceptions, makes for hacks to circumvent that
> rule, as is clear from the current "fix". I think 4) is the way to go,
> and the rule should be changed to "all depends and build-depends for
> an essential package need to be essential - if that's not possible,
> there must be a -bootstrap package whose depends and build-depends are
> essential, and which can be replaced by the normal package later once
> the build-depends can be correctly installed". Otherwise, I see
> nothing but hacky fixes out of this, which defeat the whole purpose of
> being able to bootstrap fink + essentials from scratch.
>
> What do you think?
I think the present hacky fixes work, and I don't see a compelling
reason to change that isn't at best differently hacky. -bootstrap
packages are themselves a hack. The dpkg-bootstrap isn't a hack to
work around a dependency problem just in dpkg ("bootstrap of dpkg"),
but is necessary to be able to be able to compile before fink itself
exists ("source bootstrap of the whole world"). I'm also against
changing "must be able to bootstrap from source" because I don't see
any massive gain to offset that loss of portability or to future or
alternate systems or inability to nuke and totally restart from
scratch (or to customize) on a local machine.
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] packages maintained by Murali Vadivelu
On Mon, Jul 20, 2009 at 02:40:10PM -0500, Robert Wyatt wrote: > > From: mk...@cantab.net > > > > I am working at a start-up company and have other things in hand > > as well. I would be more than happy for my packages to be taken > > over by other maintainers, as I cannot put any time in towards > > Fink. > > > > boto-py24 1.3a-1 Python interface to Amazon Web Services > > boto-py25 1.3a-1 Python interface to Amazon Web Services I updated to latest upstream and added py26. > > gnupg-interface-py240.3.2-2 Python module to interface with GnuPG > > gnupg-interface-py250.3.2-2 Python module to interface with GnuPG I updated to latest upstream and added py26. > > muparser1.28-2 Fast math parser library > > muparser-shlibs 1.28-2 Fast math parser shared library There's a new version or muparser available, but they don't seem to care about ABI stability --> visible breakage for users, so no point in updating it at this time. > > pylibacl-py24 0.2.1-1 Python module for POSIX.1e ACLs > > pylibacl-py25 0.2.1-1 Python module for POSIX.1e ACLs New 0.4.0 upstream doesn't build on my 10.4/ppc machine (undefined tokens ACL_READ ACL_WRITE). > > xattr-py24 0.2-1 Python module for filesystem ext attributes > > xattr-py25 0.2-1 Python module for filesystem ext attributes Already taken over by Evi Vanoost. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] openssl dependencies?
On Mon, Jul 20, 2009 at 12:28:30PM -0500, Robert Wyatt wrote: > Robert T Wyatt wrote: > > In trying to install pine-ssl in unstable: > > > > I'm not sure what's going on, but I think it might have to do with what > > seems to me like a catch-22: > > > > openssl097: Depends: openssl (>= 0.9.7m-5) > > > > openssl conflicts with openssl097, but openssl097 is installed > > Now that I've gotten some sleep and some coffee, it occurs to me that > I have a vague recollection that pine-ssl is not necessary. So while > this discussion may be moot, it may time to remove pine-ssl from the > PDB (if anyone has a better memory about this, please feel free to > chime in). I'll have to dig around and see if I can find the relevant > correspondence from I don't know how long ago. pine was superceded by alpine upstream. Maybe time to replace pine and pine-ssl (both presently unmaintaind) with pointers to alpine (which is maintained)? The *pine builds are scary-nonstandard...no reason to keep obsolete stuff that is difficult to understand and build. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glade3: missing icons (missing dep on gnome-icon-theme)
On Sun, Jul 19, 2009 at 11:15:09AM -0300, monipol wrote: > Howdy, > > We've had a report from a $user on -beginners that glade3 (currently > unmaintained) does not show any icons. Installing gnome-icon-theme > solved the problem so could someone possibly add it to glade3's list > of dependencies? Done. I suspect there is actually some lower-level dep that should have this, but not sure what and no other error reports, so dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] denyhosts-py25
On Fri, Jul 17, 2009 at 12:00:51PM -0500, Chupacerveza wrote: > hmmm, when building in maintainer mode: > > ... has a preferred Depends on python25-socket, but python25-socket is > an obsolete package. > > Now, another user has asked that I upgrade this to use 2.6, but I > wanted to get the quick maintainer change in first and then come back > and make those changes. > > I'm soliciting suggestions for what to do about this. You can ignore it. If a package is obsolete, it still does exist (this isn't a "no such package" type of error), and if the maintainer of it did things correctly, it still will supply whatever functionality it did previously. It's a notice that there is a better or more modern way, not that the existing way is functionally broken (unless maintainer of python25-socket himself is functionally broken:). Let us know if you want more info about obsolete-package replacement once you get going on this pkg. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] User Creation in Gnowsys.info
On Sun, Jul 05, 2009 at 06:47:18PM +0530, Sandeep Bhaskar wrote: >monipol wrote: > > What Fink command were you running when you got that error? > fink -m -K --build-as-nobody rebuild gnowsys > > > Where exactly are you issuing that su command (CompileScript, > > InstallScript, PostInstScript, ...)? > The InstallScript section within gnowsys.info file contains: > > InstallScript: << > sh install.sh %i %b %d %p > << > > The command su postgres -c ./gnowsys-pg-install.sh* *is called from within > this install.sh and not directly from within the .info file. su and sudo are not allowed under --build-as-nobody. Being able to become a different user (who presumably can write to various places on the filesystem) breaks the protection of --build-as-nobody, which specifically prevents a broken build script from accidentally writing to the filesystem anywhere except in the fink packaging dirs (%d and %b). What does gnowsys-pg-install.sh do that requires being the postgres user? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100
On Sun, Jun 28, 2009 at 09:29:21PM -0700, David R. Morrison wrote: > > Actually, /sw/bin/config_data is perfectly appropriate, since only > one module-build-pmXXX package should be installed at a time. > > The only problem here is that the perl5100 package Provides module- > build-pm5100-bin, and as such, is trying to install its own copy. So > we need module-build-pm5100-bin to Replace perl5100 (but not Conflict > with it) and the problem will be solved. ...until user installs perl5100 and then module-build-pm5100-bin, and then removes module-build-pm5100-bin (the actual one). Now we've got dpkg (and therefore fink) thinking module-build-pm5100-bin is installed due to Provides, but *no* config_data at all (for whatever purpose it would be used and expected to exist via dependencies). We really need to figure out whether config_data is used directly by users (i.e., must be in PATH so can run as command) or is just invoked by module-build-pmXXX itself (in which case it can be renamed or moved to be orthogonal pathname among the different packages that would have it). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
On Fri, Jun 26, 2009 at 09:27:36AM +0200, Alexander Hansen wrote: > Daniel Macks wrote: > > On Thu, Jun 25, 2009 at 08:27:10PM +0200, Alexander Hansen wrote: > >> Jean-Fran?ois Mertens wrote: > >>>> ln ../c++ ../cc > >>>> > > > > I *think* that last line should be "ln c++ ../cc" (otherwise ../cc > > points to ../../c++), but otherwise seems fine. > > > > > This is a hard link, though; so I wouldn't think the paths should > matter, since 'c++' doesn't _point_ to 'cc' but rather is a _copy of_ > 'cc'. At least that's how it worked when I was playing around with it. Ah yeah, I totally read a -s in there. Hardlink does indeed Do The Right Thing for the original syntax. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
On Thu, Jun 25, 2009 at 08:27:10PM +0200, Alexander Hansen wrote: > Jean-Fran?ois Mertens wrote: > > > > Too lazy to try fixing this cmake stuff.. (sure there must be a way, > > either to fix > > the flag-ordering, or to change compiler and linker); so, dirty > > solution : > > Adding to the patchscript the lines > > > >> echo '#!/bin/sh -ev > >> name=`basename $0` > >> flag-sort -v /usr/bin/$name $@' >> ../c++ > >> chmod a+x ../c++ > >> ln ../c++ ../cc I *think* that last line should be "ln c++ ../cc" (otherwise ../cc points to ../../c++), but otherwise seems fine. > > and changing the PATH line to : > > > >> export PATH="%b/..:$QTDIR/bin:%p/lib/freetype219/bin:$PATH" If this idiom is popular, would be easy enough to add a pile of cc and c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. Unrelatedly, if your BDep:freetype219 is >= 2.3.7-7, you do not need special PATH (or any other) flags or variables to find ft219. And if you are Dep/BDep >= 2.3.8-2, you also avoid some freetype219 backwards-incompatible ABI breakage. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] graphviz-nox prospects
On Mon, Jun 22, 2009 at 05:51:23PM +0200, Jean-Fran?ois Mertens wrote: > > On 22 Jun 2009, at 14:52, Daniel Johnson wrote: > > >Actually, libdevil1 is in fink unstable. > > Right _ and graphviz(-shlibs) does link nicely with it :) And I've got libgs ready to go as soon as I resolve a licensing issue. graphviz also links fine with it. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] graphviz-nox prospects
On Sun, Jun 21, 2009 at 04:58:56PM -0400, David Fang wrote: > Hi all, > After sensing a disturbance in the Source (reading my emails), > I've gathered that several people (myself included) find the current > graphviz package a little dependence-heavy. I'm considering writing a > Type: -nox variant, which I might need a little guidance with. I'm armed > with the packaging manual and some examples (emacs22.info, vim.info). I > need a little advice on which dependencies I can drop for -nox. For > example, can I remove all of the gnome, gtk, pango, cairo deps? Many of the upper-level gnome dependencies can probably be removed, period, even in a fully-gui-enabled package. They appear to be unused by graphviz itself, and were probably only needed via inheritance from older versions of some dependency. By setting the current (unstable) versions of the dependencies, you can eliminate all the packages related to avahi, bonobo, bonoboui, gnome-vfs, gnome-keyring, libgnome, libgnomecanvas, libgnomeui, libart2, popt. You can also simplify the ConfigureParams: don't need any FREETYPE2_*, and don't need the pango-ft219 or freetype219 components in PKG_CONFIG_PATH. Unrelated dependency bug: configure autodetects the gts/gts-shlibs and lasi-dev/lasi-shlibs packages, so need to add dependencies on them or force them to be ignored. Also detection of ghostscript (iapi.h and -lgs) and DevIL fail because those libs aren't in fink *right now*, but for sanity should still disable detection in case they ever do get into fink. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
