devel

devel@lists.centos.org

2 participants
4653 discussions

Speakers needed: DefConf.US CentOS Dojo (August 14th, Boston)
by Rich Bowen 01 Jul '19

01 Jul '19

Hi, folks, I've had two of my speakers for the Dojo at DevConf.US fall through, and I need to find replacements. If you are interested in speaking at this event - August 14th, 2019 in Boston - please submit your proposed talk here: https://forms.gle/UgbodVpEUhnqHdNh6 Talks should be about something you're doing with, or on, or for, CentOS. Expect the audience to be very familiar with CentOS, and able to grasp deep technical details. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

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 17 Jun '19

17 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

[CloudSIG] RDO Pike going EOL
by Alfredo Moralejo Alonso 13 Jun '19

13 Jun '19

Hi, OpenStack Pike was moved to Extended Maintenance upstream [1]. This means that no more releases will be produced for Pike series and there is no commitment on validation. Also, some projects may decide to not maintain the branches and go to EOL. >From the RDO perspective, this means that we are setting RDO CloudSIG Pike repo as EOL and the repositories will be dropped from CentOS official mirrors on next oportunity (when CentOS 7.7 is published). For users that still want to keep using packages from pike branches tip, we will keep the RDO Trunk Pike repo running in [2] chasing any new commit being merged, but note that we will probably stop running CI on it at some point in the near future. Best regards, Alfredo [1] https://docs.openstack.org/project-team-guide/stable-branches.html#extended… [2] https://trunk.rdoproject.org/centos7-pike/report.html

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel