devel June 2019

devel@lists.centos.org

39 participants
17 discussions

CentOS 8 Artwork needed
by Rich Bowen 31 Jan '20

31 Jan '20

To all the artists and designers here, we need your help. With RHEL 8 beta released, we need to start producing artwork for CentOS 8. It's time for the CentOS Artwork SIG, and anyone else that's interested in contributing to this effort, to start working on everything that will be needed for the new release. What we know we need is anaconda artwork, and new desktop backgrounds to replace the current '7' themed stuff. As we dig, we may find more things that need to be updated to the new 8 theme. Additionally, we will need to update some of the assets listed here: https://wiki.centos.org/ArtWork/Identity ... and produce new assets for 8 to be listed here: https://wiki.centos.org/ArtWork/Brand/Logo And, finally, we need someone to step up to lead this effort. While we don't yet know for certain when RHEL 8 will officially release, it's safe to assume that it's soon, and we need your help. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

10 30

Using mirrorlist in centos-release-* packages
by Anssi Johansson 12 Sep '19

12 Sep '19

Hi, as mentioned in https://lists.centos.org/pipermail/centos-devel/2018-September/016949.html mirrorlist.centos.org has been updated to produce mirror lists for SIG content as well. Some centos-release-* packages have already been modified to use mirrorlist.centos.org instead of mirror.centos.org, but many still point to mirror.centos.org. Most of mirror.centos.org hosts are also used for seeding the 600+ external mirrors we have. By directing some of their download traffic to external mirrors we can offer faster sync speeds for those external mirrors, and for people downloading individual rpms from mirror.centos.org. Second, most of those external mirrors offer faster download speeds to end users than what could be achieved by downloading from mirror.centos.org, so the users will benefit from this change as well. The better geographical coverage does not hurt either. mirror.centos.org nodes are donated servers, and it would be kind to the sponsors to use their bandwidth sparingly. The .repo files should be modified so that the current baseurl line gets commented out and a mirrorlist entry gets added, like this: mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch… #baseurl=http://mirror.centos.org/$contentdir/$releasever/storage/$basearch/gluster-4.1/ Note that mirrorlist.c.o can automatically choose between main and altarch content based on the arch parameter. The repo names are constructed from the repository path by stripping away the architecture and changing any slashes to dashes: sclo/x86_64/rh -> sclo-rh, sclo/x86_64/sclo -> sclo-sclo, paas/x86_64/openshift-origin311 -> paas-openshift-origin311, storage/x86_64/gluster-5 -> storage-gluster-5 etc. You can use 'curl' to check what mirrorlist outputs for your repository. New repos are added to mirrorlist.centos.org automatically once the repository hits mirror.centos.org. That script is currently run every three hours. I guess it could be run more frequently (it's fairly lightweight), but you should give the external mirrors a few hours to sync before announcing your release anyway. You can either submit an update to your current centos-release-* file now, or wait until you need to create a new centos-release-* package for other reasons such as releasing softwarepackage-(version+1) which uses different paths. My recommendation would be to submit an update to your current centos-release-* package, so that you would not need to worry about this when you eventually need to publish a new one for other reasons. We released an updated centos-release package for CentOS AltArch before 7.6.1810 was released for this exact reason, ie. we didn't need to worry about this change at 7.6.1810 release time. Other people (such as bstinson, arrfab and hughesjr) can probably help with creating and publishing an updated centos-release-* package, but the usual tagging procedure to extras will apply. The SIG Guide https://wiki.centos.org/SIGGuide should have all the needed details for this (if not, complain to bstinson). It is highly recommended to actually test your new centos-release-* package from buildlogs before you ask that package to be signed and pushed to extras. The holiday season is fast approaching so (I) don't expect much activity regarding these changes in the following days. I'm hoping that the SIGs would take a look at this in early 2019, though. Thanks to those SIGs who have already made these changes to their centos-release-* packages! If you have questions, feel free to ask either here or on #centos-devel. Thanks for your time!

