You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(41) |
Dec
(23) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(58) |
Feb
(78) |
Mar
(55) |
Apr
(41) |
May
(25) |
Jun
(32) |
Jul
(59) |
Aug
(29) |
Sep
(44) |
Oct
(38) |
Nov
(37) |
Dec
(18) |
2005 |
Jan
(22) |
Feb
(10) |
Mar
(65) |
Apr
(22) |
May
(84) |
Jun
(46) |
Jul
(16) |
Aug
(33) |
Sep
(48) |
Oct
(23) |
Nov
(50) |
Dec
(31) |
2006 |
Jan
(27) |
Feb
(25) |
Mar
(35) |
Apr
(36) |
May
(29) |
Jun
(30) |
Jul
(32) |
Aug
(14) |
Sep
(17) |
Oct
(21) |
Nov
(11) |
Dec
(51) |
2007 |
Jan
(24) |
Feb
(39) |
Mar
(49) |
Apr
(33) |
May
(23) |
Jun
(8) |
Jul
(11) |
Aug
(28) |
Sep
(35) |
Oct
(28) |
Nov
(25) |
Dec
(27) |
2008 |
Jan
(23) |
Feb
(16) |
Mar
(13) |
Apr
(9) |
May
(12) |
Jun
(10) |
Jul
(8) |
Aug
(10) |
Sep
(11) |
Oct
(17) |
Nov
(8) |
Dec
(16) |
2009 |
Jan
(5) |
Feb
(4) |
Mar
(42) |
Apr
(26) |
May
(34) |
Jun
(16) |
Jul
(6) |
Aug
(29) |
Sep
(28) |
Oct
(16) |
Nov
(8) |
Dec
(24) |
2010 |
Jan
(16) |
Feb
(5) |
Mar
(18) |
Apr
(13) |
May
(21) |
Jun
(41) |
Jul
(10) |
Aug
(18) |
Sep
(16) |
Oct
(10) |
Nov
(27) |
Dec
(4) |
2011 |
Jan
(7) |
Feb
(10) |
Mar
(8) |
Apr
(32) |
May
(13) |
Jun
(23) |
Jul
(43) |
Aug
(19) |
Sep
(27) |
Oct
(122) |
Nov
(42) |
Dec
(10) |
2012 |
Jan
(34) |
Feb
(42) |
Mar
(33) |
Apr
(27) |
May
(32) |
Jun
(42) |
Jul
(71) |
Aug
(34) |
Sep
(10) |
Oct
(24) |
Nov
(97) |
Dec
(15) |
2013 |
Jan
(14) |
Feb
(16) |
Mar
(15) |
Apr
(5) |
May
(4) |
Jun
(13) |
Jul
(9) |
Aug
(18) |
Sep
(23) |
Oct
(15) |
Nov
(24) |
Dec
(7) |
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(14) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(4) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(3) |
2015 |
Jan
(6) |
Feb
(2) |
Mar
|
Apr
(2) |
May
|
Jun
(16) |
Jul
(2) |
Aug
(5) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(10) |
2016 |
Jan
(16) |
Feb
(6) |
Mar
|
Apr
|
May
(10) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
(6) |
Oct
(6) |
Nov
(3) |
Dec
(7) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(19) |
2019 |
Jan
(11) |
Feb
(5) |
Mar
(22) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Hanspeter N. <fi...@sn...> - 2023-09-15 01:08:38
|
macOS 14 (Sonoma) just went into release candidate, so the final will probably be released real soon now. AFAICT, we have support through 14.0RC in master, so in theory a release should be doable. The new release tracker is at https://github.com/fink/fink/issues/254 There are 3 action items there. 1. Sync up files in dists/10.9-libcxxx to match with changes from fink/fink/10.9-libcxx (#250) 2. Add Source-Checksum: SHA256() to stuff in dists/base as well as fink/fink, but this shouldn't be a blocker. (#251) 3. missing apt-get (#252) 4. New passwd release 5. Supposed objtools failure under M1, but I think that should be fixed already (see #236) #1 is very important. Should be straightforward to merge the older .info outside base into base, matching the updates in the bootstrapping tree. z #2 should not be a blocker for now. Having Source-Checksum and Source-MD5 at the same time is OK, but fails if no SHA256 calculator is available. #3 depends on what exactly apt-get is used for internally (recursive remove?) #4 new passwd improves useability with adding users on macOS 12+. I think the current method still works on 12+, but new method behaves better. #5 needs to be confirmed as fixed. Hanspeter -- The appearance of the concept of good and evil, interpreted by man as his expulsion from Paradise, was probably a molecular disease that turned out to be evolution. --E. Zuckerkandl and L. Pauling |
From: dak180 <da...@us...> - 2022-03-01 04:11:32
|
It has been working for me; merge. > On Feb 28, 2022, at 6:01 AM, Hanspeter Niederstrasser <fi...@sn...> wrote: > > Are there any objections *against* merging the dpkg1.16 (now with dpkg-1.19) into fink-master? > > Any outstanding bugs with it might be better dealt with in the main tree rather than in a forked branch. > > Please reply with no-merge or merge. > > Hanspeter > -- > The appearance of the concept of good and evil, interpreted by man as > his expulsion from Paradise, was probably a molecular disease that > turned out to be evolution. > --E. Zuckerkandl and L. Pauling > > > > _______________________________________________ > fink-core mailing list > fin...@li... > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core -------------------------------------------------------------------------- My Web Sites: http://dak180.users.sf.com/ |
From: Hisashi T F. <ht...@tw...> - 2022-02-28 15:51:48
|
On Mon, 28 Feb 2022, Hanspeter Niederstrasser wrote: > Are there any objections *against* merging the dpkg1.16 (now with dpkg-1.19) > into fink-master? > > Any outstanding bugs with it might be better dealt with in the main tree > rather than in a forked branch. > > Please reply with no-merge or merge. It's been working for me, so I'd say merge. -- Hisashi T Fujinaka - ht...@tw... BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee |
From: Hanspeter N. <fi...@sn...> - 2022-02-28 11:01:30
|
Are there any objections *against* merging the dpkg1.16 (now with dpkg-1.19) into fink-master? Any outstanding bugs with it might be better dealt with in the main tree rather than in a forked branch. Please reply with no-merge or merge. Hanspeter -- The appearance of the concept of good and evil, interpreted by man as his expulsion from Paradise, was probably a molecular disease that turned out to be evolution. --E. Zuckerkandl and L. Pauling |
From: <fi...@sn...> - 2021-05-20 00:53:09
|
On 5/15/21 6:07 AM, Hanspeter Niederstrasser wrote: > On 5/12/21 9:07 AM, Hisashi T Fujinaka wrote: >> I think the Xquartz maintainer is reducing his participation so it might >> be quicker to fix it on our end. >> >> On Mon, 10 May 2021, Hanspeter Niederstrasser wrote: >> >>> Hi AIDA, >>> >>> The recent update to Xquartz 2.8 broke the package xinitrc because it >>> moved xinit from X11/lib/X11/xinit to X11/etc/X11/xinit [1]. I was >>> hoping to submit a fix for this change but can't find where the >>> repository might be living. Is it on github? Thanks, Hi Tomoaki, You're listed in Fink's commit logs as having pushed upgrades to Fink's xinitrc package many years ago from v1.0 to v1.3. Do you happen to still have copies around of those source tarballs? We need to update the xinitrc package to deal with the above change to Xquartz itself, and it would be nice to have some of the historical sources. Thanks, Hanspeter -- There are 3 kinds of biologists: those who can count, and those who can't. |
From: Hanspeter N. <fi...@sn...> - 2021-05-15 11:07:55
|
On 5/12/21 9:07 AM, Hisashi T Fujinaka wrote: > I think the Xquartz maintainer is reducing his participation so it might > be quicker to fix it on our end. > > On Mon, 10 May 2021, Hanspeter Niederstrasser wrote: > >> Hi AIDA, >> >> The recent update to Xquartz 2.8 broke the package xinitrc because it >> moved xinit from X11/lib/X11/xinit to X11/etc/X11/xinit [1]. I was >> hoping to submit a fix for this change but can't find where the >> repository might be living. Is it on github? Thanks, I meant in submitting a fix to our xinitrc package to switch to the etc location. So seeing if the code for Aida's xinitrc pkg is maintained anywhere public. As you said, Xquartz will not change xinit back into the lib location used in Xquartz-2.7, so fixes will have to be on our end. Hanspeter |
From: Hisashi T F. <ht...@tw...> - 2021-05-12 14:08:09
|
I think the Xquartz maintainer is reducing his participation so it might be quicker to fix it on our end. On Mon, 10 May 2021, Hanspeter Niederstrasser wrote: > Hi AIDA, > > The recent update to Xquartz 2.8 broke the package xinitrc because it moved > xinit from X11/lib/X11/xinit to X11/etc/X11/xinit [1]. I was hoping to submit > a fix for this change but can't find where the repository might be living. Is > it on github? Thanks, > > [1] https://github.com/XQuartz/XQuartz/issues/167 > > Hanspeter > -- Hisashi T Fujinaka - ht...@tw... BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee |
From: Hanspeter N. <fi...@sn...> - 2021-05-11 00:11:18
|
Hi AIDA, The recent update to Xquartz 2.8 broke the package xinitrc because it moved xinit from X11/lib/X11/xinit to X11/etc/X11/xinit [1]. I was hoping to submit a fix for this change but can't find where the repository might be living. Is it on github? Thanks, [1] https://github.com/XQuartz/XQuartz/issues/167 Hanspeter -- Disclaimer: By sending an email to ANY of my addresses you are agreeing that: 1. I am by definition, "the intended recipient" 2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. 3. I may take the contents as representing the views of your company. 4. This overrides any disclaimer or statement of confidentiality that may be included with your message. |
From: Sebastian P. <seb...@pi...> - 2021-03-25 20:43:31
|
Hello everyone! Expat 2.3.0 — simplified — brings… - bugfixes, - improvements to both build systems, and - improvements to xmlwf usability. Please see the changelog at [1] for more details. If you have patches for Expat that are still required with version 2.3.0, please send them my way. Thank you! Best Sebastian [1] https://github.com/libexpat/libexpat/blob/R_2_3_0/expat/Changes |
From: <fi...@sn...> - 2021-01-04 16:14:45
|
On 12/19/20 6:48 AM, Hanspeter Niederstrasser wrote: > BigSur11.1 broke the kernel version to macOS release mapping that > existed through the entire 10.X series. > > Previously, the major kernel version tracked the minor macOS release > (with a -4 offset). So macOS 10.13 is darwin17, 10.15 is darwin19, etc. > The minor kernel version mostly tracked point updates for a particular > macOS (darwin19.5.0 was 10.15.5, but darwin19.5.6 is both 10.15.6 and > 10.15.7). > > BigSur 11.0 is darwin20.1.0. So the -4 offset no longer held and we > added a conditional to use a -20 offset when translating the kernel > version to the macOS release. > > But BigSur 11.1 is darwin20.2.0. Apple is now using the kernel minor > version to track macOS minor versions. And macOS minor versions are more > frequent than in the past. In the 10.X series, they came annually (High > Sierra, Mojave, Catalina, etc). Now they're coming ~ monthly. > > We're not going to be able to keep making new dists and releases with > every BigSur minor release. Apple seems to be thinking that BigSur minor > releases are like 10.X point releases (11.2 is really like 10.16.2). > > I'm testing a solution that adds a new function > Services.pm::get_kernel_vers_minor() that returns the kernel minor > version, and then instead of mapping darwin20 to 11.(kernel_vers-20), we > do 11.(kernel_vers_minor-1). > This seems to rescue an existing fink install from 11.0 that got > upgraded to 11.1, but bootstrap fails. I've submitted this patch to TheSin's dpkg1.16 branch. It deals with the new way that Apple seems to be tracking darwin version to macOS version. https://github.com/TheSin-/fink/pull/6/commits/193bad7ce8c8b7b481881f044778307bf2527d2d Hanspeter -- "If we knew what it was we were doing, it would not be called research, would it?" --Albert Einstein |
From: Hanspeter N. <fi...@sn...> - 2020-12-19 12:48:57
|
BigSur11.1 broke the kernel version to macOS release mapping that existed through the entire 10.X series. Previously, the major kernel version tracked the minor macOS release (with a -4 offset). So macOS 10.13 is darwin17, 10.15 is darwin19, etc. The minor kernel version mostly tracked point updates for a particular macOS (darwin19.5.0 was 10.15.5, but darwin19.5.6 is both 10.15.6 and 10.15.7). BigSur 11.0 is darwin20.1.0. So the -4 offset no longer held and we added a conditional to use a -20 offset when translating the kernel version to the macOS release. But BigSur 11.1 is darwin20.2.0. Apple is now using the kernel minor version to track macOS minor versions. And macOS minor versions are more frequent than in the past. In the 10.X series, they came annually (High Sierra, Mojave, Catalina, etc). Now they're coming ~ monthly. We're not going to be able to keep making new dists and releases with every BigSur minor release. Apple seems to be thinking that BigSur minor releases are like 10.X point releases (11.2 is really like 10.16.2). I'm testing a solution that adds a new function Services.pm::get_kernel_vers_minor() that returns the kernel minor version, and then instead of mapping darwin20 to 11.(kernel_vers-20), we do 11.(kernel_vers_minor-1). This seems to rescue an existing fink install from 11.0 that got upgraded to 11.1, but bootstrap fails. Thoughts? Hanspeter |
From: Hanspeter N. <fi...@sn...> - 2020-09-02 21:29:05
|
If I understand this correctly: Old deb with old dpkg: .la files inside .deb have dependency_libs populated. dpkg clears them out during post install using %p/lib/fink/dpkg-base-files/postinst. The actual deb doesn't have the code to clean the .la files New deb with new dpkg: dependency_libs in .la files are cleared when the deb is being built. dpkg doesn't do anything to the .la files during post inst segment. Old deb with new dpkg: New dpkg still calls %p/lib/fink/dpkg-base-files/postinst to clear .la files if triggered. If a new tree is made w/ no upgrade path, then the trigger to clean old debs in postinst is no longer needed. Hanspeter On 8/29/20 11:16 AM, Justin Hallett wrote: > The old debs will still work the same way as it’s part of the postinstscript. > > Just the content in the deb of the la files will differ the end result will be the same. > --- > TS > http://www.southofheaven.org/ > Life begins and ends with chaos, live between the chaos! > >> On Aug 28, 2020, at 10:31 PM, Daniel Macks <dm...@ne...> wrote: >> >> (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" <th...@so...> 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, fi...@sn... 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 >> <ale...@gm...> wrote: >> On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser >> <fi...@sn...> 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 |
From: Justin H. <th...@so...> - 2020-08-29 16:16:14
|
The old debs will still work the same way as it’s part of the postinstscript. Just the content in the deb of the la files will differ the end result will be the same. --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! > On Aug 28, 2020, at 10:31 PM, Daniel Macks <dm...@ne...> wrote: > > (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" <th...@so...> 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, fi...@sn... 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 > <ale...@gm...> wrote: > On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser > <fi...@sn...> 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 > fin...@li... > 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 > fin...@li... > 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 > fin...@li... > 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 > fin...@li... > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core |
From: Daniel M. <dm...@ne...> - 2020-08-29 04:31:28
|
(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" <th...@so...> 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, fi...@sn... 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 <ale...@gm...> wrote: On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser <fi...@sn...> 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 fin...@li... 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 fin...@li... 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 fin...@li... List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core |
From: Justin H. <th...@so...> - 2020-08-28 19:24:03
|
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, fi...@sn... 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 >>> <ale...@gm...> wrote: >>>> On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser >>>> <fi...@sn...> 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 >>> fin...@li... >>> 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 >> fin...@li... >> List archive: >> http://news.gmane.org/gmane.os.apple.fink.core >> Subscription management: >> https://lists.sourceforge.net/lists/listinfo/fink-core |
From: <fi...@sn...> - 2020-08-28 19:17:52
|
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 >> <ale...@gm...> wrote: >> >>> On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser >>> <fi...@sn...> 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 >> fin...@li... >> 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 > fin...@li... > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core |
From: Justin H. <th...@so...> - 2020-08-28 17:18:15
|
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 <ale...@gm...> wrote: > > > >> On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser <fi...@sn...> 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 > fin...@li... <mailto:fin...@li...> > List archive: > http://news.gmane.org/gmane.os.apple.fink.core <http://news.gmane.org/gmane.os.apple.fink.core> > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core <https://lists.sourceforge.net/lists/listinfo/fink-core> |
From: Alexander H. <ale...@gm...> - 2020-08-28 15:58:19
|
> On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser <fi...@sn...> 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 |
From: Hanspeter N. <fi...@sn...> - 2020-08-28 09:43:37
|
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 |
From: Hanspeter N. <fi...@sn...> - 2020-04-27 11:23:40
|
Hi Daniel, Hope things are OK with you in our current situation. What's the status of your Fink packages? There are several issues and pull requests related to Fink's python packages that have not received any response. Should we proceed with these, especially those that are FTBFS? https://github.com/fink/fink-distributions/pulls/review-requested/danielj7 Please let us know. Thanks, Hanspeter |
From: Hanspeter N. <fi...@sn...> - 2020-03-25 21:29:35
|
Can I please get a review for fink PR #200: https://github.com/fink/fink/pull/200 This makes zsh a known shell inside the pathsetup script. 10.15 defaults to zsh, so we should make this work for new 10.15 users. Hanspeter |
From: Sebastian P. <seb...@pi...> - 2019-09-14 20:33:21
|
Hello everyone! To be quick, there is one heap buffer over-read DoS fix — for CVE-2019-15903 [1] —, two other bugfixes, and build system fixes. The change log with details is up at [2]. I don't expect use of the new configure option --enable-xml-attr-info in packaging anywhere, it's disabled everywhere else. In case anyone is using CMake in packaging Expat already, please share any pain points and issues with me so things get better next round. If you happen to have patches for Expat that are still required with 2.2.8, please send them my way. Thanks and best Sebastian [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15903 [2] https://github.com/libexpat/libexpat/blob/R_2_2_8/expat/Changes |
From: Hanspeter N. <fi...@sn...> - 2019-07-13 23:23:49
|
Now that Fink HEAD knows about dist 10.14.5 and 10.15, is there any reason to not merge the updates to fink-distributions so we can have necessary packages available there (such as perlXXX, texinfo, gccX, etc)? https://github.com/fink/fink-distributions/pull/423 Hanspeter |
From: Sebastian P. <seb...@pi...> - 2019-06-27 23:57:10
|
Hello everyone! Sorry for the noise if you heard about the release of 2.2.7 about a week ago through some other channel and maybe even took action, already! To be quick, there is one DoS fix — for CVE-2018-20843 [1] — and misc build system fixes. The change log with details is up at [2]. If you happen to have patches for Expat that are still required with 2.2.7, please send them my way. Thanks and best Sebastian [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20843 [2] https://github.com/libexpat/libexpat/blob/R_2_2_7/expat/Changes |
From: Hanspeter N. <fi...@sn...> - 2019-06-07 01:04:04
|
On 6/6/19 7:58 PM, Hanspeter Niederstrasser wrote: > According to Apple's 10.15beta release notes: > > * During upgrades to macOS 10.15, files and folders stored at the > root-level of a volume are moved aside to > /Library/SystemMigration/History/Migration-UUID/QuarantineRoot/. (45378791) > > It has a radar#, so hopefully that'll be taken care of before the final > release. If anyone has installed the 10.15beta, what version of Perl does Catalina ship with in /usr/bin/perl (if not bound by an NDA)? Hanspeter |