devel March 2017

devel@lists.centos.org

28 participants
31 discussions

ksplice and CentOS
by Karanbir Singh 25 Sep '25

25 Sep '25

hi guys, lots of people on this list are keen on contributing to the CentOS effort - and one place where we could, as a group of people, make a massive difference is being able to deliver a ksplice upgrade model. A couple of people have started in silo's to try and get something together but I feel it might be a good time to try and see if we can do somethng as a group. Do we have people on the list who find the idea of rebootless kernel upgrades interesting ? Is there some desire to try and make that happen within the CentOS Ecosystem ? - KB

24 47

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

Request for feedback: CentOS-Atomic container
by Karanbir Singh 25 Sep '17

25 Sep '17

hi Alpha2: registry.centos.org/kbsingh/centos-atomic:7-alpha2 The CentOS Atomic Container is a minimal ( 30MB on disk ) image that can be used to host static content, and small footprint content that does not need the entire CentOS Linux Base image. This is also not meant to replace CentOS Linux Base image as the default, we want to make it available as an additional container base for apps that find it useful. The main highlight is that it does not contain yum, but has microdnf. I am looking for feedback, and some wider testing as well as recommendations on howto further reduce size, before we move to release. You can consume this as : docker run -t -i \ registry.centos.org/kbsingh/centos-atomic:7-alpha2 \ /bin/bash regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 4

NFV SIG - update
by Dave Neary 30 May '17

30 May '17

Hi, There has been a recent resurgence of interest in the NFV SIG, and in the interest of keeping the momentum going, I would like to step aside as SIG char, and recommend that Tom Herbert take over. Tom has taken on the packaging and building of VPP and DPDK-accelerated OVS for OPNFV, and has been active in the SIG in recent weeks, and I think he will help add the structure that has been sorely lacking from me in recent months. I'm not sure what the process is for replacing a SIG chair - can someone let us know, please? Thanks, Dave. -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338

4 4

CentOS 7 extras for alternative arches and Koji workflow.
by Thomas Oulevey 18 May '17

18 May '17

Dear All, I'd like to retake a pending issue with -extras on c7 and ask for feedback. I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture. Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner. A lot of coordination (and motivated contributors) is needed if this effort is not centralized. For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default) However I understand, we need a way not to block official c7 arches for other arches that need fixes. After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa. Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated. The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do) I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it. Is altarch-extras important to you ? thank you for your feedback, -- Thomas Oulevey

7 11

CentOS PaaS SIG meeting (2017-03-29)
by Troy Dawson 31 Mar '17

31 Mar '17

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays (date -d "1700 UTC") Date: Today Wedensday, 29 March 2017 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current StatusI -- rpms -- Documentation -- Automated testing and Automated rpm building -- Multi-arch -- separate repo work -- minishift - Open Floor

2 2

Status update on CentOS Community Container Pipeline
by Bamacharan Kundu 30 Mar '17

30 Mar '17

Hi All, Below is updates for the recent works done on CentOS Community Container Pipeline * Clear up the pods and environment once build is complete * Getting all mails from container-pipeline logged in a mailing list * RPM tracking and updating container images based on RPM updates. * Postgresql (upstream) and making sure they work with openshift * Wildfly swarm stack is containerized now. * Ported Alpine based NSQ (https://nsq.io) container image to CentOS * Linter upgrade to prevent the message raised by `FROM` statement Our Current focus is on: * Single mail notification for end to end status for builds in pipeline to user * Setting up external registry * Fixing up current build repeat issue * Refactoring workers to make them more efficient * Fix jenkins issue on CI and debug failing builds on CI * Resolve container dependencies during build * Work on provision to update container images (using jenkins to use a trigger based system to pull in image when new image is pushed to the registry.) * Containerize Kyto Tycoon with the ability to run the same on openshift * Implement the usage of container graph for rpm based rebuilds in controlled and efficient manner. * Integrated container capabilities scanner with scan worker Regards Bama Charan Kundu

1 0

Pull request/Changes to CentOS Extras repo??
by Martin Juhl 29 Mar '17

29 Mar '17

Hi guys... I have some packages in the Extras repo, that I would like to be built for python3 as well as python2... I can provide the changes for the spec files, but what is the official way to commit changes / pull requests???? I would of cource then become the package manager of these packages... (we need them in the COPR project) Regards Martin Juhl

2 1

Providing checksums for our Vagrant images
by Laurentiu Pancescu 23 Mar '17

23 Mar '17

Hi there, I've been looking at making it easier for Vagrant users to verify our images when adding them. The Vagrant documentation mentions that the checksum can be added to the box metadata[1], and that this is done automatically if you build the box on Atlas - indeed, the source code shows they are verifying a checksum from the downloaded metadata[2]. Unfortunately, Atlas does not seem to provide such a checksum for any of the boxes I checked - neither those hosted by them, like debian/jessie64, nor external ones like ours' or Fedora's. The Bento boxes seemed to offer a checksum, but that's just their complete JSON metadata somehow ending up in the description field on Atlas (I assume that's an automatic step not doing what the Bento developers intended - I saw no message about verifying the checksum when adding bento/debian-8.7). We already host the images on cloud.centos.org. We could also generate the needed JSON metadata (we only need one file for all centos/7 images, and one for centos/6), including the SHA256 checksums. We could also create two Apache aliases (e.g. cloud.centos.org/vagrant/7) to make life easier for our users - after an initial "vagrant box add https://cloud.centos.org/vagrant/7", which would prove the checksum automatically, they would also be notified when new images appear and be able to use "vagrant box update centos/7", just like they do now. This would allow us to even move away from Atlas, if desired. We would finally be able to completely automate our Vagrant releases, instead of manually adding the releases to Atlas every month, and not even having embedded checksums. There was an Atlas CLI that proved not to work as expected: our 1701 and 1702 releases didn't end up on Atlas, we had to intervene. The big question is how we could communicate this to our users, not the technical side: I already tested this with a local webserver, serving the centos/7 JSON downloaded from Atlas, which I edited to add an SHA256 checksum - Vagrant automatically verified the checksum after the download was finished. Any thoughts? Laurențiu [1] https://www.vagrantup.com/docs/boxes/format.html#box-metadata [2] https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/action/builtin…

3 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel March 2017