devel

devel@lists.centos.org

11 participants
4618 discussions

[PATCH] Updated into_srpm.sh
by Pat Riehecky 25 Jun '14

25 Jun '14

From: Pat Riehecky <riehecky(a)fnal.gov> With the recent adjustment of README.md to add GPLv2 as a default licence, I've updated the into_srpm.sh script to be a bit more flexible and use that licence by default. README.md is also updated to reflect this new script Pat Riehecky (1): Added script to re-create SRPM from git commit README.md | 2 + into_srpm.sh | 152 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 154 insertions(+), 0 deletions(-) create mode 100755 into_srpm.sh

2 2

Re: [CentOS-devel] Latest builds are now online 2014-06-25_build 4
by Morten Stevens 25 Jun '14

25 Jun '14

2014-06-25 17:50 GMT+02:00 Karanbir Singh <mail-lists(a)karan.org>: > Note: this tree now has a centos-release that implements the scope of > change we were talking about in the numbering thread. I went through > quite a few permutations and what we have here seems like the best > middle ground to be on. I am also going to try and circle back to some > of the RH folks to make sure they are ok with how we message around > where the CentOS Linux release is built from. This change is not the majority of the community. # rpm -q centos-release centos-release-7-1406.el7.centos.0.4.x86_64 7-1406 looks confusing... Is it possible to remove the YYMM section from centos-release rpm? All other Red Hat projects like Fedora doesn't use this strange release numbering. 1406 sounds like an Ubuntu release... Overall, it's a rebuilt of RHEL 7.0. Why not call it CentOS 7.0? Best regards, Morten

3 2

centosplus kernel naming
by Jim Perrin 25 Jun '14

25 Jun '14

As we gear up for the upcoming CentOS 7 release, we're tracking a few things for the CentOSPlus kernel as well. One of the proposals (via http://bugs.centos.org/view.php?id=6828 ) is that we change the current name of the centosplus kernel to be a bit more consistent with other kernel names. The proposed new name would look like 'kernel-plus' or 'kernel-centosplus'. This is in keeping with other kernel names such as 'kernel-ml', 'kernel-xen', 'kernel-lt' etc. And allows for /etc/sysconfig/kernel to be used to set the DEFAULTKERNEL as desired. This change would only be for CentOS 7. Thoughts, comments, questions, flames? Please speak up with support for or against this change. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

9 15

working around stacked updates
by Karanbir Singh 24 Jun '14

24 Jun '14

hi, Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update. We want to make sure that all our sources are in the git tree's as well, and the only way to make that happen - that I could find sane anyway - was to branch, do the work on the GA tree and then merge back into the c7/ branch past the Zeroday update. Might sound odd, but its fairly simple in implementation, the final merge is done back to the c7/ branch with a merge -s ours; so it wont retrofit older content in, but still merge the branches. this is now live at https://git.centos.org/summary/rpms!kernel.git - I've attached the visual path for the repo via gitk to this email. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 11

get_sources.sh to getopt?
by Pat Riehecky 24 Jun '14

24 Jun '14

Any objections to me switching get_sources.sh to using 'getopt' rather than shifting off the args? Pat -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/

3 2

SecureBoot, Privatebuilders and logs
by Karanbir Singh 24 Jun '14

24 Jun '14

