Re: [fink-core] I just created fink/fink-distributions on github as arepository for distributions
On Wed, 10 Jun 2015 09:34:05 -0700, Alexander Hansen alexanderk.han...@gmail.com wrote: No surprise there. :-) I was going to initialize the 10.9-libc++ distribution, but then I got to thinking about whether it might not be a bad plan to use a cvs import of the 10.7 tree and then rename the directory, so that we can preserve the history. Thoughts? I do not support making a new distro subdir by simply cloning the old. This is a great chance to prune out lots of old crap that doesn't build, stop relying on system hacks like X11 symlink, stop carrying forward -shlibs stub packages from old libversions, etc. However, cloning the old into a holding-pen in git (preserving history) and then using that for selective manual moving into the live distro still within git gives us history linkage. New dist would essentially be a fork or branch. dan -- Daniel Macks dma...@netspace.org -- ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] [Fink-beginners] can not install any package.
On Wed, 30 Sep 2015 15:31:39 -0400, Daniel Macks <dma...@netspace.org> wrote: On Wed, 30 Sep 2015 15:13:16 -0400, Daniel Johnson > <daniel.johnso...@gmail.com> wrote: > > On Sep 30, 2015, at 2:58 PM, Alexander Hansen > > <alexanderk.han...@gmail.com> wrote: > > On Sep 29, 2015, at 06:37, Alexander Hansen > > <alexanderk.han...@gmail.com> wrote: > > On Sep 27, 2015, at 22:25, Oner Sufri <oner.su...@gmail.com> wrote: > > > > I currently deleted oldest version of Fink and installed the latest > > version, 0.38.7. The installation was smooth without any problems. > > However when I try to install some of the packages I needed. I > ended > getting this specific error for all my fails. > > > autoreconf -fi /sw/bin/autopoint: line 454: xz: command not found > > tar: This does not look like a tar archive > > tar: gettext-0.19.3: Not found in archive > > tar: Exiting with failure status due to previous errors > > autopoint: *** infrastructure files for version 0.19.3 not > > found; this is autopoint from GNU gettext-tools 0.19.5.1 > > autopoint: *** Stop. > autoreconf: autopoint failed with > exit status: 1 > > ### execution of autoreconf failed, exit code 1 > > ### execution of /tmp/fink.0nHgc failed, exit code 1 > > Removing runtime build-lock... > Removing build-lock > package... > /sw/bin/dpkg-lockwait -r fink-buildlock-libidn-1.32-3 > > (Reading database ... 16838 files and directories currently installed.) > > Removing fink-buildlock-libidn-1.32-3 ... > Failed: phase > compiling: libidn-1.32-3 failed > > > > I have OS 10.9.5. I would like to get some help please. > > > It looks like the new version of gettext-tools needs the xz package > > to be installed. Do a “fink install xz”, and that will solve > > the missing xz command. > > > If gettext-tools needs xz, then I assume we need to make xz Essential? > > > > Do we know why gettext-tools needs xz? xz BuildDepends on > > gettext-tools so that could be messy. gettext-tools is not > Essential:yes, so that won't be a problem. But > xz:BuildDepends:gettext-tools, so making a dependency cycle would be > a problem. If I understand gettext-tools (ha!), autopoint can use any > of several compression schemes to create an internal-use archive > of...something. It gettext-tools buildtime autodetects what's > available and hardcodes the autopoint to use that one by default. Our > build is currently non-deterministic in that it apparently whether xz > is present and the resulting executable embeds that info. Seems like > a bug that it doesn't have fallbacks at runtime. But I think we can > also force non-detection of xz at buildtime (just like we do for some > other compression schemes). Testing committed new gettext-tools. A large archive is created at build-time, which is then used at runtime, so it does make sense that the compression scheme would have to be the same:) I dialed it back to .bz2, which is available in /usr/bin. dan -- Daniel Macks dma...@netspace.org -- ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
[fink-core] Removed permissions for Jack Howarth
Several days of repeated breakage of the dep trees and refusal to clean up afterwards; altering packages of active other maintainers without discussion; revert-warring to retain his breakage; repeatedly warned about all of this over many months and recent days. Live dists are not his sandbox, and his methods of encouraging other maintainers to do things are causing damage without actually getting those maintainers to do anything. After talking to several other fink-core, I've pulled his commit bit. I'd welcome others' help in cleaning up the 10.9-libcxx dependency tree, as it currently has holes. dan -- Daniel Macks dma...@netspace.org -- ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] Expat 2.2.1 with security fixes has been released
On Sat, 17 Jun 2017 22:04:30 +0200, Sebastian Pipping wrote: > > I'm contacting you because Expat 2.2.1 -- containing security fixes -- > has just been released. For details please check the change log, online > at https://github.com/libexpat/libexpat/blob/master/expat/Changes . I updated our package. Thanks for the note! dan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] Time to de-emphasize SourceForge
On Sat, 30 Sep 2017 21:39:29 -0400, Daniel Johnson wrote: >> >> > On Sep 30, 2017, at 7:30 PM, Alexander Hansen wrote: >> > >> > 1) We no longer have the ability to remove locks from CVS. >> > 2) They’ve reduced our ability to administer our mailing lists—the list >> > owner can’t even remove users any more. >> > >> > I’d be OK with having users report bugs via issues on GitHub rather than >> > via the mailing list, especially since we’ll be able to associate them >> > directly with the relevant .info and .patch files once we get the >> > distribution up and running there. >> > >> > I’m still OK with using SourceForge to host our tarballs. >> >> I’m very much in favor. Do it. I'm in the process of rebuilding my machine (HD buh-bye), so it might be a day or so before I'm back in fink action. dan signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] mirrors
fink-core owns it:) Which DNS record(s) should be changed to what values? dan On 3/13/19, 11:59 PM, "Alexander Hansen" wrote: Hey, folks. Our mirror issue is just that the finkmirrors.net domain needs to be fixed. Does anybody remember who owns it? —Akh ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] mirrors
I can change whatever settings in DNS (dotster account), someone just needs to say "change [X] to [Y]". For these purposes, consider that I have no idea what a zone file is or where I would put it (since I do not actually have any server). dan On 3/21/19, 9:31 AM, "Justin Hallett" wrote: No idea that is what we are waiting on, last I heard the core team does, that is what dmacks said in IRC. Currently wish I did ;) --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On Mar 21, 2019, at 6:44 AM, Hanspeter Niederstrasser wrote: On 3/20/19 6:49 AM, Justin Hallett wrote: I’m guessing we are just going to let the mirrors die? Should I turn it off on snitch to save resources? --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! Who has control of the DNS settings? Hanspeter ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core ___ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
Re: [fink-core] upgrade process for big sur/dpkg1.16
(continuing with top-posting pattern of this thread...) If we don't do la
cleanup when installing old deb, then there will be bits present in the
installed la that will either easily break building other packages or lead to
propagated binary differences in them. The cleanup removes bits that trigger
additional (but needless) -lfoo flags...uncontrolled inherited BDep. The
current cleanup method definitely breaks md5sums, but was the only way to get
consistent and non-weirdly-breaking end-user experience that we could find
("least crappy solution that was actually doable without a time machine").
Clearing those bits when creating the .deb is the perfect solution, but we'd
have to disallow uncleared .deb if we don't do the clearing in PostInst. Maybe
if we're making such a hard break we should actually do that?
dan
On 8/28/20, 3:24 PM, "Justin Hallett" wrote:
It will work, new debs won’t work with old dpkg but there is a dpkg
pre-depends injected into them
The difference is triggers, and some of the la processing. Current fink
breaks debsums (and Debian rules) as it changes the la files after install,
this changes the md5sum and thus breaks debsums to check for changed files.
The new dpkg deals with it before, and uses triggers from the fink packages
to do other than that used to be injected into postinst script.
Older dpkg will just ignore fields is doesn’t know like pre-depends and
triggers. But a deb built with the dplg1.16 branch and the someone built with
master won’t be the same deb which breaks fink policy. Most of the changes and
differences are all in the la files and the Debian control directory. So the
binaries and libs will be the same.
In summary there is no danger I made sure of it. But fink policy needs to
be amended if we want to allow upgrades.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
On Aug 28, 2020, at 1:17 PM, f...@snaggledworks.com wrote:
Will old debs work with the new dpkg? Or is the deb compatibility broken in
both directions?
If we're going to need a new tree (called "11.0"?), what distributions
should we put into it? Obviously macOS 11.0. Should we also put 10.14.5 and
10.15 into it? These two share the same /usr/bin/perl (v5.18.4), but it's
different from 11.0 (v5.28.2). However, 11.0 has /usr/bin/perl5.18(.4) as well.
Is it worth (possible?) going down to earlier system versions? 10.10-10.14
share the same system-perl (5.18.2)
Hanspeter
On 2020-08-28 11:13, Justin Hallett wrote:
I’m almost positive all the packages are compare (texinfo might have
an extra split) but you can not put dpkg into the 10.5 tree since
it’ll break deb compat. This branch needs a new tree then it can be
added.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
On Aug 28, 2020, at 9:59 AM, Alexander Hansen
wrote:
On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser
wrote:
What's the upgrade process for the dpkg1.16 branch and the dists
tree?
Several packages are now essential (e.g. time-date-pm and xz) and
will have to be moved from their present subfolders in dists to
'base'. Also, some base packages have newer versions than what's
in the dpkg1.16 branch source (e.g. libiconv and texinfo). But the
dpkg1.16 branch versions have needed changes that might be
incompatible with older fink installs, so we can't just copy
what's currently in dist to the dpkg1.16 branch, or push the
dpkg1.16 branch versions directly into dists. Or are dpkg1.16
packages compatible with legacy dpkg?
Hanspeter
At minimum, the most logical thing to do would be to update
libiconv, texinfo, et. al. in the dpkg1.16 branch and also apply the
branch-specific changes - i.e. merge them in a logical sense if not
in a Git sense. I hate to say it, but this might be a case for a
new distro and clean reinstall rather than update in place. I know
we just did that for Catalina, but my impression is that Big Sur is
going to change a bunch of stuff.
--
Alexander Hansen, Ph.D.
Fink User Liaison
___
fink-core mailing list
fink-core@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core
___
fink-core mailing list
fink-core@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core
___
fink-core mailing list
fink-core@lists.sourceforge.net
List archive:
