devel

devel@lists.centos.org

4 participants
4592 discussions

Registries
by Karanbir Singh 11 Feb '16

11 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Guys, Zeeshan has offered to look at the wider state of registries and do a short briefing on them ( oci/docker specific as a place to start ) at the next centos buildsystems irc meeting. Brian: what would be the best way to host this ? 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWu0VjAAoJEI3Oi2Mx7xbtzq4H/36aBI4WM1Nmu73xcEzhiC7M t3tMsPK7/N9AqckjFQFSe00mJmIVE9ibzNIxmlTzzreHzlxjaKdDaMDES26+Op3e hOPWqsMoQ44wEJ6b7T6t7oP7pnOHo/dIdBwU+KirRfTHDKS/AcMH50GjrleqBIAm Ff7WluJQFwIO1CXH2jLYqbYCNCDdMxG932VnOgCZU0mOSPHS7cZ4VkzvDXnPdey8 VIwZKZwXYl+MBQDqohYJcSmUobiWYeEXlBOKNu6Q9J1+lYrfnrQq6/cpW6ETtpjB NdZfDf2bh7E1h88TpB0N93zPyel30Qkp9Pbe/uKF+fzP0jw6QdFQJLkiTSDUaW0= =Y6hq -----END PGP SIGNATURE-----

3 2

Re: [CentOS-devel] [atomic] official centos-7 docker image are wrong
by Jason Brooks 11 Feb '16

11 Feb '16

----- Original Message ----- > From: "Eric Paris" <eparis(a)redhat.com> > To: "Farkas Levente" <lfarkas(a)lfarkas.org>, "CentOS devel" <centos-devel(a)centos.org>, atomic(a)projectatomic.io > Sent: Wednesday, February 10, 2016 5:00:31 PM > Subject: Re: [atomic] official centos-7 docker image are wrong > > I'm willing to bet one week's pay that RH didn't silently release the > same version twice with different code... > > Wasn't there a problem that one of the base image build systems somehow > didn't support file caps and so the caps were being silently lost? > Maybe something about squashfs not understanding filecaps and rpm not > considering that a permanent failure... Very very hazy... There was this: http://www.projectatomic.io/blog/2015/04/problems-with-ping-in-containers-o… > > I know I remember this bug in the back of my head... > > In any case if you look in the centos base image (after installing > attr) > > # getfattr -n security.capability /usr/bin/ping > /usr/bin/ping: security.capability: No such attribute > > # rpm -V iputils > ........P /usr/bin/ping > ........P /usr/bin/ping6 > ........P /usr/sbin/arping > ........P /usr/sbin/clockdiff > > So while the right version/rpm was installed the actual bits in the > base image aren't what the rpm says they should be! The bug is in how > the base image is created... I don't know where, but just building it > again will likely just keep doing the wrong thing... > > I know this will trigger someone's mind who looking into this months > and months ago... > > -Eric > > On Wed, 2016-02-10 at 11:15 +0100, Farkas Levente wrote: > > hi, > > according to this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1142311 > > rh silently replace iputils with the same version with a fixed > > capabilities. > > unfortunately official base centos-7 (ie. latest 7.2) docker images > > are > > build with the wrong version, so these images should have to be > > rebuild > > with the proper version. > > currently in the official centos7 docker images: > > ------------------------------------- > > # rpm -qi iputils > > Name : iputils > > Version : 20121221 > > Release : 7.el7 > > Architecture: x86_64 > > Install Date: Wed 23 Dec 2015 06:09:24 PM UTC > > Group : System Environment/Daemons > > Size : 368577 > > License : BSD and GPLv2+ > > Signature : RSA/SHA256, Wed 25 Nov 2015 02:43:41 PM UTC, Key ID > > 24c6a8a7f4a80eb5 > > Source RPM : iputils-20121221-7.el7.src.rpm > > Build Date : Fri 20 Nov 2015 07:12:19 PM UTC > > Build Host : worker1.bsys.centos.org > > Relocations : (not relocatable) > > Packager : CentOS BuildSystem <http://bugs.centos.org> > > Vendor : CentOS > > URL : http://www.skbuff.net/iputils > > Summary : Network monitoring tools including ping > > Description : > > The iputils package contains basic utilities for monitoring a > > network, > > including ping. The ping command sends a series of ICMP protocol > > ECHO_REQUEST packets to a specified network host to discover whether > > the target machine is alive and receiving network traffic. > > ------------------------------------- > > > > while in the centos repo: > > ------------------------------------- > > # rpm -qi iputils > > Name : iputils > > Version : 20121221 > > Release : 7.el7 > > Architecture: x86_64 > > Install Date: Tue 15 Dec 2015 03:15:22 PM CET > > Group : System Environment/Daemons > > Size : 368577 > > License : BSD and GPLv2+ > > Signature : RSA/SHA256, Wed 25 Nov 2015 03:43:41 PM CET, Key ID > > 24c6a8a7f4a80eb5 > > Source RPM : iputils-20121221-7.el7.src.rpm > > Build Date : Fri 20 Nov 2015 08:12:19 PM CET > > Build Host : worker1.bsys.centos.org > > Relocations : (not relocatable) > > Packager : CentOS BuildSystem <http://bugs.centos.org> > > Vendor : CentOS > > URL : http://www.skbuff.net/iputils > > Summary : Network monitoring tools including ping > > Description : > > The iputils package contains basic utilities for monitoring a > > network, > > including ping. The ping command sends a series of ICMP protocol > > ECHO_REQUEST packets to a specified network host to discover whether > > the target machine is alive and receiving network traffic. > > ------------------------------------- > > imho it's a bug! without it ping not working from any docker > > container > > based on centos7. > > > >

1 0

SIGs, versions, and yum update
by George Dunlap 10 Feb '16

10 Feb '16

A couple of weeks ago I was just about to push an update of Xen 4.4 to Xen 4.6 to the Virt SIG repositories, and I suddenly got some push-back from the users, because Xen 4.6 has some fairly significant changes -- particularly the removal of the old toolstack daemon called xend. (xend had been disabled by default and had lots of messages warning about the upcoming deprecation, even in 4.4.) It seems some users have the expectation that they should be able to run "yum update -y" on their servers on a regular basis, without having to worry about accidentally updating to a new major version that break things. So one thing that was proposed was that we make separate packages somehow, such that users would have to actively request the newer version rather than getting it automatically. (This could be done either by having a package named xen46, or by having separate centos-release-xen-46 package that pointed to an entirely different repository.) But of course, other users pushed back on that idea, saying they would always rather have the latest version Just Work, and didn't like the idea of having to manually keep track of what version was installed on any given system, or of actually finding out that there's a new package and what that new package name is. KB and I chatted about it at the Virt SIG meeting, and decided that we should touch base with the other SIGs to have a consistent message. As for my own opinion: I can see both sides of the story, and as a package maintainer I'd be willing to do either one. But on the whole I tend to side with the "latest version" crowd. I think you should always be looking at what "yum update" gives you before installing it; even minor updates I can't guarantee are going to break things. And I'd rather the installation instructions be simple (don't have to mess around with version numbers), and I'd rather people not have to fish around for major updates (or run packages with unpatched security vulnerabilities because they didn't realize their packages were now obsolete). What do other SIGs think? -George

5 6

[Atomic SIG] Signing and Publishing RPMs for ADB
by Lalatendu Mohanty 10 Feb '16

10 Feb '16

For ADB (Atomic Developer Bundle) Vagrantbox we want to add a new RPM i.e. adb-utils [2]. For that to happen we need to sign the adb-utils which we have built in cbs [3] and making it available in CentOS projects official YUM repositories (e.g. buildlogs). So that we can include the repo while building the Vagrantbox. We need a key to sign the content and also need automatic push of builds when it is tagged with "atomic7-adb-common-testing". I have also raised issues in bugs.centos.org [4] [5] for this. At this point the RPMs only make sense inside of the ADB Vagrantbox. So we expect user to use the RPMs through the Vagrantbox. [1] https://github.com/projectatomic/adb-atomic-developer-bundle [2] https://github.com/projectatomic/adb-utils [3] http://cbs.centos.org/koji/buildinfo?buildID=8707 [4] https://bugs.centos.org/view.php?id=10345 [5] https://bugs.centos.org/view.php?id=10346 Thanks, Lala

2 1

adb effort and the PaaS SIG
by Karanbir Singh 10 Feb '16

10 Feb '16

hi, With the PaaS SIG onboarding, and being centralised around OpenShift - does it make sense to consider ADB moving from the Atomic SIG into this space ? Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

[altarch] multiarch docker images
by Manfred Touron 08 Feb '16

08 Feb '16

Hi everyone, I'm working at Scaleway on the multiarch images system, I'm @moul on IRC and talked with @Arrfab and @Evolution (thanks a lot, guys). --- Context: Today, we are using Docker as a build-step to generate our baremetal servers rootfs, what we call, the "Scaleway images". Here is an example of "1 click app" image: - Public Hub: https://hub.scaleway.com/wordpress.html - DevHub (aggregate APIs): http://devhub.scaleway.com/#/images/wordpress:latest - Source (GitHub): https://github.com/scaleway-community/scaleway-wordpress/ - Docker Hub: https://hub.docker.com/r/scaleway/wordpress/ - Build logs: https://travis-ci.org/scaleway/qa/builds/98515979 We are quite happy today with this method and are succesfully running plenty Linux distributions (Ubuntu, openSUSE, Gentoo, Fedora, Debian, Arch Linux and Alpine Linux). Actually we also have a proof-of-concept of CentOS image, but based on an old development CubieTruck snapshot with no public mirrors. Here is how I built this POC image (I wasn't aware of virt-tar-out): https://github.com/armbuild/centos-img/blob/master/buildcontainers.sh --- We will soon release new server models with new architectures, our next priorities are: `arm64` and `x86_64`, but we plan to support more architectures if we feel enough people will need it so the development worth it. I started to work on "multiarch" images (one image per architecture). Here are some images: - https://github.com/multiarch/alpine -> built with `apk-static` in a chroot - https://github.com/multiarch/busybox -> static binaries extracted from latest busybox-static.deb - https://github.com/multiarch/ubuntu-debootstrap -> qemu-debootstrap - https://github.com/multiarch/debian-debootstrap -> same as above - https://github.com/multiarch/ubuntu-core -> based on released rootfs tarballs at https://partner-images.canonical.com/core/wily/current/ All those images also contains an `x86_64` `qemu-${ARCH}-static` so you can run them on an `x86_64` host with `binfmt-support` available. Look at the README.md files for usage and examples. I began to work on the Centos image https://github.com/multiarch/centos, I successfully built the `armhf` and `arm64` images by `virt-tar-out`ing the CubieTruck released image, i.e.: http://mirror.centos.org/altarch/7.2.1511/isos/armhfp/ I also successfully built the `x86_64` and `i386` images using kickstart: livemedia-creator --arch=i386 --make-disk \ --iso=/tmp/boot7-i386.iso \ --ks=$(pwd)/centos-7.ks \ --image-name=centos-7-base-i386 based on https://github.com/CentOS/sig-cloud-instance-build/tree/livemedia_builds/do… For now I failed to build the `ppc64` nor `ppc64le` images, but that's not a priority. I have now an issue, my `armhf` and `x86_64` images are not the same, the ones based on real boards .img.xz embed about 300M of kernel images, dtb, kernel modules, firmware (I don't want them) + a lot more apps that we can find by default in the <200Mb `x86_64` Docker image. I would like to find a solution to build "same" images for all the targets and avoid as much as possible the need of diffing the outputs of `yum list installed`. My favorite solution would be to use kickstart files, which are very cool to put on GitHub. But the non `x86_64` architectures lack of a `boot.iso` file packing `isolinux`. Is it possible to add those `boot.iso` files on the mirror or tell me how to build them ? Do you see alternative ways to build identical images ? -- Manfred Touron - @moul CTO @ scaleway.com

7 16

NO CBS/Infra Meeting 08-Feb-2016
by Brian Stinson 07 Feb '16

07 Feb '16

Hi Folks, I know some of us (myself included) are traveling or recovering from the Dojo -> FOSDEM -> cfgmgmt -> Devconf marathon, so let's cancel this week's meeting. I'll send out a list of open action items here to the list sometime between airplanes tomorrow. Cheers! --Brian

1 0

release process for SIGs
by François Cami 07 Feb '16

07 Feb '16

Hi, I'd like the centos-release-ceph-hammer rpm to be included in the extras (1) repository like the other centos-release-* packages. First things first: some of these centos-release* packages are tagged el7.centos and others el7. Niels told me el7.centos was the right tag and since this matches the build target name (core7-extras-common-el7.centos), el7.centos seems like the right target. Could I get confirmation that I should use el7.centos for centos-release-ceph-*? Then, the main problem is that packages in the extras repository should be built against core7-extras-common-el7.centos but I cannot use that build target (2). Is there an accepted way of doing this? Thanks, François (1) http://mirror.centos.org/centos-7/7.2.1511/extras/x86_64/Packages/ (2) "ActionNotAllowed: tag requires build-core permission" http://cbs.centos.org/koji/taskinfo?taskID=66398

2 1

Code review platform
by Julien Pivotto 05 Feb '16

05 Feb '16

Hi all, For my project of SIG, I would be interested to get some kind of code-review tool. It would be great to be able to review the contributions before they get accepted. Also, we could hook that into cbs and/or public ci. I have no preference regarding the tool, even if several projects I use are using gerrit. Do you think that the CentOS platform could welcome such a tool? We could imagine that we limit its scope at the beginning, then we extend that to any SIG/CentOS project that wants that. -- (o- Julien Pivotto //\ Open-Source Consultant V_/_ Inuits - https://www.inuits.eu

2 1

missing updates for CentOS6
by Jacco Ligthart 05 Feb '16

05 Feb '16

Hi All, I've been busy building updated RH packages for armv5tel (http://www.redsleeve.org/). During that process I often use repodiff to check if there are updates. And I also use repodiff to the CentOS repos. (of you didn't build it it's often also of no use to me :) ) this time around I noticed that CentOS6 was missing a couple of updates. So here a modified output of repodiff. repodiff -o ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/ -n http://vault.centos.org/6.7/os/Source/ -n http://vault.centos.org/6.7/updates/Source/ --downgrade --simple Downgraded Packages: cups-pk-helper: cups-pk-helper-0.0.4-13.el6 -> cups-pk-helper-0.0.4-12.el6 dvd+rw-tools: dvd+rw-tools-7.1-7.el6 -> dvd+rw-tools-7.1-6.el6 environment-modules: environment-modules-3.2.10-3.el6 -> environment-modules-3.2.10-2.el6 findutils: findutils-4.4.2-8.el6 -> findutils-4.4.2-6.el6 freeipmi: freeipmi-1.2.1-7.el6 -> freeipmi-1.2.1-6.el6_5 gedit: gedit-2.28.4-4.el6 -> gedit-2.28.4-3.el6 ibus: ibus-1.3.4-9.el6 -> ibus-1.3.4-8.el6 libcanberra: libcanberra-0.22-3.el6 -> libcanberra-0.22-1.el6.centos libipathverbs: libipathverbs-1.3-3.el6_5 -> libipathverbs-1.3-3.el6 logwatch: logwatch-7.3.6-54.el6 -> logwatch-7.3.6-52.el6 pango: pango-1.28.1-11.el6 -> pango-1.28.1-10.el6 paps: paps-0.6.8-13.el6.3 -> paps-0.6.8-13.el6.2 passwd: passwd-0.77-7.el6 -> passwd-0.77-4.el6_2.2 perl-LDAP: perl-LDAP-0.40-2.el6 -> perl-LDAP-0.40-1.el6 pulseaudio: pulseaudio-0.9.21-24.el6 -> pulseaudio-0.9.21-21.el6 unzip: unzip-6.0-4.el6 -> unzip-6.0-2.el6_6 urw-fonts: urw-fonts-2.4-11.el6 -> urw-fonts-2.4-10.el6 watchdog: watchdog-5.6-5.el6 -> watchdog-5.6-4.el6_6 wget: wget-1.12-8.el6 -> wget-1.12-5.el6_6.1 Jacco

2 3

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