devel

devel@lists.centos.org

11 participants
4618 discussions

CentOS-6.5 support for the "Ekoore Python3v2 TOUCHPANEL added using 2 patches.
by Sebastian Yarici 07 Feb '14

07 Feb '14

hi'lo #centOS-devel, we added support to CentOS6.5 for the Tablet-PC "EKOORE Python3v2" it took us some time but we have a fix! one change to the kernel-config and one change to the FDI file, please tell me how to contribute the two changes. greetingz --c11

2 1

VoIP SIG
by Rob Thomas 06 Feb '14

06 Feb '14

I'd like to put my hand up to be part of the VoIP SIG. After mentioning this in IRC, I've also had two other people contact me privately (puzzled and JHogarth) with their interest too. Currently we (FreePBX) build 'FreePBX Distro', which is a up-to-date CentOS distro, with a couple of known-broken packages upgraded (drbd, pacemaker) or replaced (asterisk). --Rob

7 15

proposal on process to carry distro package patches
by Karanbir Singh 05 Feb '14

05 Feb '14

hi, https://git.centos.org/tree/sig-core!bld-seven.git mirrored at : https://github.com/CentOS/sig-core-bld-seven now carries a proposed process to carry package patches. So stuff like branding or build changes needed, or even content changes to make things work could be carried like this. Primary target is for people doing arch work that isnt inherited from upstream. Comments welcome, were only going to start with this for the i686 builds, but if it works and is acceptable widely, we can roll this out across the board. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 2

Repository structures for SIG and variants in the future
by Jim Perrin 05 Feb '14

05 Feb '14

As part of opening up the possibilities for SIGs and Variants within the CentOS ecosystem, we need to give some thought to how repositories should be structured so that different can cooperate with each other. What we have discussed in the past, and what I'd like to propose to the -devel community, is that we adopt a page similar to the KDE framework. The way I envision this working is as follows: - Tier 1 repositories: Adds packages only. These repos may not update or replace anything in the core distribution. (Example: EPEL) - Tier 2 repositories: These repositories may provide provide packages that update or otherwise enhance packages in the base distribution, but otherwise maintain compatibility. (Example IUS - Tier 3 repositories: These repositories contain packages that conflict with software inside the core distribution. This would be Xen4CentOS for example, which replaces the kernel, and adds in xen functionality. Each tier may choose to rely on dependencies from repositories in the tier above it, but not the other way around. For example, the tier 3 Xen4 repository could choose to rely on packages from a tier1 like EPEL, or a tier2 like IUS. However a tier1 or tier2 could not rely on a tier3. A good real-world example of this would be rpmfusion's dependence on the EPEL repository. The other aspect of this that needs to be discussed is package duplication. For example, several of the proposed SIGs have some overlap in their packages. Would the preference here be that each SIG/Variant maintain their own version of the package, or should there be a common package set established? Both methods fit into the model described above, and both have pros/cons associated. What does the community think about this? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

11 51

Centos 7 and powerpc
by Bryson Lee 04 Feb '14

04 Feb '14

Hi, Would it be possible to get some insight into the prospects for PowerPC support in Centos 7? We deliver an application on IBM Power7 servers that's currently built atop a fairly heavily customized Fedora 12 distro. We anticipate having to move our platform forward at some point, if for no other reason than keeping up with whatever IBM does in terms of hardware evolution. We also have a vested interest in the ppc64 / ppc32 question, since our app is somewhat bound into the 32-bit arch and the 64-bit kernel / 32-bit userland structure we inherit from F12. We have a small number of PS710's in-house, and will probably get at least one of whatever winds up being the equivalent Power8 machine as soon as it becomes available. I'm not in a position to be able to expose a build node to the outside world, but I can certainly build /install / test internally and do some troubleshooting. Any info that can be shared at this point? Any way I can help? Thanks, -Bryson Lee ________________________________ Please note that my e-mail address has changed. My new (current) address is Bryson.Lee(a)sslmda.com. ________________________________ This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and any attachments.

3 3

SIG reps syncing often
by Karanbir Singh 04 Feb '14

04 Feb '14