1 2

About PCYNLITX project and its innovations ( for C+++ multi-threading )
by Erkam Murat Bozkurt 01 Jul '19

01 Jul '19

Previously, I have presented my project to you. The current name of my project is PCYNLITX. PCYNLITX platform offers completely new programming technology which can be named as Programmable Meta-Programming System and PCYNLITX platform is just a particular application of this new programming methodology. Basically, PCYNLITX is an intelligent integrated development environment ( IDE ) which can produce an application-specific multi-threading library based on your needs and assists you in multi-thread software development process. PCYNLITX is not a multi-threading library. Instead, it is a multi-threading library generator. You can find out very comprehensive documentation about pcynlitx project from both project web site and source code repository. The addresses of the project web page and source code repository are given in below links. www.pcynlitx.tech https://sourceforge.net/projects/pcynlitx The outcome of the PCYNLITX platform acts as an autonomous thread management system provides deterministic scheduling of the threads. You can control the thread with the numbers given by you and determine the relation of the threads. In other words, different from the other multi-threading tools, you can directly schedule the threads independently from the operating system. The scientific journal of the project is under review on IEEE Transactions on Software Engineering. Currently, the PCYNLITX platform only works on Linux based operating systems and the other versions ( Windows and McOSx ) are under development. The License of the PCYNLITX platform is GNU GPLv3 Free Software License. You can find out many other documents including scientific introduction of the project (“Technical Introduction” ), code examples and GUI tutorial form the project web sites. You can also find out a documents introducing std::thread programming, pthread programming and OpenMP programming on the web sites. I am always waiting your valuable comments and contributions. Thanks and best regards. Erkam Murat Bozkurt M.Sc in Control Systems

2 1

Re: [CentOS-devel] Need info about kernel file "randomize_va_space"
by Maheshwari, Shagun 28 Jun '19

28 Jun '19

Hi, >> The file "/proc/sys/kernel/randomize_va_space" has write permission for user as below: >> [root@shagun ~]# ls -lrtZ /proc/sys/kernel/randomize_va_space >> rw-r--r--. root root system_u:object_r:proc_security_t:s0 /proc/sys/kernel/randomize_va_space >> >> If we want to change this permission to read only permission for the user. Is it possible? >> >> And i found the code also: >> >> kernel/sysctl.c @@ -1130,7 +1130,11 @@ static struct ctl_table kern_table[] = { .procname = "randomize_va_space", .data = &randomize_va_space, .maxlen = sizeof(int), +#ifdef CONFIG_ASLR_SYSCTL_READ_ONLY + .mode = 0444, +#else .mode = 0644, +#endif >> >> Can we make it as 0444, currently randomize_va_space is 644? > Any changes to the kernel should be requested through > https://clicktime.symantec.com/3KpmXJbD9xEqbGPHpBNCtpd7Vc?u=https%3A%2F%2Fb… for RHEL7's kernel package. > Why do you want root to not be able to write to that sysctl? Do you > not want it to be able to be modified? Because While running dASLR tool, "randomize_va_space unconfigurable" test in "Kernel Check" is FAILED. As per support for dASLR tool, "randomize_va_space_unconfigurable" fail means that "/proc/sys/kernel/randomize_va_space" has write permission. Regards, Shagun

3 2

Need info about kernel file "randomize_va_space"
by Maheshwari, Shagun 26 Jun '19

26 Jun '19

Hi, The file "/proc/sys/kernel/randomize_va_space" has write permission for user as below: [root@shagun ~]# ls -lrtZ /proc/sys/kernel/randomize_va_space rw-r--r--. root root system_u:object_r:proc_security_t:s0 /proc/sys/kernel/randomize_va_space If we want to change this permission to read only permission for the user. Is it possible? And i found the code also: kernel/sysctl.c @@ -1130,7 +1130,11 @@ static struct ctl_table kern_table[] = { .procname = "randomize_va_space", .data = &randomize_va_space, .maxlen = sizeof(int), +#ifdef CONFIG_ASLR_SYSCTL_READ_ONLY + .mode = 0444, +#else .mode = 0644, +#endif Can we make it as 0444, currently randomize_va_space is 644? Please suggest. Regards, Shagun

2 1

The future of the community build services
by Thomas Oulevey 26 Jun '19

26 Jun '19

Hi Folks, It's time to have a look to the SIGs and the community needs for the next version of the community build service(cbs). We would like to request feedback and know if the different communities plan on using modular builds, and what would be their timeline to be able to produce C8 artifacts (rpms, imagefactory builds, etc...). As you know Koji is now used to build CentOS 8 [1], and is based on the mbbox [2] distribution. It makes sense for cbs.centos.org to follow this trend and be based on the same templates. At the same time we needed to evaluate how and where we can deploy the new Openshift based templates, and associated builders for different arches. It's understood that the transition between both systems should be smooth and do not impact your C6/C7 builds and release cycle. We will plan accordingly. Please let us know, if you have comments and/or new ideas. -- Thomas Oulevey [1]: https://blog.centos.org/2019/06/centos-8-status-17-june-2019/ [2]: https://github.com/puiterwijk/mbbox

4 4

RFC: CentOS 8 Repository Structure
by Brian Stinson 25 Jun '19

25 Jun '19

Hi Folks, While we cycle through some of the remaining builds I'd like to start a discussion about what the CentOS 8 repo structure might look like. We need to think about what the repos look like on-disk, and how this might impact the mirrors. Currently the thinking is this: 3 "core" repos: - BaseOS (contains a small packageset of the base distribution) - AppStream ("where the modules go") - Devel ("-devel packages and other tools") These descriptions are very much an oversimplification, but it's an ok model to work with. We plan to compose all of those repositories, and deliver updates in the same stream. The x86_64 tree for the BaseOS repository will look something like this: x86_64 ├── debug # Note: we will likely snip this out and move debugs to debuginfo.centos.org │ └── tree │ ├── Packages │ └── repodata ├── iso └── os ├── EFI │ └── BOOT │ └── fonts ├── images │ └── pxeboot ├── isolinux ├── Packages └── repodata The plan is to re-compose BaseOS and all the "release" media like cloud images/ISOs at the traditional point-release times, and refresh the repodata in between as updates come in. Currently there are 3 primary architectures: x86_64, ppc64le, and aarch64, and 1 alternative architecture: armhfp. For CentOS 7 we split our primary and alternate architectures into /centos and /altarch on the mirrors to allow mirror admins to choose which trees to mirror. Is this something we'd like to continue? I welcome any questions and discussion that we might have. -- Brian Stinson brian(a)bstinson.com

12 42

CentOS 8 hardware enablement
by BC 18 Jun '19

18 Jun '19

According to https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… a lot of hardware is no longer supported. Specifically SAS1 drivers are my concern. Does the CentOS team plan to include those drivers in a centos-extras kernel? Likewise, would anaconda's environment have support for them or is it expected that people will have to generate their own kernel and install image? Thanks!

3 2

liibseccomp 2.3.3
by Neale Ferguson 17 Jun '19

17 Jun '19

Hi, Are there any plans to get libseccomp into 7.6.1103? This fixes a problem with docker and the support of the statx() system call used by nodejs. Currently, libseccomp won’t let this call be executed within docker-ce 18.0x and above even though it’s in its seccomp profile. Fedora 28 has it so I could experiment with it but if something official is coming down the pike then I’d rather wait. Is it worth raising an issue? Neale

2 2

CFP for Ceph Days Netherlands closes *TOMORROW*
by Rich Bowen 13 Jun '19

13 Jun '19

Ceph days Netherlands will be held on July 2nd. The CFP closes TOMORROW, June 14th. https://ceph.com/cephdays/netherlands-2019/ -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel June 2019