Activity for Daniel Macks
-
Daniel Macks posted a comment on ticket #172
That's solely based on the lack of sync between the two platforms and also between the linker and the dependencies list. But that fix causes FTBFS due to unresolved symbols when linking libutil.dylib: "_GifErrorString", referenced from: _PrintGifError in qprintf.o because qprintf.o is now only in libgif not libutil. If libutil is (as name suggests) utility functions and (as the Makefile behaves on all platforms) not actually install libutil publicly, should it be static-only on all platforms?
-
Incorrect object files in shared libutil on darwin
-
Type-mismatch in libmpeg2/idct_mmx.c
-
I had already added that flag for test/unit/CMakeLists.txt (required for recent cppunit versions (see https://sourceforge.net/p/podofo/mailman/podofo-users/thread/1501515201.2032.64.camel%40litePDF.cz) via the more generic ADD_DEFINITIONS() function, so a more specific tool like the CXX_STANDARD variables seems better already.
-
fink needs to check linkage for /sw/src
-
fink-package-precedence has long handled this task. Maintainers place it manually in CompileScript (it also catches other wrong-tree classes of errors that require some information not easily determined from the .deb but trivial for the maintainer to know).
-
podofo-0.9.7 FTBFS on OS X
-
Is the current code in git (or CVS, or...) somewhere?
-
Oh, and per autotools docs, -lfoo and libfoo.la flags should go in foo_LDADD not foo_LDFLAGS.
-
Parallel-build breakage (wrong libnco linked)
-
Building with gcc9 (and comparable results with different wording with older gcc): gfortran-fsf-9 -fimplicit-none -O2 -funroll-loops -c utils.f utils.f:65:72: 65 | call srandg(2*m,n,x,2*ldx) | 1 Warning: Type mismatch in argument 'x' at (1); passed COMPLEX(4) to REAL(4) [-Wargument-mismatch] utils.f:72:72: 72 | call drandg(2*m,n,x,2*ldx) | 1 Warning: Type mismatch in argument 'x' at (1); passed COMPLEX(8) to REAL(8) [-Wargument-mismatch] The third parameters of those two functions are prototyped...
-
Starting at line 68: subroutine zrandg(m,n,x,ldx) integer m,n,ldx double complex x(ldx,*) external srandg call drandg(2*m,n,x,2*ldx) end subroutine Presumably that should be: external drandg to declare the function that will be called.
-
Better prototyping of errmsg
-
New fortran warnings from gcc9
-
xvfb-run fix for not needing previously run X11
-
Fixed in 792e352d8c508b5819db3aa183cc63dba68dde20 using a suid wrapper written in C that runs xquartz's privileged_startx program (which runs its .d scriptlets). This all needs to happen at runtime, since the directories get nuked on reboot, not at PostInst.
-
Using the approach of https://gitlab.com/pteam/pteam-qtbase/commit/b06304e164ba47351fa292662c1e6383c081b5ca (from qtpaintengine) got me a clean build of extract_probe_data.cpp on 10.13
-
https://gist.github.com/ejtttje/7163a9ced64f12ae9444 from qtpaintengine got me a clean build of extract_probe_data.cpp on 10.13
-
libxml2-bin overwrites SGML_CATALOG_FILES variable
-
Unclear if there still is a problem, and the submitted never responded.
-
auto append X11 flags if BuildDepends contains x11-dev
-
paraview and paraview-mpi 3.4.0-1000
-
If nothing is supposed to build against it, there should be no -dev companion for the -shlibs, and the Shlibs entries should all be marked private. But otherwise, the old -shlibs needs to be kept (at its old version), not just wiped to make the new (put the Version in the .info filename, or re-shuffle to have the -shlibs as the parent?).
-
gromacs/gromacs-mpi-2016.1-1
-
Have a newer-version submission (with the same -shlibs policy issues) at: https://sourceforge.net/p/fink/package-submissions/5032/ so scrapping this one.
-
That's the same thing I said a year previously, which led to the since-stalled tracker submission for an older new-version. https://sourceforge.net/p/fink/package-submissions/4840/
-
fix libgraphviz238-shlibs-2.38.0-8 to build on 10.13
-
Now continuing at https://github.com/fink/fink-distributions/pull/143
-
fix libgraphviz238-shlibs-2.38.0-8 to build on 10.13
-
Now continuing at https://github.com/fink/fink-distributions/pull/143
-
add ncurses6-6.0-1 and libncursesw6-6.0-1 packages
-
Work on-going at https://github.com/fink/fink-distributions/pull/29
-
libncursesw5-5.9-20110507-2
-
Work on ncurses6 on-going at https://github.com/fink/fink-distributions/pull/29 which might involve scrapping a separate wchar-supporting package altogether.
-
Given we haven't supported ppc in many years and apple is dropping 32-bit, is it worthwhile to carry arch varianting any more?
-
Will need to update existing libmpfr4 to Conflicts/Replaces this one.
-
picoprolog: new package.
-
picoprolog: new package.
-
I don't see any attachment here.
-
delila-bundle: update to new versions
-
Fixed in revision -2, committed with maintainer consent. Thanks for the bug-report and diagnosis!
-
wget package: dyld: Library not loaded: /sw/lib/libunistring.2.dylib
-
Confirming libunistring is autodetected--linked externally if found, compiled own internally (not build-fail) if not. So it's just a matter of adding the BDep/Dep.
-
wget package: dyld: Library not loaded: /sw/lib/libunistring.2.dylib
-
"stable check" for checking whether pkgs are stable-ready
-
The "unstable" tree was scrapped years ago, we're all stable (well, in terms of the tree-name anyway) now. Closing.
-
fink should provide an '--orphans' option for its 'list' command
-
Branch was merged into master 2 years ago. Closing.
-
Update pkgconfig for High Sierra
-
xdotool FTBS on 10.12+
-
I pushed that new version, which happens to be a new libversion (libxdo3-{dev,shlibs}). Since there are no current reverse-dependencies on libxdo2-{dev,shlibs} I simply killed them on 10.12+ via Distribution tag.
-
xdotool FTBS on 10.12+
-
What is in nco469-dev and nco469-shlibs that requires (new version) nco Conflicts/Replaces them? It sounds like we're scrapping headers and non-versioned .dylib links, and not building .a, and those are the usual -dev things. And by history, new nco*-shlibs have not C/R old ones.
-
What is in nco469-dev and nco469-shlibs that requires (new version) nco Conflicts/Replaces them?
-
htmldoc 1.8.30 with Xcode9 fix
-
thanks!
-
ccpnmr-py-2.4.2-3 to switch build to gcc6
-
That fails at Files: in one of the subpackages because 10.13 no longer exposes some tcl files loose in /usr/bin, so some tcl support libs don't get built at all. Attached fixes it. Is it portable back to your 10.less-than-13?
-
#5059 rmagic web log analyzer update versioned
-
Update to config-inifiles-pm
-
rmagic web log analyzer update versioned
-
I'm confused here...the "rmagic.info" is for 10.10+ with perl5.18.2, but the "rmagic.patch" hardcodes perl5.16.2. One way to make this all easier is to have a "type:" variable to hold the system-perl version, then you can just use that throughout the .info (minimizes the diff between rmagic.info and rmagic-10.9.info) and have a unified .patch with a PatchScript that inserts that variable's value on-the-fly.
-
alien-sdl-pm 1.446
-
phew what a mess. Thanks for wrangling it!
-
Update to config-inifiles-pm
-
Done. Sorry for the delay! Should I bump the rmagic deps to point to the new varianted package here?
-
Good find with the "installdirs=>vendor" tag! The manpages are being misplaced on 10.13/-pm5182, going in man/ rather than man/man3. The attached modification seems to fix it for me. Could you check?
-
On my 10.13, I see: checking for SDL_image... no but if I install sdl-image, that becomes: checking for SDL_image... yes So missing dep. I also see: checking for SDL_Pango... no but we don't have sdl-pango in fink. For consistency in the future, either we should package it and add a dep, or hack the test for it to fail even if some day it does get packaged.
-
Unrelatedly, the build gives a fat binary. Any way we can scrap the i386 to save a bunch of compile-time?
-
The Makefiles in remote_cmds-54.50.1 use $MAKEFILEPATH, which is defined automatically by an Apple-specific extention of 'make'. I can't find this change documented anywhere? https://opensource.apple.com/source/gnumake/gnumake-131/patches/PR-10516611.patch.auto.html
-
xtide 2.15.1-3
-
libpng-1.6.32 breaks on OS X: no zlib.pc
-
Useless check for dirent.d_name==NULL
-
I guess this is both a patch and a bug-report...depending on whether patch is accepted and how upstream thinks the actual bug should be handled would alter what patch to fix it. Shame I didn't think this all through before being forced to choose which tracker to post.
-
Fix possible use of undefined variable
1 >