hi, >From the fosdem conversations.. it was clear that for cross SIG co-operation to work we are going to need to have a SIG's syncup every so often. And we could / should have something like : the CentOS Board is responsible for setting up and running a SIG's syncup once a month, with the SIG representatives optionally required to come themselves or nominate someone else ( again optionally ) to come along. This could be a hangout, a conf call ( go Voip SIG! ), or an irc chat. thoughts ? - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Kernel OOPS (NULL pointer) with incomplete sock structure?
by Andrew Smith 03 Feb '14

03 Feb '14

I'm debugging a problem that has appeared on a test rig here and I'm wondering if anybody could shed any additional insight into what might be happening. I have a rig running on VMWare ESXi 5.5 with 12 4 Core CentOS 6.4 shipping approximately 100MB/second across the network and within an hour usually one of the nodes fails with a trap as follows. <7>out of order segment: rcv_next 3F89F4D seq AF008380 - A5BE3000 <1>BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 <1>IP: [<ffffffff8148fd63>] skb_set_owner_r+0x53/0x70 <4>PGD 13ba5a067 PUD 13cec4067 PMD 0 <4>Oops: 0000 [#1] SMP <4>last sysfs file: /sys/module/ip_tables/initstate <4>CPU 0 <4>Modules linked in: iptable_mangle ipv6 ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables ppdev parport_pc parport vmxnet(U) vmware_balloon vmci(U) i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom vmw_pvscsi pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] <4> <4>Pid: 1329, comm: java Not tainted 2.6.32-358.11.1.el6.x86_64 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform <4>RIP: 0010:[<ffffffff8148fd63>] [<ffffffff8148fd63>] skb_set_owner_r+0x53/0x70 <4>RSP: 0000:ffff880028203a30 EFLAGS: 00010206 <4>RAX: 0000000000000000 RBX: ffff8800a405f780 RCX: 0000000000000000 <4>RDX: 0000000000000ab4 RSI: ffff8800a405f780 RDI: ffff8800a405f780 <4>RBP: ffff880028203a40 R08: 00000000000126a8 R09: 00000000fffffff7 <4>R10: 0000000000000007 R11: 000000000000000a R12: ffff8800a405f780 <4>R13: ffff8800a405f780 R14: ffff8800a405fd00 R15: 0000000000000002 <4>FS: 00007ff42d0d0700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 <4>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>CR2: 00000000000000b0 CR3: 000000013c441000 CR4: 00000000000006f0 <4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 <4>Process java (pid: 1329, threadinfo ffff8800a5596000, task ffff880139c94080) <4>Stack: <4> ffff8800a405f780 ffff8800a405f780 ffff880028203a60 ffffffff814950f2 <4><d> ffff8800a405f780 0000000000000004 ffff880028203a80 ffffffff8143d38e <4><d> 0000000000000000 ffff8800af008380 ffff880028203b50 ffffffff81496dd4 <4>Call Trace: <4> <IRQ> <4> [<ffffffff814950f2>] tcp_data_queue+0x432/0xc70 <4> [<ffffffff8143d38e>] __kfree_skb+0x1e/0xa0 <4> [<ffffffff81496dd4>] tcp_ack+0x3b4/0x12c0 <4> [<ffffffffa01810d5>] ? ipt_do_table+0x295/0x678 [ip_tables] The trap seems consistent across several (although always CentOS) Kernel revisions including 2.6.32.431.3.1 shipped with 6.5 and manifests in the same way with the following combinations.. 1. 2.6.32.385 Kernels from 6.4 and Open VM tools RPM from VMWare package feed. 2. 2.6.32.385 Kernels from 6.4 with Open VM Tools with modules built for the Kernel. 3. 2.6.32.431.3.1 Kernel from 6.5 using vmxnet3 drivers included in the Kernel. Tracing skb_set_owner I isolated the failing operation to an inline function in sock.h which seems to be present in current Linux 3.x Kernels also. static inline int sk_has_account(struct sock *sk) { /* return true if protocol supports memory accounting */ return !!sk->sk_prot->memory_allocated; } The faulting instruction actually being the bottom one here.. /usr/src/debug/kernel-2.6.32-358.11.1.el6/linux-2.6.32-358.11.1.el6.x86_64/include/net/sock.h: 970 0xffffffff8148fd58 <skb_set_owner_r+72>: mov 0x30(%r12),%rax /usr/src/debug/kernel-2.6.32-358.11.1.el6/linux-2.6.32-358.11.1.el6.x86_64/include/net/sock.h: 1515 0xffffffff8148fd5d <skb_set_owner_r+77>: mov 0xe0(%rbx),%edx /usr/src/debug/kernel-2.6.32-358.11.1.el6/linux-2.6.32-358.11.1.el6.x86_64/include/net/sock.h: 1007 0xffffffff8148fd63 <skb_set_owner_r+83>: cmpq $0x0,0xb0(%rax) And dumping the particular sock structure reveals the problem to be that the sk->sk_prot pointer (actually that's a define pointing to __sk_common.skc_prot) to be NULL. crash> *sock 0xffff8800a405f7B0 struct sock { __sk_common = { { skc_node = { next = 0x0, pprev = 0x0 }, skc_nulls_node = { next = 0x0, pprev = 0x0 } }, skc_refcnt = { counter = 0 }, skc_hash = 0, skc_family = 0, skc_state = 0 '\000', skc_reuse = 0 '\000', skc_bound_dev_if = 0, skc_bind_node = { next = 0xcd498725cd498171, pprev = 0x1803f8a043 }, skc_prot = 0x0, skc_net = 0x5b4000005b4 }, I'm somewhat baffled as to how a structure like this can occur since the socket when constructed, either for listening or for connecting, should have skc_prot pointed to an appropriate handler and this would seem to obviate the need to additionally protect the check in sk_has_account by checking the skc_prot pointer first. I was wondering if anybody has seen anything similar or can suggest how a sock can end up in a state without skc_prot populated. Regards, Andy

1 0

Re: [CentOS-devel] CentOS 7 Artwork
by Tuomas Kuosmanen 02 Feb '14

02 Feb '14

On Wed, 2014-01-15 at 10:54 +0100, Marcus Moeller wrote: > Hi all. > > Here is my proposal artwork for the upcoming CentOS 7 release. Nice! Marcus, I wanted to share this: The stars picture reminds me of this one I did: https://dl.dropboxusercontent.com/u/2730444/foss/spaceflight.png Pretty nice co-incidence and a common theme we had by accident! =) This was one of the ideas I had while I was helping the guys with the website. (I subscribed after Karanbir showed me your mail in the archives, sorry if I messed up the mail thread headers) /Tuomas

4 5

FreeIPA functional testing
by James Hogarth 01 Feb '14

01 Feb '14

Hi all, The initial commit I made (not carried out pull request just yet) does the following: * Installs IPA packages * Does automated basic configuration of server * Verifies kerberos tickets being issued for host/admin user * Tests adding a user (and checks that the initial password is expired plus the change) In the next few days I'm intending to add: * Test adding a service and getting a keytab and certificate for that service * Test adding a host * Test adding DNS zone and records * Test reloading bind (regression test for RHBA-2013-0739) * Test sudo rules configured via IPA * Test deleting all the stuff added above After that I'll issue the pull request... Next stage subsequent to the server tests working would be client side to tests registration against the IPA server itself... Is there anything else that anyone can think of that would be useful to have in the IPA test suite? Cheers, James

1 1

CentOS Interoperability SIG
by Clint Savage 29 Jan '14

29 Jan '14

One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist. Our communities already exist outside of the CentOS community purview. They are currently the GoOSe Project[1] and the Ascendos Project[2]. This shared community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts. It would seem that this SIG could be construed as contrary to the goals of the CentOS project. However, we believe there is value added to the CentOS project. We are interested in improving the CentOS community in at least a few ways. * Providing feedback and collaboration on common issues. Including, but not limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc. * Collaboration on documentation of the rebuild process, rebranding of documentation, providing new documentation, etc. * Build or maintain tools to ease rebranding of upstream packages as to ease adoption by companies who build upon and release software based on CentOS. * Providing tools to help monitor statuses of builds, repositories, releases, etc. Whether they be part of the CentOS community or otherwise. With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed. Cheers, Clint Savage Lead Developer, GoOSe project 1 - http://gooseproject.org (#gooseproject on irc.freenode.net) 2 - http://ascendos.org (#ascendos on irc.freenode.net)

10 18

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