devel April 2014

devel@lists.centos.org

46 participants
32 discussions

c7.00.00 build reports
by Karanbir Singh 12 May '14

12 May '14

hi for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal. its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ). Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 14

github mirrors and subgroups
by Karanbir Singh 06 May '14

06 May '14

hi, Working on getting some of the git.c.o stuff into place, and we came up against an interesting problem - in a single organisation on github, one cant have sub groups or sub directories. So if we intend to run a complete set of git mirrors from git.c.o on github.c then were going to have a single listing of a few thousand repos. It is possible to setup teams, that are then visible as github.com/orgs/CentOS/teams/virtsig etc - and one can see just the repos that team is responsible for - but might there be a more elegant solution ? one potential solution is to have github.com/CentOS as the parent organisation, and setup CentOS-SIG-Virt etc as completely different organisations, with teams that are able to completely admin that namespace ( maybe CentOS-SIGVirt or something shorter ). I've had a few conversations with the folks over at github and there doesnt seem to be any other obvious workaround to this. Unless, I am missing something ? thoughts / comments on a potential plan ? -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc

3 4

Request for epel-release package in CentOS repo
by Martin Jackson 01 May '14

01 May '14

Hello, With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on. Thanks, Marty

13 22

Secure Boot in RHEL7beta
by Akemi Yagi 29 Apr '14

29 Apr '14

RHEL 7 beta can be installed on systems with 'Secure Boot' enabled as seen in the Installation Guide [1]. More info about Secure Boot is available from Fedora docs and the links therein [2,3] Question is how the implementation of Secure Boot should be handled in CentOS. Akemi [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux… [2] https://fedoraproject.org/wiki/Secureboot [3] http://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/i…

2 3

Is it a bug that.Xauthority-c or .Xauthority-l was generated to lock authentication?
by jupiter 28 Apr '14

28 Apr '14

Hi, I am running CentOS 6.4. Occasionally, some new created user account encountered authentication problems where .Xauthority-c or .Xauthority-l was generated to lock the authentication. I would think it is a bug, but please correct me if the .Xauthority-c or .Xauthority-l is some kind symptoms to indicate something wrong in my system. Thank you. Kind regards, jupiter

1 0

unsuscribe
by Saket Sinha 26 Apr '14

26 Apr '14

1 0

unsuscribe
by Glen Gardner 26 Apr '14

26 Apr '14

1 0

system call msgrcv() freom 32-bit application shows error: msgrcv: No message of desired type
by Gabriella Schmidt 25 Apr '14

25 Apr '14

The latest RHEL7 still shows the error msgrcv: No message of desired type if msgrcv() is called with negative arguments within 32-bit applications. It is in Red Hat Bugzilla – Bug 1042807 but as we dont have RHN Support anymore we cant take a ticket there. I have tested the kernel-lt-3.10.37-1.el6.elrepo.x86_64 and kernel-ml-3.14.1-1.el6.elrepo.x86_64 on CentOS-6 and the 3.10.37 still show the problem, while its fixed in 3.14 The fix is very small ( see attachment ), but I dont know what is the best way to get it fixed in the 3.10 kernels too. -- Kind Regards Gabriella Schmidt -- NMR Software -- Bruker BioSpin GmbH

4 7

ostree as a delivery model
by Karanbir Singh 23 Apr '14

23 Apr '14

The Fedora cloud sig has been talking about using the gnome ostre to deliver a potential platform, i think this is fantastic and leads in quite nicely to the conversations we've all been having about a minimial manageable image ( either for virt or cloud usage, or even baremetal ). I wonder if we can make this work for CentOS-6 now and 7 when its around ? the rpm-ostree stack seems to have a systemd dep though. Who fancies taking a dig at it ? references: ostree: https://wiki.gnome.org/action/show/Projects/OSTree rpm-ostree: https://github.com/cgwalters/rpm-ostree ( this is what one would use to take a bunch of rpms and make them into an ostree VM, it spits out a qcow2 image ) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

11 45

snd_hda_intel module tweaking
by Chris Pemberton 22 Apr '14

22 Apr '14

Long story short... I'm recompiling the snd_hda_intel module to enable CONFIG_SND_HDA_RECONFIG. This will allow me to reset the pins on the card to get my sound working. (This option is already set in arch and ubuntu - where I can reprogram my pins and get sound working). I followed the 2 CentOS wikis pertaining to getting the full kernel sources and compiling a module... all seemed to go perfect. Unfortunately, when I try to load the new snd_hda_intel.ko module, I get the following: FATAL: Error inserting snd_hda_intel (/lib/modules/2.6.32-431.11.2.el6.x86_64/extra/snd-hda-intel.ko): Invalid module format A little googling suggested I run 'file' on the two modules and here is the output: /lib/modules/2.6.32-431.11.2.el6.x86_64/extra/snd-hda-intel.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped /lib/modules/2.6.32-431.11.2.el6.x86_64/kernel/sound/pci/hda/snd-hda-intel.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped They seem identical? Any suggestions where I could go from here? I'm currently recompiling the entire kernel and will just copy over the new modules and see if something better happens. Thanks, Chris

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel April 2014