devel June 2015

devel@lists.centos.org

49 participants
40 discussions

forums + portal for {lang}.centos.org sites
by Karanbir Singh 17 Aug '24

17 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

CI for kubernetes, docker, etcd and other atomic packages
by Jan Chaloupka 15 Jul '15

15 Jul '15

Hi, at the moment kubernetes, docker, etcd and other atomic packages has no CI testing in CentOS. The packages built for CentOS are taken from Fedora's repositories. There is already an effort to create CI for Fedora builds. Currently kubernetes has its own CI job which can be taken as an template for other jobs for docker, etcd, etc. in Fedora. The job among other things consists of a builder, i.e. script that can be broken down into two parts: installation and testing. The installation part takes care of installing, updating and downloading all necessary builds. Testing part runs tests. As the script is universal and differs only in the installation part, other distributions can reuse it. RHEL does that after a simple modification of the installation part. The workflow is following: update kubernetes ci job for Fedora, if it works, update it for RHEL. I would like to continue in the same sense for CentOS. Create a job for centos's kubernetes. The question is where should it run? All jobs (for Fedora and RHEL) are run in redhat's internal Jenkins. For CentOS it would be better to run the job in its own CI environment as this is not the only job. Docker, possible etcd and cadvisor can have its own set of sets that are suitable. So distributing CI effort among all distributions that are involved is natural. Another option is to run all centos jobs related to atomic packages in the internal Jenkins. Why should we bother with running centos's jobs in redhat's environment? I have all jobs at one place so I can update them all at once and they don't get out of sync. It does not take me much time to create another ci job for CentOS once I have created one for Fedora. However, I need a trigger that will trigger the job (I have started a discussion on setting up fedmsg for CentOS that could provide such a trigger [1]). Second, the CI environment is internal so everyone who wants to take a look at run jobs must have RH credentials. If CentOS's CI is used the responsibility for maintaining all jobs and keeping them in sync is completely on CentOS side. Or something between? What about I will first test the new or updated job for CentOS in internal env and then forward all changes to someone responsible for CentOS's CI which would be who? I am not against taking care of this part if I get an access/credentials to CentOS to access your CI. Some jobs in internal RH Ci environment contain private data so I can not go public. What can go public is the builder (script) for Fedora. However I don't see any benefit sharing the script without the entire *.yaml files that create the job. On the other hand if you provide a public repository I can contribute to I will update CentOS's jobs as changes or new jobs appears. Provided your template for a job. [1] http://lists.centos.org/pipermail/centos-devel/2015-June/013415.html Kind Regards Jan

4 4

Problems with custom centos-atomic-host build
by Andres Toomsalu 08 Jul '15

08 Jul '15

Hi, Im trying to do custom centos-atomic-host build - from unmodified https://github.com/CentOS/sig-atomic-buildscripts configuration source and following instruction in https://developerblog.redhat.com/2015/01/08/creating-custom-atomic-trees-im… blog post series. Im able to produce ostree and installer.iso image - BUT rpm-ostree-toolbox creates ostree tree with missing grub file, resulting in a failing installer. More details about this problem here: https://github.com/projectatomic/rpm-ostree-toolbox/issues/77 Commands used for ostree and installer creation were: --- rpm-ostree-toolbox treecompose -c ~/repos/sig-atomic-buildscripts/config.ini --ostreerepo /srv/rpm-ostree/centos-atomic-host/7/ rpm-ostree-toolbox installer -c /root/repos/sig-atomic-buildscripts/config.ini \ --ostreerepo /srv/rpm-ostree/centos-atomic-host/7/ \ --outputdir /var/www/html/latest/ --overwrite cp ~/repos/sig-atomic-buildscripts/centos-atomic-host-7.ks /var/www/html/ virt-install --name=atomic-iso --memory=1024 --vcpus=1 \ --disk=/var/lib/libvirt/images/test.qcow2,size=5 \ --location /var/www/html/latest/images/installer.iso \ --noautoconsole --accelerate --os-type=linux --os-variant=rhel7 \ --extra-args "ks=http://192.168.122.1/centos-atomic-host-7.ks" --- Another issue is that also imagefactory KVM centos-atomic-host image build fails in anaconda install stage - complaining about unknown missing file - might be the same problem - not sure... Command used for kvm image creation: --- rpm-ostree-toolbox imagefactory \ -c /root/repos/sig-atomic-buildscripts/config.ini -i kvm \ --ostreerepo /srv/rpm-ostree/centos-atomic-host/7/ \ --outputdir /srv/rpm-ostree/centos-atomic-host/7/images --- Error screenshot from imagefactory launched build VM console: http://prntscr.com/7lq38e From the build VM /tmp/anaconda.log: --- 21:40:35,454 INFO anaconda: Creating xfs on /dev/vda1 21:40:36,242 INFO anaconda: executing ostreesetup=<pykickstart.commands.ostreesetup.RHEL7_OSTreeSetup object at 0x7fdd038d3110> 21:40:36,570 ERR anaconda: Failed to pull from repository: Server returned status 404: Not Found --- Last lines from the build VM /tmp/program.log: --- 21:40:36,339 INFO program: Running... ostree --repo=/mnt/sysimage/ostree/repo remote add --set=gpg-verify=false installmedia http://192.168.122.1:47990/ 21:40:36,377 DEBUG program: Return code: 0 --- Any suggestions how to debug it further? Where should I file a bug report? Kind regards, -- <http://www.getpostbox.com>---------------------------------------------- Andres Toomsalu,andres(a)opennodecloud.com <mailto:andres@opennodecloud.com>

3 4

CentOS CLA (Contributor License Agreement)
by Fabian Arrotin 06 Jul '15

06 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, As it seems FAS (Fedora Account Ssytem) has been chosen as the central authentication system for CentOS.org infra, I'm now trying to find documentation around it .. One thing that I see is the CLA (default in Fedora, that each user must sign and agree with) so that means that for FAS we also need to have one. Has someone already looked at it and so what would be the CentOS CLA that we'll use when people will register/sign for a FAS account on centos.org ? - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlWREFIACgkQnVkHo1a+xU73jwCdF8/yIovWYalefgwBmV7npnbs aDwAn0ka66T3xgC5OoziXEja5e4f8X99 =Kt+l -----END PGP SIGNATURE-----

10 23

[NFV SIG][CBS] Question building DPDK
by Joseph Gasparakis 27 Jun '15

27 Jun '15

Hi all, I have some questions as this is the first time I am using CBS :-) First of all I have done all the prework on my .koji directory and I have verified I can build: <snap> [jgaspara@jg-vm ~]$ koji list-permissions --mine build </snap> I am trying to build DPDK 2.0 (commit id 493db80afd) and I (believe I) have successfully created a dpdk package for nfv7-opnfv-arno-[testing|release]: <snap> [jgaspara@jg-vm ~]$ koji add-pkg --owner "jgasparakis" nfv7-opnfv-arno-testing dpdk [jgaspara@jg-vm ~]$ koji add-pkg --owner "jgasparakis" nfv7-opnfv-arno-release dpdk </snap> Then, I suppose I need to kick off a git build, but it seems like I need to somehow add the DPDK git tree to the permitted SCMs for CBS: <snap> [jgaspara@jg-vm ~]$ koji build nfv7-opnfv-arno-el7 "git+http://dpdk.org/git/dpdk?#493db80afd009eea35ee7d95ad4aba49df5113a3" Created task: 15451 Task info: http://cbs.centos.org/koji/taskinfo?taskID=15451 Watching tasks (this may be safely interrupted)... 15451 build (nfv7-opnfv-arno-el7, /git/dpdk:493db80afd009eea35ee7d95ad4aba49df5113a3): open (x86_64-2.cbs.centos.org) 15452 buildSRPMFromSCM (/git/dpdk:493db80afd009eea35ee7d95ad4aba49df5113a3): free 15451 build (nfv7-opnfv-arno-el7, /git/dpdk:493db80afd009eea35ee7d95ad4aba49df5113a3): open (x86_64-2.cbs.centos.org) -> FAILED: BuildError: dpdk.org:/git/dpdk is not in the list of allowed SCMs 1 free 0 open 0 done 1 failed 15452 buildSRPMFromSCM (/git/dpdk:493db80afd009eea35ee7d95ad4aba49df5113a3): free -> FAILED: BuildError: dpdk.org:/git/dpdk is not in the list of allowed SCMs 0 free 0 open 0 done 2 failed 15451 build (nfv7-opnfv-arno-el7, /git/dpdk:493db80afd009eea35ee7d95ad4aba49df5113a3) failed </snap> Am I right? If so can someone please change permissions for the repo or let me know how I can add the repo to the allowed ones? If not can you point me to what I am doing wrong? :-) Again, the DPDK repo is http://dpdk.org/git/dpdk, the commit id that matches tag v2.0.0 is 493db80afd009eea35ee7d95ad4aba49df5113a3 and the spec file lives in pkg/dpdk.spec. I am assuming CBS will pick it up and create the rpm based on that spec file. Thanks! Joseph

2 2

c7-power64 proof of concept
by James O'Connor 25 Jun '15

25 Jun '15

I realize the altarch-power64 SIG is not officially established, but I want to share some technical progress. I created a private c7-power64 koji hub/builder environment using a pair of Fedora 22 PowerKVM guests. One guest is running Fedora 22 ppc64 and serving as a ppc/ppc64 koji builder. The second guest is running Fedora 22 ppc64le and serving as a ppc64le koji builder, koji hub, postgresql and httpd server. A pair of koji builders (ppc64, ppc64le) could be setup to integrate with cbs.centos.org instead of creating a separate koji hub. I created a c7-power64-build tag that contains arches "ppc64 ppc64le" and I am using Fedora 22 external koji repositories to serve as a build backstop until enough c7-power64 rpms are built. I am currently building with src rpms from http://vault.centos.org/7.1.1503/os/Source/SPackages/ although some ppc64le specific patches will need to be pulled from the c7-ppc64le branch on git.centos.org $ koji taginfo c7-power64-build Tag: c7-power64-build [2] Arches: ppc64 ppc64le Groups: build, srpm-build This tag is a buildroot for one or more targets Current repo: repo#16: 2015-06-24 18:16:29.668635 Targets that build from this tag: c7-power64 External repos: 10 f22-ppc64 (http://c7-ppc64.localnet/mirror/f22/ppc64/os/) 15 f22-ppc64le (http://c7-ppc64le.localnet/mirror/f22/ppc64le/os/) Inheritance: 0 .... c7-power64 [1] Next steps involve resolving some toolchain hiccups. c7 binutils fails to build with Fedora 22 gcc-5.1 and c7 gcc.ppc64 fails to build because Fedora 22 doesn’t have a 32-bit libc.so.6 needed for multilib gcc. To preserve the RHEL 7 ppc/ppc64 multilib environment a few interim c7 gcc/glibc builds will be needed. Happy to share any configuration steps or help do the work on official CentOS infrastructure as we move forward with an altarch-power64 SIG.

2 2

Weird Qt painting bug on CentOS7
by Justin Clift 23 Jun '15

23 Jun '15

With the upstream DB4S project (previously known as SQLite Browser), we've had a bug reported filed of a weird Qt painting problem... which only happens on CentOS 7: https://github.com/sqlitebrowser/sqlitebrowser/issues/354#issuecomment-1117… The direct sceenshot here: https://cloud.githubusercontent.com/assets/1067355/8144743/f944b27e-11e3-11… In the field names (middle section, not bottom section), the new name "XX" is overwriting the old name "Field1". On other OS, and other Linux distro's, the "Field1" text has been correctly wiped already so only shows "XX". Has anyone seen anything like this before, or know how we should figure out what's going wrong? Regards and best wishes, Justin Clift -- 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

2 1

"Rebuild" images ready for testing
by Joe Brockmeier 22 Jun '15

22 Jun '15

Good News, Everybody! KB let me know today that we've got some images of the rebuild of RHEL Atomic Host ready to test. You can find images here: http://buildlogs.centos.org/centos/7/atomic-host/x86_64/images/ This includes 2 flavors of Vagrant box (libvirt/KVM and VirtualBox), a qcow2 image, and ISO image suitable for installing onto bare metal or other environments. We've done some preliminary testing but more is needed. We're hoping to announce next week, so I'd invite all interested parties to test these and let us know if you find any anomalies. Best, jzb -- Joe Brockmeier | Open Source and Standards (OSAS) jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://projectatomic.io/

