From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mail-lists at karan.org Wed Apr 1 02:41:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 03:41:12 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B0AE0.8020500@mwob.org.uk> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> Message-ID: <551B5AC8.309@karan.org> On 31/03/15 22:00, Howard Johnson wrote: > > > On 31/03/2015 21:53, Karanbir Singh wrote: >> what tools are these / can we reach out and help them get the right >> content ? this solves the problem of establishing an upstream, giving >> people who only need a lose knit baseline match and also giving people >> the centos-7 release stream that we've been building up. At the time >> of 7 1406 release, this was flagged up as the biggest issue that we >> need to fix from the distro side of things. > > Hmm, ok. Can we put that data somewhere else instead (an > /etc/redhat-upstream-release file or something) and revert the > redhat-release change? We can't expect everyone to run around updating > their system management tools for a change in a minor point release :( > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html update pushed. sorry for breaking stuff folks :( -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From nkadel at gmail.com Wed Apr 1 03:01:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Mar 2015 23:01:26 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B3162.8010004@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <20150331233907.GA4174@fcshome.stoneham.ma.us> <551B3162.8010004@karan.org> Message-ID: On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh wrote: > On 01/04/15 00:39, Fred Smith wrote: >> On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote: >>> On 03/31/2015 10:00 PM, Howard Johnson wrote: >>>> >>>> >>>> On 31/03/2015 21:53, Karanbir Singh wrote: >>>>> what tools are these / can we reach out and help them get the right >>>>> content ? this solves the problem of establishing an upstream, giving >>>>> people who only need a lose knit baseline match and also giving people >>>>> the centos-7 release stream that we've been building up. At the time >>>>> of 7 1406 release, this was flagged up as the biggest issue that we >>>>> need to fix from the distro side of things. >>>> >>>> Hmm, ok. Can we put that data somewhere else instead (an >>>> /etc/redhat-upstream-release file or something) and revert the >>>> redhat-release change? We can't expect everyone to run around updating >>>> their system management tools for a change in a minor point release :( >> >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. >> > > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it. Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schr?dinger's Cat", it broke even more tools. Nico Kadel-Garcia From Florian.LaRoche at gmx.net Wed Apr 1 12:11:11 2015 From: Florian.LaRoche at gmx.net (Florian La Roche) Date: Wed, 1 Apr 2015 14:11:11 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B2544.1060909@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> Message-ID: <20150401121106.GA5105@lists> On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: > On 03/31/2015 10:33 PM, Karanbir Singh wrote: > > On 03/31/2015 10:00 PM, Howard Johnson wrote: > >> > >> > >> On 31/03/2015 21:53, Karanbir Singh wrote: > >>> what tools are these / can we reach out and help them get the right > >>> content ? this solves the problem of establishing an upstream, giving > >>> people who only need a lose knit baseline match and also giving people > >>> the centos-7 release stream that we've been building up. At the time > >>> of 7 1406 release, this was flagged up as the biggest issue that we > >>> need to fix from the distro side of things. > >> > >> Hmm, ok. Can we put that data somewhere else instead (an > >> /etc/redhat-upstream-release file or something) and revert the > >> redhat-release change? We can't expect everyone to run around updating > >> their system management tools for a change in a minor point release :( > >> > > > > we are trying to thrash out a possible solution here. stand by > > > > ok so we are issuing a new centos-release file as an update and a base > replacement that will resolve this issue - and we are also investigating > redoing the isos in a way that we can solve this problem for people > doing fresh installs. > > stand by for more details Thanks for the update coming in, /etc/redhat-release is really an important file to get right... Seems also the ISO images are refreshed with this. best regards, Florian La Roche From merlin at mwob.org.uk Wed Apr 1 13:15:54 2015 From: merlin at mwob.org.uk (Howard Johnson) Date: Wed, 01 Apr 2015 14:15:54 +0100 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551B5AC8.309@karan.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B5AC8.309@karan.org> Message-ID: <551BEF8A.3010003@mwob.org.uk> On 01/04/2015 03:41, Karanbir Singh wrote: > http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html > > update pushed. > > sorry for breaking stuff folks :( Cheers for the speedy and comprehensive response, KB :) -- HJ From johnny at centos.org Wed Apr 1 16:01:33 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 01 Apr 2015 11:01:33 -0500 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <20150331115904.GA28699@humongous.cable.virginmedia.net> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> Message-ID: <551C165D.3000000@centos.org> On 03/31/2015 06:59 AM, Jon Ludlam wrote: > On Tue, Mar 31, 2015 at 11:37:04AM +0100, Karanbir Singh wrote: >> On 31/03/15 11:17, George Dunlap wrote: >>> KB / Jonathan / Others, >>> >>> One of our potential GSoC students, Guatam Malu, has proposed trying >>> to include xapi packages in the "Xen in a Box" project. >>> >>> He's gotten packages of xapi building for CentOS 6.6 using XenServer's >>> buildroot (see below). >>> >>> The only potential issue I see is about signing. >> >> And the content and the origin of content and the build cycle for the >> entire content stream. >> >>> >>> As I understand it, xapi requires a newer version of ocaml than is >>> available in C6. The XenServer buildroot includes (and I think >>> builds) a newer version of ocaml; but (again I think) xapi is >>> statically linked, so the new ocaml packages are only required for >>> build, and not for runtime. At the moment Jonathan is trying to work >>> with one of the other SIGs to get the necessary ocaml support; it's >>> not clear when that will happen. >>> >>> Until that time, the only way to get xapi packages built in koji by >>> the Virt SIG would be to also include the newer version of ocaml (and >>> whatever other dependencies there are), which we'd like to avoid. >> >> why ? I thought there was traction around the idea of having a full >> ocaml stack that represents upstream ocaml. >> >>> >>> So the question is: Do we need to have all the packages on "Xen in a >>> Box" CD signed with the CentOS SIG key? If so, do we see any >>> likelihood that this might be possible by July -- either having a >>> suitable ocaml to build against in koji, or getting the packages built >>> and signed some other way? >> >> given that there are packages for ocaml, if someone was working on this >> as a primary focus, I dont see why it should be more than a couple of >> weeks worth of work to get them building. The key part here is going to >> be knowledge of ocaml itself. >> > > I believe the idea was to use an OCaml SCL for this, and then when the > softwarecollections.org became a CentOS SIG, the virt SIG could depend > upon it. > > I've been working on this here: > > http://copr.fedoraproject.org/coprs/jonludlam/ocaml402/builds/ > > and here: > > https://github.com/jonludlam/ocaml402-buildroot > > I had some initial feedback from the SCL guys and have incorporated > that, and the packages have had some testing by us, Jane Street and > OCamlLabs. I think the next step is to do whatever is necessary for > the SCL to become an 'official' one. > > Jon I have no idea if those SCL's can build on our koji CBS now or not. But if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, c6-updates, c6-centosplus then I would be happy to grab the and put them in the xen4 or centosplus repos for the Virt SIG to use. Same for the EL7 ones if George needs them for xen on c7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 1 16:46:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:46:55 +0100 Subject: [CentOS-devel] xapi on CentOS 6 In-Reply-To: <551C165D.3000000@centos.org> References: <551A78D0.7050203@karan.org> <20150331115904.GA28699@humongous.cable.virginmedia.net> <551C165D.3000000@centos.org> Message-ID: <551C20FF.60102@karan.org> On 04/01/2015 05:01 PM, Johnny Hughes wrote: > I have no idea if those SCL's can build on our koji CBS now or not. But > if you can build EL6 RPMs that work with themselves, c6-extras, c6-os, > c6-updates, c6-centosplus then I would be happy to grab the and put them > in the xen4 or centosplus repos for the Virt SIG to use. > > Same for the EL7 ones if George needs them for xen on c7. SCl's should build in koji - the onramp is to skip git.c.o for now, but with the targets and srpms, it should go through. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 1 16:48:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 01 Apr 2015 17:48:41 +0100 Subject: [CentOS-devel] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551AADE1.9090609@redhat.com> References: <551AADE1.9090609@redhat.com> Message-ID: <551C2169.1000603@karan.org> On 03/31/2015 03:23 PM, Honza Horak wrote: > Unfortunately I'm not available this week on Wed, I'm sorry, so > let's arrange the SCLo meeting the next week. Since we have DST in > Europe already as well, let's change to 15:00 UTC, that should fit > to out schedules the same as it did on non-DST. > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > Freenode. > > = Topics = * sync-up on current status * propose some other > topics:) > I wont be able to make it on the 8th - will be on the road. However, one important thing is that I spent a bit of time with Brian today and he's mostly caught up with the mechanics of the backend/lookaside process. It would be great if you can make sure the SCL story on that front ( which is the most complicated one ) is clearly addressed with him. Brian are you able to make this meetin on the 8th ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Wed Apr 1 18:35:56 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 1 Apr 2015 13:35:56 -0500 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551C2169.1000603@karan.org> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> Message-ID: <20150401183556.GO3399@byrd.math.ksu.edu> On Apr 01 17:48, Karanbir Singh wrote: > On 03/31/2015 03:23 PM, Honza Horak wrote: > > Unfortunately I'm not available this week on Wed, I'm sorry, so > > let's arrange the SCLo meeting the next week. Since we have DST in > > Europe already as well, let's change to 15:00 UTC, that should fit > > to out schedules the same as it did on non-DST. > > > > So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, > > 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on > > Freenode. > > > > = Topics = * sync-up on current status * propose some other > > topics:) > > > > I wont be able to make it on the 8th - will be on the road. However, > one important thing is that I spent a bit of time with Brian today and > he's mostly caught up with the mechanics of the backend/lookaside > process. It would be great if you can make sure the SCL story on that > front ( which is the most complicated one ) is clearly addressed with > him. > > Brian are you able to make this meetin on the 8th ? Definitely. I should have a short update on tooling by then, and we can dig into the details of the SCL workflow. Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From seitz at bsd-unix.net Thu Apr 2 04:21:40 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 02 Apr 2015 00:21:40 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <20150401121106.GA5105@lists> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> Message-ID: <551CC3D4.9090409@bsd-unix.net> On 4/1/15 8:11 AM, Florian La Roche wrote: > On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote: >> we are trying to thrash out a possible solution here. stand by >> >> ok so we are issuing a new centos-release file as an update and a base >> replacement that will resolve this issue - and we are also investigating >> redoing the isos in a way that we can solve this problem for people >> doing fresh installs. >> >> stand by for more details > Thanks for the update coming in, /etc/redhat-release is > really an important file to get right... > > Seems also the ISO images are refreshed with this. > > best regards, > > Florian La Roche > > Team, I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! From afb at users.sourceforge.net Thu Apr 2 07:28:32 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 09:28:32 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CC3D4.9090409@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> Message-ID: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Karanbir Singh wrote: >> another less-than-optimal solution would be for app developers to >> start using lsb_release to find out what distro and release they >> are installing onto. of course, that's a different problem, in more >> than one way, at least one of which is that lsb_release is not installed >> by default. >> >> I'm switching the app installer for the program I maintain (at work) >> to use lsb_release just because it's so much easier than groping >> /etc/redhat-release. > > have you looked at /etc/os-release ? you can just source it and you get > the content needed. I believe most people are trying to drive towards > using that ( plus you dont need the lsb dep chain under it then ) Bryan Seitz wrote: > Team, > > I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. * http://0pointer.de/blog/projects/os-release.html Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier. I don't think it's possible to change all redhat-release usage anyway. --anders From peter at pajamian.dhs.org Thu Apr 2 08:31:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 02 Apr 2015 21:31:39 +1300 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <551CFE6B.6080000@pajamian.dhs.org> On 04/02/2015 08:28 PM, Anders F Bj?rklund wrote: > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > > But os-release is a systemd "feature"*. Seems unlikely to make it ? Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6. > I don't think it's possible to change all redhat-release usage anyway. Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints. Peter From walters at verbum.org Thu Apr 2 10:01:50 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 02 Apr 2015 06:01:50 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> Message-ID: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > As discussed in last week's meeting > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > I've put a CentOS Atomic release checklist in the wiki at: > > http://wiki.centos.org/Atomic/ReleaseManagement Nice, thanks for putting this together. But should this go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? From afb at users.sourceforge.net Thu Apr 2 10:49:25 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Apr 2015 12:49:25 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551CFE6B.6080000@pajamian.dhs.org> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: Peter wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> >> But os-release is a systemd "feature"*. Seems unlikely to make it ? > > Really? On my system it's a very simple text file included with the > centos-release package. I honestly can't see how having sys-v-init or > upstart would make it impossible or even remotely difficult to create > such a text file and include it in CentOS 5 and 6. Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ? Most downstream usage of the distro/release is plain wrong*, anyway... * easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything. Go ahead and use the silly name of the distro file. I'm sure I'll survive :-) >> I don't think it's possible to change all redhat-release usage anyway. > > Well, fortunately it's not redhat-release, that's a package that comes > with RHEL. CentOS comes with the package centos-release which is > specific to CentOS and therefore we should be able to make changes to > without worrying about upstream constraints. Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release... And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ? i.e. /etc/redhat-release is a symlink to it, so the syntax does matter. But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy. And for the OS rant earlier, I suppose there's always uname(1) and arch(1). --anders From nkadel at gmail.com Thu Apr 2 11:51:54 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 2 Apr 2015 07:51:54 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:49 AM, Anders F Bj?rklund wrote: > Peter wrote: > >>>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >>> >>> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> >> Really? On my system it's a very simple text file included with the >> centos-release package. I honestly can't see how having sys-v-init or >> upstart would make it impossible or even remotely difficult to create >> such a text file and include it in CentOS 5 and 6. > > Sure, and as such it's probably "better" than the lsb_release *program*. > But you would still have to install something extra, in the old releases ? And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this: https://xkcd.com/1172/ From hhorak at redhat.com Thu Apr 2 12:40:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 02 Apr 2015 14:40:48 +0200 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <20150401183556.GO3399@byrd.math.ksu.edu> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> Message-ID: <551D38D0.6030300@redhat.com> On 04/01/2015 08:35 PM, Brian Stinson wrote: > On Apr 01 17:48, Karanbir Singh wrote: >> On 03/31/2015 03:23 PM, Honza Horak wrote: >>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>> let's arrange the SCLo meeting the next week. Since we have DST in >>> Europe already as well, let's change to 15:00 UTC, that should fit >>> to out schedules the same as it did on non-DST. >>> >>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>> Freenode. >>> >>> = Topics = * sync-up on current status * propose some other >>> topics:) >>> >> >> I wont be able to make it on the 8th - will be on the road. However, >> one important thing is that I spent a bit of time with Brian today and >> he's mostly caught up with the mechanics of the backend/lookaside >> process. It would be great if you can make sure the SCL story on that >> front ( which is the most complicated one ) is clearly addressed with >> him. >> >> Brian are you able to make this meetin on the 8th ? > > Definitely. I should have a short update on tooling by then, and we can > dig into the details of the SCL workflow. That sounds really nice, thanks. Honza From adragomir at gmail.com Thu Apr 2 12:51:06 2015 From: adragomir at gmail.com (Andrei DRAGOMIR) Date: Thu, 2 Apr 2015 15:51:06 +0300 Subject: [CentOS-devel] Building Centos 7 Cloud images Message-ID: Hi, I have a question related to the cloud images available here: http://cloud.centos.org/centos/7/images/ 1. How do I build an image ? I looked at the source repos on git.centos.org, the closest one seems to be the sig-cloud-instance/build-instance repository, but I cannot find centos 7 related kickstarts in there. (I am assuming that the images are being built in an automated fashion, using unattended installation) Thank you, Andrei Dragomir -- /A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Apr 2 15:27:29 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:27:29 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> Message-ID: On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia wrote: > > > And in *all* the old management tools that need to detect the > operating system, even the obsolete releases.Please don't muck with > stable workflow: And for the inevitable XKCD cartoon about this: > > https://xkcd.com/1172/ Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/files/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/ (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows). Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.1/view/head:/lib/Ocsinventory/Agent/Backend/OS/Linux/Distro/NonLSB/CentOS.pm (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too. Why does something this simple have to waste so much time? -- Les Mikesell lesmikesell at gmail.com From lowen at pari.edu Thu Apr 2 15:34:58 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 2 Apr 2015 11:34:58 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> Message-ID: <551D61A2.40100@pari.edu> On 04/02/2015 11:27 AM, Les Mikesell wrote: > Why does something this simple [as figuring out what OS and version > you're on] have to waste so much time? Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs. It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem. From lesmikesell at gmail.com Thu Apr 2 15:59:15 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 2 Apr 2015 10:59:15 -0500 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <551D61A2.40100@pari.edu> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen wrote: > On 04/02/2015 11:27 AM, Les Mikesell wrote: >> >> Why does something this simple [as figuring out what OS and version you're >> on] have to waste so much time? > > Sorry for the editorial brackets there, Les, but that is, I think, an > accurate distillation of the previous paragraphs. > > It's not simple because of the Perl mantra and the very nature of free and > open source development. It is the beast we have; and as long as consensus > between disparate distributions of just Linux is not found on this topic it > will remain less simple than it could be. Distributions have vested > interests - competitive, egotistic, and other - to do things differently, > and that's not likely to change, as much as I wish it would. And that's > just within the Linux ecosystem. I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards... -- Les Mikesell lesmikesell at gmail.com From kwade at redhat.com Thu Apr 2 16:00:04 2015 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Apr 2015 09:00:04 -0700 Subject: [CentOS-devel] Congratulations for selection in GSOC-2015 In-Reply-To: <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> References: <54F4C24A.3010405@redhat.com> <54F5B282.9020704@karan.org> <54F60686.9060001@redhat.com> <54FE1D38.1090400@redhat.com> <54FEE459.6000704@karan.org> <54FF7E06.2050008@redhat.com> <1C0860C1-79D7-49E9-B6D5-310E58DAFE3F@gmail.com> <551037EF.30509@redhat.com> <0195D2AA-C767-4807-8974-59C86AA7B475@gmail.com> Message-ID: <551D6784.6030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 05:42 AM, Lars Kurth wrote: > Karsten, > > what I really wanted to ask is how the CentOS community wants to > handle 7, assuming there are always too many GSoC applicants. All > the other steps are understood. Thanks, & just getting around to replying, sorry for the delay. > What I did in the past was to organize 1-3 private meetings with > mentors to come up with a shortlist and figure out how many slots > to allocate. The scoring mechanism is OK, but people tend to give > their proposals often a higher score than they should and mentors > have different expectations. Coming up with a shortlist (or ordered > list of applicants) can be a bit of a chore for larger projects and > there could be disagreements between mentors of course. I don't really have any issues with that approach, it's different than what I've done in the past. I haven't had too many issues with not being able to sort out the priority order -- mentors are usually honest when they are up-voting for personal desire v. because they like/dislike other proposals. > And from past experience I found that it is better to focus on the > best students and the ones who engage with the mailing list very > publicly straight from the beginning. Those who don't rarely tend > to engage more during the program. This is quite true. Anyway, I'm glad we discussed this transparently here, but as it's about GSoC process (v. technical discussion), I'm going to start a new thread on centos-gsoc@ list to discuss our proposal finalizing process. - - Karsten-- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdZ4QACgkQ2ZIOBq0ODEFV+gCeIpjgxA98v0ZSNPrXcJcKJNtc aXsAniJ9f54eaKoO4JUzVJ4/VvOhxRyE =YWre -----END PGP SIGNATURE----- From jzb at redhat.com Thu Apr 2 16:12:10 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Thu, 2 Apr 2015 12:12:10 -0400 (EDT) Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> Message-ID: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Colin Walters" > To: centos-devel at centos.org > Sent: Thursday, April 2, 2015 6:01:50 AM > Subject: Re: [CentOS-devel] Atomic release checklist > > On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: > > As discussed in last week's meeting > > (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), > > I've put a CentOS Atomic release checklist in the wiki at: > > > > http://wiki.centos.org/Atomic/ReleaseManagement > > Nice, thanks for putting this together. But should this > go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ From rbowen at redhat.com Thu Apr 2 17:00:05 2015 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 02 Apr 2015 13:00:05 -0400 Subject: [CentOS-devel] Cloud SIG meeting minutes Message-ID: <551D7595.5090202@redhat.com> Notes from today's Cloud SIG Meeting. We were pleased to have NuxRo from the Apache CloudStack community in attendance, and a major topic of conversation was how CloudStack can get involved in what we're doing, benefit from the CI effort, and various other cloud-init related discussions. Thank you all for your time and participation. Minutes: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.html Minutes (text): http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.txt Log: http://centos.org/minutes/2015/april/centos-devel.2015-04-02-15.11.log.html -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From kunaalus at gmail.com Thu Apr 2 21:23:19 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 02:53:19 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From kunaalus at gmail.com Thu Apr 2 21:45:07 2015 From: kunaalus at gmail.com (kunaal jain) Date: Fri, 3 Apr 2015 03:15:07 +0530 Subject: [CentOS-devel] Reg: Documentation Toolchain [GSOC] Message-ID: Hi guys, I have submitted my proposal on google-melange. I have been active in discussion regarding this on centos-docs as well with Karsten. I have created a small demo tool chain, to have a clarity on how process will flow and how site can be generated on git commits and deploying to hosting platform. You can find the code as well as the live version at : https://github.com/kunaaljain/test-centos-docs Please have a look at the proposal and the sample code I have written and give suggestions on how I can improve the proposal. Please note that the sample code is written for testing purpose, the actual toolchain may not use the open source tools I am using in it. Regards, Kunal Jain From mail-lists at karan.org Thu Apr 2 22:23:14 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:23:14 +0100 Subject: [CentOS-devel] Building Centos 7 Cloud images In-Reply-To: References: Message-ID: <551DC152.9060508@karan.org> On 02/04/15 13:51, Andrei DRAGOMIR wrote: > Hi, I have a question related to the cloud images available > here: http://cloud.centos.org/centos/7/images/ > > 1. How do I build an image ? I looked at the source repos on > git.centos.org , the closest one seems to be the > sig-cloud-instance/build-instance repository, but I cannot find centos 7 > related kickstarts in there. (I am assuming that the images are being > built in an automated fashion, using unattended installation) we exchanged emails around this earlier today, as i had mentioned there - the AMI's are just the GenericCloud image, you would need to refer to the ec2 tool chains to see how best you can consume them. -KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 2 22:24:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Apr 2015 23:24:22 +0100 Subject: [CentOS-devel] [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) In-Reply-To: <551D38D0.6030300@redhat.com> References: <551AADE1.9090609@redhat.com> <551C2169.1000603@karan.org> <20150401183556.GO3399@byrd.math.ksu.edu> <551D38D0.6030300@redhat.com> Message-ID: <551DC196.6020501@karan.org> On 02/04/15 13:40, Honza Horak wrote: > On 04/01/2015 08:35 PM, Brian Stinson wrote: >> On Apr 01 17:48, Karanbir Singh wrote: >>> On 03/31/2015 03:23 PM, Honza Horak wrote: >>>> Unfortunately I'm not available this week on Wed, I'm sorry, so >>>> let's arrange the SCLo meeting the next week. Since we have DST in >>>> Europe already as well, let's change to 15:00 UTC, that should fit >>>> to out schedules the same as it did on non-DST. >>>> >>>> So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, >>>> 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on >>>> Freenode. >>>> >>>> = Topics = * sync-up on current status * propose some other >>>> topics:) >>>> >>> >>> I wont be able to make it on the 8th - will be on the road. However, >>> one important thing is that I spent a bit of time with Brian today and >>> he's mostly caught up with the mechanics of the backend/lookaside >>> process. It would be great if you can make sure the SCL story on that >>> front ( which is the most complicated one ) is clearly addressed with >>> him. >>> >>> Brian are you able to make this meetin on the 8th ? >> >> Definitely. I should have a short update on tooling by then, and we can >> dig into the details of the SCL workflow. > > That sounds really nice, thanks. > I wonder if Jon's OCAML scl might be usable as the exercise to validate this.. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From tsorensen at gmail.com Sun Apr 5 02:49:48 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Sat, 4 Apr 2015 22:49:48 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <551CFE6B.6080000@pajamian.dhs.org> <551D61A2.40100@pari.edu> Message-ID: On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell wrote: > So, please - stick to standards... > The wonderful thing about standards is that there are so many of them to choose from. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Mon Apr 6 07:02:10 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 06 Apr 2015 03:02:10 -0400 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> Message-ID: <55222F72.5000106@bsd-unix.net> On 4/2/15 3:28 AM, Anders F Bj?rklund wrote: > Karanbir Singh wrote: >>> another less-than-optimal solution would be for app developers to >>> start using lsb_release to find out what distro and release they >>> are installing onto. of course, that's a different problem, in more >>> than one way, at least one of which is that lsb_release is not installed >>> by default. >>> >>> I'm switching the app installer for the program I maintain (at work) >>> to use lsb_release just because it's so much easier than groping >>> /etc/redhat-release. >> have you looked at /etc/os-release ? you can just source it and you get >> the content needed. I believe most people are trying to drive towards >> using that ( plus you dont need the lsb dep chain under it then ) > > Bryan Seitz wrote: > >> Team, >> >> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! > But os-release is a systemd "feature"*. Seems unlikely to make it ? > Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. > > * http://0pointer.de/blog/projects/os-release.html > > Ironically it doesn't even contain the name of the Operating System... > We saw this when it was introduced in (and broke) PackageKit earlier. > > I don't think it's possible to change all redhat-release usage anyway. Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. From afb at users.sourceforge.net Mon Apr 6 08:12:28 2015 From: afb at users.sourceforge.net (=?iso-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Apr 2015 10:12:28 +0200 Subject: [CentOS-devel] enhancing /etc/*-release In-Reply-To: <55222F72.5000106@bsd-unix.net> References: <54EA640E.7070008@karan.org> <551AFF03.60906@mwob.org.uk> <551B0936.8090008@karan.org> <551B0AE0.8020500@mwob.org.uk> <551B12B1.8020602@karan.org> <551B2544.1060909@karan.org> <20150401121106.GA5105@lists> <551CC3D4.9090409@bsd-unix.net> <15764F17-DB9B-4737-BC5F-C9A408EB9FA5@users.sourceforge.net> <55222F72.5000106@bsd-unix.net> Message-ID: <3E03EF25-3597-43D0-B601-342C98A9095C@users.sourceforge.net> Bryan Seitz wrote: >>> I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work! >> But os-release is a systemd "feature"*. Seems unlikely to make it ? >> Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then. >> >> * http://0pointer.de/blog/projects/os-release.html >> >> Ironically it doesn't even contain the name of the Operating System... >> We saw this when it was introduced in (and broke) PackageKit earlier. >> >> I don't think it's possible to change all redhat-release usage anyway. > Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works. > > I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward. I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is... It does address my concerns (for redhat-release) in that article, too. :-) Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility". Says http://www.freedesktop.org/software/systemd/man/os-release.html But you would still need to parse "some other file" to get the minor version. Since systemd only includes the "operating system version", i.e. 5 or 6 or 7 NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" So that old redhat-release would still be "needed", for getting at the 6.6... --anders From s_gowtham at live.com Mon Apr 6 13:02:51 2015 From: s_gowtham at live.com (Gow Tham) Date: Mon, 6 Apr 2015 18:32:51 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS Message-ID: Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Mon Apr 6 13:06:25 2015 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 6 Apr 2015 18:36:25 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay From jzb at redhat.com Mon Apr 6 15:40:26 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 06 Apr 2015 11:40:26 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> Message-ID: <5522A8EA.3030202@redhat.com> On 04/02/2015 12:12 PM, Joe Brockmeier wrote: > ----- Original Message ----- >> From: "Colin Walters" >> To: centos-devel at centos.org >> Sent: Thursday, April 2, 2015 6:01:50 AM >> Subject: Re: [CentOS-devel] Atomic release checklist >> >> On Fri, Mar 27, 2015, at 03:03 PM, Jason Brooks wrote: >>> As discussed in last week's meeting >>> (http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html), >>> I've put a CentOS Atomic release checklist in the wiki at: >>> >>> http://wiki.centos.org/Atomic/ReleaseManagement >> >> Nice, thanks for putting this together. But should this >> go under http://wiki.centos.org/SpecialInterestGroup/Atomic ? > > Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. OK, I moved the page and *tried* nuking Atomic but seem not to have enough permissions juice to do so. -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amyagi at gmail.com Mon Apr 6 15:49:22 2015 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 6 Apr 2015 08:49:22 -0700 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: <5522A8EA.3030202@redhat.com> References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: On Mon, Apr 6, 2015 at 8:40 AM, Joe Brockmeier wrote: > On 04/02/2015 12:12 PM, Joe Brockmeier wrote: >> Yeah. I will do that and also nuke /Atomic/ so we don't have confusion. > > OK, I moved the page and *tried* nuking Atomic but seem not to have > enough permissions juice to do so. That page deleted. Akemi From jzb at redhat.com Tue Apr 7 13:11:32 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:11:32 -0400 Subject: [CentOS-devel] Atomic release checklist In-Reply-To: References: <1680177056.6887038.1427483021746.JavaMail.zimbra@redhat.com> <1427968910.1985045.248472325.6B406DA9@webmail.messagingengine.com> <253865147.8491365.1427991130593.JavaMail.zimbra@redhat.com> <5522A8EA.3030202@redhat.com> Message-ID: <5523D784.8000808@redhat.com> On 04/06/2015 11:49 AM, Akemi Yagi wrote: > That page deleted. Thanks, Akemi! Much appreciated. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jzb at redhat.com Tue Apr 7 13:39:57 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Tue, 07 Apr 2015 09:39:57 -0400 Subject: [CentOS-devel] Atomic SIG Meeting Minutes & Meeting Reminder (Thursday 16:00 UTC) Message-ID: <5523DE2D.4000704@redhat.com> Next meeting is Thursday 9 April at 16:00 UTC. ========================= #centos-devel: Atomic SIG ========================= Meeting started by jzb at 16:03:35 UTC. The full logs are available at http://centos.org/minutes/2015/april/centos-devel.2015-04-02-16.03.log.html . Meeting summary --------------- * LINK: http://centos.org/minutes/2015/march/centos-devel.2015-03-19-16.00.html (jzb, 16:04:15) * signing (jzb, 16:04:23) * ACTION: imcleod take lead on getting signing ready for imminent "stable" release (jzb, 16:06:00) * document release checklist (jzb, 16:06:36) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:49) * LINK: http://wiki.centos.org/Atomic/ReleaseManagement (jzb, 16:07:56) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic has a bunch of stuff under there, maybe this can also live there ? (kbsingh, 16:08:51) * LINK: http://wiki.centos.org/SpecialInterestGroup/Atomic/Download as an example (kbsingh, 16:09:00) * LINK: http://wiki.centos.org/Atomic/WeeklyMeeting (kbsingh, 16:09:23) * ACTION: jzb move Release Management page after meeting (jzb, 16:10:29) * release scheme for image kickstarts and Dockerfiles (jzb, 16:11:01) * ACTION: imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o (jzb, 16:15:47) * get final dates/info on two and four-week update plans. (jzb, 16:17:11) * ACTION: jzb set up meeting to align 4-week cycle. (jzb, 16:20:19) * atomic info in /etc/os-release (jzb, 16:20:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1200122 (walters, 16:29:48) * ACTION: lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel (jzb, 16:32:39) * open floor (jzb, 16:32:49) Meeting ended at 16:36:47 UTC. Action Items ------------ * imcleod take lead on getting signing ready for imminent "stable" release * jzb move Release Management page after meeting * imcleod Establish ongoing release process for non-RPM artifacts, ideally into g.c.o * jzb set up meeting to align 4-week cycle. * lalatenduM set up discussion with kbsingh and langdon about os-release, report back to atomic-devel -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Tue Apr 7 15:10:47 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 07 Apr 2015 11:10:47 -0400 Subject: [CentOS-devel] "CentOS.devel" Message-ID: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ And I'm sure others. (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) From lsm5 at fedoraproject.org Tue Apr 7 15:27:31 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 10:27:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> Message-ID: <20150407152730.GA9831@naruto> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update? > > Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo. +1, given that packages like docker could be relevant to atomic and virt. > > As well as these "hand built" RPMs: > http://people.redhat.com/lnykryn/systemd/ > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > And I'm sure others. I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision. > > (I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives) > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Tue Apr 7 21:35:43 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 7 Apr 2015 16:35:43 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <20150407213536.GA15980@naruto> Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kwade at redhat.com Tue Apr 7 22:49:32 2015 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Apr 2015 15:49:32 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55245EFC.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. A few questions that come to mind ... What is the SLA that Fedora has around bugzilla.redhat.com? (One clear advantage of running our own bug tracker is full autonomy.) What is the process like to get changes made to Bugzilla to support project needs? Are we able to have all the granularity we need as just a sub-product in Bugzilla? (E.g. for SIGs where we might have multiple versions of a package for the same major version of CentOS.) Can CentOS QA or security track issues privately as part of a group in the product? (By this I include being able to block all other users including @redhat.com accounts.) What are the benefits to bug testers? I know the benefit to people who maintain packages in Fedora who are also upstream maintainer at Red Hat, but most of the bug testers/QA folk for CentOS mainly work on just CentOS and not Fedora nor RHEL. Are the terms of service for bugzilla.redhat.com different enough that people who are comfortable getting an account on a non-commercially-supported bug tracker are less comfortable or maybe not even able to get an account on a redhat.com domain? > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. While I can see how it would help the subset of contributors who deal with bugs, how does it help the end-user experience? My reckoning is that most CentOS users are not also users of Fedora. Some may be users of RHEL, but if they are, they can file bugs under their customer account and get better attention than filing under a CentOS product. While we can never know the crossover, can we presume that anyone filing a bug on centos.org is likely choosing the only method that makes sense? So this change would benefit primarily people who deal with bugs in all three distros, but how many of the users (who now user bugs.centos.org happily enough) would be inconvenienced for the small set of users who also file bugs in all three distros? > Considering docker as an example, when people complain about docker > bugs they notice on CentOS7, I'm not sure whether to ask them to > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > something from RHEL. My guess is their first choice is to file bugs > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > variants and these are not pulled from RHEL. For bugs related to > these, I'll need to ask users to file bugs on bugs.c.o and if this > affects fedora/rhel as well, there would be separate bugs on RH's > bugzilla about this. > > I feel it'd be much more convenient for me (and possibly others) to > keep track of bugs and reference them if they're all hosted in a > single place. > > Comments? > > > * This issue has been apparently raised in the past as per > conversations with Evolution on #centos-devel but it's kinda hard > to find out recorded history about it. If anyone could send logs > about why this was rejected or whatever, it'd be great. I don't recall any public discussions on this topic. I do recall that when we were working on the effort to have Red Hat join the CentOS Project, we talked about the relative advantages and disadvantages of having separate bug systems. As with all other such things, we then left further discussions and potential changes up to an eventual community conversation. I'm asking these questions as a person experienced in dealing with bugzilla.redhat.com from the Fedora Project context (running the Docs Project) of focusing on making the project more awesome. In that context, we didn't care about the perspective of an @redhat.com package maintainer or developer because none of what we worked on was pulled in to RHEL. Some of that applies to the CentOS Project, some doesn't. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr =vDOS -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Tue Apr 7 23:04:55 2015 From: peter at pajamian.dhs.org (Peter) Date: Wed, 08 Apr 2015 11:04:55 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: <55246297.7090307@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > bugzilla instance itself under a CentOS product, just like how we > have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal > with bugs related to all 3 distros. I can certainly see the upside to such a move. A lot of CentOS bugs are actually bugs that need to be re-filed upstream with RedHat. If we were to use bugzilla then it should be possible to simply change the project from CentOS to RHEL in the bug itself rather than requiring that it be re-filed n bugzilla, saving a lot of time and grief and the ever present, "you've filed this bug in the wrong place, go file it in bugzilla for RHEL". The main downside I can see, and one I would like to make sure doesn't happen before any such move is made is that the RedHat Bugzilla is known to close off a lot of bugs which would better serve the community if they were left public. It seems like when I see a bugzilla number mentioned in a RedHat changelog it is usually the case that I cannot view the bug entry in bugzilla. I would want to make certain that CentOS bugs, as well as bugs that initially filed for CentOS and then changed to RHEL, would remain publicly viewable except in the most extreme security cases, and even then they should be private for only as long as it takes to release a fix. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= =X0vq -----END PGP SIGNATURE----- From lsm5 at fedoraproject.org Wed Apr 8 16:41:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:41:58 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408164154.GA23494@naruto> Responses inlined. Don't have answers to all questions though, guess others can chime in on those. On Tue, Apr 07, 2015 at 03:49:32PM -0700, Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) > > What is the process like to get changes made to Bugzilla to support > project needs? > > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) Not sure we can do this yet, but this might be something which could get addressed if everyone can come to agree on Colin's post to this list (titled "CentOS.devel"), which basically says all SIGs combine packages into a 'centos-devel' repo, probably involving SIGs working together towards a single version per package per major version of CentOS. > > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) > > What are the benefits to bug testers? I know the benefit to people who > maintain packages in Fedora who are also upstream maintainer at Red > Hat, but most of the bug testers/QA folk for CentOS mainly work on > just CentOS and not Fedora nor RHEL. It probably won't make any difference to CentOS testers. In fact, they could better engage RHEL/fedora folks on CentOS bugs if it's a cross-distro issue. Excluding the SIGs, I'd guess most CentOS bugs would actually be RHEL bugs, so this would be beneficial to CentOS testers too. (Quite possibly I lack a CentOS tester's POV, so correct me if I'm wrong) > > Are the terms of service for bugzilla.redhat.com different enough that > people who are comfortable getting an account on a > non-commercially-supported bug tracker are less comfortable or maybe > not even able to get an account on a redhat.com domain? > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > While I can see how it would help the subset of contributors who deal > with bugs, how does it help the end-user experience? > > My reckoning is that most CentOS users are not also users of Fedora. > Some may be users of RHEL, but if they are, they can file bugs under > their customer account and get better attention than filing under a > CentOS product. While we can never know the crossover, can we presume > that anyone filing a bug on centos.org is likely choosing the only > method that makes sense? > > So this change would benefit primarily people who deal with bugs in > all three distros, but how many of the users (who now user > bugs.centos.org happily enough) would be inconvenienced for the small > set of users who also file bugs in all three distros? RE: 3 paragraphs above consider this bug: http://bugs.centos.org/view.php?id=8406 filed by a CentOS user on a package gotten from RHEL. Now, all the action related to this bug will actually happen on https://bugzilla.redhat.com/show_bug.cgi?id=1209439 (a duplicate of the CentOS bug) while the CentOS user is pretty much left wondering what's up with his bug. Now, if this user filed a bug on RH's bugzilla itself under a CentOS product and 'docker' component, it would be much easier for me and other people working on this to jump on this bug and track progress, and that would keep the user notified too. In case of duplicate bugs filed under CentOS and RHEL on RH bugzilla, we could effectively track and eliminate duplicates. But, someone has to actively do back and forth between the bugs on RH and CentOS just to keep the user notified. Or tell the user that his CentOS bug is being worked on on the RH bugzilla. Now, I don't see a typical user caring much about whether he/she files a bug on bugzilla.rh.c or bugs.c.o as long as someone responds to them regularly. Having the bug filed on bugzilla.rh.c would actually be beneficial to both the CentOS end user and the people working on it. And my guess is this would apply to most bugs that are fixed in RHEL first. Again, correct me if I'm wrong. > > > Considering docker as an example, when people complain about docker > > bugs they notice on CentOS7, I'm not sure whether to ask them to > > file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually > > something from RHEL. My guess is their first choice is to file bugs > > on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' > > variants and these are not pulled from RHEL. For bugs related to > > these, I'll need to ask users to file bugs on bugs.c.o and if this > > affects fedora/rhel as well, there would be separate bugs on RH's > > bugzilla about this. > > > > I feel it'd be much more convenient for me (and possibly others) to > > keep track of bugs and reference them if they're all hosted in a > > single place. > > > > Comments? > > > > > > * This issue has been apparently raised in the past as per > > conversations with Evolution on #centos-devel but it's kinda hard > > to find out recorded history about it. If anyone could send logs > > about why this was rejected or whatever, it'd be great. > > I don't recall any public discussions on this topic. I do recall that > when we were working on the effort to have Red Hat join the CentOS > Project, we talked about the relative advantages and disadvantages of > having separate bug systems. As with all other such things, we then > left further discussions and potential changes up to an eventual > community conversation. > > I'm asking these questions as a person experienced in dealing with > bugzilla.redhat.com from the Fedora Project context (running the Docs > Project) of focusing on making the project more awesome. In that > context, we didn't care about the perspective of an @redhat.com > package maintainer or developer because none of what we worked on was > pulled in to RHEL. Some of that applies to the CentOS Project, some > doesn't. > > Regards, > - - Karsten > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUkXvwACgkQ2ZIOBq0ODEG/uQCeOf2nrsVHw2aqRSSvY+v3xUqL > e/0AnjovBgWnuzX7ZGj5SOriVcdjVwLr > =vDOS > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lsm5 at fedoraproject.org Wed Apr 8 16:59:51 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 8 Apr 2015 11:59:51 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55246297.7090307@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> Message-ID: <20150408165947.GB23494@naruto> On Wed, Apr 08, 2015 at 11:04:55AM +1200, Peter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/2015 09:35 AM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > > > My guess is this should make life easier for people who file/deal > > with bugs related to all 3 distros. > > I can certainly see the upside to such a move. A lot of CentOS bugs > are actually bugs that need to be re-filed upstream with RedHat. If > we were to use bugzilla then it should be possible to simply change > the project from CentOS to RHEL in the bug itself rather than > requiring that it be re-filed n bugzilla, saving a lot of time and > grief and the ever present, "you've filed this bug in the wrong place, > go file it in bugzilla for RHEL". > > The main downside I can see, and one I would like to make sure doesn't > happen before any such move is made is that the RedHat Bugzilla is > known to close off a lot of bugs which would better serve the > community if they were left public. It seems like when I see a > bugzilla number mentioned in a RedHat changelog it is usually the case > that I cannot view the bug entry in bugzilla. I would want to make > certain that CentOS bugs, as well as bugs that initially filed for > CentOS and then changed to RHEL, would remain publicly viewable except > in the most extreme security cases, and even then they should be > private for only as long as it takes to release a fix. Could you provide some sample bug ids that were closed off to the public? I can forward this concern to the powers that be. > > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVJGKXAAoJEAUijw0EjkDvUJQH/2HfSemq1wBKeO3jC3+BxIkk > nhYiEKFfMKIpQ1YITC5gZ7QQhOQ38Wr4tH+zfLzodb7MaLB5WHZ+WDMZfifJalxF > QFzHzylaylyRtDNk0pHB2Dl/0KCaa7qiwfkIVAK5+fvdNvUd+JSmlqP0cRHMDxXK > zR0q74rkzUC+cesXgetQFI+/60oqh6FtY8gzV4KHJR5e5oe1ZjwEHyOQxKLh8ii/ > 12FLZ7aVJo68lwbXzJrbpft+JhCXbh/dOTmObkYXLOVekK9PIZx4Aq0izL4v19CO > a45789niCZ24zFFI5OyluAKVmJzeu/qTzckThAt7zawPi1r2dmyv/MRMrBDrdVg= > =X0vq > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kevin at scrye.com Wed Apr 8 17:05:45 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 11:05:45 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <55245EFC.8000806@redhat.com> References: <20150407213536.GA15980@naruto> <55245EFC.8000806@redhat.com> Message-ID: <20150408110545.061d5162@voldemort.scrye.com> On Tue, 07 Apr 2015 15:49:32 -0700 Karsten Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/2015 02:35 PM, Lokesh Mandvekar wrote: > > Given that we now have a lot of co-operation amongst > > CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's > > bugzilla instance itself under a CentOS product, just like how we > > have Fedora and RHEL products. > > A few questions that come to mind ... > > What is the SLA that Fedora has around bugzilla.redhat.com? (One clear > advantage of running our own bug tracker is full autonomy.) There's no formal SLA that I know of (I'd love to be wrong!). That said, bugzilla has proved pretty stable over the years. Sometimes it's slow, there have been a few outages, but overall it's pretty reliable. > What is the process like to get changes made to Bugzilla to support > project needs? Depends. On the Fedora side we have a account that has permissions to do a number of things with the "Fedora" product. So, we can just manage all that ourselves without bothering anyone else. I would expect/hope CentOS would get something setup similarly. > Are we able to have all the granularity we need as just a sub-product > in Bugzilla? (E.g. for SIGs where we might have multiple versions of a > package for the same major version of CentOS.) I guess that would need some kind of tree setup: CentOS product SIG 1 package foo SIG 2 package foo > Can CentOS QA or security track issues privately as part of a group in > the product? (By this I include being able to block all other users > including @redhat.com accounts.) The bugzilla folks have been open to creating new groups and such in the past. For example abrt sometimes marks bugs private when it thinks they have a high security impact. In fedora this marks them now in a group that the fedora maintainer can read/unmark, etc. ...snip... I'm not in a good position to answer the rest of the excellent questions here. Hopefully those that use the current centos bug tracker/qa folks, etc will chime in with thoughts on these. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Wed Apr 8 18:31:02 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:31:02 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150407152730.GA9831@naruto> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: > On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > > For a long time, Red Hat engineers have dropped public RPMs onto > people.redhat.com. Now that CentOS is a more official part of the > family, it seems like an obvious idea to me, but why not create a > "centos7-devel" branch that is public work that is intended to go into the > next upstream update? > > > > Several of the existing repos like virt7-testing and atomic7-testing > could simply be folded into this repo. > > +1, given that packages like docker could be relevant to atomic and virt. > > > > > As well as these "hand built" RPMs: > > http://people.redhat.com/lnykryn/systemd/ > > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > > > > And I'm sure others. > > I'd love to see epel get combined with this as well, but I'm probably > speaking with a docker-tunneled vision. > > I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..) That said, I had an idea called EPIC which might be a better place for these items. > > > > (I wouldn't be surprised if this has come up before but I couldn't > figure out any keywords that would find previous conversation on this topic > from the archives) > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 18:47:24 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 13:47:24 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) > > That said, I had an idea called EPIC which might be a better place for these > items. I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Apr 8 18:59:46 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 12:59:46 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 12:47, Les Mikesell wrote: > On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > > > That said, I had an idea called EPIC which might be a better place for > these > > items. > > I think you are missing the point of conservatism, which is about not > And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Wed Apr 8 19:07:28 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 14:07:28 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen wrote: > >> >> I think you are missing the point of conservatism, which is about not > > > And I think you are jumping to conclusions about my point. So we are both at > a loss to how to communicate. Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere... -- Les Mikesell lesmikesell at gmail.com From brian at bstinson.com Wed Apr 8 20:23:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 8 Apr 2015 15:23:26 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) Message-ID: <20150408202326.GV3399@byrd.math.ksu.edu> Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/ From peter at pajamian.dhs.org Wed Apr 8 22:47:58 2015 From: peter at pajamian.dhs.org (Peter) Date: Thu, 09 Apr 2015 10:47:58 +1200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150408165947.GB23494@naruto> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> Message-ID: <5525B01E.9060004@pajamian.dhs.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >> Could you provide some sample bug ids that were closed off to the >> public? I can forward this concern to the powers that be. This is easy to do. I just run rpm -q --changelog httpd on an EL5 box and the very first BZ# listed in that is closed to public: - - mod_ldap: copy the global mutex from the base server to vhosts (#1101385) The second, fortunately, is open. (#1058426), (#976465), (#1047319), (#1078177), (#1003073), (#991367) and (#970994) all closed, that's eight out of the first ten unique bz numbers listed in the httpd changelog. I could go on, and check other packages and other versions of CentOS as well, but the results will largely be the same. This has been a well known issue for some time and I don't see RedHat changing this extremely annoying habit anytime soon. I would want to make certain that this doesn't happen to CentOS (or even CentOS-originating) bugzilla entries were we to switch to using the RedHat bugzilla system, this to me is of great concern as it plays directly to the transparency of the project as a whole. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJbAdAAoJEAUijw0EjkDv/KUIAJt5MNrabX/xOUxh72nWUgMI zOZnfOw6Rgxtb63eaxwHUUAIjjNApRXLwfRcDaMqTztHEBvqyBpqujLJ79lPsXtr D2FENqBs3slf7XXT2W1Im3QppEu9q9dHiZOH7zCuE9QuP95eH91mkE//DcggKS9B 1fv8iNnaxy1d/+hOiOqqudVK/4nN4sGAEcj/FpW1SizCAYx0LzrdYgNl8dP3PBKc SKp+BzWWegB6VRw+XfemvGQ/QHxISW7ums+BZiF4uyncoXwhTs2Dhmgk6MYpbt22 E4lfYjlh4Y70LIJRo4x54VIyXYk5woerwHE6wMtkAnmWz8voOR9Rymd7x211/50= =st7E -----END PGP SIGNATURE----- From smooge at gmail.com Wed Apr 8 23:44:07 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Apr 2015 17:44:07 -0600 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <20150407213536.GA15980@naruto> References: <20150407213536.GA15980@naruto> Message-ID: On 7 April 2015 at 15:35, Lokesh Mandvekar wrote: > Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I > was hoping we could host CentOS bugs on RH's bugzilla instance itself > under a > CentOS product, just like how we have Fedora and RHEL products. > > My guess is this should make life easier for people who file/deal with > bugs related > to all 3 distros. > > Considering docker as an example, when people complain about docker bugs > they > notice on CentOS7, I'm not sure whether to ask them to file bugs on > bugs.c.o or bugzilla.rh.c, as that bug is actually something from > RHEL. My guess is their first choice is to file bugs on bugs.c.o. > There's also the virt SIG 'docker' and 'docker-master' variants and > these are not pulled from RHEL. For bugs related to these, I'll need to ask > users to file bugs on bugs.c.o and if this affects fedora/rhel as well, > there > would be separate bugs on RH's bugzilla about this. > > I feel it'd be much more convenient for me > (and possibly others) to keep track of bugs and reference them if > they're all hosted in a single place. > > So we have some Fedora people and we have some CentOS people, but we don't have any of the people from Red Hat bugzilla team here to answer if this is possible. One thing that I have gotten from talking with them in the past is how much load Fedora puts on the bugzilla already (with about 1/2 -> 2/3 of the traffic and bugs) There have been discussions on whether it would be better to have a seperate bugzilla for Fedora because many of the slow times/outages in bugzilla are because Fedora is branching or some widely used application is causing abrt reports like a rocket. I do not know if they would want to add yet another operating system to that mix. [And no it isn't a simple replication of the RHEL items in the database.. it requires a couple of sacrifices of black roosters and a quart of unicorns spit. ] > Comments? > > > * This issue has been apparently raised in the past as per conversations > with > Evolution on #centos-devel but it's kinda hard to find out recorded history > about it. If anyone could send logs about why this was rejected or > whatever, it'd be great. > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkadel at gmail.com Thu Apr 9 00:20:04 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Apr 2015 20:20:04 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen wrote: > > > On 7 April 2015 at 09:27, Lokesh Mandvekar wrote: >> >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: >> > For a long time, Red Hat engineers have dropped public RPMs onto >> > people.redhat.com. Now that CentOS is a more official part of the family, >> > it seems like an obvious idea to me, but why not create a "centos7-devel" >> > branch that is public work that is intended to go into the next upstream >> > update? >> > >> > Several of the existing repos like virt7-testing and atomic7-testing >> > could simply be folded into this repo. >> >> +1, given that packages like docker could be relevant to atomic and virt. >> >> > >> > As well as these "hand built" RPMs: >> > http://people.redhat.com/lnykryn/systemd/ >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ >> > >> > And I'm sure others. >> >> I'd love to see epel get combined with this as well, but I'm probably >> speaking with a docker-tunneled vision. >> > > I don't think EPEL could fit in here because the audience for EPEL is a lot > more conservative in what they want than what people working on anything > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of > pushback from users when things get updated (this is the reason openstack > and various other tools have had to been pulled from EPEL in the past..) That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6. > That said, I had an idea called EPIC which might be a better place for these > items. > > >> >> > >> > (I wouldn't be surprised if this has come up before but I couldn't >> > figure out any keywords that would find previous conversation on this topic >> > from the archives) >> > >> > _______________________________________________ >> > CentOS-devel mailing list >> > CentOS-devel at centos.org >> > http://lists.centos.org/mailman/listinfo/centos-devel >> >> -- >> Lokesh >> Freenode, OFTC: lsm5 >> GPG: 0xC7C3A0DD >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From lesmikesell at gmail.com Thu Apr 9 01:46:31 2015 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 8 Apr 2015 20:46:31 -0500 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia wrote: >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot of >> pushback from users when things get updated (this is the reason openstack >> and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either. -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Thu Apr 9 01:53:59 2015 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 8 Apr 2015 19:53:59 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <20150408195359.73c19957@voldemort.scrye.com> On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell wrote: > On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia > wrote: > >> Projects which are aimed at the EL-7 -> EL-8 space will get a lot > >> of pushback from users when things get updated (this is the reason > >> openstack and various other tools have had to been pulled from > >> EPEL in the past..) > > > > That's partly because there are a *lot* of components in EPEL 6 than > > are present in EPEL 7. I ran headlong into this trying to build up > > RT version 4, the perl dependencies include something like 20 perl > > module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them > > are available in EPEL 6. > > Do you know if there is some showstopper reason for this or is is just > that it takes a long time to get done? I just noticed the other day > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Apr 9 02:00:38 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Apr 2015 22:00:38 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <20150408195359.73c19957@voldemort.scrye.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <20150408195359.73c19957@voldemort.scrye.com> Message-ID: <20150409020038.GA13446@mattdm.org> On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote: > > Do you know if there is some showstopper reason for this or is is just > > that it takes a long time to get done? I just noticed the other day > > that backuppc isn't there either. > http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-epel-7/ tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out. -- Matthew Miller Fedora Project Leader From carl.george at RACKSPACE.COM Thu Apr 9 13:34:35 2015 From: carl.george at RACKSPACE.COM (Carl George) Date: Thu, 9 Apr 2015 13:34:35 +0000 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, Message-ID: <1428586450704.43948@RACKSPACE.COM> I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again. https://gist.github.com/cgtx/b854281462a18007f509 If no one has further suggestions for edits, what is the next step to make it official? Carl George Rackspace RPM Development ________________________________________ From: centos-devel-bounces at centos.org on behalf of Nico Kadel-Garcia Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wrote: > On 03/30/2015 10:29 PM, Peter wrote: >> >> On 03/31/2015 07:37 AM, Carl George wrote: >>> >>> How does this phrasing work for yall? >>> >>> * If the repository has the potential to replace stock packages when >>> `yum update` is run, it must be disabled by default. >>> * If the repository is disabled by default, comments must be included >>> in the repo file to explain why. >> >> That works for me :-) >> >> > +1 from me This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel at centos.org http://lists.centos.org/mailman/listinfo/centos-devel From smooge at gmail.com Thu Apr 9 16:51:21 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 10:51:21 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: On 8 April 2015 at 18:20, Nico Kadel-Garcia wrote: > On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen > wrote: > > > > > > On 7 April 2015 at 09:27, Lokesh Mandvekar > wrote: > >> > >> On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote: > >> > For a long time, Red Hat engineers have dropped public RPMs onto > >> > people.redhat.com. Now that CentOS is a more official part of the > family, > >> > it seems like an obvious idea to me, but why not create a > "centos7-devel" > >> > branch that is public work that is intended to go into the next > upstream > >> > update? > >> > > >> > Several of the existing repos like virt7-testing and atomic7-testing > >> > could simply be folded into this repo. > >> > >> +1, given that packages like docker could be relevant to atomic and > virt. > >> > >> > > >> > As well as these "hand built" RPMs: > >> > http://people.redhat.com/lnykryn/systemd/ > >> > http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/ > >> > > >> > And I'm sure others. > >> > >> I'd love to see epel get combined with this as well, but I'm probably > >> speaking with a docker-tunneled vision. > >> > > > > I don't think EPEL could fit in here because the audience for EPEL is a > lot > > more conservative in what they want than what people working on anything > > from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% > are > > EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot > of > > pushback from users when things get updated (this is the reason openstack > > and various other tools have had to been pulled from EPEL in the past..) > > That's partly because there are a *lot* of components in EPEL 6 than > are present in EPEL 7. I ran headlong into this trying to build up RT > version 4, the perl dependencies include something like 20 perl module > SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are > available in EPEL 6. > > I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins. Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kdreyer at redhat.com Thu Apr 9 17:01:35 2015 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 09 Apr 2015 11:01:35 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <5526B06F.3050605@redhat.com> On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > We get way more pushback > from developers finding out that their package is in an EL without their > knowledge than we do from either consumers of EPEL not finding a > particular one. Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels? - Ken From smooge at gmail.com Thu Apr 9 17:21:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 9 Apr 2015 11:21:47 -0600 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526B06F.3050605@redhat.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: On 9 April 2015 at 11:01, Ken Dreyer wrote: > On 04/09/2015 10:51 AM, Stephen John Smoogen wrote: > > We get way more pushback > > from developers finding out that their package is in an EL without their > > knowledge than we do from either consumers of EPEL not finding a > > particular one. > > Bit of a tangent... but would you mind clarifying who "we" is there? If > there is pushback to EPEL packagers, I'm not seeing it on the epel-devel > list, or in the bugs I'm watching, so it must be happening through other > channels? > > My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7]. The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X) > - Ken > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenkieske at gmail.com Thu Apr 9 20:54:56 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 22:54:56 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526E720.1010206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 15:34, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that > not all 3rd party repos necessarily work with each other. Here is > the link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step > to make it official? Well, you write: "These repositories are still not associated with or supported by the CentOS project." I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation). but maybe that's just me nitpicking. just my 2 cents kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJucgAAoJEAq0kGAWDrqlt1AMAMMnty6Osq5ZmTHMZIGitbvy fNKYQnHMsivdH6QxXaIdSM50H/RnWkFXh1+eOAKud7PqtpvqozblqlTROTIIN5vQ lvywIfXIE6suui/SsO12VJYNknQpwQKM/UsuTYYGJW3E3/d6vZrrzSucfudLaBRT yx4d7BWUMDM9sNOvRNzSmu7ja5cR8t7mKXCIxmd9XEn1Q/1nJcPTBThownT6GJb3 V+Y69AjBxyuu8W8/OmUybc7YNAbr542gDTeecD50nepLBaQhcjddv9JhkZJhYrcI VAtAlL4Yxo70N1nTZcahKXbWYdZbCjhEioj2UIIIdop6KQX28siOVo0ovBbSTsAh bxIJ4AT6Bw6zt5WR3UPcSffVv1AiNnq1xRQi+DNoRBn5viMNm5a7bn0AXQwrlyZL jdQcWTbkYu1yhPKRq0oSQV1HN4zkq6cTqtPizUrzP0JDaNDHNhdXnpq/ZQuXEYIj gr4Al8oRLz9gpJtVbk6Ykc+IUHCVZvI3oFkKjVYUCA== =K/G6 -----END PGP SIGNATURE----- From svenkieske at gmail.com Thu Apr 9 21:02:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Thu, 09 Apr 2015 23:02:06 +0200 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> Message-ID: <5526E8CE.4030402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09.04.2015 19:21, Stephen John Smoogen wrote: > The problem usually are reported in direct emails or IRC. We also > see the opposite emails where the developers are wondering why > their package wasn't put in EL-6 or EL-7 when they had it in > EL-5... but the release group decided it was better to surprise on > the side of caution (eg no branch into EL-X) I don't get why either side (user or developer/maintainer) needs to get "surprised"? Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)? you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years). this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so. And of course someone would have to work out this stuff. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVJujOAAoJEAq0kGAWDrqleDoL/ikQf3oCjiMzghPrOBMx2TFt 6X02/f7e+nMIwSzitk2XSrikNuUYFsJel5ArSGfa5iwb2IjK2rxa+2WgSLTq0g/U GfBi839IffCD02MlmHMVg4Cu5bXuCCKYnkkIgt5PqcGABuANFZYvEdJCwFV+zY4D o4ZZe8dGbfGEHwsALGm/aSEtKThQOTz75NiLT3tReMggvBlEUbQTjWAsRJUbKCTN ZjTcZiGTHrkW1WIVfaTUlHNS7kcEJaFHSMuHEFN5s/BMA7W05h1r+gfOcOjZSYcg aDwwF54O5cZa7qMrFgFx/e5NQ7Ea5WaBc5v3liZge4HofY8oy63ZvznRudlZTdiM gIrK5Rcen9rV79Ykk5IdTUpHOCw54frhL43MR/bYJLlKj1d4es4EVepyN9nRjPot 9GFkGe8dfTZ/wdviXsX3Ia/yUVjuZ6303mAUNkeHTB/+/6HSPpJZL/655TMxiTmr vN98hKDw19TzPuaa1rcxoLb0iWrd+OLyGswTsuPpkA== =/eXz -----END PGP SIGNATURE----- From peter at pajamian.dhs.org Thu Apr 9 21:10:51 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 09:10:51 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <1428586450704.43948@RACKSPACE.COM> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro>, <1428586450704.43948@RACKSPACE.COM> Message-ID: <5526EADB.8010600@pajamian.dhs.org> On 04/10/2015 01:34 AM, Carl George wrote: > I have worked on this a bit more, fixed a few typos, and clarified > some parts. In particular, I added a sentence pointing out that not > all 3rd party repos necessarily work with each other. Here is the > link again. > > https://gist.github.com/cgtx/b854281462a18007f509 > > If no one has further suggestions for edits, what is the next step to > make it official? Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras. Peter From wolfy at nobugconsulting.ro Thu Apr 9 21:54:06 2015 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 10 Apr 2015 00:54:06 +0300 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <5526E8CE.4030402@gmail.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <5526B06F.3050605@redhat.com> <5526E8CE.4030402@gmail.com> Message-ID: <5526F4FE.2000305@nobugconsulting.ro> On 04/10/2015 12:02 AM, Sven Kieske wrote: > Couldn't a simple mechanism exists which asks every package maintainer > before a new epel release gets created if his package should be included > there (a mail with a link to website with a yes/no button would > suffice, or something similar)? By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first. From nkadel at gmail.com Fri Apr 10 00:17:41 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 20:17:41 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5526EADB.8010600@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 5:10 PM, Peter wrote: > On 04/10/2015 01:34 AM, Carl George wrote: >> I have worked on this a bit more, fixed a few typos, and clarified >> some parts. In particular, I added a sentence pointing out that not >> all 3rd party repos necessarily work with each other. Here is the >> link again. >> >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If no one has further suggestions for edits, what is the next step to >> make it official? > > Looks good to me. At this stage I think the only thing to add would be > the actual instructions on how to get your -release file added to extras. It needs another rule, I thinkk: * Stable packes do not *obsolete* packages from the standard repositories. RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. . From peter at pajamian.dhs.org Fri Apr 10 02:35:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 10 Apr 2015 14:35:56 +1200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> Message-ID: <5527370C.2020208@pajamian.dhs.org> On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: > It needs another rule, I thinkk: > > * Stable packes do not *obsolete* packages from the standard repositories. I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone. My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it. Peter From nkadel at gmail.com Fri Apr 10 02:47:26 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 9 Apr 2015 22:47:26 -0400 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: <5527370C.2020208@pajamian.dhs.org> References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: On Thu, Apr 9, 2015 at 10:35 PM, Peter wrote: > On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote: >> It needs another rule, I thinkk: >> >> * Stable packes do not *obsolete* packages from the standard repositories. > > I don't personally have an issue with excluding packages that obsolete > core packages, but I can't speak for everyone. I meant "by default". Thank you for clarifying that. > My main issue (that is now addressed) was to allow packages that replace > core packages so long as the repo is disabled by default. The current > language allows that and I'm happy with it. > > > Peter > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From lmohanty at redhat.com Fri Apr 10 06:48:44 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 12:18:44 +0530 Subject: [CentOS-devel] etcd fails to start in latest CentOS Atomic images Message-ID: <5527724C.3070004@redhat.com> I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode From marianne at tuxette.fr Fri Apr 10 13:35:57 2015 From: marianne at tuxette.fr (Marianne Lombard) Date: Fri, 10 Apr 2015 15:35:57 +0200 Subject: [CentOS-devel] including 3rd party repo release RPMs in Extras In-Reply-To: References: <5517742C.6030204@pajamian.dhs.org> <1427740632832.47968@RACKSPACE.COM> <5519A431.9020001@pajamian.dhs.org> <5519A79B.6040802@nobugconsulting.ro> <1428586450704.43948@RACKSPACE.COM> <5526EADB.8010600@pajamian.dhs.org> <5527370C.2020208@pajamian.dhs.org> Message-ID: <5527D1BD.5050509@tuxette.fr> As long as issue as the one describe by Remi will exist, it will be a bad idea. IU is not safe for me Regards -- Marianne (Jehane) Lombard Geekfeminist and sysadmin From lmohanty at redhat.com Fri Apr 10 14:37:04 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 10 Apr 2015 20:07:04 +0530 Subject: [CentOS-devel] No Storage SIG meeting today Message-ID: <5527E010.6080409@redhat.com> Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode From kwade at redhat.com Sun Apr 12 18:32:59 2015 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Apr 2015 11:32:59 -0700 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <5525B01E.9060004@pajamian.dhs.org> References: <20150407213536.GA15980@naruto> <55246297.7090307@pajamian.dhs.org> <20150408165947.GB23494@naruto> <5525B01E.9060004@pajamian.dhs.org> Message-ID: <552ABA5B.2080605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2015 03:47 PM, Peter wrote: > On 04/09/2015 04:59 AM, Lokesh Mandvekar wrote: >>> Could you provide some sample bug ids that were closed off to >>> the public? I can forward this concern to the powers that be. > > This is easy to do. I just run rpm -q --changelog httpd on an EL5 > box and the very first BZ# listed in that is closed to public: - > mod_ldap: copy the global mutex from the base server to vhosts > (#1101385) > > The second, fortunately, is open. > > (#1058426), (#976465), (#1047319), (#1078177), (#1003073), > (#991367) and (#970994) all closed, that's eight out of the first > ten unique bz numbers listed in the httpd changelog. > > I could go on, and check other packages and other versions of > CentOS as well, but the results will largely be the same. > > This has been a well known issue for some time and I don't see > RedHat changing this extremely annoying habit anytime soon. I > would want to make certain that this doesn't happen to CentOS (or > even CentOS-originating) bugzilla entries were we to switch to > using the RedHat bugzilla system, this to me is of great concern as > it plays directly to the transparency of the project as a whole. This has been an issue in the Fedora Project, too. One of the advantages of the two bug systems is that RH engineers/product people can keep a bug private without cutting off the community transparency. In fact, the CentOS side could be a good place to paste in public details from a private bug report. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUqulsACgkQ2ZIOBq0ODEEkcgCgsAOO5Bdu8yugjsQGzHwyuiCj QWEAoJCB45neHoqFHO5FukNrqJrOaM6W =fbOu -----END PGP SIGNATURE----- From smooge at gmail.com Sun Apr 12 22:36:09 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Apr 2015 16:36:09 -0600 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: On 13 March 2015 at 13:25, Toni Spets wrote: > Hello list, > > I've been in contact with Anders F Bj?rklund (afb) earlier this week > regarding the state of Xfce on CentOS 7 and in general in any supported > EPEL release. > > What we discussed was what he has done in the past for his personal use > and what are the things we would both agree on that should get some > attention to make the experience better. > > Here are some initial things that we think are critical (give or take, > Anders has his own list): > > 1. Packaging issues > - comp group @xfce-desktop doesn't depend on @X Window System so it > doesn't really work and has some wrong packages and some missing > - @xfce-desktop depends on gdm instead of lightdm, we think it should do > that instead > - dejavu sans fonts are not a dependency and fonts are broken because of > that > - gtk-xfce-engine package is missing (EPEL7) > > 2. Branding issues > - "Default" appearance theme is missing (requires gtk-xfce-engine, > request sent to EPEL) > - default background is blank (broken Fedora branding, patch submitted) > - default icon set is wrong and broken (should be GNOME because "Fedora" > doesn't exist on RHEL, patch submitted) > > > Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 13 03:32:16 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 12 Apr 2015 22:32:16 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 13-Apr-2015 14:00 UTC Message-ID: <20150413033215.GY3399@byrd.math.ksu.edu> Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From earlaramirez at gmail.com Mon Apr 13 11:24:27 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 07:24:27 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Dear CentOS Development Team, I am interested in starting a new SIG or merging with the ?Hardening? SIG, I didn?t find sufficient information about the hardening SIG. I have been on the mailing list for some years and I have noticed a number of concerns with regards to security, e.g. the default sshd_config, gnome user list and more. My goal is to use the base and modify the OS with these changes and make it available for the CentOS community, I will mention this on the mailing list to get the community feedback so that they can have an opportunity to contribute, and more importantly get an OS that meets their needs, with regards to their security concerns. I?m not too familiar with the CentOS build system, however I started to read up on it and practice to get a feel on things. Some of the things that I will like to change are as follow: SSH: disable root (uncomment 'PermitRootLogin' and change to no) enable 'strictMode' modify 'MaxAuthTries' modify 'ClientAliveInterval' modify 'ClientAliveCountMax' Gnome: disable Gnome user list Console: Remove reboot, halt poweroff from /etc/security/console.app Looking forward for your response on how can I proceed with this? -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Apr 13 11:55:15 2015 From: leamhall at gmail.com (Leam Hall) Date: Mon, 13 Apr 2015 07:55:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <552BAEA3.9070701@gmail.com> On 04/13/15 07:24, Earl A Ramirez wrote: > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the ?Hardening? > SIG, I didn?t find sufficient information about the hardening SIG. I > have been on the mailing list for some years and I have noticed a number > of concerns with regards to security, e.g. the default sshd_config, > gnome user list and more. > -- > Kind Regards > Earl Ramirez Earl, I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. Leam From earlaramirez at gmail.com Mon Apr 13 12:45:49 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 08:45:49 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <552BAEA3.9070701@gmail.com> References: <552BAEA3.9070701@gmail.com> Message-ID: On 13 April 2015 at 07:55, Leam Hall wrote: > On 04/13/15 07:24, Earl A Ramirez wrote: > >> Dear CentOS Development Team, >> >> I am interested in starting a new SIG or merging with the ?Hardening? >> SIG, I didn?t find sufficient information about the hardening SIG. I >> have been on the mailing list for some years and I have noticed a number >> of concerns with regards to security, e.g. the default sshd_config, >> gnome user list and more. >> -- >> Kind Regards >> Earl Ramirez >> > > Earl, > > I'm in the same boat but different oar. I think we have a few folks > interested in SIG Hardening. > > Informal poll; who all is interested in SIG-Hardening? Speak up with your > interests; let's see if there's enough to get more organized. > > Leam > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > Leam, Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Mon Apr 13 13:16:20 2015 From: corman at cormander.com (Corey Henderson) Date: Mon, 13 Apr 2015 07:16:20 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <552BAEA3.9070701@gmail.com> Message-ID: <92C20F37-9A50-4E3B-9AA8-8047C957EF8E@cormander.com> > On Apr 13, 2015, at 6:45 AM, Earl A Ramirez wrote: > > > >> On 13 April 2015 at 07:55, Leam Hall wrote: >>> On 04/13/15 07:24, Earl A Ramirez wrote: >>> Dear CentOS Development Team, >>> >>> I am interested in starting a new SIG or merging with the ?Hardening? >>> SIG, I didn?t find sufficient information about the hardening SIG. I >>> have been on the mailing list for some years and I have noticed a number >>> of concerns with regards to security, e.g. the default sshd_config, >>> gnome user list and more. >>> -- >>> Kind Regards >>> Earl Ramirez >> >> Earl, >> >> I'm in the same boat but different oar. I think we have a few folks interested in SIG Hardening. >> >> Informal poll; who all is interested in SIG-Hardening? Speak up with your interests; let's see if there's enough to get more organized. >> >> Leam >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > > Leam, > > Happy that we are in the same boat; hopefully we get more folks involved and the approval of a board member so that we can make this happen. I will shoot an email over to the general mailing list to see if anyone are interested to get onboard. > > -- > Kind Regards > Earl Ramirez > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I'm happy to throw my hat in the ring to help out. I just can't be the one coordinating things. -- Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyeron at pdinc.us Mon Apr 13 13:33:15 2015 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 13 Apr 2015 09:33:15 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: > -----Original Message----- > From: Earl A Ramirez > Sent: Monday, April 13, 2015 7:24 > > Dear CentOS Development Team, > > I am interested in starting a new SIG or merging with the > 'Hardening' SIG, I didn't find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards to > security, e.g. the default sshd_config, gnome user list and more. I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. This sounds interesting. > > My goal is to use the base and modify the OS with these > changes and make it available for the CentOS community, I > will mention this on the mailing list to get the community > feedback so that they can have an opportunity to contribute, > and more importantly get an OS that meets their needs, with > regards to their security concerns. > > I'm not too familiar with the CentOS build system, however I > started to read up on it and practice to get a feel on > things. Some of the things that I will like to change are as follow: > > SSH: > disable root (uncomment 'PermitRootLogin' and change to no) > enable 'strictMode' > modify 'MaxAuthTries' > modify 'ClientAliveInterval' > modify 'ClientAliveCountMax' > > Gnome: > disable Gnome user list > > Console: > Remove reboot, halt poweroff from /etc/security/console.app > > > Looking forward for your response on how can I proceed with this? > > > > -- > > Kind Regards > Earl Ramirez > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. From leamhall at gmail.com Mon Apr 13 13:37:03 2015 From: leamhall at gmail.com (leam hall) Date: Mon, 13 Apr 2015 09:37:03 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > > I have been patching/rebuilding RHEL/Centos RPMs to comply with the STIGs. > This sounds interesting. > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the new project is pulling in those and Puppet content as well. https://github.com/LeamHall/SecComFrame Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlaramirez at gmail.com Mon Apr 13 14:10:14 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Mon, 13 Apr 2015 10:10:14 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: On 13 April 2015 at 09:37, leam hall wrote: > > On Mon, Apr 13, 2015 at 9:33 AM, Jason Pyeron wrote: > >> >> I have been patching/rebuilding RHEL/Centos RPMs to comply with the >> STIGs. This sounds interesting. >> > > Hey Jason! The stuff I'm working on is STIG compliance as well. I've done > a lot of RHEL 6 scripts, Vincent Passaro did a lot of RHEL 5 ones, and the > new project is pulling in those and Puppet content as well. > > https://github.com/LeamHall/SecComFrame > > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > This looks promising, do we need some sort of formal proposal to the CentOS board to get the ball rolling? Corey, We will be happy to have your hat in; I think one of us can coordinate things. -- Kind Regards Earl Ramirez -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:37:09 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:37:09 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx Message-ID: <20150413153709.GA32597@fcshome.stoneham.ma.us> Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- From fredex at fcshome.stoneham.ma.us Mon Apr 13 15:40:40 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Mon, 13 Apr 2015 11:40:40 -0400 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413153709.GA32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> Message-ID: <20150413154040.GB32597@fcshome.stoneham.ma.us> On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: > Hi all! > > Using Centos-7, I'm trying to build a C-language app using > -fsanitize=address, or -fsanitize=thread. > > If I compile (and link) with -fsanitize=address when it tries to link > it complains of missing libasan.so.x.x.x. Similarly compiling with > -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. > > I can't figure out where one is supposed to find those libraries. they > don't appear to be part of the GCC packages, and doing yum whatprovides > */libasan.so or yum whatprovides */libtsan.so turns up nothing. > > Clues appreciated, thanks in advance! > > Fred Oh woe is me. tired, aged, brain, etc. the moment I hit send I realized I needed to try: yum whatprovides */libasan.so\* instead of */libasan.so. So I did, and voila, it gives me the answer I needed. Sorry 'bout the noise on the list. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- From ajb at elrepo.org Mon Apr 13 16:30:50 2015 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 13 Apr 2015 17:30:50 +0100 Subject: [CentOS-devel] compiling on EL 7.x, using -fsanitize=xxx [SOLVED] In-Reply-To: <20150413154040.GB32597@fcshome.stoneham.ma.us> References: <20150413153709.GA32597@fcshome.stoneham.ma.us> <20150413154040.GB32597@fcshome.stoneham.ma.us> Message-ID: On 13 April 2015 at 16:40, Fred Smith wrote: > On Mon, Apr 13, 2015 at 11:37:09AM -0400, Fred Smith wrote: >> Hi all! >> >> Using Centos-7, I'm trying to build a C-language app using >> -fsanitize=address, or -fsanitize=thread. >> >> If I compile (and link) with -fsanitize=address when it tries to link >> it complains of missing libasan.so.x.x.x. Similarly compiling with >> -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. >> >> I can't figure out where one is supposed to find those libraries. they >> don't appear to be part of the GCC packages, and doing yum whatprovides >> */libasan.so or yum whatprovides */libtsan.so turns up nothing. >> >> Clues appreciated, thanks in advance! >> >> Fred > > Oh woe is me. tired, aged, brain, etc. > > the moment I hit send I realized I needed to try: > > yum whatprovides */libasan.so\* instead of */libasan.so. So I did, > and voila, it gives me the answer I needed. > > Sorry 'bout the noise on the list. > > -- > ---- Fred Smith -- Just a friendly comment, this is the wrong mailing-list for such queries. You really should have used the general mailing-list. Alan. From walters at verbum.org Mon Apr 13 22:00:39 2015 From: walters at verbum.org (Colin Walters) Date: Mon, 13 Apr 2015 18:00:39 -0400 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> Message-ID: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: > > I don't think EPEL could fit in here because the audience for EPEL is > a lot more conservative in what they want than what people working on > anything from this decade want. An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting. (Snip lots of other discussion about EPEL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Apr 14 08:58:06 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 09:58:06 +0100 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <20150408202326.GV3399@byrd.math.ksu.edu> References: <20150408202326.GV3399@byrd.math.ksu.edu> Message-ID: <552CD69E.1000104@karan.org> On 04/08/2015 09:23 PM, Brian Stinson wrote: > > Thoughts/Questions? > For properties that already have overlapping account space - eg. bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do you have any thoughts on howto unify the accounts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From kbsingh at centos.org Tue Apr 14 11:22:31 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 14 Apr 2015 12:22:31 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host Message-ID: <552CF877.9020005@centos.org> Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. Regards -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: CAH-Downstream.png Type: image/png Size: 105813 bytes Desc: not available URL: From johnny at centos.org Tue Apr 14 11:54:35 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 06:54:35 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) Message-ID: <552CFFFB.60208@centos.org> We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Tue Apr 14 12:48:35 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 14 Apr 2015 13:48:35 +0100 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat Message-ID: <552D0CA3.40407@karan.org> hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jeff at tag1consulting.com Tue Apr 14 14:04:45 2015 From: jeff at tag1consulting.com (Jeff Sheltren) Date: Tue, 14 Apr 2015 07:04:45 -0700 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: On Tue, Apr 14, 2015 at 5:48 AM, Karanbir Singh wrote: > > > Welcome aboard Brian! > > Congratulations, and thanks for all your hard work! -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Tue Apr 14 14:58:58 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 10:58:58 -0400 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <552CFFFB.60208@centos.org> References: <552CFFFB.60208@centos.org> Message-ID: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: > We are looking at the possibility of providing signed repomd.xml.asc > files for all CentOS controlled repos for CentOS-6 and CentOS-7. For anyone who hasn't seen it, the TL;DR from: http://theupdateframework.com/ is "GPG sign your repo metadata", so I'm glad we're doing this =) > For CentOS-7: > repo_gpgcheck=1 > baseurl=http://dev.centos.org/centos/7/updates/x86_64/ I tested this via "docker run --rm -ti centos bash", then editing the /etc/yum.repos.d file, and it worked. I saw in strace that yum was at least downloading and trying to verify the signature. > One thing we would like to figure out (and then tes)t is the ability to > somehow get this key to be added automatically via a kick start so that > one can use signed metadata for unattended installs. GPG signatures and RPM and Anaconda has always been pretty broken, sadly: https://bugzilla.redhat.com/show_bug.cgi?id=998 (That's only "fixed" by not using GPG, but relying on TLS, which is very much not the same thing. It gets closer if you use "pinned TLS" i.e. pre-specify a particular CA root instead of relying on ca-certificates) > Without testing and feedback, and possibly key auto import capability, > this proposal will likely go nowhere .. so if this is a feature that you > want, please test and provide feedback and help us find a solution for > auto import of the yum key. Even if Anaconda doesn't support it, it's still possible for downstream users to manually enable in the repo file post installation. Probably very few will, but at some point maybe Anaconda will learn GPG... From brian at bstinson.com Tue Apr 14 18:12:15 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 14 Apr 2015 13:12:15 -0500 Subject: [CentOS-devel] Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA) In-Reply-To: <552CD69E.1000104@karan.org> References: <20150408202326.GV3399@byrd.math.ksu.edu> <552CD69E.1000104@karan.org> Message-ID: <20150414181215.GB22550@ender.bstinson.int> On Apr 14 09:58, Karanbir Singh wrote: > On 04/08/2015 09:23 PM, Brian Stinson wrote: > > > > Thoughts/Questions? > > > > For properties that already have overlapping account space - eg. > bugs.centos.org and maybe cbs.centos.org or the forums / wiki etc, do > you have any thoughts on howto unify the accounts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel We have a couple of options in that space. FAS3[1] will speak LDAP and FedOAuth has a FAS authentication module if we want to look into OpenID. It appears that both Mantis and phpBB have LDAP support built in. Of course the same options (LDAP + OpenID) apply to FreeIPA, since FedOAuth also has an LDAP module. Brian [1] https://fedoraproject.org/wiki/User:Laxathom/Drafts:FAS3.0 -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From marcin.dulak at gmail.com Tue Apr 14 20:17:48 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Tue, 14 Apr 2015 22:17:48 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla Message-ID: <552D75EC.4070304@gmail.com> Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin From znmeb at znmeb.net Tue Apr 14 20:24:31 2015 From: znmeb at znmeb.net (M. Edward (Ed) Borasky) Date: Tue, 14 Apr 2015 13:24:31 -0700 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-) On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards > > -- > 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 > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. From jperrin at centos.org Tue Apr 14 20:51:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 15:51:26 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D7DCE.1080300@centos.org> On 04/14/2015 03:17 PM, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. How is it unprecedented? > For me it shows that the CentOS community has not enough resources to > deal with the reported issues. You're right. We could absolutely use more community members willing to step up and help triage/fix/duplicate the bugs. > From this point of view it would be better to have CentOS issues > integrated into RHEL's bugzilla, Unsure what you mean here. Putting our bugs in bugzilla would simply mean we move from not responding to them on bugs.centos to not responding to them in bugzilla. We don't get any additional resources simply by using bugzilla. > > 2. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. Elaborate here please? The core system does not change. That's been a distro fundamental from the beginning. If RH closes a bug, we inherit their change (or lack thereof). SIGs are the way for groups of interested people to work together and make those changes themselves. > > 3. > One more point, and it has to do with the way Fedora/EPEL package > updates are handled. > When I update an RPM package fixing a bug for Fedora/EPEL the update > almost never gets any reviews. This is a Fedora/EPEL issue, and is something we as a distro don't have any control over. We've had discussions a few times with the Fedora/EPEL folks about this but there is no simple answer or immediate fix. > The update is sitting for some fixed amount of time (2 weeks for EPEL) > and after that I push it to stable (still without any review). > I'll bring the famous case here what the result of such releases could > potentially be: > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > know if the offending release was reviewed or not). > Or another case which affected me: > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > Red Hat changed major version of software (mpich2 -> mpich3) which > resulted in a couple months of empty running reviews > (2 weeks each) at EPEL in order to fix all dependencies. So step in. Contribute feedback, jump on the EPEL-devel mailing list and request feedback for packages. Join the relevant irc channels and request/give feedback. > I'm not familiar with the role CentOS could have in the process of > preparation of new RHEL updates, Effectively 0. We see the updates when they land in git, the same as everyone else. > but if there is anything that could be done to improve the RPM package > update process, > it should be considered as an important factor in case of merging CentOS > issues to bugzilla. RHEL and EPEL are quite separate, so I don't really follow what you mean here. In my eyes, there are two benefits from using rh's bugzilla vs our own tracker. 1. It's one less thing to manage. 2. Bugs that have upstream relevance could (in theory) be more easily tagged/cloned without asking the user to duplicate as we currently do. This is still a hypothetical, as we've not talked with the bugzilla folks yet to see how any of this would work, or what would be possible. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From stickster at gmail.com Tue Apr 14 21:27:27 2015 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Apr 2015 17:27:27 -0400 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <552D0CA3.40407@karan.org> References: <552D0CA3.40407@karan.org> Message-ID: <20150414212727.GN19822@raquel-eth.internal.frields.org> On Tue, Apr 14, 2015 at 01:48:35PM +0100, Karanbir Singh wrote: > hi Everyone, > > I would like to take this opportunity to welcome Brian Stinson to the > CentOS Engineering Team at Red Hat, as a part of the Open Source and > Standards group. In this team he will initially be focused on the > central authentication services. As an extention he will also own the > user interface and toolings around the UI to the CentOS Build Services > and Source control. As a part of his additional portfolio, he's going to > help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and > associated infrastructure management. > > Brian has been a key community contributor to the centpkg and the > buildsystem efforts and more recently in the QA teams. He lives and > works out of the Midwest USA ( Summer time offset: UTC -5:00 ). > > Brian is also helping the EPEL effort as a member of their Steering > Committee and helping bridge the CentOS to EPEL stories. > > You can find him on #centos-devel on irc.freenode.net as bstinson and > on twitter as @bstinsonmhk > > Welcome aboard Brian! Congratulations Brian. On the Fedora team our main authentication contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach out to him to discuss development you're doing in this area. The team is usually around on IRC Freenode #fedora-admin. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com From jperrin at centos.org Tue Apr 14 22:42:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 14 Apr 2015 17:42:46 -0500 Subject: [CentOS-devel] Welcoming Brian to CentOS Engineering Team at Red Hat In-Reply-To: <20150414212727.GN19822@raquel-eth.internal.frields.org> References: <552D0CA3.40407@karan.org> <20150414212727.GN19822@raquel-eth.internal.frields.org> Message-ID: <552D97E6.8040107@centos.org> On 04/14/2015 04:27 PM, Paul W. Frields wrote: > > Congratulations Brian. On the Fedora team our main authentication > contact is Patrick Uiterwijk (TZ UTC +1). Please feel free to reach > out to him to discuss development you're doing in this area. The team > is usually around on IRC Freenode #fedora-admin. Agreed. We got to meet with him at FOSDEM this year and discuss a few things. He was working on a plugin for FAS we may take advantage of. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From nkadel at gmail.com Tue Apr 14 22:46:35 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 18:46:35 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. Some of us try. There is a serious learning curve for Fedora and EPEL to get involved in publishing patches to their code: I've tried on at least 3 distinct occassions, and gotten bogged down every time in the "koji" setups. "Look it up on the web" doesn't help, and IRC is not documentation. The variety of bugzillas and credentials needed for the multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. >> I'm not familiar with the role CentOS could have in the process of >> preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. I'm going to be very confused if you do not, individually, have RHEL licenses for early RPM and SRPM review. Are you saying that the git repo updates occur simultaneously, or before, RPM and SRPM publication for RHEL customers? I can imagine "clean room" reasons to avoid access for CentOS core developers, but as a DevOps guy, I'll be surprised. >> but if there is anything that could be done to improve the RPM package >> update process, >> it should be considered as an important factor in case of merging CentOS >> issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. I agree. I personally find RHEL useless without EPEL these days, though. There are consistently too many perl and python modules and useful components backported from Fedora that I need to do even modest work. This especially includes 'mock', for cleanly building patched RHEL or CentOS packages. > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. If it's feasible, I'd appreciate it. Bugzilla is very flexible and sculptable to many different workflows, and I tend to submit patches and workarounds that would be good for both CentOS, RHEL, and Scientific Linux users to all see. From mail-lists at karan.org Tue Apr 14 23:04:23 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 00:04:23 +0100 Subject: [CentOS-devel] triggering external actions from koji builds Message-ID: <552D9CF7.8010506@karan.org> hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From trevor.hemsley at ntlworld.com Tue Apr 14 23:11:31 2015 From: trevor.hemsley at ntlworld.com (Trevor Hemsley) Date: Wed, 15 Apr 2015 00:11:31 +0100 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552D9EA3.1040301@ntlworld.com> On 14/04/15 21:17, Marcin Dulak wrote: > Hi, > > i would like to add some more to the discussion started at > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > 1. > On the plot attached to http://bugs.centos.org/view.php?id=8447 > one can see that since the CentOS 7 release the number of unresolved > issues on bugs.centos.org has increased, > and the number is currently more than 50 unresolved issues per month. > Many issues do not obtain any attention (nothing in the notes). > This continues for several months, and is an unprecedented situation. Many of the bugs that are raised on bugs.centos.org are reporting real errors in the packages and since CentOS only repackages what Redhat provides, this is really not the right place to report the problems. Those bugs that are reported say against the kernel resulting in a panic are not usually ones that CentOS will ever fix - the real solution is to report the bug on bugzilla.redhat.com or via Redhat Support channels. When a new point release comes out then many of those bugs could probably be closed ... well if the bug has been fixed upstream! The bugs that should be on bugs.centos.org should be of the "this works in RHEL but not in CentOS" and "this package is broken because it doesn't recreate the way that it's pacakged in RHEL" variety. > A single example I would like to bring up is the fate of > http://bugs.centos.org/view.php?id=8249 > The reporter made a substantial effort to collect usability issues > encountered during an installation of CentOS, > got asked to report the issues at bugzilla what he did, and there this > got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > This seems to be his only bug at bugzilla.redhat.com. The reporter has probably voiced the thoughts that many of us have had when confronted with the "new improved" installer in RHEL/CentOS 7. But to bundle all those complaints up into one bug report is not the right way to do it, either in CentOS or in Redhat. One bug, one bug report. This is also a CentOS bug report that's a prime example of the above: CentOS don't write the installer, Redhat do. If there are bugs to be fixed then they need to be fixed upstream so it's really rather pointless reporting it on bugs.centos.org at all. All those complaints in that one bugzilla should have been split out into many bugzilla reports and then they might have been fixed individually. > Maybe if CentOS was at bugzilla then CentOS developers could focus more > on the "open-source" way of dealing with people's reports, > which will counteract a bit Red Hat's enforcement of compliance with > it's strategies. I'm not entirely sure what the open-source" way of dealing with people's reports is! If my experience on various freenode IRC channels is anything to go by it's just to say, "yeah, that's how it works and I can't be bothered to fix it but if you want to send me a patch then I'll consider it". Either that or outright rudeness and ridicule :-( ... no, actually the usual response is "compile it from git and if you can recreate it on that then maybe I'll look at it". My own concern about using Redhat's bugzilla is that it's not known for being a speed demon. There are times when I've tried to use it where I've seen response times that feel like minutes but are probably not as long as that. How it would perform with the added load of handling bugs.centos.org traffic as well is anyone's guess. In addition, I'm not sure that bugzilla is exactly user friendly. This doesn't mean that I'm a fan-boi of Mantis, I'm not sure that I'm very keen on that either and it has some quite significant strangenesses. Trevor From johnny at centos.org Tue Apr 14 23:17:30 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 14 Apr 2015 18:17:30 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552DA00A.8040600@centos.org> On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: > >> So step in. Contribute feedback, jump on the EPEL-devel mailing list and >> request feedback for packages. Join the relevant irc channels and >> request/give feedback. > > Some of us try. There is a serious learning curve for Fedora and EPEL > to get involved in publishing patches to their code: I've tried on at > least 3 distinct occassions, and gotten bogged down every time in the > "koji" setups. "Look it up on the web" doesn't help, and IRC is not > documentation. The variety of bugzillas and credentials needed for the > multiple systems, CentOS, RHEL, Fedora, EPEL, etc. all get confusing. > >>> I'm not familiar with the role CentOS could have in the process of >>> preparation of new RHEL updates, >> >> Effectively 0. We see the updates when they land in git, the same as >> everyone else. > > I'm going to be very confused if you do not, individually, have RHEL > licenses for early RPM and SRPM review. Are you saying that the git > repo updates occur simultaneously, or before, RPM and SRPM publication > for RHEL customers? I can imagine "clean room" reasons to avoid access > for CentOS core developers, but as a DevOps guy, I'll be surprised. Stand by to be surprised ... the first time I see any code from Red Hat that goes into CentOS is when it lands in git.centos.org (or for older distros, ftp.redhat.com). Community members of the QA channel can verify that we send information into that channel when updates are found on ftp or git. I then build and push the updates. I do not have a RHEL subscription or access to RHEL SRPMS from inside RHN and I never have. I build almost every SRPM that gets released into every CentOS version, and my access to these things is unchanged from what it was 1, 2, 5, or 10 years ago. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Apr 15 01:39:16 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 14 Apr 2015 21:39:16 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552DA00A.8040600@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> <552DA00A.8040600@centos.org> Message-ID: On Tue, Apr 14, 2015 at 7:17 PM, Johnny Hughes wrote: > On 04/14/2015 05:46 PM, Nico Kadel-Garcia wrote: >> On Tue, Apr 14, 2015 at 4:51 PM, Jim Perrin wrote: >>> Effectively 0. We see the updates when they land in git, the same as >>> everyone else. >> >> I'm going to be very confused if you do not, individually, have RHEL >> licenses for early RPM and SRPM review. Are you saying that the git >> repo updates occur simultaneously, or before, RPM and SRPM publication >> for RHEL customers? I can imagine "clean room" reasons to avoid access >> for CentOS core developers, but as a DevOps guy, I'll be surprised. > > Stand by to be surprised ... the first time I see any code from Red Hat > that goes into CentOS is when it lands in git.centos.org (or for older > distros, ftp.redhat.com). Thank you for clarifying that. Since some CentOS key developers are now Red Hat employees, the workflow is not completely clear. > Community members of the QA channel can verify that we send information > into that channel when updates are found on ftp or git. I then build > and push the updates. > > I do not have a RHEL subscription or access to RHEL SRPMS from inside > RHN and I never have. Lord, I have, precisely for development and debugging for both communities. > I build almost every SRPM that gets released into every CentOS version, > and my access to these things is unchanged from what it was 1, 2, 5, or > 10 years ago. > > > > Thanks, > Johnny Hughes Thanks for explaining that. I remain surprised: I actually publish tools for using 'reposync' to pull an internal mirror of RHEL repositories for customers with licenses for RHEL, partly for patching and building modified packages with 'mock' and publishing updates back to RHEL or, as appropriate, CentOS. It's also handy for internal updating against the frequently RHN yum repositories. The easy access to CentOS repositories, and more graceful and efficient rsync mirroring of that content, is actually a reason that some of my clients have used CentOS instead of RHEL. Nico Kadel-Garcia From walters at verbum.org Wed Apr 15 03:07:53 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Apr 2015 23:07:53 -0400 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552D9CF7.8010506@karan.org> References: <552D9CF7.8010506@karan.org> Message-ID: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > My immediate requirement is to run jenkins jobs when a new rpm drops > into a repo. Does koji have any support for this without the remote > having to constantly poll every second ? https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg. From thomas.oulevey at cern.ch Wed Apr 15 07:25:08 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 09:25:08 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> Message-ID: <552E1254.3040001@cern.ch> Hi Folks, On 04/15/2015 05:07 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: > >> My immediate requirement is to run jenkins jobs when a new rpm drops >> into a repo. Does koji have any support for this without the remote >> having to constantly poll every second ? > > https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py > > is one example. The main question I'd say is around *which* messaging system > and the larger work around wiring things up around it like Fedora has been > doing with fedmsg. I agree that having a messaging queue is the best solution long term. In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py Run mash tasks and do some action at the end. -- Thomas. From mail-lists at karan.org Wed Apr 15 08:09:31 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 09:09:31 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1254.3040001@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> Message-ID: <552E1CBB.7040903@karan.org> On 04/15/2015 08:25 AM, Thomas Oulevey wrote: > Hi Folks, > > On 04/15/2015 05:07 AM, Colin Walters wrote: >> On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote: >> >>> My immediate requirement is to run jenkins jobs when a new rpm drops >>> into a repo. Does koji have any support for this without the remote >>> having to constantly poll every second ? >> >> https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py >> >> is one example. The main question I'd say is around *which* messaging >> system >> and the larger work around wiring things up around it like Fedora has >> been >> doing with fedmsg. > > I agree that having a messaging queue is the best solution long term. yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally ) > In the meantime, we could hack something like this : > https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_spacewalk_sync_task_handler/mash_and_spacewalk.py > > > Run mash tasks and do some action at the end. How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From thomas.oulevey at cern.ch Wed Apr 15 08:44:28 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Wed, 15 Apr 2015 10:44:28 +0200 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E1CBB.7040903@karan.org> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> Message-ID: <552E24EC.1030903@cern.ch> >> >> Run mash tasks and do some action at the end. > > How would we push this in ? is it a case of setting up the plugin by > hand and dropping it into the koji setup ? - Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf From marcin.dulak at gmail.com Wed Apr 15 11:09:34 2015 From: marcin.dulak at gmail.com (Marcin Dulak) Date: Wed, 15 Apr 2015 13:09:34 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D7DCE.1080300@centos.org> References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny at centos.org Wed Apr 15 12:00:55 2015 From: johnny at centos.org (Johnny Hughes) Date: Wed, 15 Apr 2015 07:00:55 -0500 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: References: <552D75EC.4070304@gmail.com> <552D7DCE.1080300@centos.org> Message-ID: <552E52F7.2060809@centos.org> On 04/15/2015 06:09 AM, Marcin Dulak wrote: > > > On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin > wrote: > > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > > > it looks unprecedented to me on the plot. > There has never been a time on bugs.centos.org > with that > many bugs left open per month for such a long period of time. > You do net seem to understand .. CentOS does NOT fix or close technical bugs that exist in both RHEL and CentOS. We only fix bugs that we create in the few packages we modify that are not in RHEL source code, if we introduce them. CentOS rebuilds RHEL source code .. if there is a bug in the RHEL source code, CentOS fixes it when it is fixed in the RHEL source code and released. Bugs.centos.org is a tool for the community to help each other fix, then report to Red Hat (if it is a bug in RHEL code). It is NOT a place to get support for CentOS. CentOS does not now, nor have we ever provides support via bugs.centos.org. If there is a bug that effects you .. fix it and report what you did to fix it. Any and all support (if you want to use that term) for CentOS does now, and always has, come from the community. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nshaikh at redhat.com Wed Apr 15 13:21:19 2015 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 15 Apr 2015 18:51:19 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <552E65CF.4020100@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > +1 I would like get involved in builds and testing. What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server? -- Navid From mail-lists at karan.org Wed Apr 15 16:32:21 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:32:21 +0100 Subject: [CentOS-devel] triggering external actions from koji builds In-Reply-To: <552E24EC.1030903@cern.ch> References: <552D9CF7.8010506@karan.org> <1429067273.3542293.253886549.6E3754B6@webmail.messagingengine.com> <552E1254.3040001@cern.ch> <552E1CBB.7040903@karan.org> <552E24EC.1030903@cern.ch> Message-ID: <552E9295.6070000@karan.org> On 15/04/15 09:44, Thomas Oulevey wrote: > >>> >>> Run mash tasks and do some action at the end. >> >> How would we push this in ? is it a case of setting up the plugin by >> hand and dropping it into the koji setup ? > > - Design and code ; define if we want a koji-builder plugin or koji-hub > plugin What would the difference be ? it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 15 16:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 17:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E65CF.4020100@redhat.com> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> Message-ID: <552E93C8.2020404@karan.org> On 15/04/15 14:21, Navid Shaikh wrote: > > I would like get involved in builds and testing. excellent! > > What does `Source Drop` block means? Will it be a store of OSTree > repositories as output of compose-server? Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release. this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From svenkieske at gmail.com Wed Apr 15 16:45:06 2015 From: svenkieske at gmail.com (Sven Kieske) Date: Wed, 15 Apr 2015 18:45:06 +0200 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552D75EC.4070304@gmail.com> References: <552D75EC.4070304@gmail.com> Message-ID: <552E9592.6010200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as an (most times) just end user of EL6/7 I'd like to say that I would prefer bugzilla.redhat.com for centos bugs as well. It makes shifting bugs between RHEL and CentOS very much simpler. The reason many bugs get reported first vs CentOS ist people do not really know the relationship between RHEL and CentOS. And the people who know the relationship have often no license to test if it's a CentOS or RHEL Bug (you would need a RHEL license to try to reproduce). When you have some experience you can of course tell with a high probability if it's CentOS or upstream related. TBH: Most (upstream)bugs tend to get closed anyway if someone finds out your not using RHEL. (This get's masked via sentences like "Please contact your support channel if you want to raise the priority of this problem") I wish RedHat would improve this behaviour, but you can not really argue if you get it for free. Back to the Bugzilla Question: I really think bugzilla has way better features and usability than mantis, but that's just me, and of course you have the ability to shift a bug to epel/fedora/rhel if it turns out you reported it against the wrong product. I think this might be increasingly important when you look at all the sig products which incorporate many projects already using bugzilla.redhat.com like ovirt, glusterfs and so on. kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVLpWSAAoJEAq0kGAWDrql1HsMAKrPppy6uGcKbYezs1aZaLrt 6Ry8Q+OL+w/HGTaFN6fkuUJCyndxLH7dMgcRapGOu9Dnm78l1oKP/mkEl1FYiCe7 4WFQdYVDBeGPdnkw0qPRAywBwlq+maS2EtbK8iOq0nmcXFKnCuETzVe3oW59xHXQ vagHmp28rKsSgSB1IGgkmiigL0hWp34M9g/wDW4qnkf72tubB1dqYA5vJwMKODfi xQS2L/4Qg72W96sJXyjMU3i0XJlPgSeXVlwHu7msslTHD08iACH32Pc00WfXQrNg Fnf3UgdNdFZXocpG276VP/6dRKQ3zPAw1TZbCQE5DiYaTEI+FJKFln9I7hrj0j01 wUvS8OIKKrBlaPsTQExhxmHpY5akmdBrRKdxHHf5by5MN82w9uO3WMk0GKm2Xt+I WoIMdrfL3Qm/h2BtBbn9EK0d21aGZDmIww0Or91LPGBTt2tluOfr2HSgPc0cli7u xPgO7G4q3ddLP89MZ/LBg7R/NhAxiTiBwuzfv4hZ3A== =Jhsb -----END PGP SIGNATURE----- From tsorensen at gmail.com Wed Apr 15 17:28:33 2015 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 15 Apr 2015 13:28:33 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: On Wednesday, April 15, 2015, Sven Kieske wrote: > > The reason many bugs get reported first vs > CentOS ist people do not really know the relationship > between RHEL and CentOS. Agreed. No matter how much the CentOS devs say this, a large number of users don't know this. > And the people who know the relationship > have often no license to test if it's a CentOS > or RHEL Bug (you would need a RHEL license > to try to reproduce). Note that most of the CentOS devs don't either, including those employed by Red Hat. They can request an employee sub, but don't have one by default, and that helps keep things clean. > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") If it's a legitimate bug (defect) then that shouldn't happen. If it's a RFE then, yes, that's proper - support and input into future direction (big or small) is a significant part of the RHEL value proposition (sales-y enough for you?). If you have an example of the former then let me know. That's a standing offer. My take on the overall question is that if the CentOS team can get the flexibility needed for their own purposes then it seems like a big win. The project has always been tied to Red Hat, so worrying about the bug tracker being owned by RH seems rather silly. The ability to properly transfer bugs to upstream (be it RH or Fedora) and making the relationship more obvious and transparent to reporters cannot be overstated. FYI, the usual reasons for RHEL bugs to be marked private is either confidential customer info or security. And it annoys employees too. I would hope that CentOS sourced, non-security bugs wouldn't fall into this, but really cannot say with any certainty. That is something that would need to be discussed with the RH Bz team and the CentOS devs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Apr 15 17:40:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 15 Apr 2015 18:40:25 +0100 Subject: [CentOS-devel] "CentOS.devel" In-Reply-To: <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> References: <1428419447.4102677.250290689.3B20ECE0@webmail.messagingengine.com> <20150407152730.GA9831@naruto> <1428962439.2597858.253279729.08D3F0BD@webmail.messagingengine.com> Message-ID: <552EA289.80800@karan.org> On 13/04/15 23:00, Colin Walters wrote: > On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote: >> >> I don't think EPEL could fit in here because the audience for EPEL is >> a lot more conservative in what they want than what people working on >> anything from this decade want. > > An important point of this "CentOS.devel" repository would be that EPEL > would *not* be present in the buildroot - this is only for newer > versions of the core packages which should be self-hosting. A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily. We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ? given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From centos at dm.cobite.com Wed Apr 15 17:40:24 2015 From: centos at dm.cobite.com (David Mansfield) Date: Wed, 15 Apr 2015 13:40:24 -0400 Subject: [CentOS-devel] Hosting CentOS bugs on RH bugzilla In-Reply-To: <552E9592.6010200@gmail.com> References: <552D75EC.4070304@gmail.com> <552E9592.6010200@gmail.com> Message-ID: <552EA288.9060103@dm.cobite.com> On 04/15/2015 12:45 PM, Sven Kieske wrote: > > TBH: Most (upstream)bugs tend to get closed anyway > if someone finds out your not using RHEL. > (This get's masked via sentences like "Please > contact your support channel if you want to raise > the priority of this problem") > > I wish RedHat would improve this behaviour, but > you can not really argue if you get it for free. > > While I have seen this, generally I would disagree, although I have seen on numerous occasions that a fix would not be pushed until the next "dot" release (i.e. not a candidate for the bug fix stream for the current "dot" release), and in those cases I was asked that if I could open a RH issue with under my account then maybe it would happen, which is completely fair. FWIW, I'm for coagulating the bug trackers. Thanks, David From jperrin at centos.org Thu Apr 16 00:39:01 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 15 Apr 2015 19:39:01 -0500 Subject: [CentOS-devel] nss build failure - Just an FYI to folks who may be rebuilding. Message-ID: <552F04A5.80509@centos.org> One of the tests in the nss build will fail, because paypal issued a new cert[1]. This will cause the package build to fail. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1151037 -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jbrooks at redhat.com Thu Apr 16 15:24:10 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 16 Apr 2015 11:24:10 -0400 (EDT) Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1394719555.1185012.1429197799580.JavaMail.zimbra@redhat.com> Message-ID: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> At the Atomic SIG mtg last week, I mentioned consolidating our two json files that contain the centos atomic host definition into one json file. Here's a commit for that in my fork of the repo: https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb Any objections to carrying this change over to the main repo? Regards, Jason --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com From lmohanty at redhat.com Thu Apr 16 16:14:09 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 16 Apr 2015 21:44:09 +0530 Subject: [CentOS-devel] Storage SIG Meeting 17-April-2015 15:30 UTC Message-ID: <552FDFD1.9040800@redhat.com> Greetings All! Time for a Storage SIG meeting. We will be meeting in #centos-devel on Freenode. Thanks, Lala From mail-lists at karan.org Thu Apr 16 17:37:58 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:37:58 +0100 Subject: [CentOS-devel] CentOS Atomic: json consolidation In-Reply-To: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> References: <1617021161.1186387.1429197850756.JavaMail.zimbra@redhat.com> Message-ID: <552FF376.8010102@karan.org> On 04/16/2015 04:24 PM, Jason Brooks wrote: > > At the Atomic SIG mtg last week, I mentioned consolidating our two > json files that contain the centos atomic host definition into one > json file. > > Here's a commit for that in my fork of the repo: > > https://github.com/jasonbrooks/sig-atomic-buildscripts/commit/2a0af4e5e3dfa131031f0f6567657b5406a09fbb > > Any objections to carrying this change over to the main repo? > looks good to me, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Thu Apr 16 17:42:08 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 16 Apr 2015 18:42:08 +0100 Subject: [CentOS-devel] Atomic devel builds automation Message-ID: <552FF470.2090504@karan.org> hi, The Atomic devel builds are now running from cron again, after a 2 week lag, they now run every 12 hours, midnight and midday UTC. These builds now also run with a complete toolchain update taking place before the build gets run. The build script is now in git itself : https://github.com/CentOS/sig-atomic-buildscripts/blob/master/build_ostree_components.sh and the cron worker will git pull, before running this, so updates are consumed immediately. That does make line 10 to 12 of this script completely redundant, but I've left it in as an indicator. Build runs are logged at : http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ And the ostree repo remains at : http://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ Once the installer image starts building, we can push that to http://buildlogs.centos.org/centos/7/atomic/x86_64/ which would in turn allow the vagrant and image builds to also run. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lsm5 at fedoraproject.org Thu Apr 16 20:52:20 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 16 Apr 2015 15:52:20 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS Message-ID: <20150416205220.GA31303@naruto> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches) There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases. Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included. Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches. We could either: a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches c) ...anything else?? Comments? -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imcleod at redhat.com Fri Apr 17 13:16:58 2015 From: imcleod at redhat.com (Ian McLeod) Date: Fri, 17 Apr 2015 08:16:58 -0500 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <553107CA.2090709@redhat.com> On 04/14/2015 06:22 AM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. > > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. This looks good to me and I'm keen to assist. As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable. It's currently sitting in this directory and branch of my fork of the Atomic SIG repo: https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week. I'd also be interested in getting plugged in on the CI/CD infrastructure side of things. -Ian > > Regards > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > From mattdm at mattdm.org Fri Apr 17 15:11:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 17 Apr 2015 11:11:44 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <20150417151144.GA23199@mattdm.org> On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) -- Matthew Miller Fedora Project Leader From mail-lists at karan.org Fri Apr 17 15:21:34 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:21:34 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <20150417151144.GA23199@mattdm.org> References: <552CF877.9020005@centos.org> <20150417151144.GA23199@mattdm.org> Message-ID: <553124FE.60705@karan.org> On 17/04/15 16:11, Matthew Miller wrote: > On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote: >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > > Can you help me understand how this relates to the "4 week Atomic > releases" plan Mike McGrath posted about last month? > (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html) > > > it doesnt. the '4' builds will happen orthogonal from these ones. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Fri Apr 17 15:23:40 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 17 Apr 2015 16:23:40 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5531257C.3040207@karan.org> On 17/04/15 14:16, Ian McLeod wrote: > On 04/14/2015 06:22 AM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. >> >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. > > This looks good to me and I'm keen to assist. > > As a starting point, I've put up a snapshot of the non-RPM metadata that > is being used to generate the upstream Atomic content. It differs > substantially from the current CentOS Atomic SIG content and will need > at least some modification to be workable. > > It's currently sitting in this directory and branch of my fork of the > Atomic SIG repo: > > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable. > > I'd also be interested in getting plugged in on the CI/CD infrastructure > side of things. sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Fri Apr 17 15:40:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:40:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: <55312978.20605@centos.org> On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches > > c) ...anything else?? Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options. As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla. in both cases though, we should "fix" these to actually work whether they are broken upstream or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From johnny at centos.org Fri Apr 17 15:45:40 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 17 Apr 2015 10:45:40 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <55312978.20605@centos.org> References: <20150416205220.GA31303@naruto> <55312978.20605@centos.org> Message-ID: <55312AA4.5030909@centos.org> On 04/17/2015 10:40 AM, Johnny Hughes wrote: > On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote: >> I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh >> patches) >> >> There's the default docker that CentOS gets in extras from RHEL which comes >> with RH patches (of course). But this kinda comes quite a bit after upstream >> docker releases. >> >> Next up is 'docker' in virt SIG which usually tracks upstream releases. Would >> people prefer this build be vanilla upstream or with RH patches included. >> >> Then there is 'docker-master' in virt SIG which is a daily rebuild of docker >> upstream master branch + redhat patches. >> >> We could either: >> >> a) ship 'docker' in virt SIG with RH patches and also provide a >> 'docker-upstream' which is a vanilla upstream package >> >> b) ship 'docker' in virt SIG without any RH patches and provide a >> 'docker-redhat' with RH patches >> >> c) ...anything else?? > > Well, I think we should ship an AS-IS downstream from the RHEL platform > as one of the options. > > As far as the "more progressive / newer" option, I would think one with > some RH patches (assuming the RH patches make it more stable than > vanilla upstream) would be desired. I this being just the vanilla > upstream if we really wanted. But I would think optimized with RH > patches would likely be better than pure vanilla. > > in both cases though, we should "fix" these to actually work whether > they are broken upstream or not. Holy moley .. I read that to myself and it sounded fine :) What I mean is .. one should be the rhel released one (but we can patch it if it is really broken). The other one can either be vanilla or newer with RH patches in .. which ever is more stable. The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster. I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Fri Apr 17 15:50:47 2015 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Apr 2015 11:50:47 -0400 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552E93C8.2020404@karan.org> References: <552CF877.9020005@centos.org> <552E65CF.4020100@redhat.com> <552E93C8.2020404@karan.org> Message-ID: On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh wrote: > On 15/04/15 14:21, Navid Shaikh wrote: >> >> I would like get involved in builds and testing. > > excellent! > Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running. >> >> What does `Source Drop` block means? Will it be a store of OSTree >> repositories as output of compose-server? > > Since this is the downstream build, the source drop in this case would > be when the srpm sources show up at git.centos.org > > but you raise a good question: once we have the image up, what ostree > repo would this be pointing at ? Off the top of my head, I'd guess the > ostree repo would just be the atomic definition in the composed images, > and a nightly update to include updates released into the CentOS Linux > distro. And then rebase on next release. > > this way anyone, once onramped onto an atomic image, would just keep > running an 'atomic update' to get new content and never need to rebase > the image. > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From alain.reguera at gmail.com Fri Apr 17 17:00:28 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Fri, 17 Apr 2015 13:00:28 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure Message-ID: Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al. From arrfab at centos.org Sat Apr 18 06:19:10 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Sat, 18 Apr 2015 08:19:10 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: Message-ID: <5531F75E.2020108@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 19:00, Alain Reguera Delgado wrote: > Hello Everyone, > > I am wondering if we could have a talk about CentOS visual > identity, so to consolidate the path to follow and coordinate > further efforts in this matter. > > There are two points I would like to call attention to. The first > one is the visual structure of CentOS Project (see > http://wiki.centos.org/ArtWork/Identity). The second one is the > CentOS Project logo (see > http://wiki.centos.org/ArtWork/Brand/Logo). > > In the very specific case of CentOS Logo it is necessary to note > that it is being used in different manners in official places. This > affects the strength of the CentOS brand. For example, consider > the construction described in the wiki page above and the logos > shown in wiki.centos.org, bugs.centos.org and mirror.centos.org > sites. Although they are similar they aren't exactly the same. > > The construction I propose in the wiki is based on the CentOS logo > published in the sources of CentOS 5. In these files, the CentOS > logo is entirely plain and does not have any ornament (like shadow > or bright) on it. > > I am planning to put ready-to use CentOS logos files in SVG format > in the wiki and I would like you to express your opinion in the > correct CentOS logo that should be used so we can unify this and > give more strength to CentOS Project visual identity. > > Best Regards, al. Hi Alain, That's a good idea. What I'm wondering is why using a black font for "CentOS" on a light background ? why not using something like blue ? Cheers, and thanks a lot for your work - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUx914ACgkQnVkHo1a+xU49GQCdHVjZ7Im20MUDyU9+Z6+Tem0M DuwAoIwpjbg7RNSW93d4FVGBQvOU+Rcs =bjKL -----END PGP SIGNATURE----- From s_gowtham at live.com Sat Apr 18 07:13:03 2015 From: s_gowtham at live.com (Gow Tham) Date: Sat, 18 Apr 2015 12:43:03 +0530 Subject: [CentOS-devel] Getting started on contributing to CentOS In-Reply-To: References: Message-ID: ping From: s_gowtham at live.com To: centos-devel at centos.org CC: centos-gsoc at centos.org Subject: Getting started on contributing to CentOS Date: Mon, 6 Apr 2015 18:32:51 +0530 Hi, I have been using CentOS for quite a while now and would like to switch from the user to a contributor. kbsingh mentioned on the ilug mailing list that this was a good time to get acquainted with the community because of the influx of new users due to the Google Summer of Code event. Looking at the Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the one about writing a Lightweight Cloud instance contextualisation tool seemed like a good place to start. How can I start with it ? -sg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Sat Apr 18 07:48:25 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 18 Apr 2015 08:48:25 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <552FF470.2090504@karan.org> References: <552FF470.2090504@karan.org> Message-ID: <55320C49.7060104@karan.org> On 16/04/15 18:42, Karanbir Singh wrote: > hi, > > The Atomic devel builds are now running from cron again, after a 2 week > lag, they now run every 12 hours, midnight and midday UTC. These builds > now also run with a complete toolchain update taking place before the > build gets run. http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, and we can verify that we have 12 hrly builds. As the next step, I'd like to now expand this to run a build for every git branch in the upstream sig-atomic-buildscripts repo. What / how should we handle naming those ? one option might be to leave http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to deliver the master branch, and then create http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each branch, would that work ? We would also need new centos-release-atomic- in each of those, otherwise the ostree upstream repo url will point into the default master's repo. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From bart.vanassche at sandisk.com Sat Apr 18 09:39:06 2015 From: bart.vanassche at sandisk.com (Bart Van Assche) Date: Sat, 18 Apr 2015 11:39:06 +0200 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> Message-ID: <5532263A.5040003@sandisk.com> On 03/11/15 18:01, Justin Clift wrote: > On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >> Hello, >> >> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? > > The "take a risk X might break" bit doesn't really sound suitable > for the CentOS audience. > > That being said... how often does the RDMA ABI change? If it's > once every X years, then it might be live-able (with sufficient > catches/warning so users aren't affected). (back from traveling - sorry for the delay in replying) Hello Justin, So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Bart. From walters at verbum.org Sat Apr 18 13:58:57 2015 From: walters at verbum.org (Colin Walters) Date: Sat, 18 Apr 2015 09:58:57 -0400 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> On Sat, Apr 18, 2015, at 03:48 AM, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Awesome, thanks! Having this script public and well known with logs is a big step forwards. > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? One thing that Ari and I have been exploring is using Jenkins for these sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc notification etc.), and supports "parameterization" of jobs which is is exactly what you mentioned above. I'll see if we can get the prototype published soon, it's using jenkins-job-builder (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 and should be easily built on C7) From justin at gluster.org Sat Apr 18 14:09:29 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 15:09:29 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <5532263A.5040003@sandisk.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> Message-ID: <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: > On 03/11/15 18:01, Justin Clift wrote: >> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>> Hello, >>> >>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >> >> The "take a risk X might break" bit doesn't really sound suitable >> for the CentOS audience. >> >> That being said... how often does the RDMA ABI change? If it's >> once every X years, then it might be live-able (with sufficient >> catches/warning so users aren't affected). > > (back from traveling - sorry for the delay in replying) > > Hello Justin, > > So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;) Doug (just added to this email chain) likely knows though. Doug? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From justin at gluster.org Sat Apr 18 18:25:58 2015 From: justin at gluster.org (Justin Clift) Date: Sat, 18 Apr 2015 19:25:58 +0100 Subject: [CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week) In-Reply-To: <1429375014.15740.5.camel@redhat.com> References: <54F8FFF0.2050404@redhat.com> <54F9B1C2.2090904@redhat.com> <54FED0E4.2000903@sandisk.com> <95EC7C8F-B5CC-4AD7-B924-D3F0C1B420D3@gluster.org> <5532263A.5040003@sandisk.com> <439CC4A1-454C-4D0E-BCA5-D56AF9A92392@gluster.org> <1429375014.15740.5.camel@redhat.com> Message-ID: <2B321176-5DEA-4FC3-83B5-74FE1BD5F113@gluster.org> On 18 Apr 2015, at 17:36, Doug Ledford wrote: > On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote: >> On 18 Apr 2015, at 10:39, Bart Van Assche wrote: >>> On 03/11/15 18:01, Justin Clift wrote: >>>> On 10 Mar 2015, at 11:09, Bart Van Assche wrote: >>>>> Hello, >>>>> >>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ? >>>> >>>> The "take a risk X might break" bit doesn't really sound suitable >>>> for the CentOS audience. >>>> >>>> That being said... how often does the RDMA ABI change? If it's >>>> once every X years, then it might be live-able (with sufficient >>>> catches/warning so users aren't affected). >>> >>> (back from traveling - sorry for the delay in replying) >>> >>> Hello Justin, >>> >>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ... >> >> Hmmmm... in general RHEL has an attitude of "don't change ABI in >> updates", > > It's not an attitude, it's a hard requirement that requires managerial > approval for an exception to break it. > >> but RDMA may or may not have different assumptions. I >> have no idea. ;) > > It does. We exempt the kernel portion of the RDMA stack from any ABI > claims entirely. For user space, we make a best effort to preserve > backward binary compatibility, but not forward. Meaning if you compile > a user space app against 7.0, our 7.1 and later updates will all be > backward compatible to your compiled program. However, we add > extensions, so if you compile against 7.2 let's say, and use one of the > new extensions, then you program will not run on 7.0. However, keep in > mind that this is a best effort. On occasion, with managerial approval, > we break this too. The RDMA simply moves too fast to keep it static > through the life of a RHEL product. Thanks Doug. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift From alain.reguera at gmail.com Sun Apr 19 20:28:17 2015 From: alain.reguera at gmail.com (Alain Reguera Delgado) Date: Sun, 19 Apr 2015 16:28:17 -0400 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: <5531F75E.2020108@centos.org> References: <5531F75E.2020108@centos.org> Message-ID: On 4/18/15, Fabian Arrotin wrote: ... > What I'm wondering is why using a black font for "CentOS" on a light > background ? why not using something like blue ? Hi Fabian, The black color gives us the highest contrast we can take on light backgrounds, just as white color does on dark backgrounds. The contrast here is important because it may affect the visual impact of the brand and so its recognition when it is printed on different media. Using other color but black in light backgrounds would reduce the number of possibilities the CentOS word and, by extension, the CentOS logo could have in this respect (i.e., the number of media it can be applied to). On the other hand, if there is an identity issue strong enough for the community as to use a different color but black in the CentOS word, I don't have a problem with it. All we need is to be aware of the implications and be consistent with it in whatever implementation we adopt. Best Regards, al From arrfab at centos.org Mon Apr 20 05:30:08 2015 From: arrfab at centos.org (Fabian Arrotin) Date: Mon, 20 Apr 2015 07:30:08 +0200 Subject: [CentOS-devel] The CentOS Project Visual Identity Structure In-Reply-To: References: <5531F75E.2020108@centos.org> Message-ID: <55348EE0.3050504@centos.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/15 22:28, Alain Reguera Delgado wrote: > On 4/18/15, Fabian Arrotin wrote: ... >> What I'm wondering is why using a black font for "CentOS" on a >> light background ? why not using something like blue ? > > Hi Fabian, > > The black color gives us the highest contrast we can take on light > backgrounds, just as white color does on dark backgrounds. The > contrast here is important because it may affect the visual impact > of the brand and so its recognition when it is printed on > different media. Using other color but black in light backgrounds > would reduce the number of possibilities the CentOS word and, by > extension, the CentOS logo could have in this respect (i.e., the > number of media it can be applied to). > > On the other hand, if there is an identity issue strong enough for > the community as to use a different color but black in the CentOS > word, I don't have a problem with it. All we need is to be aware of > the implications and be consistent with it in whatever > implementation we adopt. > > Best Regards, al Hi Alain, Well, I understand and follow your explanations for the light background and the black color. I was just giving my simple user opinion (not being a designer nor a artwork guy myself ;-) ) I was thinking that it would make more sense to use the same color for the "CentOS" word, like for example for the one we have already for the bug tracker : https://bugs.centos.org/images/centos-292-new.png Still "enough" dark, but not black, and so it can be seen as a whole : logo and centos words are part of the same identity and not something constructed from a logo on one side, and a centos word from somewhere else. Just giving my opinion though - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU0juAACgkQnVkHo1a+xU7BFwCgiSqr2aHrgHu6cvdXZo9dOMcn GaMAn0e5Y3s1+miEOzhRm0p1g/0DJvYx =v7so -----END PGP SIGNATURE----- From dunlapg at umich.edu Mon Apr 20 11:25:46 2015 From: dunlapg at umich.edu (George Dunlap) Date: Mon, 20 Apr 2015 12:25:46 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150416205220.GA31303@naruto> References: <20150416205220.GA31303@naruto> Message-ID: On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar wrote: > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > patches) > > There's the default docker that CentOS gets in extras from RHEL which comes > with RH patches (of course). But this kinda comes quite a bit after upstream > docker releases. > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > people prefer this build be vanilla upstream or with RH patches included. > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > upstream master branch + redhat patches. > > We could either: > > a) ship 'docker' in virt SIG with RH patches and also provide a > 'docker-upstream' which is a vanilla upstream package > > b) ship 'docker' in virt SIG without any RH patches and provide a > 'docker-redhat' with RH patches What do the RH patches actually do? I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release. -George From veillard at redhat.com Mon Apr 20 13:58:03 2015 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Apr 2015 21:58:03 +0800 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <55320C49.7060104@karan.org> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> Message-ID: <20150420135803.GM18419@redhat.com> On Sat, Apr 18, 2015 at 08:48:25AM +0100, Karanbir Singh wrote: > On 16/04/15 18:42, Karanbir Singh wrote: > > hi, > > > > The Atomic devel builds are now running from cron again, after a 2 week > > lag, they now run every 12 hours, midnight and midday UTC. These builds > > now also run with a complete toolchain update taking place before the > > build gets run. > > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/ has content, > and we can verify that we have 12 hrly builds. Out of curiosity, I followed http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log and see errors: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ---------- installer No config file: /srv/sig-atomic-buildscripts//installer.ini ---------- Vagrant usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [-i IMAGES] [--name NAME] [--tdl TDL] [--virtnetwork VIRTNETWORK] -o OUTPUTDIR [--overwrite] [-k KICKSTART] [--vkickstart VKICKSTART] [-p PROFILE] [-v] rpmostreecompose-main: error: argument -c/--config is required ---------- liveimage usage: rpmostreecompose-main [-h] -c CONFIG [--ostreerepo OSTREEREPO] [--overwrite] -o OUTPUTDIR [-p PROFILE] [-k KICKSTART] [--tdl TDL] [--name NAME] [--diskimage DISKIMAGE] [--skip-subtask SKIP_SUBTASK] [-b YUM_BASEURL] rpmostreecompose-main: error: argument -c/--config is required ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and sending incremental file list 20150420_120001/ seems to only cary the new directory right ? Daniel > As the next step, I'd like to now expand this to run a build for every > git branch in the upstream sig-atomic-buildscripts repo. What / how > should we handle naming those ? > > one option might be to leave > http://buildlogs.centos.org/centos/7/atomic/x86_64/ as the place to > deliver the master branch, and then create > http://buildlogs.centos.org/centos/7/atomic-BranchName/x86_64/ for each > branch, would that work ? We would also need new > centos-release-atomic- in each of those, otherwise the > ostree upstream repo url will point into the default master's repo. > > regards, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From mail-lists at karan.org Mon Apr 20 16:27:33 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 20 Apr 2015 17:27:33 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <20150420135803.GM18419@redhat.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <20150420135803.GM18419@redhat.com> Message-ID: <553528F5.7010707@karan.org> On 20/04/15 14:58, Daniel Veillard wrote: > Out of curiosity, I followed > http://buildlogs.centos.org/centos/7/atomic/x86_64/Builds/20150420_120001/log > > and see errors: > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ---------- installer > No config file: /srv/sig-atomic-buildscripts//installer.ini yeah, adding the content into the git repos should resolve this. > > and > > sending incremental file list > 20150420_120001/ > > seems to only cary the new directory > > right ? yes, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Apr 20 17:22:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 20 Apr 2015 19:22:33 +0200 Subject: [CentOS-devel] summary for tags/branches in SCLo SIG Message-ID: <553535D9.5050008@redhat.com> Hi guys, few days back we talked about tags and branches names on the SCLo meeting and I found out that I missed the important CBS meeting [1].. which I'm sorry.. Anyway, we ended with things in our heads but I can't find anything written, so I tried to summarize what should be the result (as I understood it) and would like to ask for correction if I failed to get it... I realize that rh-mariadb100 confuses people, because it includes rh- in the name, but for tags/branches names it is nothing more than part of the collection name. If the dash is an issue, then we may use underscore (rh_mariadb100) or just rhmariadb100 if necessary for tags/branches, but mariadb100 alone is simply not correct. What is more, not all collections in RHSCL have rh- prefix (existing collections) although the new collections should have it in the future. Anyway, I rather took another collection (that doesn't use rh- prefix) to not complicate it even more and the bellow are examples of two collections within SCLo -- one that *is part of RHSCL* (mariadb55) and one that is only part of SCLo (mariadb55extra; could include packages that extend mariadb55 collection for example), which *is not part* of RHSCL. final tags (and repositories) for non-RHSCL collections (include also packages from rhscl repos bellow): sclo6-sclo-release sclo6-sclo-candidate sclo6-sclo-testing sclo7-sclo-release sclo7-sclo-candidate sclo7-sclo-testing final tags (and repositories) for RHSCL collections (separate in order to allow using the sclo- repositories together with RH's rhscl channel, the same as epel is used): sclo6-rhscl-release sclo6-rhscl-candidate sclo6-rhscl-testing sclo7-rhscl-release sclo7-rhscl-candidate sclo7-rhscl-testing build tags: sclo6-el6-mariadb55extra-sclo-build sclo7-el7-mariadb55extra-sclo-build sclo6-el6-mariadb55-rhscl-build sclo7-el7-mariadb55-rhscl-build (el6- and el7- part used for keeping the disttag in the name as agreed from the beginning for all SIGs -- that was mentioned as a requirement before already) build targets: sclo6-el6-mariadb55extra-sclo sclo7-el7-mariadb55extra-sclo sclo6-el6-mariadb55-rhscl sclo7-el7-mariadb55-rhscl git branches under sclo/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl git branches under rpms/ project: sclo6-mariadb55extra-sclo sclo7-mariadb55extra-sclo sclo6-mariadb55-rhscl sclo7-mariadb55-rhscl Are we on the same page with the schema above? [1] http://www.centos.org/minutes/2015/april/centos-devel.2015-04-13-14.01.log.html Honza From lsm5 at fedoraproject.org Mon Apr 20 18:06:15 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Mon, 20 Apr 2015 13:06:15 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> Message-ID: <20150420180614.GA21180@naruto> On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote: > On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar > wrote: > > I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh > > patches) > > > > There's the default docker that CentOS gets in extras from RHEL which comes > > with RH patches (of course). But this kinda comes quite a bit after upstream > > docker releases. > > > > Next up is 'docker' in virt SIG which usually tracks upstream releases. Would > > people prefer this build be vanilla upstream or with RH patches included. > > > > Then there is 'docker-master' in virt SIG which is a daily rebuild of docker > > upstream master branch + redhat patches. > > > > We could either: > > > > a) ship 'docker' in virt SIG with RH patches and also provide a > > 'docker-upstream' which is a vanilla upstream package > > > > b) ship 'docker' in virt SIG without any RH patches and provide a > > 'docker-redhat' with RH patches I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go. For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy. > What do the RH patches actually do? Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too. > > I think either one could make sense depending on how much value the > patches provide / how much they cost to port to the latest release. These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Mon Apr 20 19:43:26 2015 From: jperrin at centos.org (Jim Perrin) Date: Mon, 20 Apr 2015 14:43:26 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553556DE.2070001@centos.org> On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote: > > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers. > For anyone interested in RH patches, there's 'docker-master' in virt SIG > (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. > Also, I could add anything else to make anyone else happy. > >> What do the RH patches actually do? > > > Some docker behavior does get modified, like adding and blocking registries, > checking for confirmation before pushing to public registries. AFAIK, patches > were added only with permission from upstream docker and we're working > towards upstreaming those patches too. > >> >> I think either one could make sense depending on how much value the >> patches provide / how much they cost to port to the latest release. > These patches are desirable to enterprise users, but I've been hearing a lot > directly/indirectly from CentOS users that they only want vanilla docker > behavior. Porting/rebasing is taken care of by RH folks on a daily basis. Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jzb at redhat.com Mon Apr 20 21:40:27 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 20 Apr 2015 17:40:27 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <5535724B.4040504@redhat.com> On 04/20/2015 03:43 PM, Jim Perrin wrote: >> > I've pretty much decided that 'docker' in virt SIG would only track upstream >> > sources (no RH patches in it). Don't want this to sound like "I don't care >> > what anyone says", but docker upstream and many CentOS users want a build >> > which will only track upstream docker sources. Having 'docker' in virt SIG to >> > be this build sounds like the way to go. > > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lmohanty at redhat.com Tue Apr 21 06:30:31 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:00:31 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <552CF877.9020005@centos.org> References: <552CF877.9020005@centos.org> Message-ID: <5535EE87.6060009@redhat.com> On 04/14/2015 04:52 PM, Karanbir Singh wrote: > Hi, > > One of the things that the Atomic SIG will attempt to do is build a > downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. > Most code and info needed for this is now available, and its a good > point to think about the build, release process. I've attached a map of > what that might look like. Think of it as a proposal. +1. I think this will serve as the stable build for CentOS Atomic SIG. Have we decided about the time-line to make this happen? > Some of the things that are marked with red stars are things that we > will try and help, from the Core SIG, to get this process onramped - but > largely we are looking at community and SIG involvement here with the > aim that the entire process can be offload ( taken over ? ) but the > community. > > This process proposed here very closely maps to the Core CentOS Linux > process. > > I would very much like to hear comments and thoughts around this from > everyone on centos-devel, specially around areas where people can help. > > Regards -Lala From lmohanty at redhat.com Tue Apr 21 07:28:02 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 21 Apr 2015 12:58:02 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535EE87.6060009@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> Message-ID: <5535FC02.3080603@redhat.com> On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: > On 04/14/2015 04:52 PM, Karanbir Singh wrote: >> Hi, >> >> One of the things that the Atomic SIG will attempt to do is build a >> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >> Most code and info needed for this is now available, and its a good >> point to think about the build, release process. I've attached a map of >> what that might look like. Think of it as a proposal. > > +1. I think this will serve as the stable build for CentOS Atomic SIG. > > Have we decided about the time-line to make this happen? > The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host. >> Some of the things that are marked with red stars are things that we >> will try and help, from the Core SIG, to get this process onramped - but >> largely we are looking at community and SIG involvement here with the >> aim that the entire process can be offload ( taken over ? ) but the >> community. >> >> This process proposed here very closely maps to the Core CentOS Linux >> process. >> >> I would very much like to hear comments and thoughts around this from >> everyone on centos-devel, specially around areas where people can help. >> >> Regards > -Lala > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From mail-lists at karan.org Tue Apr 21 12:31:55 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 13:31:55 +0100 Subject: [CentOS-devel] Atomic devel builds automation In-Reply-To: <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> References: <552FF470.2090504@karan.org> <55320C49.7060104@karan.org> <1429365537.1134989.255442713.292A19E1@webmail.messagingengine.com> Message-ID: <5536433B.9070408@karan.org> hi On 18/04/15 14:58, Colin Walters wrote: >> As the next step, I'd like to now expand this to run a build for every >> git branch in the upstream sig-atomic-buildscripts repo. What / how >> should we handle naming those ? > > One thing that Ari and I have been exploring is using Jenkins for these > sort of "post-Koji" tasks as it has a wealth of plugins (messaging, irc > notification etc.), and supports "parameterization" of jobs which is > is exactly what you mentioned above. We might take the short route and add something to the mash runs for the time being, longer term getting a plugin that can mark a build as fail, when a test fails would be good. > I'll see if we can get the prototype published soon, it's using jenkins-job-builder > (which btw is now packaged for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1208904 > and should be easily built on C7) This is sort of where I started from initially, having the work just get done and triggered from a jenkins job, Lets see how it works for the that model, we can always just go to this anytime. When we looked at JJB, it seemed limited in what plugins and what things it might be able to do, but its worth a revisit if it helps solve these issues. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From dunlapg at umich.edu Tue Apr 21 12:55:19 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 13:55:19 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150420180614.GA21180@naruto> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar wrote: > I've pretty much decided that 'docker' in virt SIG would only track upstream > sources (no RH patches in it). Don't want this to sound like "I don't care > what anyone says", but docker upstream and many CentOS users want a build > which will only track upstream docker sources. Having 'docker' in virt SIG to > be this build sounds like the way to go. It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-) That sounds like a perfectly reasonable decision. -George From dwalsh at redhat.com Tue Apr 21 13:50:51 2015 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Apr 2015 09:50:51 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> Message-ID: <553655BB.2050709@redhat.com> On 04/21/2015 08:55 AM, George Dunlap wrote: > On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > wrote: >> I've pretty much decided that 'docker' in virt SIG would only track upstream >> sources (no RH patches in it). Don't want this to sound like "I don't care >> what anyone says", but docker upstream and many CentOS users want a build >> which will only track upstream docker sources. Having 'docker' in virt SIG to >> be this build sounds like the way to go. > It sounds like you care what "many CentOS users want", which is hardly > "I don't care what anyone says". :-) > > That sounds like a perfectly reasonable decision. > > -George > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas. Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald. And most importantly customers running on rhel will have a different experience then on Centos. From walters at verbum.org Tue Apr 21 13:58:21 2015 From: walters at verbum.org (Colin Walters) Date: Tue, 21 Apr 2015 09:58:21 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553556DE.2070001@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553556DE.2070001@centos.org> Message-ID: <1429624701.626585.256611225.595E4433@webmail.messagingengine.com> On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote: > Agree. It would be nice to hear what the Atomic SIG folks think about > this though as they're direct consumers. This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve. Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata. # rpm -q docker docker-1.6.0-3.x86_64 (6 patches) or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful. From dunlapg at umich.edu Tue Apr 21 14:16:34 2015 From: dunlapg at umich.edu (George Dunlap) Date: Tue, 21 Apr 2015 15:16:34 +0100 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh wrote: > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything. > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience. Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-) The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over. For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in. -George From mail-lists at karan.org Tue Apr 21 14:37:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 21 Apr 2015 15:37:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5535FC02.3080603@redhat.com> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> Message-ID: <553660A8.9000904@karan.org> On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote: > On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote: >> On 04/14/2015 04:52 PM, Karanbir Singh wrote: >>> Hi, >>> >>> One of the things that the Atomic SIG will attempt to do is build a >>> downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. >>> Most code and info needed for this is now available, and its a good >>> point to think about the build, release process. I've attached a map of >>> what that might look like. Think of it as a proposal. >> >> +1. I think this will serve as the stable build for CentOS Atomic SIG. >> >> Have we decided about the time-line to make this happen? >> > > The reason I am interested in it because I am getting in to one or other > issues while using the test builds of CentOS Atomic hosts and don't > think SIG provides a stable build yet. So I think rebuilding the RHEL > Atomic will give us a stable Atomic host. > the intention is to build this as soon as we can and get the things moving. Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From johnny at centos.org Tue Apr 21 16:05:46 2015 From: johnny at centos.org (Johnny Hughes) Date: Tue, 21 Apr 2015 11:05:46 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553655BB.2050709@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> Message-ID: <5536755A.9020906@centos.org> On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > On 04/21/2015 08:55 AM, George Dunlap wrote: >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar >> wrote: >>> I've pretty much decided that 'docker' in virt SIG would only track upstream >>> sources (no RH patches in it). Don't want this to sound like "I don't care >>> what anyone says", but docker upstream and many CentOS users want a build >>> which will only track upstream docker sources. Having 'docker' in virt SIG to >>> be this build sounds like the way to go. >> It sounds like you care what "many CentOS users want", which is hardly >> "I don't care what anyone says". :-) >> >> That sounds like a perfectly reasonable decision. >> >> -George >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel > I have not chimed in on this yet, but the patches include stuff to make > docker run better on a > systemd based system. Going purely upstream eliminates us from > experimenting and testing > some of our ideas. > > Current patches include fixes for SELinux, patches to allow systemd to > run within a container without > requiring --privileged mode. Handling of multiple registries, Proper > integration into the systemd, MachineCtl, journald. > > And most importantly customers running on rhel will have a different > experience then on Centos. Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Wed Apr 22 09:30:32 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:30:32 +0100 Subject: [CentOS-devel] bugs.centos.org summary posted Message-ID: <55376A38.7090806@karan.org> hi I guess this is more for Jim / Ralph : but is there anyway to get mantis to send out an email nightly, with a list of 'new' bugs reported during the last 24 hrs ? Additional win if we can also get a list of bugs that have had no activity for > 60 days and are not in status: Feedback Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 09:56:28 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 10:56:28 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553107CA.2090709@redhat.com> References: <552CF877.9020005@centos.org> <553107CA.2090709@redhat.com> Message-ID: <5537704C.3060409@karan.org> On 04/17/2015 02:16 PM, Ian McLeod wrote: > https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapshot/rhel-scratch-snapshot > > Prior to the full RPM source drop being available, I'd like to at least > try some initial smoke test tree composes using the SIG content in CBS. > I will attempt to start on this early next week. Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon. With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ? I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ). regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jperrin at centos.org Wed Apr 22 12:06:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 22 Apr 2015 07:06:50 -0500 Subject: [CentOS-devel] bugs.centos.org summary posted In-Reply-To: <55376A38.7090806@karan.org> References: <55376A38.7090806@karan.org> Message-ID: <55378EDA.7000008@centos.org> On 04/22/2015 04:30 AM, Karanbir Singh wrote: > hi > > I guess this is more for Jim / Ralph : but is there anyway to get mantis > to send out an email nightly, with a list of 'new' bugs reported during > the last 24 hrs ? Not that's listed in the documentation that I can see. I'll dig a bit more on this. > Additional win if we can also get a list of bugs that have had no > activity for > 60 days and are not in status: Feedback > This could likely be done via the soap interface, and some scripting. It's not a configurable thing to just send out though. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 22 13:55:56 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 14:55:56 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: Message-ID: <5537A86C.4000706@karan.org> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > This looks promising, do we need some sort of formal proposal to the > CentOS board to get the ball rolling? You will need someone to help with that process, i can do that if you are willing to wait till the first week of May. Another thing i want to throw in, paraphrasing another conversation: We should consider for EL7, building everything (as far as possible) as PIE/RELRO, swapping out dlmalloc in libc for something else (probably jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) and -fwrapv. Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From leamhall at gmail.com Wed Apr 22 14:04:25 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 22 Apr 2015 10:04:25 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh wrote: > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > I'm happy to wait, if we can move forward in decent time. What do you need from us? Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From corman at cormander.com Wed Apr 22 14:06:13 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 22 Apr 2015 08:06:13 -0600 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537A86C.4000706@karan.org> References: <5537A86C.4000706@karan.org> Message-ID: > On Apr 22, 2015, at 7:55 AM, Karanbir Singh wrote: > >> On 04/13/2015 03:10 PM, Earl A Ramirez wrote: >> >> This looks promising, do we need some sort of formal proposal to the >> CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > Another thing i want to throw in, paraphrasing another conversation: > > We should consider for EL7, building everything (as far as possible) as > PIE/RELRO, swapping out dlmalloc in libc for something else (probably > jemalloc). Perhaps also use -finit-local-vars (especially in the kernel) > and -fwrapv. > > Thoughts ? > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? From hhorak at redhat.com Wed Apr 22 14:21:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Apr 2015 16:21:38 +0200 Subject: [CentOS-devel] Probably no CentOS SCLo SIG sync-up meeting (2015-04-22) Message-ID: <5537AE72.3090502@redhat.com> Unfortunately, I've just learnt can't make it for today's 3 UTC sync-up meeting, so unless anybody else is volunteering to chair it after such a short notice, we can skip and talk on IRC/ML. Just for getting some update, we've just had an earlier talk about tags for SCL, cleared up few things and agreed to continue with further discussions about tags/branches on IRC. Honza From mail-lists at karan.org Wed Apr 22 14:28:18 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:28:18 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B002.9020502@karan.org> On 04/22/2015 03:04 PM, leam hall wrote: > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > wrote: > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > This looks promising, do we need some sort of formal proposal to the > > CentOS board to get the ball rolling? > > > You will need someone to help with that process, i can do that if you > are willing to wait till the first week of May. > > > I'm happy to wait, if we can move forward in decent time. What do you > need from us? We will need to workout a clear picture on what we intend to deliver, what the wider goal is going to be, what resources we need and who's going to be in and helping play the game ( ideally, also a few things around how we can promote this effort etc ). Maybe take a look at the already onboarding/onboarded SIG's proposals eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and http://wiki.centos.org/SpecialInterestGroup/Cloud http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where the proposal should end up at. If you want, ask for write perms on that url in the centos-docs list and feel free to start working on a draft if you like :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Wed Apr 22 14:30:57 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Apr 2015 15:30:57 +0100 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: References: <5537A86C.4000706@karan.org> Message-ID: <5537B0A1.1060308@karan.org> On 04/22/2015 03:06 PM, Corey Henderson wrote: > > Is this for stock EL7 or would there be a whole new slew of rpm packages in a separate repo with these compile options that need to be maintained? yeah, seperate repo :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From byrnejb at harte-lyne.ca Wed Apr 22 14:39:45 2015 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Wed, 22 Apr 2015 10:39:45 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening Message-ID: Earl A Ramirez earlaramirez at gmail.com Mon Apr 13 11:24:27 UTC 2015 > I am interested in starting a new SIG or merging with the > ?Hardening? SIG, I didn?t find sufficient information about > the hardening SIG. I have been on the mailing list for some > years and I have noticed a number of concerns with regards > to security, e.g. the default sshd_config, gnome user list > and more. I will participate; given that the SIG is established. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From lsm5 at fedoraproject.org Wed Apr 22 16:07:12 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Wed, 22 Apr 2015 11:07:12 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <20150422160712.GA19305@naruto.redhat.com> On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote: > On 04/21/2015 08:50 AM, Daniel J Walsh wrote: > > > > > > On 04/21/2015 08:55 AM, George Dunlap wrote: > >> On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar > >> wrote: > >>> I've pretty much decided that 'docker' in virt SIG would only track upstream > >>> sources (no RH patches in it). Don't want this to sound like "I don't care > >>> what anyone says", but docker upstream and many CentOS users want a build > >>> which will only track upstream docker sources. Having 'docker' in virt SIG to > >>> be this build sounds like the way to go. > >> It sounds like you care what "many CentOS users want", which is hardly > >> "I don't care what anyone says". :-) > >> > >> That sounds like a perfectly reasonable decision. > >> > >> -George > >> _______________________________________________ > >> CentOS-devel mailing list > >> CentOS-devel at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-devel > > I have not chimed in on this yet, but the patches include stuff to make > > docker run better on a > > systemd based system. Going purely upstream eliminates us from > > experimenting and testing > > some of our ideas. > > > > Current patches include fixes for SELinux, patches to allow systemd to > > run within a container without > > requiring --privileged mode. Handling of multiple registries, Proper > > integration into the systemd, MachineCtl, journald. > > > > And most importantly customers running on rhel will have a different > > experience then on Centos. > > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources) I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier. We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem. What say? > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From earlaramirez at gmail.com Wed Apr 22 16:59:16 2015 From: earlaramirez at gmail.com (Earl A Ramirez) Date: Wed, 22 Apr 2015 12:59:16 -0400 Subject: [CentOS-devel] CentOS - SIG Hardening In-Reply-To: <5537B002.9020502@karan.org> References: <5537A86C.4000706@karan.org> <5537B002.9020502@karan.org> Message-ID: <1429721956.31607.17.camel@kvmhost> On Wed, 2015-04-22 at 15:28 +0100, Karanbir Singh wrote: > On 04/22/2015 03:04 PM, leam hall wrote: > > On Wed, Apr 22, 2015 at 9:55 AM, Karanbir Singh > > wrote: > > > > On 04/13/2015 03:10 PM, Earl A Ramirez wrote: > > > > > > This looks promising, do we need some sort of formal proposal to the > > > CentOS board to get the ball rolling? > > > > > > You will need someone to help with that process, i can do that if you > > are willing to wait till the first week of May. > > > > > > I'm happy to wait, if we can move forward in decent time. What do you > > need from us? > > We will need to workout a clear picture on what we intend to deliver, > what the wider goal is going to be, what resources we need and who's > going to be in and helping play the game ( ideally, also a few things > around how we can promote this effort etc ). > > Maybe take a look at the already onboarding/onboarded SIG's proposals > eg: http://wiki.centos.org/SpecialInterestGroup/Virtualization and > http://wiki.centos.org/SpecialInterestGroup/Cloud > > http://wiki.centos.org/SpecialInterestGroup/Hardending is likely where > the proposal should end up at. If you want, ask for write perms on that > url in the centos-docs list and feel free to start working on a draft if > you like :) > I will start working on the draft in the mean time and when the clear picture worked out the wiki will be updated. -- Earl A Ramirez From mail-lists at karan.org Thu Apr 23 09:11:22 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 23 Apr 2015 10:11:22 +0100 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <553660A8.9000904@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> Message-ID: <5538B73A.9010308@karan.org> Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play, - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From lmohanty at redhat.com Thu Apr 23 09:14:54 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 23 Apr 2015 14:44:54 +0530 Subject: [CentOS-devel] Building a downstream CentOS Atomic Host In-Reply-To: <5538B73A.9010308@karan.org> References: <552CF877.9020005@centos.org> <5535EE87.6060009@redhat.com> <5535FC02.3080603@redhat.com> <553660A8.9000904@karan.org> <5538B73A.9010308@karan.org> Message-ID: <5538B80E.8000100@redhat.com> On 04/23/2015 02:41 PM, Karanbir Singh wrote: > Quick update on this, we have the rpm stack done once - its going to > need debranding, but we can start on that once we have the other things > sorted out. Ian's done some work last night to get the images and the > anaconda side of things sorted out, but that work is not finished yet. > We hope to keep working on that through the day today and see if we can > get to a testable set of components by the close of play, > > - KB > Awesome news!. I am looking forward to use the 1st cut. -Lala From johnny at centos.org Fri Apr 24 13:26:12 2015 From: johnny at centos.org (Johnny Hughes) Date: Fri, 24 Apr 2015 08:26:12 -0500 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> Message-ID: <553A4474.7030701@centos.org> On 04/14/2015 09:58 AM, Colin Walters wrote: > On Tue, Apr 14, 2015, at 07:54 AM, Johnny Hughes wrote: >> We are looking at the possibility of providing signed repomd.xml.asc >> files for all CentOS controlled repos for CentOS-6 and CentOS-7. > > For anyone who hasn't seen it, the TL;DR from: > http://theupdateframework.com/ > is "GPG sign your repo metadata", so I'm glad we're doing this =) > >> For CentOS-7: >> repo_gpgcheck=1 >> baseurl=http://dev.centos.org/centos/7/updates/x86_64/ > > I tested this via "docker run --rm -ti centos bash", then editing > the /etc/yum.repos.d file, and it worked. I saw in strace that > yum was at least downloading and trying to verify the signature. > >> One thing we would like to figure out (and then tes)t is the ability to >> somehow get this key to be added automatically via a kick start so that >> one can use signed metadata for unattended installs. > > GPG signatures and RPM and Anaconda has always been pretty broken, sadly: > https://bugzilla.redhat.com/show_bug.cgi?id=998 > > (That's only "fixed" by not using GPG, but relying on TLS, which is very > much not the same thing. It gets closer if you use "pinned TLS" i.e. > pre-specify a particular CA root instead of relying on ca-certificates) > >> Without testing and feedback, and possibly key auto import capability, >> this proposal will likely go nowhere .. so if this is a feature that you >> want, please test and provide feedback and help us find a solution for >> auto import of the yum key. > > Even if Anaconda doesn't support it, it's still possible for downstream > users to manually enable in the repo file post installation. Probably > very few will, but at some point maybe Anaconda will learn GPG... No real feedback with this except for Colin .. my understanding is lots of people want this, where is the testing? If we don't get any more feed back or help in adjusting this to auto-import the key, then we will just start doing it as is in 2 weeks. Now is the time to test and get your fixes in ! Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Fri Apr 24 13:33:26 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 24 Apr 2015 14:33:26 +0100 Subject: [CentOS-devel] Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing) In-Reply-To: <553A4474.7030701@centos.org> References: <552CFFFB.60208@centos.org> <1429023538.3377200.253598421.0CBA1562@webmail.messagingengine.com> <553A4474.7030701@centos.org> Message-ID: <553A4626.3080708@karan.org> On 04/24/2015 02:26 PM, Johnny Hughes wrote: > > No real feedback with this except for Colin .. my understanding is lots > of people want this, where is the testing? > Since the change will not impact existing installs, and people have the opportunity to opt into getting secure content, verifyable end to end - I'd say lets go ahead and make this change. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From brian at bstinson.com Mon Apr 27 01:10:24 2015 From: brian at bstinson.com (Brian Stinson) Date: Sun, 26 Apr 2015 20:10:24 -0500 Subject: [CentOS-devel] CBS/Infra Meeting 27-Apr-2015 14:00 UTC Message-ID: <20150427010948.GM25495@ender.bstinson.int> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Central Authentication #info Topic: Open Floor See you there! Brian - -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVPYx/AAoJEIMGvNKzCweMUAcP/3XWzoMuE0YCHJZE1RnOmPxq LM8IOtiWqoRkH2kpvmxsaNiOdW1xuEC/oMIwzCzVdYIGOeb4m2rGO6fJqNpor3SE M8JizlzX/siBHpDvJrNfElbKUbwdzqxdOJQYbNo1jUVECimGtko4Vmhgb3fYXJr0 xDbqU/qqVBiVgZWHFcjBabK7GUE/JV61JLxgt7Ttnt4Uc+q+N8bFf533JjgEhRz7 BseYRH8s6EDGpqwunBmoTDSj64lEP2r2ceLmSC+YiOTeCP9GfP0u9cWOlpx8szRs jqVZ1w7b/MSGN9FJLvR3eGA4Dfh0fzuI5L8qf/KutlGc8uA+/q5Xv4Jd/twkGZli iHtfltwkJUXxL8TcwEe05D6doImjnvnJHhVdtfk8L/PXap9/0KJmfiMm5YEdaX9q 6Fofm+HFs9tOvjDV7h899yIIqtoF0XbDftKTQAVPM0bQZalgaswT86hBlk357DDq ffMdKrltdm4nWAhsCdtUmhGVUD7B+4kK7Yg86VFp89ghqDt1Rj6k4JneVd27wE7M CS5O3PWojKlgZ1MdQSAB0bgI9IpsvJ1p4XEO7TVFZqx9rocrNDvqTa1MHUsE9Tu5 MR9m/4GLl2BKjHUWfCd4MO0paODux0KfDcGUNSpecf2BN/A/hDJ+djNNx9SIKUcy PD50QMjYZcqhvO+hsdtr =ri6T -----END PGP SIGNATURE----- From msuchy at redhat.com Mon Apr 27 08:43:01 2015 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Apr 2015 10:43:01 +0200 Subject: [CentOS-devel] Upstream for dist-git [RFC] Message-ID: <553DF695.2040701@redhat.com> Hi, Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: https://github.com/release-engineering/dist-git This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf I know that CentOS is one of the user of dist-git. It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package - it passed through package review in Fedora just now. Future plans: 1) Listen to your initial feedback and do alternations according to your feedback. 2) Change Fedora dist-git server to use this package. .... 5) Enjoy the benefits of common upstream. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From stephan.schultchen at gmail.com Mon Apr 27 09:44:37 2015 From: stephan.schultchen at gmail.com (stephan schultchen) Date: Mon, 27 Apr 2015 11:44:37 +0200 Subject: [CentOS-devel] confd spec file Message-ID: Hey CentOS fellows, i have created confd spec for centos 7, that is more or less based on the etcd spec file found on cbs ( http://cbs.centos.org/koji/packageinfo?packageID=102), that i would like to contribute. I guess it would fit nicely to the SIGs that etcd is part off. What are the steps to take to get the spec reviewed and added to these SIGs? Cheers, schlitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at bstinson.com Mon Apr 27 15:02:53 2015 From: brian at bstinson.com (Brian Stinson) Date: Mon, 27 Apr 2015 10:02:53 -0500 Subject: [CentOS-devel] Upstream for dist-git [RFC] In-Reply-To: <553DF695.2040701@redhat.com> References: <553DF695.2040701@redhat.com> Message-ID: <20150427150253.GN25495@ender.bstinson.int> On Apr 27 10:43, Miroslav Such? wrote: > Hi, > Adam Samal?k took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is > Fedora specific and with cooperation of Dan Mach and Palo Babincak he created upstream for dist-git: > > https://github.com/release-engineering/dist-git > > This is Fedora version of dist-git and already have passed first round of comments in fedora-infra. > > The changes from ansible.git version are described here: > https://github.com/release-engineering/dist-git/blob/master/changes.txt > and he extracted some code to be configuration driven: > https://github.com/release-engineering/dist-git/blob/master/configs/dist-git/dist-git.conf > > I know that CentOS is one of the user of dist-git. > It would be nice if you can contribute your changes to dist-git to this upstream and eventually use dist-git rpm package > - it passed through package review in Fedora just now. > > Future plans: > 1) Listen to your initial feedback and do alternations according to your feedback. > 2) Change Fedora dist-git server to use this package. > .... > 5) Enjoy the benefits of common upstream. > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel This is great! I'll look to see if any of our work is upstreamable. Our "dist-git" is similar in idea to other implementations, but we have a few differences (most notably the package layout in git itself, and the directory structure for the lookaside). Thanks for the link! Brian -- Brian Stinson brian at bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk From lmohanty at redhat.com Mon Apr 27 15:03:36 2015 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 27 Apr 2015 20:33:36 +0530 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools Message-ID: <553E4FC8.7050006@redhat.com> Hi All, This is my first attempt to create a CentOS7 Vagrant box using CBS (CentOS build system). The idea is to create a Vagrant image which can used as development box for packaging applications in CentOS Linux containers. This Vagrant box will also have required Linux container tools (e.g. atomic command line, k8ns, etcd). If you want to see any tool in this Vagrant box, let me know. The present build includes Docker. The scratch build is at http://cbs.centos.org/koji/taskinfo?taskID=10480 Here are steps how you can quickly test the image. I am looking for feedback on the same. More detailed information is present in the github project [1] . I have used Fedora21 to set-up Vagrant with libvirt/KVM backend. There is a effort going on to provide Vagrant packages on CentOS too as now it is not available through CentOS core. #Setting up Vagrant on Fedora 21 $yum/dnf install -y vagrant-libvirt vagrant #Running the Vagrant box with Vagrant and libvirt I have also uploaded the images in https://atlas.hashicorp.com/lalatendum/boxes/centos7-docker Step-1 : Initialising a new Vagrant environment by creating a Vagrantfile vagrant init lalatendum/centos7-docker Step-2 : To start the vagrant image and ssh in to it, please run following command vagrant up vagrant ssh vagrant ssh should take you inside of the Vagrant box #To destroy the Vagrant box vagrant destroy #Running docker inside the Vagrant box Inside the vagrant box, you should be run docker containers Example: (following commands should be run inside the Vagrant box) docker pull centos docker run -t -i centos /bin/bash [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box Thanks, Lala From t004 at kbocek.com Mon Apr 27 15:24:59 2015 From: t004 at kbocek.com (Kirk Bocek) Date: Mon, 27 Apr 2015 08:24:59 -0700 Subject: [CentOS-devel] Possible 7.1 Install Bug Message-ID: <553E54CB.6050504@kbocek.com> Hope I'm not spamming the devs here, but I've got what really feels like a bug with the installer here. I've got a new SuperMicro X10-DRI motherboard with a 3Ware 9750 raid card that hangs during installation of 7.1. If I pull the card, the installer proceeds normally. CentOS 6.6 installs without error on this hardware so I know the hardware is working. I've documented this here: https://www.centos.org/forums/viewtopic.php?f=49&t=52231 If there is more information I can provide, please let me know. Kirk Bocek From jzb at redhat.com Mon Apr 27 16:54:09 2015 From: jzb at redhat.com (Joe Brockmeier) Date: Mon, 27 Apr 2015 12:54:09 -0400 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <5536755A.9020906@centos.org> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> Message-ID: <553E69B1.3060204@redhat.com> On 04/21/2015 12:05 PM, Johnny Hughes wrote: > Which is why I thought we want RH type behavior (ie patches) on both our > fast moving and RHEL Atomic Host downstream branches for C7. We need > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > IMHO, we want newer docker and RH patches. I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible. Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb at redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail-lists at karan.org Mon Apr 27 16:26:15 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 27 Apr 2015 17:26:15 +0100 Subject: [CentOS-devel] Fixing up Xfce for CentOS 7 In-Reply-To: References: Message-ID: <553E6327.7@karan.org> On 12/04/15 23:36, Stephen John Smoogen wrote: > Hey guys. I realize it has been a month, and I forgot to send out that > there is a centos-xfce channel I have been sitting in if people are on > IRC and want to work out what is needed for finishing up 4.12 for CentOS. > given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From mail-lists at karan.org Tue Apr 28 09:26:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 28 Apr 2015 10:26:04 +0100 Subject: [CentOS-devel] CentOS7 Vagrant box with container runtime and tools In-Reply-To: <553E4FC8.7050006@redhat.com> References: <553E4FC8.7050006@redhat.com> Message-ID: <553F522C.5030703@karan.org> On 27/04/15 16:03, Lalatendu Mohanty wrote: > > #Setting up Vagrant on Fedora 21 > > $yum/dnf install -y vagrant-libvirt vagrant > You can get vagrant setup on CentOS6/7 using the coprs repo here : https://copr.fedoraproject.org/coprs/jstribny/vagrant1/ - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From rbowen at redhat.com Tue Apr 28 14:25:36 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Apr 2015 10:25:36 -0400 Subject: [CentOS-devel] Fwd: RDO (Cloud SIG) meetup at OpenStack Summit In-Reply-To: <553EA2E7.9000002@redhat.com> References: <553EA2E7.9000002@redhat.com> Message-ID: <553F9860.4090107@redhat.com> FYI, for those of you who care about the Cloud SIG, and will be at the OpenStack Summit in Vancouver next month. -------- Forwarded Message -------- Subject: [Rdo-list] RDO meetup at OpenStack Summit Date: Mon, 27 Apr 2015 16:58:15 -0400 From: Rich Bowen To: rdo-list at redhat.com I am still working on getting a room for an RDO meetup at OpenStack Summit, but I wanted to go ahead and get this out there to start collecting agenda of what people want to discuss and/or work on at that meetup. I've put up an etherpad at https://etherpad.openstack.org/p/RDO_Vancouver where we can start collect those ideas, and where I will post times/locations once I get them. Thanks -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From fredex at fcshome.stoneham.ma.us Tue Apr 28 15:32:05 2015 From: fredex at fcshome.stoneham.ma.us (Fred Smith) Date: Tue, 28 Apr 2015 11:32:05 -0400 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 Message-ID: <20150428153205.GA21846@fcshome.stoneham.ma.us> Hi all! I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi threaded program. When I run the program I get a lot of terse output from the thread sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. I'm trying to find the debuginfo for those libraries with the hope that will allow human-readable info in that output. But so far I've not found anything that looks like the right stuff. Suggestions, anyone? Thanks! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) ----------------------------- From lsm5 at fedoraproject.org Tue Apr 28 17:27:23 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Tue, 28 Apr 2015 12:27:23 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <553E69B1.3060204@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <553E69B1.3060204@redhat.com> Message-ID: <20150428172720.GC1094@naruto> On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote: > On 04/21/2015 12:05 PM, Johnny Hughes wrote: > > Which is why I thought we want RH type behavior (ie patches) on both our > > fast moving and RHEL Atomic Host downstream branches for C7. We need > > stuff that works correctly with SELINUX and systemd on CentOS-7. So, > > IMHO, we want newer docker and RH patches. > > I certainly do - it doesn't make sense to me to have a faster moving > Atomic missing the RHT patches and then put them into the rebuild. Let's > be consistent as much as possible. > > Now, what the virt-SIG does is really up to them, maybe they intend to > always ship vanilla upstream -- which is fine, Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome). > but IMO it would make > more sense to have a consistent story as much as possible. Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too. > > Best, > > jzb > > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > jzb at redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jperrin at centos.org Tue Apr 28 19:18:47 2015 From: jperrin at centos.org (Jim Perrin) Date: Tue, 28 Apr 2015 14:18:47 -0500 Subject: [CentOS-devel] Using gcc -fsanitize=thread on C7 In-Reply-To: <20150428153205.GA21846@fcshome.stoneham.ma.us> References: <20150428153205.GA21846@fcshome.stoneham.ma.us> Message-ID: <553FDD17.3070701@centos.org> On 04/28/2015 10:32 AM, Fred Smith wrote: > Hi all! > > I'm attempting to use the thread sanitizer (in gcc 4.8.x) on a multi > threaded program. > > When I run the program I get a lot of terse output from the thread > sanitizer, much of which refers to hits inside libtsan, libc, and libcrypto. > > I'm trying to find the debuginfo for those libraries with the hope that > will allow human-readable info in that output. But so far I've not found > anything that looks like the right stuff. Use yum to identify the package which contains the libraries you want debuginfo for. Then 'debuginfo-install ' Alternatively, you can browse debuginfo.centos.org for the packages manually. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From mail-lists at karan.org Wed Apr 29 08:57:07 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 29 Apr 2015 09:57:07 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings Message-ID: <55409CE3.6080300@karan.org> hi, All the GSoC stuff going through should map to a SIG ( or in some cases multiple ones ) - it would be great to see the GSoC students come along and interface with the SIG's, and maybe do updates on progress at the SIG Meetings. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From louis at kragniz.eu Wed Apr 29 10:12:47 2015 From: louis at kragniz.eu (Louis Taylor) Date: Wed, 29 Apr 2015 11:12:47 +0100 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <55409CE3.6080300@karan.org> References: <55409CE3.6080300@karan.org> Message-ID: <20150429101246.GA6874@gmail.com> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: > All the GSoC stuff going through should map to a SIG ( or in some cases > multiple ones ) - it would be great to see the GSoC students come along > and interface with the SIG's, and maybe do updates on progress at the > SIG Meetings. Hi, This sounds like a great idea. My project (kernel livepatching) seems to fall somewhere under the new hardening SIG, but that is still in the process of being set up. Is delivering kernel patch modules within the scope of this SIG? Cheers, Louis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From corman at cormander.com Wed Apr 29 13:42:36 2015 From: corman at cormander.com (Corey Henderson) Date: Wed, 29 Apr 2015 07:42:36 -0600 Subject: [CentOS-devel] GSoC projects and SIG meetings In-Reply-To: <20150429101246.GA6874@gmail.com> References: <55409CE3.6080300@karan.org> <20150429101246.GA6874@gmail.com> Message-ID: > On Apr 29, 2015, at 4:12 AM, Louis Taylor wrote: > >> On Wed, Apr 29, 2015 at 09:57:07AM +0100, Karanbir Singh wrote: >> All the GSoC stuff going through should map to a SIG ( or in some cases >> multiple ones ) - it would be great to see the GSoC students come along >> and interface with the SIG's, and maybe do updates on progress at the >> SIG Meetings. > > Hi, > > This sounds like a great idea. My project (kernel livepatching) seems to fall > somewhere under the new hardening SIG, but that is still in the process of > being set up. Is delivering kernel patch modules within the scope of this SIG? > > Cheers, > Louis > It does fall into the scope of hardening but is also has enough scope of its own to stand alone. So keep an ear out (so will I) and try to get involved, but don't let it hold you up. If you hit any road blocks just loop me and KB in. -- Corey From rbowen at redhat.com Wed Apr 29 15:10:06 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 29 Apr 2015 11:10:06 -0400 Subject: [CentOS-devel] [Cloud SIG] RDO/OpenStack test day, May 5th, 6th Message-ID: <5540F44E.5090501@redhat.com> For those that are interested in the progress of the RDO OpenStack packaging effort, we'll be having an RDO test day May 5th and 6th (48 hours, so that folks from every timezone have a chance to participate at some point). We'll be testing the RDO packages of the Kilo release. We'd appreciate it if you can find an hour or two some time in that window to come help us out. Links: Main info: https://www.rdoproject.org/RDO_test_day_Kilo Test scenarios: https://www.rdoproject.org/RDO_test_day_Kilo_RC_milestone_test_cases Live discussion on #rdo (Freenode IRC). Async discussion on rdo-list http://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From leamhall at gmail.com Wed Apr 29 15:17:41 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:17:41 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals Message-ID: My personal project goal is to work on scripts and Puppet content to meet STIG requirements. I'm not really talented enough to putz around with the kernel stuff but don't object if others do. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Wed Apr 29 15:28:15 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2015 09:28:15 -0600 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On 29 April 2015 at 09:17, leam hall wrote: > My personal project goal is to work on scripts and Puppet content to meet > STIG requirements. I'm not really talented enough to putz around with the > kernel stuff but don't object if others do. > > What kind of scripts are you looking for and need? There are several out there for STIG requirements so I was wondering if they could be used. > Leam > > -- > Mind on a Mission > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Wed Apr 29 15:49:26 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 11:49:26 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen wrote: > > On 29 April 2015 at 09:17, leam hall wrote: > >> My personal project goal is to work on scripts and Puppet content to meet >> STIG requirements. I'm not really talented enough to putz around with the >> kernel stuff but don't object if others do. >> >> > What kind of scripts are you looking for and need? There are several out > there for STIG requirements so I was wondering if they could be used. > I've used Aqueduct, and wrote some of them. Working on implementing a newer project and focusing on Puppet code as that's what I'm need to learn most. Still getting a handle on what all is out there. Leam -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 18:01:46 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 13:01:46 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: Message-ID: <55411C8A.2040109@centos.org> On 04/29/2015 10:49 AM, leam hall wrote: > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > wrote: > >> >> On 29 April 2015 at 09:17, leam hall wrote: >> >>> My personal project goal is to work on scripts and Puppet content to meet >>> STIG requirements. I'm not really talented enough to putz around with the >>> kernel stuff but don't object if others do. >>> >>> >> What kind of scripts are you looking for and need? There are several out >> there for STIG requirements so I was wondering if they could be used. >> > > I've used Aqueduct, and wrote some of them. Working on implementing a newer > project and focusing on Puppet code as that's what I'm need to learn most. > Still getting a handle on what all is out there. It might be easier to look at the tooling mentioned here https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi for pointing it out) and assessing the level of effort needed to make that work for CentOS. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 18:28:36 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 14:28:36 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55411C8A.2040109@centos.org> References: <55411C8A.2040109@centos.org> Message-ID: Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. That's been one of my motivators. On Wed, Apr 29, 2015 at 2:01 PM, Jim Perrin wrote: > > > On 04/29/2015 10:49 AM, leam hall wrote: > > On Wed, Apr 29, 2015 at 11:28 AM, Stephen John Smoogen > > > wrote: > > > >> > >> On 29 April 2015 at 09:17, leam hall wrote: > >> > >>> My personal project goal is to work on scripts and Puppet content to > meet > >>> STIG requirements. I'm not really talented enough to putz around with > the > >>> kernel stuff but don't object if others do. > >>> > >>> > >> What kind of scripts are you looking for and need? There are several out > >> there for STIG requirements so I was wondering if they could be used. > >> > > > > I've used Aqueduct, and wrote some of them. Working on implementing a > newer > > project and focusing on Puppet code as that's what I'm need to learn > most. > > Still getting a handle on what all is out there. > > > It might be easier to look at the tooling mentioned here > https://access.redhat.com/comment/913583#comment-913583 (thanks Akemi > for pointing it out) and assessing the level of effort needed to make > that work for CentOS. > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Apr 29 19:05:22 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:05:22 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> Message-ID: <55412B72.8050008@centos.org> On 04/29/2015 01:28 PM, leam hall wrote: > Red Hat seems to not be putting a lot of work into RHEL 5 STIG compliance. > That's been one of my motivators. EL5 dies in a year and a half or so, and has several outstanding (minor to medium) cve's presently. I'm absolutely fine with ignoring it until it goes away as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:06:35 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:06:35 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55412B72.8050008@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: There are a lot of RHEL 5 boxes in production. Any solution that doesn't take it into account isn't a solution for me. On Wed, Apr 29, 2015 at 3:05 PM, Jim Perrin wrote: > > > On 04/29/2015 01:28 PM, leam hall wrote: > > Red Hat seems to not be putting a lot of work into RHEL 5 STIG > compliance. > > That's been one of my motivators. > > > EL5 dies in a year and a half or so, and has several outstanding (minor > to medium) cve's presently. I'm absolutely fine with ignoring it until > it goes away as well. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Wed Apr 29 19:30:44 2015 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Apr 2015 15:30:44 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <20150429193044.GA20455@mattdm.org> On Wed, Apr 29, 2015 at 03:06:35PM -0400, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. RHEL5 _extended_ life cycle support goes into 2020. -- Matthew Miller Fedora Project Leader From jperrin at centos.org Wed Apr 29 19:40:02 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 29 Apr 2015 14:40:02 -0500 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> Message-ID: <55413392.5060307@centos.org> On 04/29/2015 02:06 PM, leam hall wrote: > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > take it into account isn't a solution for me. Oh I know there are tons of el5 boxen. From the project side we'll continue to provide for them. From a personal side, I'm just not interested in el5 anymore. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From leamhall at gmail.com Wed Apr 29 19:46:02 2015 From: leamhall at gmail.com (leam hall) Date: Wed, 29 Apr 2015 15:46:02 -0400 Subject: [CentOS-devel] [SIG Harden] Personal goals In-Reply-To: <55413392.5060307@centos.org> References: <55411C8A.2040109@centos.org> <55412B72.8050008@centos.org> <55413392.5060307@centos.org> Message-ID: On Wed, Apr 29, 2015 at 3:40 PM, Jim Perrin wrote: > > On 04/29/2015 02:06 PM, leam hall wrote: > > There are a lot of RHEL 5 boxes in production. Any solution that doesn't > > take it into account isn't a solution for me. > > > Oh I know there are tons of el5 boxen. From the project side we'll > continue to provide for them. From a personal side, I'm just not > interested in el5 anymore. > Understood. I'm not against RHEL 7 stuff but don't use it personally. ;) The part that grates on me most is that RH isn't hyped about supporting RHEL 5 much. There are large, paying, installs that could use SCAP, but can't. Thus their SCAP tool is kinda wimpy. -- Mind on a Mission -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbrooks at redhat.com Wed Apr 29 23:04:52 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:04:52 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150422160712.GA19305@naruto.redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> Message-ID: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 22, 2015 9:07:12 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > ... > > Given the conflicting requirements, would it make sense to have appropriate > tags such that, a particular 'docker' (something with RH patches) build only > makes it to atomic, while another 'docker' build makes it to virt7-release > (only upstream docker sources) +1 I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own. Jason From jbrooks at redhat.com Wed Apr 29 23:16:30 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Wed, 29 Apr 2015 19:16:30 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> Message-ID: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Brooks" > To: "The CentOS developers mailing list." > Sent: Wednesday, April 29, 2015 4:04:52 PM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ----- Original Message ----- > > From: "Lokesh Mandvekar" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > ... > > > > Given the conflicting requirements, would it make sense to have appropriate > > tags such that, a particular 'docker' (something with RH patches) build > > only > > makes it to atomic, while another 'docker' build makes it to virt7-release > > (only upstream docker sources) > > +1 > > I think it makes sense for everything atomic needs to live in atomic7, > and if atomic wants the same version as virt has, great, if not, atomic > could have its own. I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts... > > Jason > From lsm5 at fedoraproject.org Thu Apr 30 13:37:58 2015 From: lsm5 at fedoraproject.org (Lokesh Mandvekar) Date: Thu, 30 Apr 2015 08:37:58 -0500 Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> References: <20150416205220.GA31303@naruto> <20150420180614.GA21180@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> Message-ID: <20150430133758.GA3417@naruto> On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > ----- Original Message ----- > > From: "Jason Brooks" > > To: "The CentOS developers mailing list." > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > ----- Original Message ----- > > > From: "Lokesh Mandvekar" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > ... > > > > > > Given the conflicting requirements, would it make sense to have appropriate > > > tags such that, a particular 'docker' (something with RH patches) build > > > only > > > makes it to atomic, while another 'docker' build makes it to virt7-release > > > (only upstream docker sources) > > > > +1 > > > > I think it makes sense for everything atomic needs to live in atomic7, > > and if atomic wants the same version as virt has, great, if not, atomic > > could have its own. > > I just tried a tree compose w/ docker-master, but it Provides > docker-io, not docker, so yum's trying to pull in plain "docker" > as well, which conflicts... Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps?? > > > > > Jason > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jbrooks at redhat.com Thu Apr 30 15:17:08 2015 From: jbrooks at redhat.com (Jason Brooks) Date: Thu, 30 Apr 2015 11:17:08 -0400 (EDT) Subject: [CentOS-devel] RH patches v/s vanilla docker in CentOS In-Reply-To: <20150430133758.GA3417@naruto> References: <20150416205220.GA31303@naruto> <553655BB.2050709@redhat.com> <5536755A.9020906@centos.org> <20150422160712.GA19305@naruto.redhat.com> <1420368128.10743042.1430348692400.JavaMail.zimbra@redhat.com> <967868143.10749025.1430349390758.JavaMail.zimbra@redhat.com> <20150430133758.GA3417@naruto> Message-ID: <1801361810.11421467.1430407028362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lokesh Mandvekar" > To: "The CentOS developers mailing list." > Sent: Thursday, April 30, 2015 6:37:58 AM > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote: > > > > > > ----- Original Message ----- > > > From: "Jason Brooks" > > > To: "The CentOS developers mailing list." > > > Sent: Wednesday, April 29, 2015 4:04:52 PM > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lokesh Mandvekar" > > > > To: "The CentOS developers mailing list." > > > > Sent: Wednesday, April 22, 2015 9:07:12 AM > > > > Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS > > > > > > > > > > ... > > > > > > > > Given the conflicting requirements, would it make sense to have > > > > appropriate > > > > tags such that, a particular 'docker' (something with RH patches) build > > > > only > > > > makes it to atomic, while another 'docker' build makes it to > > > > virt7-release > > > > (only upstream docker sources) > > > > > > +1 > > > > > > I think it makes sense for everything atomic needs to live in atomic7, > > > and if atomic wants the same version as virt has, great, if not, atomic > > > could have its own. > > > > I just tried a tree compose w/ docker-master, but it Provides > > docker-io, not docker, so yum's trying to pull in plain "docker" > > as well, which conflicts... > > Ah ok, I can update it to 'Provides: docker' as well. But would that help > solve > the conflict or would it still get confused between 'docker' and > 'docker-master'. Maybe, docker-master deserves to be in a separate tag, > virt7-nightly perhaps?? It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing. Jason > > > > > > > > > Jason > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > -- > Lokesh > Freenode, OFTC: lsm5 > GPG: 0xC7C3A0DD > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel >