Hi
I noticed my ppc64 builds failing today. Going through the build logs, I noticed
that yum pulled in a lot of ppc packages for no apparent reason.
Blacklisting *.ppc works around this issue, but this was not necessary yesterday.
Looking at http://mirror.centos.org/altarch/7/os/ppc64/Packages/ I notice a lot
of ppc packages in there. I don't remember seeing them before.
Is this an error, or was it done on purpose?
Mihai
Hello,
It's time for our weekly PaaS SIG sync-up meeting
Time: 1700 UTC - Wedensdays (date -d "1700 UTC")
Date: Today Wedensday, 15 November 2017
Where: IRC- Freenode - #centos-devel
Agenda:
- OpenShift Current Status
-- rpms
-- Automated rpm building and Automated testing
-- Multi-arch
-- Documentation
-- Images and Image building
-- minishift / kompose / kedge
- Open Floor
Minutes from last meeting:
https://www.centos.org/minutes/2017/November/centos-devel.2017-11-08-17.04.…
Here are some notes taken from the CERN pre-dojo meeting from last week :
<paste>
Allow SIGs to have separate accounts for build bots
- separate user accounts from "bot" accounts for security reasons
- [proposal] have an email alias (not list) per sig for the bots, like
sig-<bla>@centos.org pointing to the SIG's chair
- [proposal] SIG chair must request or approve email alias requests/
ACO account creation sent to CentOS Board chairman
</paste>
So, (as also discussed yesterday in the CBS meeting -
https://www.centos.org/minutes/2017/October/centos-devel.2017-10-23-14.01.l…)
The proposal would be to create a @centosproject.org (or @centos.org)
email alias, that would go to SIG chair, and that would be used to
create an account on https://accounts.centos.org
While we can manually generate x509 cert with longer validity period, we
discussed the fact that using centos-cert just takes 2 seconds every 6
months, so SIG members who were present didn't find it a real issue.
(email notifications go to SIG chair - and/or other members ? - in
advance so easy to follow)
That's probably the workflow people use already anyway, while Brian
confirmed that longer-term a proper credentials store would be on the
roadmap, but soon.
--
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
The CentOS Atomic SIG has released an updated version[1] of CentOS
Atomic Host (7.1710), a lean operating system designed to run Linux
containers, built from standard CentOS 7 RPMs, and tracking the
component versions included in Red Hat Enterprise Linux Atomic Host.
[1] https://wiki.centos.org/SpecialInterestGroup/Atomic/Download
This release includes an updated version of rpm-ostree that allows for
more flexibility when using rpm-ostree's package layering features.
CentOS Atomic Host includes these core component versions:
* atomic-1.19.1-5.git48c224b.el7.centos.x86_64
* cloud-init-0.7.9-9.el7.centos.2.x86_64
* docker-1.12.6-61.git85d7426.el7.centos.x86_64
* etcd-3.2.7-1.el7.x86_64
* flannel-0.7.1-2.el7.x86_64
* kernel-3.10.0-693.5.2.el7.x86_64
* kubernetes-node-1.5.2-0.7.git269f928.el7.x86_64
* ostree-2017.11-1.el7.x86_64
* rpm-ostree-client-2017.9-1.atomic.el7.x86_64
Package Layering with rpm-ostree
Using rpm-ostree package layering[2], it is possible to dynamically
add more packages onto the system that are not part of the commit
composed on the server. These additional "layered" packages are
persistent across upgrades, rebases, and deploys. If a package you
wish to layer conflicts with a package already in the atomic host
image, a set of recently-added "override" commands can help resolve
the conflict.
[2] http://rpm-ostree.readthedocs.io/en/latest/manual/administrator-handbook/#h…
For instance, the "origin-clients" package can be used to quickly
stand up an OpenShift Origin install using the command `oc cluster
up`, but this package conflicts with the "kubernetes-client" package
that comes baked into the CentOS Atomic Host image. You can use
package layering to configure the repository containing the
"origin-clients" rpm, to remove the conflicting kubernetes packages,
and to install "origin-clients."
# rpm-ostree install centos-release-openshift-origin36
# rpm-ostree ex livefs
# rpm-ostree ex override remove kubernetes-client kubernetes-node
# rpm-ostree install origin-clients -r
Download CentOS Atomic Host
CentOS Atomic Host is available as a VirtualBox or libvirt-formatted
Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image.
For links to media, see the CentOS wiki[3].
[3] https://wiki.centos.org/SpecialInterestGroup/Atomic/Download
Upgrading
If you're running a previous version of CentOS Atomic Host, you can
upgrade to the current image by running the following command:
# atomic host upgrade
Release Cycle
The CentOS Atomic Host image follows the upstream Red Hat Enterprise
Linux Atomic Host cadence. After sources are released, they're rebuilt
and included in new images. After the images are tested by the SIG and
deemed ready, we announce them.
Getting Involved
CentOS Atomic Host is produced by the CentOS Atomic SIG[4], based on
upstream work from Project Atomic[5]. If you'd like to work on
testing images, help with packaging, documentation -- join us!
[4] http://wiki.centos.org/SpecialInterestGroup/Atomic
[5] http://www.projectatomic.io/
The SIG meets every two weeks as part of the Project Atomic community
meeting at 16:00 UTC on Monday in the #atomic channel. You'll often
find us in #atomic and/or #centos-devel if you have questions. You can
also join the atomic-devel[6] mailing list if you'd like to discuss
the direction of Project Atomic, its components, or have other
questions.
[6] https://lists.projectatomic.io/mailman/listinfo/atomic-devel
Getting Help
If you run into any problems with the images or components, feel free
to ask on the centos-devel mailing list. Have questions about using
Atomic? See the atomic mailing list or find us in the #atomic channel
on Freenode.
Hi Folks,
If you have topics for the Distro Devroom, now's the time! See the CFP
Here:
----- Forwarded message -----
> To: fosdem(a)lists.fosdem.org
> Date: Tue, 31 Oct 2017 17:55:56 +0100
> Subject: [FOSDEM] FOSDEM 2018 - Distributions Devroom Call for Participation
>
> The Distributions devroom will take place Sunday 4 February 2018 at
> FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles.
>
> For this year's distributions devroom, we want to focus on the ways that
> distribution technologies can be leveraged to allow for easier
> creation of a multi-verse of artifacts from single source trees. We also
> want to continue to highlight the huge efforts being made in shared
> environments around Build/Test/Release cycles.
>
> We welcome submissions targeted at contributors interested in issues
> unique to distributions, especially in the following topics:
>
> - Distribution and Community collaborations, eg: how does code flow from
> developers to end users across communities, ensuring trust and code
> audibility
>
> - Automating building software for redistribution to minimize human
> involvement, eg: bots that branch and build software, bots that
> participate as team members extending human involvement
>
> - Cross-distribution collaboration on common issues, eg: content
> distribution, infrastructure, and documentation
>
> - Growing distribution communities, eg: onboarding new users, helping
> new contributors learn community values and technology, increasing
> contributor technical skills, recognizing and rewarding contribution
>
> - Principals of Rolling Releases, Long Term Supported Releases (LTS),
> Feature gated releases, and calendar releases
>
> - Distribution construction, installation, deployment, packaging and
> content management
>
> - Balancing new code and active upstreams verus security updates, back
> porting and minimization of user breaking changes
>
> - Delivering architecture independent software universally across
> architectures within the confines of distribution systems
>
> - Effectively communicating the difference in experience across
> architectures for developers, packagers, and users
>
> - Working with vendors and including them in the community
>
> - The future of distributions, emerging trends and evolving user demands
> from the idea of a platform
>
> Ideal submissions are actionable and opinionated. Submissions may
> be in the form of 25 or 50 minute talks, panel sessions, round-table
> discussions, or Birds of a Feather (BoF) sessions.
>
> Dates
> ------
> Submission Deadline: 03-Dec-2017 @ 2359 GMT
> Acceptance Notification: 8-Dec-2017
> Final Schedule Posted: 15-Dec-2017
>
> How to submit
> --------------
> Visit https://penta.fosdem.org/submission/FOSDEM18
>
> 1.) If you do not have an account, create one here
> 2.) Click 'Create Event'
> 3.) Enter your presentation details
> 4.) Be sure to select the Distributions Devroom track!
> 5.) Submit
>
> What to include
> ---------------
> - The title of your submission
> - A 1-paragraph Abstract
> - A longer description including the benefit of your talk to your target
> audience, including a definition of your target audience.
> - Approximate length / type of submission (talk, BoF, ...)
> - Links to related websites/blogs/talk material (if any)
>
> Administrative Notes
> ----------------
> We will be live-streaming and recording the Distributions Devroom.
> Presenting at FOSDEM implies permission to record your session and
> distribute the recording afterwards. All videos will be made available
> under the standard FOSDEM content license (CC-BY).
>
> If you have any questions, feel free to contact the
> devroom organizers: distributions-devroom(a)lists.fosdem.org
> (https://lists.fosdem.org/listinfo/distributions-devroom)
>
> Cheers!
>
> Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter:
> @bstinsonmhk) for and on behalf of The Distributions Devroom Program
> Committee
>
> _______________________________________________
> FOSDEM mailing list
> FOSDEM(a)lists.fosdem.org
> https://lists.fosdem.org/listinfo/fosdem
----- End forwarded message -----
Cheers!
--
Brian Stinson
Hi there,
Emmanuel Kasper of the Debian Cloud Team contacted me about two days
ago: they discovered that Vagrant simply ignores any --checksum
parameter when adding the box. You can even provide "1234" instead of a
valid SHA256 sum, and Vagrant will just add the downloaded box, without
any warning or error whatsoever:
vagrant box add --checksum-type sha256 --checksum 1234 --provider
libvirt --box-version 1710.01 centos/7
==> box: Loading metadata for box 'centos/7'
box: URL: https://atlas.hashicorp.com/centos/7
==> box: Adding box 'centos/7' (v1710.01) for provider: libvirt
box: Downloading:
https://vagrantcloud.com/centos/boxes/7/versions/1710.01/providers/libvirt.…
==> box: Successfully added box 'centos/7' (v1710.01) for 'libvirt'!
echo $?
0
Our signatures are basically useless for most users: Vagrant will only
check the signature if one is included in the metadata (which is not the
one in the box we host, but generated by Vagrant Cloud, formerly known
as Atlas - there's simply no way to get Hashicorp's servers to include
the checksum, not even for the boxes they host themselves). The
--checksum argument is honored if you add a raw box, but I doubt our
users would be willing to do that, even if they knew about it:
$ vagrant box add --checksum-type sha256 --checksum 1234 --name c7tmp
https://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-Vag…
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'c7tmp' (v0) for provider:
box: Downloading:
https://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-Vag…
box: Calculating and comparing box checksum...
The checksum of the downloaded box did not match the expected
value. Please verify that you have the proper URL setup and that
you're downloading the proper file.
Expected: 1234
Received: 9d1ddb812de88578326538d69fdd5f59ba68adf04862144300c42d0293f61d2f
$ echo $?
1
Another possibility would be to also host the metadata ourselves, along
with the raw boxes, on cloud.centos.org. Endymion can already generate
the needed metadata, and I already verified that Vagrant works properly
with it, even detecting newer versions of the boxes for updates. The
problem of convincing our users to use a cloud.c.o URL instead of Atlas
still remains.
I guess I'll have to replace the section in our future release
announcements about verifying the images downloaded from Atlas with some
sort of warning. Any other ideas of what we could do? Vagrant's
behavior is described in its documentation, so I assume it's by design.
How about adding the missing Vagrant functionality as distro patches, if
upstream doesn't want to?
Regards,
Laurențiu
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878759https://github.com/lpancescu/endymion
Ceph Jewel 10.2.10 was tagged for release after several weeks of testing
with no
reported issues.
It will make it's way to the stable repositories during the next
synchronization.
David Moreau Simard
Senior Software Engineer | OpenStack RDO
dmsimard = [irc, github, twitter]
On Wed, Oct 18, 2017 at 5:50 PM, David Moreau Simard <dms(a)redhat.com> wrote:
> Hi,
>
> Ceph Jewel 10.2.10 was released upstream on October 8th and is now
> available for testing [1] from the Ceph storage SIG repositories.
>
> You can find the release notes for 10.2.10 here [2] and the spec
> update here [3].
>
> To test this new release of Ceph, you will need to enable the testing
> repositories like so:
>
> yum -y install centos-release-ceph-jewel
> yum-config-manager --enable centos-ceph-jewel-test
>
> We plan on releasing 10.2.10 soon if no issues are reported.
>
> Thanks !
>
> [1]: http://cbs.centos.org/koji/buildinfo?buildID=20348
> [2]: http://ceph.com/releases/v10-2-10-jewel-released/
> [3]: https://github.com/CentOS-Storage-SIG/ceph/commit/
> 1b1e5d0b302b18fc79f397c88c22df85ab78f9ab
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
Hello,
It's time for our weekly PaaS SIG sync-up meeting
Please remember that in U.S. daylight savings happened, and this
meeting is keyed to UTC. So this meeting is now one hour later that
it was last week.
Time: 1700 UTC - Wedensdays (date -d "1700 UTC")
Date: Today Wedensday, 08 November 2017
Where: IRC- Freenode - #centos-devel
Agenda:
- OpenShift Current Status
-- rpms
-- Automated rpm building and Automated testing
-- Multi-arch
-- Documentation
-- Images and Image building
-- minishift
-- kompose / kedge
- Open Floor
Minutes from last meeting:
https://www.centos.org/minutes/2017/November/centos-devel.2017-11-01-17.01.…
Hi there,
I'm hitting a conflict when using Ceph and oVirt 4.2beta.
The upcoming oVirt 4.2 release is pulling in ~liburcu-cds.so.6 where
Ceph is requiring liburcu-cds.so.1. And the same for liburcu-bp.
Here is the output from yum update:
http://pastebin.centos.org/411116/
Cheers,
Alex
When can I expect a test build of origin 3.7.0 rpm package?
Over the weekend I grabbed the tarball 3.7.0-rc.0 and used it to update one of my systems. In 3.6, it was having problems using Vsphere as a cloud provider. 3.7 fix the issues I was having.