devel

devel@lists.centos.org

10 participants
4617 discussions

[opstools] Building opstools7-fluentd-012-release for ppc64le
by Mark Hamzy 22 Feb '18

22 Feb '18

Hey y'all, So what scripts/process builds the group of rpms for the tag opstools7-fluentd-012-release? I would like to build them for ppc64le. So the packages in http://mirror.centos.org/centos/7/opstools/x86_64/ Would end up mirror.centos.org/altarch/7/opstools/ppc64le/ Is this something I could help with? -- Mark You must be the change you wish to see in the world. -- Mahatma Gandhi Never let the future disturb you. You will meet it, if you have to, with the same weapons of reason which today arm you against the present. -- Marcus Aurelius

3 3

CentOS PaaS SIG meeting (2018-02-21)
by Troy Dawson 21 Feb '18

21 Feb '18

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays (date -d "1700 UTC") Date: Today Wedensday, 21 February 2018 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms -- Automated rpm building and Automated testing -- Multi-arch -- Documentation -- Images and Image building - Open Floor Minutes from last meeting: https://www.centos.org/minutes/2018/February/centos-devel.2018-02-14-17.02.…

1 0

php71 build targets
by Charles A. Plater 21 Feb '18

21 Feb '18

I’m trying to figure out how build targets are requested / added to the Software Collections, specifically php71 and php71-fpm. Currently, the php71 RPMs are available for RHEL7 and CentOS7. What is the process to request these RPMs to be added to the CentOS6 (and potentially RHEL6) Software Collection? Many thanks in advance. -- Charles Plater Lead Application Technical Analyst Internet Services +1-313-577-4620 ab3189(a)wayne.edu

2 1

Re: [CentOS-devel] Vagrant / Centos 7 Install Error: Cannot find a valid baseurl for repo: base/7/x86_64
by Simon Payne 21 Feb '18

21 Feb '18

Hi Laurentiu, Thank you very much for trying it out and giving your feedback. I will have a look at some of those other options. Cheers Simon Message: 11 > Date: Tue, 20 Feb 2018 20:45:36 +0100 > From: Laurentiu Pancescu <lpancescu(a)centosproject.org> > To: centos-devel(a)centos.org > Subject: Re: [CentOS-devel] Vagrant / Centos 7 Install Error: Cannot > find a valid baseurl for repo: base/7/x86_64 > Message-ID: <abbbfc72-9579-462f-dff2-6bab7ee6ecf8(a)centosproject.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Simon, > > On 20/02/18 12:01, Simon Payne wrote: > > I am trying to get a Centos VM working with Vagrant + VirtualBox on > Windows > > 8. However I'm getting an error to do with the centos/7 box. > > > > I have installed Vagrant using its automated installer, and VirtualBox, > and > > downloaded this box: > > > > https://app.vagrantup.com/centos/boxes/7 > [snip] > > Cannot find a valid baseurl for repo: base/7/x86_64 > > > > I don't know how to fix it. I append the error trace and my Vagrantfile. > > Any help will be appreciated. > > I'm not sure what's going on,either. VirtualBox users on Windows have > been plagued by DNS problems immediately after centos/7 boots (disabling > the NAT DNS resolver is an attempt to work around that). I tried to > simulate that by disabling the host networking immediately after running > "vagrant up", and that produces the same error message you got. > > I don't have access to Windows, so I ran your example on a Mac with > VirtualBox 5.2.6, vagrant-vbguest 0.15.1 and centos/7 1801.02. It > installed the guest additions and mounted the shared folder via vboxsf. > The DNS resolver problems were always restricted to VirtualBox on > Windows - it works on Mac and Linux, as do all other hypervisors. I'm > afraid I can't help you; perhaps you can try to use our Hyper-V images > (Hyper-V is included for free in Windows Professional and higher) or > VMware, if that's an option. > > Please note that the guest additions aren't really needed. Networking > works just fine without them, and you can use Samba or vagrant-sshfs for > sharing files: > > https://github.com/dustymabe/vagrant-sshfs > > Best regards, > Lauren?iu >

1 0

Vagrant / Centos 7 Install Error: Cannot find a valid baseurl for repo: base/7/x86_64
by Simon Payne 20 Feb '18

20 Feb '18