hi, The way I have the CentOS Distro buildsystems running at this point, we cant have the secureboot signing run within the same infra ( keys, hsms other things ); The flip side to this is that logs and build results from these machines ( there are 2 in a HA pair, called the kbuilder's ) is not being pushed to buildlogs, and for the short term future - it wont be. There are a couple of technical challenges that are going to prevent this from being solved in the next few weeks. Components impacted are: shim, grub2, kernel. Code for these is still going via git.c.o - grub2, shim and kernel packages with updated centos.cer's replacing the placeholder RH ones are already in git.centos.org. I will have this issue resolved longer term, but for now logs from these builds will not be on buildlogs.centos.org. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Release file versioning, sunk costs and community involvement
by R P Herrold 24 Jun '14

24 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have stayed still on the topic of release naming, as I had little new to offer. TL;DR: my opinion is that Smooge probably has it right suggesting most recently a NEVR of: Name: centos-release Epoch: nil Version: 7.0_201407 Release: 0.201407 And I see Johnny responding to a question about trust from 'Toracat', and "Ned Slider" [each long time community participants], suggest: > I finally get the opportunity to actually work on the > project full time to make it better and somehow I am > purposely recommending something that would somehow sabotage > it? How does that make any sense at all? While 'absence of evidence is not evidence of absence' of ulterior motives, I have the strong impression that 'behind the scenes', Johnny has been carrying the water and keeping the buildsystem running, as he has since the start of the 6 series for CentOS. Part of that buildsystem is the ability to key off of a release file, which then cascades down into the 'dist' tag, and more. He seems to be an honorable man. Indeed, so are they all, all honorable men, absent indicia to the contrary. BUT notwithstanding the RHT takeover, their number is still few -- I see very few public external 'community' members commits. About three outside people and that is it, in one sample The three external non-source code branches which have activity at the centos 'git' site are: https://git.centos.org/tree/sig-cloud-instance!build-instance.git https://git.centos.org/tree/sig-core!bld-seven.git https://git.centos.org/tree/sig-core!livemedia.git and they may be viewed without pulling the git contents at: https://git.centos.org/summary/sig-cloud-instance!build-instance.git https://git.centos.org/summary/sig-core!livemedia.git https://git.centos.org/summary/sig-cloud-instance!build-instance.git I see overnight commits on: create mode 120000 mock/c7-updates-i386.cfg create mode 100644 mock/c7-updates-i686.cfg create mode 120000 mock/c7-updates-noarch.cfg create mode 100644 mock/c7-updates-x86_64.cfg ============= We have been told that the buildsystem runs off mock configs, and I have absolutely no reason to doubt it If a person wants a centos release file of a given form OTHER than a Version of: Major.Minor.`date +%y%m` My example above would be: Major.Minor_`date +%Y%m` ... it is easy enough to edit the driver sources file for 'centos-release', and the corresponding mock config files via something like: find . -type f -a -exec sed -i \ -e "@Major.Minor.`date +%y%m`(a)Major.Minor_`date +%Y%m`@g" {} \; and submit a diff from the community ============= Until then, there is a 'sunk cost' and the inertia of not touching running code [1]. Time for some community coders to step up and put meat on the bones of the words of alternative forms, or let it be fwiw, I really dislike the use of '.' as the second separatorin Version, and simply changing to '_' and adopting a 4 digit YYYY would go a LONG way to dis-ambiguate possible interpretations, and aid communication to PHB's who dont want to know all the 'inside baseball' bike-shedding, which that thread represents Just some thoughts - -- Russ herrold ps: nice link, Lamar. As a child in Montana, I was tasked with driving cows and their stupid heifers around the pasture and back to the barn, from time to time. The heifers, like those in Hosea, were amazingly stupid but creative (they could slip outside of the fences). I encountered once, and learned from that, to watch to avoid later contact with the 'presents' left by the cows in the fields [1] http://www.lifehack.org/articles/communication/how-the-sunk-cost-fallacy-ma… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlOpjG0ACgkQMRh1QZtklkRxrQCgxujq72syLiU5GTBEVZ45TibO 7dcAniwvubq4L4X3sjy+e0I/msNDCRFU =Lh5j -----END PGP SIGNATURE-----

2 1

CentOS-7 i686 Spin
by Johnny Hughes 24 Jun '14

24 Jun '14

We are going to try to build a full i686 tree. This will happen after we do the full release of the actual CentOS-7 x86_64 GA, since RHEL-7 does not have an i686 spin. There is a full i686 kernel in the i686 tree at this point, but it has not been tested, and we won't actually test it until after the CentOS-7 release happens, but the source and binary for the full i686 kernel are available in the build repos here: http://buildlogs.centos.org/c7.00.02/kernel/20140529190808/3.10.0-121.el7.i… We are not completely sure exactly where this full i686 tree will live yet in the CentOS infrastructure (ie, in /7/os/i686/ OR in a SIG repo) since it is not in RHEL-7. All things that the board will need to decide. But, I did want to make sure people know this is on our agenda .. and if there are people that want to help this along, they can get all the mock configs and try to compose a tree, etc, from mock local builds. If things don't build and need patches, then those same people can work on that as well. This list can certainly be used by those same community members to discuss or collaborate that build. If noone does it here, then I will start on it after we get CentOS-7 GA and Zero Day update released, on the trees and the initial issues fixed, etc. Along with this i686 ARCH, we will be doing a ppc64, armv7hl (32-bit), and likely (maybe) ppc (32-bit) and armv8<something> (64-bit) arches. I will announce again on this list when we get closer to actually doing things with code and/or start building those arches. Thanks, Johnny Hughes

2 1

docs for 7
by Karanbir Singh 24 Jun '14

24 Jun '14

hi, Anyone looking at Docs ? is it going to be easier/harder for us to get the docs compared with 6 ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Pam x86_64 and i686 have conflicting man pages
by Ljubomir Ljubojevic 24 Jun '14

24 Jun '14

I tried to install qt-mobility.i686 and qtwebkit.i686 from Fedora so I can install Skype. It demanded a ton of packages and among them was pam.i686. Transaction stopped with error: Transaction check error: file /usr/share/man/man8/faillock.8.gz from install of pam-1.1.8-9.el7.i686 conflicts with file from package pam-1.1.8-9.el7.x86_64 file /usr/share/man/man8/pam_env.8.gz from install of pam-1.1.8-9.el7.i686 conflicts with file from package pam-1.1.8-9.el7.x86_64 file /usr/share/man/man8/pam_faillock.8.gz from install of pam-1.1.8-9.el7.i686 conflicts with file from package pam-1.1.8-9.el7.x86_64 file /usr/share/man/man8/pam_unix.8.gz from install of pam-1.1.8-9.el7.i686 conflicts with file from package pam-1.1.8-9.el7.x86_64 file /usr/share/man/man8/pwhistory_helper.8.gz from install of pam-1.1.8-9.el7.i686 conflicts with file from package pam-1.1.8-9.el7.x86_64 -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant

4 6

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