devel

devel@lists.centos.org

2 participants
4653 discussions

anjuta crash when open UI file
by Andreas Benzler 13 May '16

13 May '16

Hello Everyone, While I poke today on totem, anjuta crash on open preferences.ui. glade = 3.15 I downgrade glade to version 3.14.3. Now it works as expected. http://centos.cms4all.org/centos/7/other/SRPMS/glade-3.14.3-6.el7.centos.sr… fixed to compile man pages. Sincerely Andy

1 0

[Config Management SIG] Ansible version(s)
by François Cami 12 May '16

12 May '16

Hi, The main Ceph Jewel installer is based on Ansible, so the Ceph part of the Storage SIG would like to be a consumer of the Config Management SIG Ansible bits. However, Ceph upstream has confirmed: * 1.9.4 and 2.0.0.1 are 100% compatible * 2.1 should work (but is quite probably not tested at all) This raises the following questions: * would any member of the Config Management SIG be interested in building and maintaining either 1.9.4 or 2.0.0.1 for the Storage SIG? * if not, would the Config Management SIG be open to let Storage SIG members maintain an Ansible 2.0 branch? Regards, François

4 7

PXE boot images
by Jeff White 11 May '16

11 May '16

I have a number of systems which PXE boot and mount and NFS-based root. These boot using the files provided here: http://mirror.centos.org/centos/7.2.1511/os/x86_64/images/pxeboot/ However, these seem to contain an old kernel (3.10.0-327.el7.x86_64) instead of any later one released as part of CentOS 7. Two questions: 1. Are new pxeboot images going to be released? 2. If not, how can new ones be created? Can whoever made those images share the dracut configuration used to build them? -- Jeff White HPC Systems Engineer Information Technology Services - WSU

2 1

CentOS PaaS SIG meeting (2016-05-11)
by Troy Dawson 11 May '16

11 May '16

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 11 May 2016 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms / Upstream -- Automated testing -- images / image building - Open Floor

1 0

Re: [CentOS-devel] [scl.org] Looking for a new timeslot for SCLo SIG meeting
by Honza Horak 11 May '16

11 May '16

There were few matches, because not many people have responded, so let me pick one time-slot: Tuesday 13:00 UTC/GMT, 15:00 CEST, 9:00 EDT Let's meet every EVEN week (first time the next week). I'll update the meeting time on https://www.centos.org/community/calendar/ and the wiki. Honza On 04/28/2016 03:32 PM, Honza Horak wrote: > I know about several people who are not very happy about current > timeslot for SCLo SIG sync-up meeting, including me, so.. For everybody > who thinks about attending SCLo SIG meetings regularly in the future, > please, vote which timeslot would be fine for you: > > http://whenisgood.net/5k554ep > > The voting is opened till next Wednesday, 4th May, 23:59 UTC. > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg(a)redhat.com > https://www.redhat.com/mailman/listinfo/sclorg

1 0

Config Management Sig Meetings
by Julien Pivotto 11 May '16

11 May '16

Hi all, The config Management SIG meetings are not a success and I suggest we stop trying. There are many busy people of the SIG that have busy schedules at customer, families, and many other good reasons that makes it difficult to join a meeting during or after office hours. This is not a lack of motivation, but for all of us this SIG is a side project, and it is more easy to be able to participate when we actually have time. My suggestion is then to discuss SIG matters in this mailing list, so we will be able to start working on technical work ASAP. I will bootstrap a few discussions on this mailing list in the coming days. I hope CentOS core members will be able to participate as well, even if I know it's release time (6.8). Other emails will follow with some discussion topics. -- (o- Julien Pivotto //\ Config Management SIG V_/_ https://frama.link/cfgmgmt

1 0

Re: [CentOS-devel] test builds on private server (drivers, mesa, fixes)
by Andreas Benzler 10 May '16

10 May '16

Hello Guys, i upgraded system-config-printer to 1.4.8 and it works, tested. My patch to the old one here isn’t needed. Sincerely Andreas Benzler

1 1

Re: [CentOS-devel] [atomic-devel] docker and docker-latest packages on CentOS Virt SIG
by Daniel J Walsh 10 May '16

10 May '16

On 05/10/2016 12:06 PM, Erik Swanson (eriswans) wrote: > >> On May 10, 2016, at 05:48, Daniel J Walsh <dwalsh(a)redhat.com> wrote: >> >> On 05/09/2016 07:38 PM, Erik Swanson (eriswans) wrote: >>>> On May 9, 2016, at 07:54, Lokesh Mandvekar <lsm5(a)fedoraproject.org> wrote: >>>> >>>> - /usr/bin/docker is a script which execs /usr/bin/docker-current (v1.9) or >>>> /usr/bin/docker-latest (v1.10) based on what $DOCKERBINARY is set to. >>> Too late (or wrong forum?) perhaps, but this split is very distressing to me as an end-user because it breaks the use case of bind-mounting the docker client binary and socket into a privileged container, a pattern which otherwise would work on basically every Docker-host OS out there regardless of Docker version. >>> >>> — >>> Erik Swanson >>> >>> >> Yes we had not thought about this. I guess you would need to volume mount docker and docker-current or docker-latest into the container. > (And whatever envionrment/configuration the /usr/bin/docker stub uses to decide which to execute, as well.) > > Currently, I can tell people to bind-mount /usr/bin/docker and the socket, and it’ll work *everywhere*. With this change, I’ll have to document a ridiculous matrix of how to launch a docker-using privileged container, varying on the host OS and the version of the host OS (and what version of Docker they’ve elected to use). Well not quite everywhere since docker is not static linked. If you volume mount in docker-current or docker-latest it will work. docker run -v /usr/bin/docker-latest:/usr/bin/docker -v /run/docker.sock:/run/docker.sock ... Will work. > The assumption of /usr/bin/docker being a self-contained(-ish) binary guaranteed to be compatible with the running daemon’s socket isn’t entirely uncommon: A quick google search for “-v /usr/bin/docker:” shows ~1670 results, all of which are going to be broken by the eccentric change of making /usr/bin/docker a stub (or a symlink). > > (Is there a more appropriate venue for this concern/appeal?) Open a bugzilla on this. > — > Erik Swanson >

1 0

Re: [CentOS-devel] [atomic-devel] docker and docker-latest packages on CentOS Virt SIG
by Daniel J Walsh 10 May '16

10 May '16

On 05/09/2016 07:38 PM, Erik Swanson (eriswans) wrote: >> On May 9, 2016, at 07:54, Lokesh Mandvekar <lsm5(a)fedoraproject.org> wrote: >> >> - /usr/bin/docker is a script which execs /usr/bin/docker-current (v1.9) or >> /usr/bin/docker-latest (v1.10) based on what $DOCKERBINARY is set to. > Too late (or wrong forum?) perhaps, but this split is very distressing to me as an end-user because it breaks the use case of bind-mounting the docker client binary and socket into a privileged container, a pattern which otherwise would work on basically every Docker-host OS out there regardless of Docker version. > > — > Erik Swanson > > Yes we had not thought about this. I guess you would need to volume mount docker and docker-current or docker-latest into the container.

1 0

[Proposal] Adding an alternative architecture to your SIG.
by Thomas Oulevey 09 May '16

09 May '16

Hi Folks, We are able to build packages for new arches we need to propose a workflow to support a new architecture in a SIG project. Two use cases : A/ It's an official architecture. -> Sources *must* build for all enable architecture. SIGs are responsible to fix issues for all arches. -> We provide a script that will rebuild existing arch specific packages (scratch build + merge scratch build) if needed. (Note: In case only newer version of your project supports this arch, this step may be skipped.) => "On Monday SIG board decided to enable aarch64, and then all new tasks must build for aarch64." B/ It's a proposed architecture. -> Some person in a SIG would like to work on add an architecture and do the porting work but SIG would not support it as a first citizen until it gets traction. -> Source will be build on a separate tag (a different disttag will be used) -> We provide a script that rebuild srpm (NV must remain the same as original SIG package) and merge the build when architecture is promoted as an "official architecture". => "Work on this architecture support and when ready send a proposal to promote your working port to the SIG board" I think that supporting the two use cases will benefit the community, and allow less common architectures to be supported faster. At koji level, these modifications can be done per SIG *project*. Let us know what you think/expect and your feedback. -- Thomas Oulevey

2 2

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