devel July 2014

devel@lists.centos.org

82 participants
64 discussions

Cloud image default login
by Karanbir Singh 16 Jul '14

16 Jul '14

Hi, This is a conversation thats been had in the past, but i want to make sure that everyone has a perspective on this : what is the default username we should ship the cloud images with ? there seems to be an ever growing not-root voice, which is fine. For CentOS-5/6 I would prefer to still leave it as 'root' for now, however since we dont have CentOS-7 images out there yet, it might be good to get the changes in place now. options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ? 'centos' is another potentially good option, there is precidence there already. 'somethingelse': what would that something else be ? - KB -- 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

12 35

Koji targets for the SIGs
by Thomas Oulevey 16 Jul '14

16 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Folks, As discussed in the past on this mailing list for the Centos build service we need to define different koji targets for the SIGs. I 'll try to present you a possible solution. In the koji world, a "target" has a "build tag" and "destination tag". To simply the "build tag" is the buildroot and "destination tag" is the tag that will contain all the packages. If you look at Fedora koji instance (http://koji.fedoraproject.org/koji/buildtargets) you see that it is quite simple : fXX target and the associated "build tag" is fXX-build. That implies they build only packages with a single "disttag" (from the macro file) for a "destination tag". As we want to provide for each "sig" a set of targets we need to think about the naming. The SIGs will be able to choose a "disttag" ; which can be default el7.centos, el7 or something else. Let's say we have SIG="storage" DISTRIBUTION="el7". storage7-el7-build storage7-el7.centos-build storage7-el7_0-build On top of that some products we want to build/rebuild use software collection so we will need an additional buildroot (e.g: *python33-build): storage7-el7-python33-build storage7-el7_0-python33-build This part is needed for some rebuild, if the packaging is done correctly we should not need more than Requires:COLLECTION-build in the spec files. So my proposal is: For the build tags : <SIG><MAJOR>-<TAG>[-<COLLECTION>,]-build And the target : <SIG><MAJOR>-<TAG>[-<COLLECTION>,] The destination can be <SIG><MAJOR>-testing/<SIG><MAJOR>-release for all the target. (or keep the Fedora naming dist-*, but it looks more confusing to me) Maybe we can find something better, let me know. I think we need to take decision on the naming so we can integrate with centpkg (don't forget about tomorrow centpkg demo : http://lists.centos.org/pipermail/centos-devel/2014-July/011474.html) The tools need to be able depending on the "disttag" to use the correct "target" on the koji CLI, so it will be transparent to build service users. e.g: koji build storage7-el7.centos https://git.centos.org/pkg?#tag I presented this as our SIG use case but please keep in mind that we will have the same issues in the future ("Force sig to use 1 disttag only" argument) if we want to add more rebuild use cases (scl, devtoolset, etc...) I hope I did not confused you more :-) I am waiting for your feedback. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTxOseAAoJEH2Wn86OP8NiqkMH/3tOlrJVhILu7XlxCMfg8Rc9 BOVFDF2GEGO5Fru+n2kcsEFnP509Wh+EVz7Kmn01KQNggtR50hkEqhrDe6k01B9a NgedJmHoInDHZCdbQeZD/auwJIn/nQfKzRj7bmcP4lOGhRgEUPOWu/NH/QjODa7i ii2R82iw4nGnD/8N7tdsU+sVe32qiGEMIy2z3K0wfApz30VgszoUrfaW+PJ/6Zqd NOcVcXE+Zt3uV/forSj/x8KTu0JKaoh30/2MN7FNvaYedKZwavtVeu6+bLNfF2mg v32Z7fAFZbKu4+eJikW7QbrhjOLM0kWM/LjeZMHvsPDQ4N0MxrgW9GXtueRt38c= =LhVQ -----END PGP SIGNATURE-----

6 10

dist tag in rebuild SRPM
by David Mansfield 16 Jul '14

16 Jul '14

Hi All, Congrats on Centos 7, and thanks a million! This may have been answered before but I can't seem to discover... I did: yumdownloader --source sssd rpmbuild --rebuild sssd-1.11.2-68.el7_0.5.src.rpm And the packages I got had a different "dist" tag than the installed versions. Installed versions are ".el7_0" and the built ones were ".el7.centos". sssd-1.11.2-68.el7_0.5.x86_64 <== in repo sssd-1.11.2-68.el7.centos.5.x86_64 <== rebuilt locally Is there a reason for this mismatch and is in intentional or an error? It's a pain in the butt because I often want to replace existing package version using 'rpm --replacepkgs --oldpackage' while testing fixes and this makes it close to impossible due to huge dependency issues. (also, it seems like the default rebuild of the above package "forgets" to generate one of the necessary packages: python-sssdconfig, but thats a different issue). -- Thanks, David Mansfield Cobite, INC.

3 8

Upgrade tool patching and debugging.
by Jim Perrin 16 Jul '14

16 Jul '14

Now that we've got c7 mostly finalized we're starting to look at the upgrade tool. There are several moving pieces for the upgrade tool that will need some patching to work properly. For anyone who's interesting in taking a dive into the code and helping out, we have some first-run binaries located at http://dev.centos.org/centos/6/upg/ with the source living on git.centos.org These binaries will most likely not work, but they should provide a decent starting point for testing and debugging. We do not consider the upgrade tool to be a blocker for c7, so if someone would like to take a swing at the patches required to make this work while we put the finishing touches on getting c7 out the door, it would be greatly appreciated. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

6 6

vault.centos.org rsync mirror site
by Farkas Levente 15 Jul '14

15 Jul '14

hi, is there any rsync mirror site of vault.centos.org? i was unable to find any:-( thanks. regards. -- Levente "Si vis pacem para bellum!"

7 13

Re: [CentOS-devel] CentOS7 minimal install ISO
by Vincent Van der Kussen 15 Jul '14

15 Jul '14

On Jul 15, 2014 3:52 PM, Fabian Arrotin <fabian.arrotin(a)arrfab.net> wrote: > > On 15/07/14 15:14, vincent(a)vanderkussen.org wrote: > <snip> > > Hi, > > > > If possible, it would be nice to have "libselinux-python" included to > > keep > > Ansible users happy :-). Although I don't know how much deps it requires > > on el7. > > > > Regards, > > Vincent > > > > Hi Vincent, > > It's installed by default now, so yes, it's included in the packages > manifest on the iso minimal. > > Cheers, > -- > Fabian Arrotin > gpg key: 56BEC54E | twitter: @arrfab Hi Fabian, Parfait! Vincent

1 0

Delta RPMs disabled by default?
by Mustafa Muhammad 13 Jul '14

13 Jul '14

Hi, I installed CentOS 7 today, congratulations, and thank you for this fast release. I found a problem (or a design decision?), deltarpm is not installed by default (minimal install), when I ran "yum distro-sync" I got: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. deltarpm is important to me (and anybody with limited bandwidth), so is this intended or simply a bug? Regards

15 38

Centpkg: Demo and Roadmap Hangout (16-Jul, 15:00 UTC)
by Brian Stinson 12 Jul '14

12 Jul '14

Hi All, There will be a demo of Centpkg and a short discussion of the development roadmap Wednesday, July 16th at 15:00 UTC at the following Google Hangout: http://www.youtube.com/watch?v=B3hoTkHRFMc To convert this appointment to your local time run: date -d '2014-07-16 15:00 UTC' Agenda: - Short Demo of Current centpkg functionality - Questions - Next steps - How do we distribute pyrpkg without conflicting with epel? - How do we integrate properly with the CBS? - Getting quick feedback and adding new features - Anything else? Hope to see you there! Brian -- Brian Stinson bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

1 0

Processing bugs - Possible new status addition
by Phil Wyett 10 Jul '14

10 Jul '14

Hi all, This morning the discussion of certain statuses for bugs came up in #centos-devel on IRC. Scenario: - Bug reported. For argument an aged bug that is >= 1 point release lower than current point release for the bug. - Bug cannot be reproduced on same major release/current point release. - Reporter asked for feedback - Do they still have the issue? etc. - Feedback does not come in 6 months. At this point it was decided the bug should not be closed, but an appropriate status be assigned. Current statuses do not really cover the above scenario. One suggestion on IRC was a status of: CLOSED_NOFEEDBACK Thoughts, ideas, suggestions? Regards Phil

4 5

[PATCH] Added option to set explicit %dist per request
by Pat Riehecky 10 Jul '14

10 Jul '14

From: Pat Riehecky <riehecky(a)fnal.gov> --- into_srpm.sh | 32 ++++++++++++++++++++------------ 1 files changed, 20 insertions(+), 12 deletions(-) diff --git a/into_srpm.sh b/into_srpm.sh index 6ff2260..8c2434c 100755 --- a/into_srpm.sh +++ b/into_srpm.sh @@ -13,7 +13,7 @@ ##################################################################### usage() { echo '' >&2 - echo "$0 [-htq] [-b branch] [-c shasum]" >&2 + echo "$0 [-hqts] [-d dist] [-b branch] [-c shasum]" >&2 echo '' >&2 echo 'You need to run this from inside a sources git repo' >&2 echo '' >&2 @@ -22,6 +22,8 @@ usage() { echo ' -t: Set srpm timestamp to commit date' >&2 echo ' -s: Allow building as a SCL style package' >&2 echo '' >&2 + echo ' -d: Use this %{dist} instead of automatic value'>&2 + echo '' >&2 echo ' -b: specify a branch to examine' >&2 echo " defaults to repo's current branch" >&2 echo " NOTE: your repo will be set to this branch">&2 @@ -32,6 +34,8 @@ usage() { echo '' >&2 echo " $0" >&2 echo " $0 -b c7 -t" >&2 + echo " $0 -b c7 -s" >&2 + echo " $0 -b c7 -d yourdisthere" >&2 echo " $0 -b remotes/origin/c7" >&2 echo " $0 -c 865ae5909b2b5d5fb37971b7ad7960f1fd5a5ffa" >&2 echo " $0 -b c7 -c 865ae5909b2b5d5fb37971b7ad7960f1fd5a5ffa" >&2 @@ -45,13 +49,14 @@ KEEPTIMESTAMP=0 ALLOWSCL=0 COMMITHASH="" BRANCH="" +DIST='' ##################################################################### # setup args in the right order for making getopt evaluation # nice and easy. You'll need to read the manpages for more info # utilizing 'while' construct rather than 'for arg' to avoid unnecessary # shifting of program args -args=$(getopt -o htsqb:c: -- "$@") +args=$(getopt -o htsqb:c:d: -- "$@") eval set -- "$args" while [[ 0 -eq 0 ]]; do @@ -76,6 +81,11 @@ while [[ 0 -eq 0 ]]; do ALLOWSCL=1 shift ;; + -d ) + # Set %{dist} to this instead the automatic value + DIST=$2 + shift + ;; -c ) # Use this commit id COMMITHASH=$2 @@ -118,12 +128,6 @@ if [[ $? -ne 0 ]]; then exit 1 fi -which get_sources.sh >/dev/null 2>&1 -if [[ $? -ne 0 ]]; then - echo 'You need get_sources.sh from centos-git-common in PATH' >&2 - exit 1 -fi - which show_possible_srpms.sh >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo 'You need show_possible_srpms.sh from centos-git-common in PATH' >&2 @@ -180,10 +184,14 @@ fi # build our rpmopts list RPMOPTS="-bs --nodeps" -if [[ ${QUIET} -eq 1 ]]; then - DIST=$(return_disttag.sh -q) -else - DIST=$(return_disttag.sh) + +# determine automatically unless we've got one set +if [[ "x${DIST}" == 'x' ]]; then + if [[ ${QUIET} -eq 1 ]]; then + DIST=$(return_disttag.sh -q) + else + DIST=$(return_disttag.sh) + fi fi # put it all together -- 1.7.1

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel July 2014