cucumber-linux-development Mailing List for Cucumber Linux
A general purpose desktop and server Linux distribution.
Brought to you by:
z5t1
Menu
▾
▴
cucumber-linux-development — Development discussion mailing list.
You can subscribe to this list here.
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(21) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Scott C. <sc...@cu...> - 2019-05-09 18:59:26
|
Hello All, The Linux kernel has just been updated from 4.14 to 4.19 on Cucumber Linux 2.0. Like all major kernel updates, this introduces a bunch of nifty new features and has the potential to break existing features, so caveat emptor to all 2.0 users. If you can, please help us test out the new kernel (especially on new physical hardware) to make sure everything works as expected. Thanks, and happy hacking! - Scott |
|
From: Scott C. <sc...@cu...> - 2019-04-02 21:44:48
|
Hello All, As many of you may have noticed, there has been a *lack of activity with the Cucumber Linux Project* in the past month and a half. Truthfully, life has been busy lately and I was starting to suffer from burnout, so I needed to take a break. Prior to this, I had not had a break of more than a few days since I started the project back in May of 2016, so I feel that this has been long overdue. Now, as I return to work on Cucumber Linux, I am realizing that this project has grown substantially since its beginnings in 2016 and it has reached a point where I can no longer do everything on my own. If Cucumber Linux is going to continue on for the long term, *I need help*. Here's an *overview of where we stand right now*: Cucumber Linux 2.0 is still in development and /really needs/ to see a release in the next six months. While this is happening, Cucumber Linux 1.1 still needs maintenance. The attempt to transition to GitLab did not work out, and now I'm migrating everything back to GitHub. Our security tracker and model is having more and more difficulty keeping up with our needs and it needs an overhaul. In order to remedy this, I have come up with the following to *do list and action plan*, conveniently formatted in Markdown: # What Needs to be Done * Improve Security Tracker & Integrate it with the Source Tree * Security Fixes * Update Packages for Cucumber Linux 2.0 * Release Cucumber Linux 2.0 * Come up with a new distribution lifecycle to make the developers' lives easier. # How to do This 1. Create a maintenance team. * This team will be broken down into subteams for each supported version of Cucumber Linux. * Each subteam will be responsible for building new packages for its version of Cucumber Linux. * Idealy, each subteam will have two leaders: 1. A senior branch maintainer. 2. A junior branch maintainer. * The senior and junior branch maintainers will have the same rights, capabilities and privileges; the difference in titles is really just a formailty. The senior title will go to whichever developer has been part of the Cucumber Linux project longer. * The senior maintainer, junior maintainer and Scott will be the only ones with access to that version's build infrastrucutre. * The senior maintainer and junior maintainer will be responsible for building and publishing updated packages for their version of Cucumber Linux. * The senior and junior branch maintainers will be the ones who merge changes into their version's source tree. * The maintenance team's primary goal should be keeping the distribution stable. 2. Create a security team. * This team will be responsible for the following one time actions: * Making a better security tracker. * Exporting the database from the old tracker to the new one. * The security team will then be responsible for the following actions: * Ensure entries for vulnerabilities are made in the security tracker. * Analyze new vulnerabilities against all supported versions of Cucumber Linux and determine what actions need to be taken. * Notify the individual Cucumber Linux branch maintainers of what actions need to be taken to patch the vulnerability on each supported version of Cucumber Linux. * The security team's primary goal should be keeping the distribution secure. 3. Create a development team. * This team will responsible for developing the unstable version of Cucumber Linux. * This team's primary goals should be designing new versions of the distribution and keeping the packages in the unstable version up to date. 4. Create a few supporting positions/teams: * Recruitment - This position will be responsible for recruiting new developers, maintainers and security analysts. * Public Relations - This position will be responsible for promoting Cucumber Linux and building a positive community around the project. # Positions to Fill * Maintenance Team: * 1.1 * Senior Branch Maintainer: Scott Court * Junior Branch Maintainer: **Help Wanted** * Security Team: * Security Analysts (Several): * Scott Court * **Help Wanted** * Development Team: * Development Branch Maintainers * Senior Branch Maintainer: Scott Court * Junior Branch Maintainer: **Help Wanted** * Developers (Several): * Scott Court * **Help Wanted** * Security Tracker Developer: **Help Wanted** * Supporting Positions * Recruitment: **Help Wanted** * Public Relations: **Help Wanted** In the near(ish) future, both a Senior and Junior Branch Maintainer will be needed for the Cucumber Linux 2.0 branch. We will put out a call for these positions as we get closer to a 2.0 stable release. # Priorities This is the priority for filling these positions: 1. 1.1 Junior Branch Maintainer 2. Security Tracker Developer 3. Security Analysts 4. Developers 5. Public Relations 6. Recruitment 7. Development Junior Branch Maintainer For the jobs marked as **Help Wanted**, *I would really appreciate any help that anyone can give*. If you are interested in any of these jobs and have some free time, please send me an email. Keep in mind that right now I am doing literally all of this work, so any contribution in any department (regardless of what the priority is or how large it is) will lessen my burden and be much appreciated. Please don't view these positions as a minimum amount of how much you should contribute, and certainly feel free to volunteer for more than one position if you'd like. Thank you for taking the time to read this very long email, and here's to a bright future for Cucumber Linux. - Scott |
|
From: Scott C. <sc...@cu...> - 2019-01-09 15:11:20
|
Hello All, I know it's been a while, but I'm excited to finally announce that the Cucumber Linux 2.0 build system is up and running! The build system has been largely rewritten since Cucumber Linux 1.1 to provide a much more streamlined workflow. All of the scripts for running the build/mirror system are also now available on our GitLab server at https://gitlab.cucumberlinux.com/cucumber/buildtools. I've also written some documentation on how the build system works on the wiki (see https://wiki.cucumberlinux.com/wiki/devdocs:start#maintainer_s_guide). Now that this is done, *binary updates will be available for Cucumber Linux 2.0 from here on out*. If you are using Cucumber Linux 2.0 Alpha, you will need to make a change to your /etc/pickle.conf file so that you are prompted to install the new binary packages when running 'pickle': find the line IGNORE_NEW_PACKAGES=true and change it to IGNORE_NEW_PACKAGES=false - Scott |
|
From: Scott C. <sc...@cu...> - 2018-11-30 16:25:17
|
Synopsis This is the official notice that Cucumber Linux 1.0 has reached its end of life (as of November 30, 2018). In summary this means that the Cucumber Linux Security Team will no longer provide any security or bug fixes for Cucumber Linux 1.0. We strongly recommend that any and all remaining users of Cucumber Linux 1.0 upgrade their systems to Cucumber Linux 1.1 as soon as possible. Cucumber Linux 1.1 will be fully supported through the end of 2019 and selectively supported into 2020. Upgrading to Cucumber Linux 1.1 Cucumber Linux 1.1 is a minor release of Cucumber Linux 1.x. Sticking with the Cucumber Linux support policy, the process of upgrading from Cucumber Linux 1.0 to 1.1 is designed to be as unintrusive as possible. It is possible to update a live system and most systems can be updated in less than 20 minutes without any downtime. A full guide for upgrading can be found at https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html. Resources * Cucumber Linux 1.0 Lifecycle: https://cucumberlinux.com/lifecycle/cucumber_linux_1.0.html * The Cucumber Linux Support Policy: https://cucumberlinux.com/support_policy.php * Guide for Upgrading to Cucumber Linux 1.1: https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html * Supported Versions of Cucumber Linux: https://cucumberlinux.com/supported_versions.php |
|
From: Scott C. <sc...@cu...> - 2018-11-18 00:38:05
|
The first alpha for Cucumber Linux 2.0 is now available. Several packages have been updated from Cucumber Linux 1.1, including Linux, GCC, glibc, binutils, OpenSSH, MariaDB, Rsync, Perl and PHP. Additionally, LibreSSL and Neovim make their debut. This release is intended for early testing purposes as it contains only a subset of the packages that will be included in the final release. New packages will be installable via pickle <https://wiki.cucumberlinux.com/wiki/package_management#update_management> as they become available. The installable ISO files are available for download at the download page <https://z5t1.com/cucumber/download.php>. Starting with this release, we will no longer be providing basic ISO images; users will need to use a DVD or USB flash drive to install. The full list of changes can be found in the CHANGELOGs <https://z5t1.com/cucumber/changelog.php> and on GitHub <https://github.com/cucumberlinux/ports/commits/sysbuild18002>. |
|
From: Scott C. <sc...@cu...> - 2018-10-01 21:18:15
|
Synopsis This is the official notice that Cucumber Linux 1.0 has reached its end of full support (as of September 30, 2018) and is now in selective support. In summary this means that the Cucumber Linux Security Team is no longer able to guarantee the security of systems running Cucumber Linux 1.0. During selective support we will continue to publish security patches when possible through November 30, 2018; however, we make no guarantees. After November 30, 2018 we will provide no further security updates for Cucumber Linux 1.0 whatsoever. Complete details about the Cucumber LInux 1.0 Lifecycle can be found on the Cucumber Linux 1.0 Lifecycle page <https://cucumberlinux.com/lifecycle/cucumber_linux_1.0.html>. We strongly recommend that all users of Cucumber Linux 1.0 begin upgrading their systems to Cucumber Linux 1.1. Cucumber Linux 1.1 will be fully supported through the end of 2019 and selectively supported into 2020, as the table below shows: +-------------+-------------------------+-------------------+ | Version | End of Full Support | End of Life | +-------------+-------------------------+-------------------+ | 1.1 | December 31, 2019 | March 31, 2020 | +-------------+-------------------------+-------------------+ | 1.0 | September 30, 2018 | November 30, 2018 | +-------------+-------------------------+-------------------+ Upgrading to Cucumber Linux 1.1 Cucumber Linux 1.1 is a minor release of Cucumber Linux 1.x. Sticking with the Cucumber Linux support policy, the process of upgrading from Cucumber Linux 1.0 to 1.1 is designed to be as unintrusive as possible. It is possible to update a live system and most systems can be updated in less than 20 minutes without any downtime. A full guide for upgrading can be found at https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html. Resources * Cucumber Linux 1.0 Lifecycle: https://cucumberlinux.com/lifecycle/cucumber_linux_1.0.html * The Cucumber Linux Support Policy: https://cucumberlinux.com/support_policy.php * Guide for Upgrading to Cucumber Linux 1.1: https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html * Supported Versions of Cucumber Linux: https://cucumberlinux.com/supported_versions.php |
|
From: Scott C. <sc...@cu...> - 2018-09-01 14:47:57
|
Synopsis This is the second notice that Cucumber Linux 1.0 will reach its end of full support in one month on September 30, 2018. In summary this means that as of October 1, 2018 the Cucumber Linux Security Team will no longer be able to guarantee the security of systems running Cucumber Linux 1.0. After this date, Cucumber Linux 1.0 will enter selective support for two months. During selective support we will continue to publish security patches when possible through November 30, 2018; however, we make no guarantees. After November 30, 2018 we will provide no further security updates for Cucumber Linux 1.0 whatsoever. Complete details about the Cucumber LInux 1.0 Lifecycle can be found on the Cucumber Linux 1.0 Lifecycle page <https://cucumberlinux.com/lifecycle/cucumber_linux_1.0.html>. We strongly recommend that all users of Cucumber Linux 1.0 begin upgrading their systems to Cucumber Linux 1.1. Cucumber Linux 1.1 will be fully supported through the end of 2019 and selectively supported into 2020, as the table below shows: +-------------+-------------------------+-------------------+ | Version | End of Full Support | End of Life | +-------------+-------------------------+-------------------+ | 1.1 | December 31, 2019 | March 31, 2020 | +-------------+-------------------------+-------------------+ | 1.0 | September 30, 2018 | November 30, 2018 | +-------------+-------------------------+-------------------+ Upgrading to Cucumber Linux 1.1 Cucumber Linux 1.1 is a minor release of Cucumber Linux 1.x. Sticking with the Cucumber Linux support policy, the process of upgrading from Cucumber Linux 1.0 to 1.1 is designed to be as unintrusive as possible. It is possible to update a live system and most systems can be updated in less than 20 minutes without any downtime. A full guide for upgrading can be found at https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html. Resources * Cucumber Linux 1.0 Lifecycle: https://cucumberlinux.com/lifecycle/cucumber_linux_1.0.html * The Cucumber Linux Support Policy: https://cucumberlinux.com/support_policy.php * Guide for Upgrading to Cucumber Linux 1.1: https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html * Supported Versions of Cucumber Linux: https://cucumberlinux.com/supported_versions.php |
|
From: Scott C. <sc...@cu...> - 2018-08-30 22:41:34
|
Hello All, On 2018-05-15, I sent an email informing everyone that we were going to be starting out with 3 phases for the Cucumber Linux 2.0 build process. The original way we were going to divide the process into the 3 phases has proven problematic for a couple of reasons, so we will be adding a fourth phase in between what was previously phases 2 and 3. The phase that used to be phase 3 is now phase 4, and the the new phase is now phase 3. The full details are explained in the commit message at https://github.com/cucumberlinux/ports/commit/3d0fe32a0ff291a59ca4aba4422efa996b02b559. The Cucumber Linux from Scratch wiki page has also been updated to reflect the changes at https://wiki.cucumberlinux.com/wiki/cucumber_linux_from_scratch. - Scott |
|
From: Scott C. <sc...@cu...> - 2018-07-24 18:51:34
|
Hello All, As you all know, we have two different installer ISOs available for each version of Cucumber Linux: the Basic Edition and the Full Edition. If you're not familiar with why this is the case, an explanation can be found at https://cucumberlinux.com/editions.php. Publishing a basic ISO in its current form requires that every package group be split into two subgroups: a Basic subgroup and a General subgroup (i.e. net-base and net-general), with only the basic subgroup being included on the CD installer (Basic Edition), and both subgroups being included on the DVD installer (Full Edition). Furthermore, care must be taken to ensure that all of the Basic subgroups are under 650 MB when combined (so they fit on a single CD). I know several of us have been finding the subgroup division to be quite cumbersome and more of a pain than anything else. The only reason we really have it is so that we can continue to publish the Basic Edition ISO and provide an installation image that fits on a single CD. Now CDs are rapidly going the way of the floppy disk. Pretty much every computer I have seen that was made in 2001 or later is capable of booting from a DVD and/or USB flash drive. So that being the case, my question to you all is *should we continue providing the Basic Edition**ISO*? If we do cease providing the Basic Edition ISO, that would enable us to eliminate the subgroup divisions, resulting in a single group for networking applications and so on. The single group approach is also the approach we are taking in the community ports tree (https://github.com/cucumberlinux/ports/tree/master/community), so it would also make the ports tree structure more consistent between the official Cucumber directory and the community directory. Personally, I think the time has come to say goodbye to CDs. *Does anyone see any potential issues with or have any objections **discontinuing installation CD support*? If you do, please speak now. - Scott |
|
From: Scott C. <sc...@cu...> - 2018-07-12 18:30:30
|
Hello All, I am pleased to announce the immediate availability of Cucumber Linux sysbuild 18001. What is a sysbuild you may ask? Every time Cucumber Linux is rebuilt from scratch, it has the potential to end up with a new ABI. Recently, I wrote an article about how to build Cucumber Linux from scratch (https://z5t1.com/cucumber/wiki/cucumber_linux_from_scratch). Now that we have transitioned approximately one third of the packages in the binary distribution to the new build system format, it has become much easier to rebuild the system from scratch. This is good because it makes it much easier to test ABI breaking changes. The drawback to this though is that it will result in a large amount of ABI diversity across different development builds. In order to differentiate between the different ABIs, each new build of the system will be given a unique sysbuild number to identify it. More details and a list of sysbuilds can be found at https://z5t1.com/cucumber/wiki/devdocs:sysbuild_numbers. This new sysbuild was built from the Cucumber Linux 2.0 source tree. I have tagged the point at which it was built as a pre-release (https://github.com/cucumberlinux/ports/releases/tag/sysbuild18001). This build contains only the packages found in phase 2 and will receive no security updates. It is intended to be used only in testing environments, primarily for testing the new toolchain and system utilities. *Do not use it in a production environment*. Once enough of the phase 3 packages are updated for the ports tree to become self hosted I will make a second sysbuild. That sysbuild will become the first alpha for Cucumber Linux 2.0 and will be used to build the rest of the packages in the ports tree once they get updated. You can download sysbuild 18001 at https://cucumberlinux.com/all_downloads.php#sysbuild18001. Happy Hacking, - Scott |
|
From: Scott C. <sc...@cu...> - 2018-06-29 17:00:57
|
Synopsis This is a notice that Cucumber Linux 1.0 will reach its end of full support in three months on September 30, 2018. In summary this means that as of October 1, 2018 the Cucumber Linux Security Team will no longer be able to guarantee the security of systems running Cucumber Linux 1.0. After this date, Cucumber Linux 1.0 will enter selective support for two months. During selective support we will continue to publish security patches when possible through November 30, 2018; however, we make no guarantees. After November 30, 2018 we will provide no further security updates for Cucumber Linux 1.0 whatsoever. More details can be found in the Cucumber Linux Support Policy <https://cucumberlinux.com/support_policy.php>. We strongly recommend that all users of Cucumber Linux 1.0 begin upgrading their systems to Cucumber Linux 1.1. Cucumber Linux 1.1 will be fully supported through the end of 2019 and selectively supported into 2020, as the table below shows: +-------------+-------------------------+-------------------+ | Version | End of Full Support | End of Life | +-------------+-------------------------+-------------------+ | 1.1 | December 31, 2019 | March 31, 2020 | +-------------+-------------------------+-------------------+ | 1.0 | September 30, 2018 | November 30, 2018 | +-------------+-------------------------+-------------------+ Upgrading to Cucumber Linux 1.1 Cucumber Linux 1.1 is a minor release of Cucumber Linux 1.x. Sticking with the Cucumber Linux support policy, the process of upgrading from Cucumber Linux 1.0 to 1.1 is designed to be as unintrusive as possible. It is possible to update a live system and most systems can be updated in less than 20 minutes without any downtime. A full guide for upgrading can be found at https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html. Resources * The Cucumber Linux Support Policy: https://cucumberlinux.com/support_policy.php * Guide for Upgrading to Cucumber Linux 1.1: https://cucumberlinux.com/upgrade_guide/cucumber_linux_1.1.html * Supported Versions of Cucumber Linux: https://cucumberlinux.com/supported_versions.php |
|
From: Scott C. <sc...@cu...> - 2018-06-07 19:30:17
|
Hello all, I have an exciting announcement to make: our much anticipated *infrastructure upgrade* is complete! We have retired our old, ancient build server (circa 2007) and replaced it with a newer server consisting of two 8 core hyper threaded Intel Xeon processors (that's 32 logical cores), 64 GB of RAM and 5 TB of usable storage. This new build server will enable us to maintain up to four versions of Cucumber Linux at a time; previously, we could maintain only two. This means we now have the infrastructure in place to start building the official Cucumber Linux 2.0 release, which segues nicely to my next point. We are currently 75% of the way done with updating the *phase 2 packages* for Cucumber Linux 2.0. Here's my rough plan: My hope is to have them done next week. Once all the phase 2 packages and lfscript (https://github.com/cucumberlinux/lfscript) are updated, I will do an initial experimental build of Cucumber Linux 2.0. After that is done, we will tweak the phase 2 packages and begin converting/updating the phase 3 packages. After all of that is done, I will do a full rebuild of the distribution and that will hopefully become the final Cucumber Linux 2.0 release. Keep in mind that this is just a plan, and as Winston Churchill said plans are useless, but planning is essential. - Scott |
|
From: Scott C. <sc...@cu...> - 2018-05-17 02:54:20
|
Hello all, In case you haven't heard, we've reached the point where we are converting the Cucumber Linux 1.x buildscripts to Cucumber Linux 2.x buildinfos and updating the packages. We are starting by converting and updating the phase 2 packages only. To coordinate the effort, we are keeping track of who is responsible for converting and updating each package in a spreadsheet at https://docs.google.com/spreadsheets/d/1wz0QenLKYio_4zqJZsloEqlsXk5LfBrb34N6jiZ60eQ/edit#gid=0. If you would like to volunteer to convert and/or update a package, that would be much appreciated; please sign up on that spreadsheet (email me if you are having trouble accessing it). Instructions for what needs to be done to update a package can be found at https://github.com/cucumberlinux/ports/blob/master/utilities/documentation/instructions-for-updating-packages-1.1-to-2.0. If you are going to be helping convert and/or update packages, please read through them. We have 75 packages that need to be updated for phase 2. That may seem like a lot, but if everyone who is signed up can do 3 packages a day, we will have this done in less than 10 days. Sorry, this part might not be a lot of fun but I really appreciate everyone helping with it. - Scott |
|
From: LM <lm...@gm...> - 2018-05-16 19:47:23
|
On Wed, May 16, 2018 at 10:53 AM, Scott Court <sc...@cu...> wrote: > Cons: > > Lack of features. NetBSD curses does not support all of the features of > Ncurses. This means there will be some code breakage if we do make the > switch, which will likely force us to create our own patches to get certain > applications to work. Some other distributions are using it, so there are already patches available for some common packages that might need it. Some packages will work out of the box and be compatible. I use pdcurses with SDL backend (which can work with DirectFB) for some of the packages I build. Switching between different versions of curses wasn't hard for the applications build from source and use. Thought I'd throw it out as an interesting package option. I'm going to be experimenting with it in place of pdcurses for some of my Linux based packages builds. Sincerely, Laura |
|
From: Scott C. <sc...@cu...> - 2018-05-16 14:52:28
|
I had not looked into using NetBSD curses instead of ncurses. Thanks for
sharing. It's an interesting idea, and looking into it now here are my
thoughts:
Pros:
1. Security. Ncurses has a lot of security related problems (see
https://security.cucumberlinux.com/security/table.php?type=ALL&page_size=10&search=ncurses,
and that's just since last September). The upstream developers do a
really poor job of addressing them. NetBSD curses has had
significantly fewer vulnerabilities in that same amount of time.
This is probably at least partially due to the fact that NetBSD
curses has a substantially smaller user base than Ncurses, so I'm
not really sure that NetBSD curses is necessarily more secure than
Ncurses. Also the NetBSD project as a whole is not too concerned
with security so this could be a con as well. That being said though
NetBSD curses does have a substantially smaller code base, which
means less attack surface which generally (but not always)
correlates to fewer vulnerabilities and better security.
2. Less bloat, and consequentially faster execution.
3. Simpler design, which is easier to understand.
Cons:
1. Lack of features. NetBSD curses does not support all of the features
of Ncurses. This means there will be some code breakage if we do
make the switch, which will likely force us to create our own
patches to get certain applications to work.
2. Poorer documentation. Ncurses is very well documented, whereas
NetBSD curses is not. There are several cases where the only
documentation for NetBSD curses is the actual header files. This
would make our job substantially harder, and it would also make it
more difficult for end user to develop/compile programs using curses.
3. Smaller support base. It appears that Sabotage Linux is the only
group maintaining a portable version of NetBSD curses, and they
apparently have only two developers (I can't knock them for this
though because we don't really have them beat by far). That being
said, their curses repository hasn't seen a commit in over five
months, their primary repository
(https://github.com/sabotage-linux/sabotage) hasn't seen a commit
since the beginning of April and their mailing list has been silent
for over two years. That being the case, if we do adopt NetBSD
curses there is a good chance we will ultimately have to maintain
the portable version ourselves.
4. Stability. Pretty much everything is designed to use Ncurses. NetBSD
curses changes certain behaviors in very subtle ways (see
https://wiki.netbsd.org/curses_in_netbsd/). Furthermore these
discrepancies are not well documented. I'm worried that the switch
would have a negative impact on the stability of curses applications
and consequentially the stability and usability of the distribution
as a whole.
So looking at all of this now, it looks like if we do make the switch we
will likely have to maintain our own curses library. This includes
security fixes, porting new features and fixing stuff in other packages
when they break as a result of this. I can't speak for the other
developers here, put I personally am not in a position to take on that
sort of commitment on top of everything else. If you or any other
developers would be seriously interested in taking on this
responsibility, then we can discuss this further. Otherwise I believe we
should stick with Ncurses.
- Scott
On 05/16/2018 07:39 AM, LM wrote:
> Was looking through the packages list for Phase II. Was wondering if
> anyone has looked into using BSD-curses (
> https://github.com/sabotage-linux/netbsd-curses ) as an alternative to
> ncurses. I know a few other Linux distributions that have made the
> switch. Think it's great that you're using packages like libressl
> instead of openssl and eudev, sysvinit instead of the systemd
> packages.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cucumber-linux-development mailing list
> Cuc...@li...
> https://lists.sourceforge.net/lists/listinfo/cucumber-linux-development
|
|
From: LM <lm...@gm...> - 2018-05-16 11:39:36
|
Was looking through the packages list for Phase II. Was wondering if anyone has looked into using BSD-curses ( https://github.com/sabotage-linux/netbsd-curses ) as an alternative to ncurses. I know a few other Linux distributions that have made the switch. Think it's great that you're using packages like libressl instead of openssl and eudev, sysvinit instead of the systemd packages. |
|
From: Scott C. <sc...@cu...> - 2018-05-15 22:17:23
|
Hello All,
There's been a lot of talk about this lately, but just in case you've
missed it or want clarification, here is the process we will be using to
build Cucumber Linux 2.0:
We will be breaking the build process down into multiple phases. Each
phase encompasses a different part of the build process. For now, we are
starting with three phases:
Phase 1
Phase 1 roughly corresponds to chapters 1 through 5 of Linux from
Scratch (http://www.linuxfromscratch.org/lfs/view/8.2/). During this
phase, a temporary /tools environment will be built in preparation for
chapter 6. This phase goes up to and includes the "Adjusting the
Toolchain
<http://www.linuxfromscratch.org/lfs/view/8.2/chapter06/adjusting.html>"
step in chapter 6 of Linux from Scratch.
Maarten Hendrickx is in charge of this phase. The process of building
phase 1 will be automated using a modified version of LFScript. For now,
any progress on LFScript and phase 1 will be available on GitHub at
https://github.com/cucumberlinux/lfscript.
Phase 2
Phase 2 roughly corresponds to chapters 6, 7 and 8 of Linux from
Scratch. It will pick up where phase 1 left off. This is the phase where
we will be building the beginnings of the final Cucumber Linux 2.0
system. During this phase, we will be building only a small subset of
the packages that will be included in the final 2.0 release; only the
packages that are necessary to create a bootable system capable of
bootstrapping phase 3 will be included in phase 2. A list of phase 2
packages can be found at
https://docs.google.com/spreadsheets/d/1wz0QenLKYio_4zqJZsloEqlsXk5LfBrb34N6jiZ60eQ/edit#gid=0.
Scott Court is in charge of this phase. The process of building phase 2
will be automated using the ports tree and portmake. These are available
on GitHub at https://github.com/cucumberlinux/ports.
Phase 3
Phase 3 will encompass building the rest of the destribution that was
not built as part of phases 1 or 2. We haven't fleshed out all the
details of this phase yet, but it will be automated using the ports tree
and portmake. There is also a chance that phase 3 will be broken into
multiple phases. More details to follow about this phase.
- Scott
|
|
From: Scott C. <sc...@cu...> - 2018-05-14 21:01:49
|
Hello All, I'm pleased to announce the availability of *portmake*, a shell script to automate the process of building packages. As I alluded to in the subject, portmake works similarly to the make utility, only it build binary packages from source using the buildscripts in the ports tree. For instance, to install Firefox from source, all you have to do is run `portmake install firefox`. It automatically handles (among other things): downloading source archives, verifying the integrity of package sources, building and installing packages from source, resolving and installing build time dependencies, and updating packages from source. It can be found in the ports tree at ports/utilities/tools/portmake (https://github.com/cucumberlinux/ports/blob/master/utilities/tools/portmake). Documentation on how to use portmake can be found in ports/utilities/documentation/building-packages (https://github.com/cucumberlinux/ports/blob/master/utilities/documentation/building-packages). Also, it stores all of the packages that it builds in /opt/packages, mirroring the hierarchy found in the ports tree, which mirrors the hierarchy of the official Cucumber Linux source tree. This, combined with the dependency resolution, should make it much easier to build Cucumber Linux 2.0. - Scott |
|
From: Scott C. <sc...@cu...> - 2018-05-12 15:40:27
|
Hello All, The *buildscript-buildinfo format* has been officially adopted as the new buildscript format for Cucumber Linux 2.0. It has also been imported into the ports tree (https://github.com/cucumberlinux/ports/tree/master/utilities/templates/cucumber-buildinfo). From now on, all modifications to the buildscript/buildinfo format will occur in the ports tree; the repository https://github.com/cucumberlinux/new-buildscript-format is now defunct. If you look around the ports tree, you will see that I've written buildinfo files for a couple of packages: iptables and iproute2. I converted the iptables.buildscript file from Cucumber Linux 1.1 to the buildinfo format. The process was quite easy and iptables appears to be working fine after being built with it. We can probably script this process for when we convert the entire Cucumber Linux 1.1 source tree to the buildinfo format. Additionally, I have written a tool to aid in *generating buildinfo files* (https://github.com/cucumberlinux/ports/blob/master/utilities/tools/generate-cucumber-buildinfo-template) and *exhaustive documentation* on the buildinfo format (https://github.com/cucumberlinux/ports/blob/master/utilities/documentation/cucumber-buildinfo). I strongly recommend you read through the documentation and one or two examples before you begin writing buildinfo files. If anyone is *looking for something to do*, I would recommend writing some buildinfo files for packages not found in the binary distribution. This has the dual benefit of helping to build up our ports tree and helping to test out the new format. Once you've written and tested them, submit a pull request to the ports repository. Right now I'm in the process of writing a tool to automate the process of building packages from the ports tree and handling dependency resolution. Expect an email about that this weekend. - Scott |
|
From: Maarten H. <maa...@ao...> - 2018-05-11 21:02:02
|
Hi all, I have finished what will become the buildtool for cucumber-2.0. So what is it? It's basically ch5 of LFS with added which and tar-1.13 so pkgtools will work. There are still a few steps needed that are NOT documented in the LFS-book so good documentation is important here. It's an i686-build. You do not need special tools I used LFS-8.2 except for: findutils-4.4.2 (lfs 7.8/slackware-current) file-5.33 (lfs svn/slackware-current) gawk-4.2.1 (lfs svn/slackware-current) sed-4.5 (lfs svn/slackware-current) util-linux-2.32 (lfs svn/slackware-current) xz-5.2.4 (lfs svn/slackware-current) perl-5.26.2 (lfs svn/slackware-current) There won't be big changes between now and the release of cucumber-2.0 except for perl perhaps that will see an update to 5.28.x. Binutils might see a release between now and June, glibc will be in August. Now, you can just chroot as in the book and with a few steps added, you can build all packages from modified buildscripts from cucumber/slackware/crux/nutyx or even arch linux. How? First get the tarball for the tools and sources. https://wetransfer.com/downloads/6098fa9dd5138e07dd912e41779ce3bc20180511205055/d045eddc9097f2a309d1f7de576b0dd220180511205055/411ce6 https://wetransfer.com/downloads/a62de28c4f5e31e58a068d923ff5c49420180511205650/50e40cd2ffd80193d1b3b1e8d299b49a20180511205650/0cf2cc Untar both to /mnt/lfs/ http://www.linuxfromscratch.org/lfs/view/development/chapter02/aboutlfs.html http://www.linuxfromscratch.org/lfs/view/development/chapter06/kernfs.html http://www.linuxfromscratch.org/lfs/view/development/chapter06/chroot.html NOW you are inside the chroot, all the following is done inside the chroot! http://www.linuxfromscratch.org/lfs/view/development/chapter06/creatingdirs.html http://www.linuxfromscratch.org/lfs/view/development/chapter06/createfiles.html ln -sv /tools/bin/du /bin I have added installpkg and makepkg from pkgtools-15.0 cp /mnt/lfs/sources/installpkg /sbin/ cp /mnt/lfs/sources/makepkg /sbin/ mkdir -v /etc cat > /etc/group << "EOF" root:x:0:root EOF cat > /etc/passwd << "EOF" root:x:0:0::/root:/bin/bash EOF chmod 644 /etc/group /etc/passwd exec /tools/bin/bash --login +h For each package and a "hand made" installation do: cd package && ./package.SlackBuild && installpkg /tmp/package*.t?z You will need to create the package-dir and download the buildscripts for this to work. It's a very early version of the documentation but if someone wants to try it out, here it is. Good day to all! |
|
From: LM <lm...@gm...> - 2018-05-11 19:45:08
|
On Fri, May 11, 2018 at 12:37 PM, Scott Court <sc...@cu...> wrote: > > I'm worried that using routines for other common utilities would decrease > the readability of the buildinfo files. I wouldn't use a routine just to alias a utility. I think MXE just uses shell variables. > I don't think it is terribly likely that we'll need to use a different tar > or other different utilities in the future. There are some advantages to curl over wget that might be worth looking into. For one thing, it's better at following links that are redirected. I know the standard Slackbuild scripts typically use wget, but I've pretty much switched to curl in most of my use cases. I've also hit a few cases where the tar utility failed to unarchive a source file and had to switch to other utilities. Sincerely, Laura |
|
From: Scott C. <sc...@cu...> - 2018-05-11 16:36:30
|
Hello All, I have added support for checksum verification and build time dependency tracking to the new buildscript format. I believe that this adequately completes the buildscript-buildinfo format. At this point I would like to get final feedback on the new format. If none are opposed, I would like to adopt this as the official buildscript format for Cucumber Linux 2.0. I'm giving a brief description of how it works here; more details can be found on GitHub (https://github.com/cucumberlinux/new-buildscript-format/tree/master/buildscript-buildinfo-format). Here's how the *checksum verification* works: When running |./iproute2.buildscript verify|, the following actions occur: 1. If the file 'sha512sums' exists, verify those SHA512 checksums 2. If the file 'sha256sums' exists, verify those SHA256 checksums 3. If the file 'sha1sums' exists, verify those SHA1 checksums 4. If the file 'shasums' exists, verify those SHA1 checksums 5. If the file 'md5sums' exists, verify those MD5 checksums 6. Run the 'verify' function in iproute2.buildinfo If any of these steps fails (i.e. exits with a non-zero status), then the checksum/signature verification step fails. If all of them succeed, the checksum/signature verification step succeeds. The 'verify' function in *.buildinfo is optional; if it is not present then only steps 1 through 5 will be run. The reason for supporting a custom 'verify' function is to allow for signature verification; the process for verifying signatures varies significantly from one package to the next, so it is necessary for this to be defined on a per package basis. Here's how the *build time dependency tracking* works: |./iproute2.buildscript builddeps| - Lists the build time dependencies for this package. These are defined in the *.buildinfo file by setting the |pkg_build_dependencies| to an array containing the names of the packages it depends on, as they appear in the Cucumber Linux source/ports tree. - Scott |
|
From: Scott C. <sc...@cu...> - 2018-05-11 16:36:29
|
Laura,
I've been thinking about this. Here are my thoughts:
1. I'm worried that using routines for other common utilities would
decrease the readability of the buildinfo files.
2. I don't think it is terribly likely that we'll need to use a
different tar or other different utilities in the future.
3. In the event that #2 turns out to be wrong, we can still add a
function named 'tar' that adds a wrapper around whatever version of
tar we need to use to make it behave similarly enough to the old
version of tar for the buildscripts to work. Something similar could
be done for other utilities as well if need be.
That being the case, I think the cost (#1) of adding more wrappers
outweighs the benefits, especially given that needing the wrappers on
Cucumber Linux is an unlikely scenario and we have another work around
we can use if need be.
I see how this very beneficial for the build system you are working on,
but our build systems have slightly different goals: we are creating the
Cucumber Linux build system to target a specific distribution whereas
you are making LM BLD as portable as possible. This is a very noble
goal, I just don't think it should be a goal for the Cucumber Linux
project at this point in time, given our limited resources and how much
else we have to do for Cucumber Linux 2.0 already.
- Scott
On 05/08/2018 01:39 PM, LM wrote:
> Using pkgapi_strip, pkgapi_make, etc. is a good idea. You may need to
> build on a system that can't handle parallel make calls or that uses a
> different name for make (such as gmake on BSD). You just need to
> change the buildscript file and it should work. If it I were writing
> this, I'd use routines for tar and some of the other utilities as
> well.
>
> I use a preprocessor and templates instead of functions in case I'm
> dealing with a system that may not have a shell that handles functions
> (like msh). I also mentioned I wanted the ability to concatenate
> using the preprocessor. In my own scripts, I do things like give the
> command to extract files, but also give it an extension, so it knows
> whether to extract a zip file or a .tar.xz file based on using
> decompress concatenated with the file extension and it generates the
> appropriate code. It works similar to passing parameters to a
> function. I can change between configure, autogen.sh, qmake, cmake,
> cdetect or other configure utilities by specifying the type of
> configure code I want generated.
>
> I have global locations where tools are listed so I can change them
> out. I may want to use tar on a system, but I also may prefer to use
> bsdtar or 7za. I also switch between options like sed or minised or
> perl for search and replace based on a global setting. One needs to
> regenerate the build scripts when the default tools are changed. It
> does give you the freedom to use the tools you prefer or the ones you
> have available on a system though.
>
> As to having to regenerate the build script before building a package,
> I have a script that goes through a simple list of packages and runs a
> series of steps on them, such as regenerate the build script using the
> template system, build the program or library, install the program or
> library. If I need to build a lot of packages from source, I'd rather
> have the whole process automated and not have to run each script by
> hand. I also have a script that goes through a list of packages and
> runs the checks for each to see if the version is updated.
>
> I've mentioned the build system I'm working on to Scott, but if anyone
> else on the list is interested, you can see some packages I'm working
> on and some sample inputs (lm bld files) and outputs (bash build
> scripts) for my build system here:
> http://www.distasis.com/cpp/lmports.htm
> I'm still making patches to packages and uploading them, so it's a
> work in progress.
>
> I definitely like the changes to the new Cucumber buildinfo format.
> I'd personally take it a step further and use functions or templates
> for common tools (like tar). MXE does that with their calls to wget
> and sed.
>
> Sincerely,
> Laura
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cucumber-linux-development mailing list
> Cuc...@li...
> https://lists.sourceforge.net/lists/listinfo/cucumber-linux-development
|
|
From: Scott C. <sc...@cu...> - 2018-05-10 15:03:05
|
Hello all, There has been some discussion about this in the past couple of day, so I'd like to make it official: Python 2 will be removed from the binary distribution in Cucumber Linux 2.0. The big reason for this is that Python 2 will be supported upstream until only 2019-12-31, but Cucumber Linux 2.0 will be supported past then. So if we were to keep Python 2 in the binary distribution, we would be shipping a core package that would (for a good portion of Cucumber 2.0's life cycle) not be able to receive any security patches. This is not acceptable, so the only other option that leaves us is to remove Python 2 from the binary distribution. That being said, we will be including Python 2 in the ports tree for Cucumber 2.0, so if you /really/ still need Python 2, you will be able to install it from source via the ports system. - Scott |
|
From: Maarten H. <maa...@ao...> - 2018-05-08 18:57:56
|
Hi Scott, I do not see a clear advantage with the api but I have seen similar things somewhere else so there must be something :). As long as the package format remains and the back-end is pkgtools, I am not worried. When adding repos and extra package sets, there is need for more features. Just look at all the add-ons for slackware that are made to handle installing extra stuff on top. I wonder if there will be extra dependencies needed. Ideally a linux distro is build in layers with the first one being ch5 the next ch6 and all others on top of ch6 OR ch6 plus a set of dependencies. This way broken packages should be non-existing. Even on a partial install (compared to a full slackware-like install). I'll focus on ch5 and next up is the defined set of a ch6-like base system and where the new buildsystem fits. Greetings, Maarten |
