Gene,
it looks like the syslinux master branch is broken since February [1].
Peter created the wip.makefixes branch but I wasn't able to get it
working (yet) and it lacks activity since March.
I think it might be time to revert commit 458a54133ecd ("Fix all
warnings, and better separate code that should not be mixed") which
broke master. Then apply at least the outstanding patch "Force the
linker to put all sections into a single PT_LOAD segment" [2] from
Debian which is required for EFI. And maybe tag the result as
syslinux-6.04-pre4.
[1] https://www.syslinux.org/archives/2019-February/026335.html
[2] https://www.syslinux.org/archives/2018-August/026167.html
Sebastian
> it looks like the syslinux master branch is broken since February [1]. > Peter created the wip.makefixes branch but I wasn't able to get it > working (yet) and it lacks activity since March.Since you are mentioning it in your email, I would like to bring up a complication of merging almost anything from the "wip.makefixes" branch onto the master branch. One of the things that Peter performed in the "wip.makefixes" branch was to move around a lot of files. This "shuffling" has a very important negative consequence, at least at this time. Considering the lack of active development of the last few years, most Linux distributions have been picking up patches and workarounds in order to (barely) "maintain" their Syslinux-related packages. In more than a few cases, those patches and workarounds are not provided by upstream Syslinux nor included in the official upstream repositories. Using this "method", Linux distros are (currently) using very different versions of Syslinux, from 4.04 onward. "Shuffling around" files in current git master would imply that prior patches and workarounds that have been ignored by upstream Syslinux while embraced by downstream package maintainers would be much harder to apply in different distros/packages in the future. Moreover, if at some point someone would decide to pick up Syslinux's development, proposed patches that are still "awaiting" for some reaction from upstream Syslinux would be useless after this massive "shuffling" of files. To be clear, there are more-than-just-a-few of those previously-ignored proposed patches. One additional negative aspect of this massive "shuffling" of files is documentation. For some time now, I've been updating documents in the wiki, including paths that are mentioned, even in the wikified official documents. It would be very inconvenient and confusing, for users and package maintainers alike, to have paths being relevant "from 5.00 to 6.04-pre1" while other, different paths would be relevant "from 6.04-pre4". Moving around files in such way also complicates things when trying to track down specific changes, especially when searching for bugs that were introduced in the code before such shuffling. If development of Syslinux had been much more active, someone could claim that this massive "shuffling" of files is necessary in order to keep the code clean and continue with development of features (and solving bugs). But in such hypothetical case, Syslinux would be at a "higher" version number by now, and "active and continuous development" (together with a "higher" version number) would introduce more "sense" in the reasoning for this massive shuffling of files. I claim that we should be more realistic, and there is no sign of "active and continuous development" in the near future for Syslinux. I do have comments regarding the current status of git master (which is either FTBFS or the resulting binaries are not working as expected), but I'd rather leave them for some future email. I very much hope (and even "beg") that the massive "shuffling" of files that is currently seen in the "wip.makefixes" branch is _not_ merged onto the master branch. I think that the negative consequences are much greater than the potential benefits at this time. Thank you and Best Regards, Ady.
Hello, On 7/7/19 11:13 PM, Ady Ady via Syslinux wrote: ...> "Shuffling around" files in current git master would imply that prior > patches and workarounds that have been ignored by upstream Syslinux > while embraced by downstream package maintainers would be much harder > to apply in different distros/packages in the future. Moreover, if at > some point someone would decide to pick up Syslinux's development, > proposed patches that are still "awaiting" for some reaction from > upstream Syslinux would be useless after this massive "shuffling" of > files. To be clear, there are more-than-just-a-few of those > previously-ignored proposed patches. > > One additional negative aspect of this massive "shuffling" of files is > documentation. For some time now, I've been updating documents in the > wiki, including paths that are mentioned, even in the wikified official > documents. It would be very inconvenient and confusing, for users and > package maintainers alike, to have paths being relevant "from 5.00 to > 6.04-pre1" while other, different paths would be relevant "from > 6.04-pre4". > > Moving around files in such way also complicates things when trying to > track down specific changes, especially when searching for bugs that > were introduced in the code before such shuffling. > > If development of Syslinux had been much more active, someone could > claim that this massive "shuffling" of files is necessary in order to > keep the code clean and continue with development of features (and > solving bugs). But in such hypothetical case, Syslinux would be at a > "higher" version number by now, and "active and continuous development" > (together with a "higher" version number) would introduce more "sense" > in the reasoning for this massive shuffling of files. I claim that we > should be more realistic, and there is no sign of "active and > continuous development" in the near future for Syslinux. > > I do have comments regarding the current status of git master (which is > either FTBFS or the resulting binaries are not working as expected), > but I'd rather leave them for some future email.... As an aside (off topic, but triggered by the quoted message): I provide at time of writing for the Slint ditribution (Slackware derivative, polyglot and more accessible to blind and partially sighted users): 1. installation ISOs like found here: http://slackware.uk/slint/x86_64/slint-14.2.1/iso/ that rely for booting on isolinux in DOS aka Legacy mode, GRUB in EFI mode, 2. installation of GRUB to boot the installed system, and possibly other systems found in the same machine, 3. ability to make USB boot sticks using syslinux/GRUB respectively to help in case booting the installed system from the device where it is installed fails. Now that GRUB 2.04 has been released, I plan to rely on it exclusively for aforementioned features in next Slint version, in all contexts, i.e. EFI and Legacy booting. Preliminary tests didn't raise issues, but is there any caveat doing that? More generally, are here still unique features provided by SYSLINUX, PXELINUX, ISOLINUX and EXTLINUX that I would miss using GRUB? Best regards, Didier
On July 7, 2019 8:37:10 AM PDT, Sebastian Herbszt <herbszt at gmx.de> wrote:>Gene, > >it looks like the syslinux master branch is broken since February [1]. >Peter created the wip.makefixes branch but I wasn't able to get it >working (yet) and it lacks activity since March. > >I think it might be time to revert commit 458a54133ecd ("Fix all >warnings, and better separate code that should not be mixed") which >broke master. Then apply at least the outstanding patch "Force the >linker to put all sections into a single PT_LOAD segment" [2] from >Debian which is required for EFI. And maybe tag the result as >syslinux-6.04-pre4. > >[1] https://www.syslinux.org/archives/2019-February/026335.html >[2] https://www.syslinux.org/archives/2018-August/026167.html > >SebastianCould you make a tree that I can pull? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
hpa wrote:> On July 7, 2019 8:37:10 AM PDT, Sebastian Herbszt <herbszt at gmx.de> > wrote: > >Gene, > > > >it looks like the syslinux master branch is broken since February > >[1]. Peter created the wip.makefixes branch but I wasn't able to get > >it working (yet) and it lacks activity since March. > > > >I think it might be time to revert commit 458a54133ecd ("Fix all > >warnings, and better separate code that should not be mixed") which > >broke master. Then apply at least the outstanding patch "Force the > >linker to put all sections into a single PT_LOAD segment" [2] from > >Debian which is required for EFI. And maybe tag the result as > >syslinux-6.04-pre4. > > > >[1] https://www.syslinux.org/archives/2019-February/026335.html > >[2] https://www.syslinux.org/archives/2018-August/026167.html > > > >Sebastian > > Could you make a tree that I can pull?A temporary branch named 20190708 is now available at git://repo.or.cz/syslinux/sherbszt.git Sebastian
hpa wrote:> On July 7, 2019 8:37:10 AM PDT, Sebastian Herbszt <herbszt at gmx.de> > wrote: > >Gene, > > > >it looks like the syslinux master branch is broken since February > >[1]. Peter created the wip.makefixes branch but I wasn't able to get > >it working (yet) and it lacks activity since March. > > > >I think it might be time to revert commit 458a54133ecd ("Fix all > >warnings, and better separate code that should not be mixed") which > >broke master. Then apply at least the outstanding patch "Force the > >linker to put all sections into a single PT_LOAD segment" [2] from > >Debian which is required for EFI. And maybe tag the result as > >syslinux-6.04-pre4. > > > >[1] https://www.syslinux.org/archives/2019-February/026335.html > >[2] https://www.syslinux.org/archives/2018-August/026167.html > > > >Sebastian > > Could you make a tree that I can pull?A new temporary branch named 20190723 is now available at git://repo.or.cz/syslinux/sherbszt.git It contains the following commits: d9374841 Add exp function 303c54a0 Some fixes from commit 458a5413 e8df886e Force the linker to put all sections into a single PT_LOAD segment 1a18b2ee Revert "Fix all warnings, and better separate code that should not be mixed" Sebastian