Hello, I am trying to get a Centos VM working with Vagrant + VirtualBox on Windows 8. However I'm getting an error to do with the centos/7 box. I have installed Vagrant using its automated installer, and VirtualBox, and downloaded this box: https://app.vagrantup.com/centos/boxes/7 here is the output of that: D:\Vagrant>vagrant box add centos/7 ==> box: Loading metadata for box 'centos/7' box: URL: https://vagrantcloud.com/centos/7 This box can work with multiple providers! The providers that it can work with are listed below. Please review the list and choose the provider you will be working with. 1) hyperv 2) libvirt 3) virtualbox 4) vmware_desktop Enter your choice: 3 ==> box: Adding box 'centos/7' (v1801.02) for provider: virtualbox box: Downloading: https://vagrantcloud.com/centos/boxes/7/versions/1801.02/providers/virtualb… box: Progress: 100% (Rate: 950k/s, Estimated time remaining: --:--:--) ==> box: Successfully added box 'centos/7' (v1801.02) for 'virtualbox'! So I did a vagrant init, ran "vagrant up" and I got a warning about VB guest additions needed, so I ran this command: vagrant plugin install vagrant-vbguest D:\Vagrant>vagrant plugin install vagrant-vbguest Installing the 'vagrant-vbguest' plugin. This can take a few minutes... Fetching: micromachine-2.0.0.gem (100%) Fetching: vagrant-vbguest-0.15.1.gem (100%) Installed the plugin 'vagrant-vbguest (0.15.1)'! I then tried "vagrant up" again but got this error: Cannot find a valid baseurl for repo: base/7/x86_64 I don't know how to fix it. I append the error trace and my Vagrantfile. Any help will be appreciated. thanks, Simon Appendages... ERROR TRACE ============= D:\Vagrant>vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Checking if box 'centos/7' is up to date... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat ==> default: Forwarding ports... default: 80 (guest) => 8080 (host) (adapter 1) default: 22 (guest) => 2222 (host) (adapter 1) ==> default: Running 'pre-boot' VM customizations... ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key ==> default: Machine booted and ready! [default] No installation found. Loaded plugins: fastestmirror One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=<repoid> ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable <repoid> or subscription-manager repos --disable=<repoid> 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true Cannot find a valid baseurl for repo: base/7/x86_64 ==> default: Checking for guest additions in VM... default: No guest additions were detected on the base box for this VM! Guest default: additions are required for forwarded ports, shared folders, host only default: networking, and more. If SSH fails on this machine, please install default: the guest additions and repackage the box to continue. default: default: This is not an error message; everything may continue to work properly, default: in which case you may ignore this message. The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! yum install -y kernel-devel-`uname -r` gcc binutils make perl bzip2 Stdout from the command: Loaded plugins: fastestmirror Stderr from the command: One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=<repoid> ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable <repoid> or subscription-manager repos --disable=<repoid> 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true Cannot find a valid baseurl for repo: base/7/x86_64 MY VAGRANTILE ============== # -*- mode: ruby -*- # vi: set ft=ruby : # All Vagrant configuration is done below. The "2" in Vagrant.configure # configures the configuration version (we support older styles for # backwards compatibility). Please don't change it unless you know what # you're doing. Vagrant.configure("2") do |config| # The most common configuration options are documented and commented below. # For a complete reference, please see the online documentation at # https://docs.vagrantup.com. # Every Vagrant development environment requires a box. You can search for # boxes at https://vagrantcloud.com/search. config.vm.box = "centos/7" # Disable automatic box update checking. If you disable this, then # boxes will only be checked for updates when the user runs # `vagrant box outdated`. This is not recommended. # config.vm.box_check_update = false # Create a forwarded port mapping which allows access to a specific port # within the machine from a port on the host machine. In the example below, # accessing "localhost:8080" will access port 80 on the guest machine. # NOTE: This will enable public access to the opened port # config.vm.network "forwarded_port", guest: 80, host: 8080 # Create a forwarded port mapping which allows access to a specific port # within the machine from a port on the host machine and only allow access # via 127.0.0.1 to disable public access config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1" # Create a private network, which allows host-only access to the machine # using a specific IP. # config.vm.network "private_network", ip: "192.168.33.10" # Create a public network, which generally matched to bridged network. # Bridged networks make the machine appear as another physical device on # your network. # config.vm.network "public_network" # Share an additional folder to the guest VM. The first argument is # the path on the host to the actual folder. The second argument is # the path on the guest to mount the folder. And the optional third # argument is a set of non-required options. # config.vm.synced_folder "./data", "/vagrant_data" # Provider-specific configuration so you can fine-tune various # backing providers for Vagrant. These expose provider-specific options. # Example for VirtualBox: # config.vm.provider "virtualbox" do |vb| # # Display the VirtualBox GUI when booting the machine # vb.gui = true # # # Customize the amount of memory on the VM: # vb.memory = "1024" vb.customize ["modifyvm", :id, "--natdnshostresolver1", "off"] end # # View the documentation for the provider you are using for more # information on available options. # Enable provisioning with a shell script. Additional provisioners such as # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the # documentation for more information about their specific syntax and use. # config.vm.provision "shell", inline: <<-SHELL # apt-get update # apt-get install -y apache2 # SHELL config.vm.synced_folder ".", "/vagrant", type: "virtualbox" end