4 6

Finished a prototype of GSoC project: Implement a new doc toolchain
by Lei Yang 20 Jun '15

20 Jun '15

Hi, Kunaal and I have completed a prototype of the first part of our GSoC project (implement a new doc toolchain). Our goal is to implement a doc toolchain for short how-to docs and lower the barrier for new comers to contribute. This is the workflow of the prototype: 1. Contributor creates a new pull request on GitHub 2. A corresponding issue is automatically created on Pagure 3. Staff and contributor discuss on Pagure 4. When the pull request can be accepted, it is marked as “fixed”, and the pull request on github is automatically merged 5. New change is synced to Pagure (doc website will update according to Pagure repo, to be implemented later) We have made a prototype performing the steps above, and is now running ;) Next we plan to integrate a CI so the doc can be built in real time and ready for staff to review. Could you please give us some suggestions about the workflow above and about the toolchain? The original GSoC idea can be found here: http://wiki.centos.org/GSoC/2015/Ideas#docs-toolchain <http://wiki.centos.org/GSoC/2015/Ideas#docs-toolchain> We use Pagure as a part of the toolchain. Pagure is an excellent git-centered forge created by Pierre-Yves Chibon <pingou(a)pingoured.fr <mailto:pingou@pingoured.fr>>. Currently Pagure is in its early stage and the APIs and web hooks are changing and improving. We are working closely with Pierre to better integrate Pagure into the toolchain. In the future we plan to sync complete pull request so that discussion can happen either on github or Paugre, and contributor doesn’t need to leave github in the whole process, which lowers the barrier of contributing a lot. To test it, you may create a PR on github. A corresponding issue will be created automatically on Pagure, so you may go to Pagure.io to check it. If you want to merge the PR, change the status of issue from Open to Fixed on Pagure (need admin access to the repo, if you want to test this part, please email me or Kunaal <kunaalus(a)gmail.com <mailto:kunaalus@gmail.com>> so we can add you as admin). Once the issue is marked as Fixed, the PR on github will be merged. GitHub repo link: https://github.com/yangl1996/doc-test <https://github.com/yangl1996/doc-test> Pagure repo link: https://pagure.io/docs-test <https://pagure.io/docs-test> The syncing tool is a prototype and is a basic part of the toolchain. Please tell us what you think about the workflow, the syncing tool and the idea. Thank you in advance :) Also, we are not very sure whether running a Pagure instance will add much workload to sys admin team. What’s your idea? Thanks! Regards, Lei

1 0

Re: [CentOS-devel] [atomic-devel] "Rebuild" images ready for testing
by Karanbir Singh 19 Jun '15

19 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/06/15 22:57, James wrote: > On Thu, Jun 18, 2015 at 4:49 PM, Joe Brockmeier <jzb(a)redhat.com> > wrote: >> KB let me know today that we've got some images of the rebuild of >> RHEL Atomic Host ready to test. >> >> You can find images here: >> >> http://buildlogs.centos.org/centos/7/atomic-host/x86_64/images/ > > > RHEL or CentOS ? > > The CentOS Atomic Host is a downstream rebuild of the RHEL Atomic Host. These are images of the CentOS Atomic Host. 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) iQEcBAEBAgAGBQJVg0qZAAoJEI3Oi2Mx7xbteYYH/RtSt0JGUJKTUwU4HfRMRxBO pt/RwKAjdeLVU+ZD2Zg7vy12X1YEsrjcxlYzLw4usnNtyBa6rpgHZ/DFGoP85BCX cr0BKXjT4QrK02urlX4GndnST84jcYZYEl/WvpNIK2VfvPtSwRSxLqsaqqMWVHq9 psy0B0vP+thQrdFEd0DKg9xuEMu2HKUXQyYS4Tz4Rs2aOkknEVuM5lcHScL8+/OK 58FuDvAX9b3NITpPtEup4hyhuBM7/HUtoLlpr0uYNwBjnWQpws9S4Og+EsKj7BPK XLUIqrqReQSTkUzzVlFSFygR+DRhLvOzQoBHpolpkWuoHZzH1Iibua/okkrm9yA= =I/mK -----END PGP SIGNATURE-----

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel June 2015