2 1

CentOS for IBM Mainframes.
by Javier Romero 20 Feb '18

20 Feb '18

Hi all, I see that IBM LinuxONE, provides a Z Mainframe running with Linux Red Hat, SUSE OR Ubuntu Server distros. Do you think that could also be useful for CentOS to be another option for LinuxONE? Maybe a a CentOS Mainframe SIG can be created to work on this. Thanks for your attention. Regards, Javier Romero

3 4

Atomic Container in github.com/centos/atomic-container
by Karanbir Singh 20 Feb '18

20 Feb '18

Hi, As the atomic container process has matured to a point where we can move towards a release, I've moved the content from kbsingh/atomic-container to centos/atomic-container on github.com Bama, can you move the index to point at this ? also move the container to be available in the registry from /centos/ namespace and confirm once its there. Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 1

G++ Testsuite tls/thread_local-order2.C fails with 4.8.5 20150623 and older
by Jan Boehme 19 Feb '18

19 Feb '18

Hello, while playing with building a current gcc by myself I detected that the latest Centos 7 g++ isn't able to pass the respective test suite because of FAIL: g++.dg/tls/thread_local-order2.C -std=c++11 execution test Is this accepted behavior? If so, it basically breaks C++11 support on this platform. What is already known in terms of a cause? Is it a glibc problem (I'm not seeing it using Fedora with glibc 2.26)? g++ --version g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) g++ /tmp/gcc-7.3.0/gcc/testsuite/g++.dg/tls/thread_local-order2.C -o /tmp/thread_local-order2.exe -std=c++11 /tmp/thread_local-order2.exe Aborted (core dumped) /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.17 Thanks, Jan.

1 0

Some way to validate SIG repo repodata (via HTTPS or GPG-signed repomd?)
by Neal Gompa 19 Feb '18

19 Feb '18

Hey, I've been trying to get the CentOS SIG repositories enabled in the openSUSE Build Service[1]. Today, I started working with Adrian Schröter (who is CC'd to this email) on getting this done, and the issue right now is that there's no way to securely validate the repodata. OBS supports two ways: 1. Validating repodata from a mirror using the copy on the master server fetched through HTTPS. 2. Validating repodata through GPG-signed repodata (signed repomd.xml) While the base repositories do the latter, none of the repositories produced through CBS do, and _nothing_ currently does the former. Is there something that can be done to make this better so we can have nice things? Best regards, Neal [1]: https://progress.opensuse.org/issues/29568 -- 真実はいつも一つ！/ Always, there's only one truth!

3 3

[Infra] - planned outage : bugs.centos.org (Bug Tracker)
by Fabian Arrotin 19 Feb '18

19 Feb '18

This notification to let you know that we'll migrate our https://bugs.centos.org bug tracker service to a different node, and also updated to a new version of MantisBT (version 2.x) This migration will give us more possibilities, including soon trying to get SSO working even on our bug tracker (that part still need to be done though) Migration is scheduled for """"Tuesday February 20th, 8:00 am UTC time"""". You can convert to local time with $(date -d '2018-2-20 8:00 UTC') The expected "downtime" is estimated to ~10 minutes , time needed to update/propagate updated dns A/AAAA records + last mysql dump/restore on the new node. Thanks for your comprehending and patience. on behalf of the Infra team, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel