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
Hi Folks,
I've done a bit of work on centpkg, now that we have a testbed at
git.stg.centos.org. The goal here is to allow centpkg and fedpkg
(Fedora's site) to both understand the different formats. The test
version of centpkg described below is the first step in that direction.
Basically you can try this out by pulling a container image:
`podman pull quay.io/bstinsonmhk/centpkg:develop`
Why a container image?
- The patches to make this happen involve invasive changes to rpkg,
that are still in flight (basically,
https://pagure.io/rpkg/pull-request/393)
- I wanted to bake in the sources and configs to develop this a little
faster as we find problems.
What's included, and where to file bugs?
- centpkg from:
https://bitbucket.org/bstinsonmhk/centpkg/branch/develop
- rpkg from:
https://pagure.io/fork/bstinson/rpkg/tree/centpkg-inbound
- fedpkg from:
https://pagure.io/fedpkg/tree/master
Here's how I run it for testing CentOS packages (substitute your centos
user certificate and a path to RPMs to fit your workstation):
`podman run --rm -it -v
/home/bstinson/.centos.cert:/home/centpkg-user/.centos.cert:Z -v
/home/bstinson/rpms:/home/centpkg-user/rpms:Z
quay.io/bstinsonmhk/centpkg:develop`
If you're a SIG member, you can push to a sig branch. For example, if I
was a mamber of the atomic SIG I could do:
# Clone the repo
$ centpkg clone -b c7 a2ps
# Download the sources from C7
$ centpkg sources
# Change to a SIG branch
$ git checkout -b c7-sig-atomic-cockpit-preview
# Manual push is needed here until we work out a way to register the
# new branches
$ git push -u origin c7-sig-atomic-cockpit-preview
# Upload sources to the SIG branch in the lookaside
$ centpkg upload SOURCES/a2ps-4.14.tar.gz SOURCES/i18n-fonts-0.1.tar.gz
# CBS does not yet build from SCM, so still need srpms
$ centpkg scratch-build --srpm
# Try out a fedora branch
$ centpkg switch-branch f28
$ centpkg clean
# From a Fedora branch this should use your Fedora creds
$ centpkg scratch-build # this should work with Fedora's ko
What I need help with:
- Review the open PRs to rpkg as they come in
- Help me find more places where we need to use the new 'Layout'
objects (that is where rpkg has paths hard-coded)
- Test Fedora workflows, and other commands with centpkg
- Help add new commands
- to request SIG branches
- to translate from one layout to another (ex. bringing a Fedora
branch into a CentOS SIG branch)
Happy building!
--Brian
> Who will prepare the logo? I do not know, we could use a volunteer.
>
I had to track down SVG logo files for the Robox website. Not sure, is
this what you need?
https://roboxes.org/res/centos.svg
If you want something in the December newsletter, please get it to me by
Monday. Thanks.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
So here we go again. As one of the virtues of a programmer is laziness,
I'll just cut&paste the previous email with some modifications. You know
the drill.
RHEL 7.6 was released a few days ago and building CentOS 7.6.1810 has
just started. This would be an excellent time to remove any EOL software
you may have floating around on mirror.centos.org. mirror.centos.org
should have only supported packages available.
SIGs should explicitly state which content they want copied over from
7.5.1804 to 7.6.1810.
I'd imagine that for example ceph-jewel could be dropped because it went
EOL in July 2018. Is there some other content that could be dropped? If
you are planning to keep content available that has gone EOL upstream,
you must commit to backport any required security fixes to it.
If SIGs want to transfer some of their packages from 7.5.18004 to
7.6.1810, please let hughesjr know. You can probably simply reply to
this message to let people know of your decision. It is possible that
some other SIG depends on your packages that are going to be removed. In
that case the other SIG should probably update their packages to depend
on supported versions.
Content to be transferred over to 7.6.1810 can be specified either by
directory name, or by individual package names.
There are also various centos-release-* packages in extras,
http://mirror.centos.org/centos/7.5.1804/extras/x86_64/Packages/ ,
perhaps some of those could be trimmed as well.
You should also communicate to your users in advance that the EOL
packages will disappear, and if necessary, instruct them to migrate to a
newer supported version. Having instructions for that procedure
published somewhere would be nice.
The old content under 7.5.1804, including any EOL content, will be
archived to vault.centos.org, and that content will be available in the
vault indefinitely. The 7.5.1804 directory on mirror.centos.org will be
emptied some time after 7.6.1810 is released.
For reference and inspiration, here are some directories from
mirror.centos.org, including both up-to-date content and potentially EOL
content. SIGs should review the list to make sure these directories can
be copied over to 7.6.1810 when that time comes. Making the decisions
now would save a bit of time at 7.6.1810 release time.
cloud/x86_64/openstack-ocata
cloud/x86_64/openstack-pike
cloud/x86_64/openstack-queens
cloud/x86_64/openstack-rocky
configmanagement/x86_64/ansible26
configmanagement/x86_64/yum4
dotnet
nfv/x86_64/fdio/vpp/vpp-1710
nfv/x86_64/fdio/vpp/vpp-1801
nfv/x86_64/fdio/vpp/vpp-1804
nfv/x86_64/fdio/vpp/vpp-1807
opstools/x86_64/common
opstools/x86_64/fluentd
opstools/x86_64/logging
opstools/x86_64/perfmon
opstools/x86_64/sensu
paas/x86_64/openshift-origin
paas/x86_64/openshift-origin13
paas/x86_64/openshift-origin14
paas/x86_64/openshift-origin15
paas/x86_64/openshift-origin36
paas/x86_64/openshift-origin37
paas/x86_64/openshift-origin38
paas/x86_64/openshift-origin39
paas/x86_64/openshift-origin310
sclo/x86_64/rh/devassist09
sclo/x86_64/rh/devtoolset-3
sclo/x86_64/rh/devtoolset-4
sclo/x86_64/rh/devtoolset-6
sclo/x86_64/rh/devtoolset-7
sclo/x86_64/rh/git19
sclo/x86_64/rh/go-toolset-7
sclo/x86_64/rh/httpd24
sclo/x86_64/rh/llvm-toolset-7
sclo/x86_64/rh/mariadb55
sclo/x86_64/rh/maven30
sclo/x86_64/rh/mongodb24
sclo/x86_64/rh/mysql55
sclo/x86_64/rh/nginx16
sclo/x86_64/rh/nodejs010
sclo/x86_64/rh/passenger40
sclo/x86_64/rh/perl516
sclo/x86_64/rh/php54
sclo/x86_64/rh/php55
sclo/x86_64/rh/postgresql92
sclo/x86_64/rh/python27
sclo/x86_64/rh/python33
sclo/x86_64/rh/python34
sclo/x86_64/rh/rh-eclipse46
sclo/x86_64/rh/rh-git29
sclo/x86_64/rh/rh-haproxy18
sclo/x86_64/rh/rh-java-common
sclo/x86_64/rh/rh-mariadb100
sclo/x86_64/rh/rh-mariadb101
sclo/x86_64/rh/rh-mariadb102
sclo/x86_64/rh/rh-maven33
sclo/x86_64/rh/rh-maven35
sclo/x86_64/rh/rh-mongodb26
sclo/x86_64/rh/rh-mongodb30upg
sclo/x86_64/rh/rh-mongodb32
sclo/x86_64/rh/rh-mongodb34
sclo/x86_64/rh/rh-mongodb36
sclo/x86_64/rh/rh-mysql56
sclo/x86_64/rh/rh-mysql57
sclo/x86_64/rh/rh-nginx18
sclo/x86_64/rh/rh-nginx110
sclo/x86_64/rh/rh-nginx112
sclo/x86_64/rh/rh-nodejs4
sclo/x86_64/rh/rh-nodejs6
sclo/x86_64/rh/rh-nodejs8
sclo/x86_64/rh/rh-perl520
sclo/x86_64/rh/rh-perl524
sclo/x86_64/rh/rh-perl526
sclo/x86_64/rh/rh-php56
sclo/x86_64/rh/rh-php70
sclo/x86_64/rh/rh-php71
sclo/x86_64/rh/rh-postgresql10
sclo/x86_64/rh/rh-postgresql94
sclo/x86_64/rh/rh-postgresql95
sclo/x86_64/rh/rh-postgresql96
sclo/x86_64/rh/rh-python35
sclo/x86_64/rh/rh-python36
sclo/x86_64/rh/rh-redis32
sclo/x86_64/rh/rh-ror42
sclo/x86_64/rh/rh-ror50
sclo/x86_64/rh/rh-ruby23
sclo/x86_64/rh/rh-ruby24
sclo/x86_64/rh/rh-ruby25
sclo/x86_64/rh/rh-scala210
sclo/x86_64/rh/rh-thermostat16
sclo/x86_64/rh/rh-varnish4
sclo/x86_64/rh/rh-varnish5
sclo/x86_64/rh/ror40
sclo/x86_64/rh/ror41
sclo/x86_64/rh/ruby193
sclo/x86_64/rh/ruby200
sclo/x86_64/rh/ruby22
sclo/x86_64/rh/rust-toolset-7
sclo/x86_64/rh/thermostat1
sclo/x86_64/rh/v8314
sclo/x86_64/sclo/sclo-cassandra3
sclo/x86_64/sclo/sclo-git25
sclo/x86_64/sclo/sclo-git212
sclo/x86_64/sclo/sclo-httpd24more
sclo/x86_64/sclo/sclo-php54
sclo/x86_64/sclo/sclo-php55
sclo/x86_64/sclo/sclo-php56
sclo/x86_64/sclo/sclo-php70
sclo/x86_64/sclo/sclo-php71
sclo/x86_64/sclo/sclo-python27
sclo/x86_64/sclo/sclo-python34
sclo/x86_64/sclo/sclo-python35
sclo/x86_64/sclo/sclo-ror42
sclo/x86_64/sclo/sclo-subversion19
sclo/x86_64/sclo/vagrant1
storage/x86_64/ceph-jewel
storage/x86_64/ceph-luminous
storage/x86_64/gluster-3.10
storage/x86_64/gluster-3.12
storage/x86_64/gluster-4.0
storage/x86_64/gluster-4.1
storage/x86_64/gluster-5
virt/x86_64/azure
virt/x86_64/kubernetes19
virt/x86_64/kubernetes110
virt/x86_64/kvm-common
virt/x86_64/libvirt-latest
virt/x86_64/ovirt-4.2
virt/x86_64/xen-46
virt/x86_64/xen-48
virt/x86_64/xen-410
In addition to those, ovirt-4.1 should have already been removed, but it
is still available in the altarch branch for aarch64 and ppc64le. This
is an error, which will hopefully get fixed this round.
Hi Folks,
I have a couple of problems and proposals that I'd like to discuss for
bugs.centos.org:
PROBLEM 1:
Currently when a user reports an issue it's very difficult for them to
know where to route things properly. The confusion seems to be between
projects and categories. For example, Ci.centos.org Ecosystem Testing is
the category under the Buildsys project that's supposed to be used for
both infrastructure issues and new account requests. It's not
immediately obvious that the user needs to select the Buildsys project
to get there though. If they do make it that far, but forget to choose
the Ci.centos.org ecosystem testing category , it may get assigned by
default to someone who are active in CentOS but outside of maintaining
the CICO infra (sorry alphacc and range!).
PROPOSAL: Move CentOS CI to it's own "Project" so that it shows up in
the dropdown list, and allow us to segment CI requests from SIG requests.
PROBLEM 2:
In the Buildsys project, once someone reports and issue, they can no
longer update it (ex: if they chose the wrong category, or no longer
have the issue and would like to close it). In a few projects like
Buildsys (and CICO) it makes sense to allow these folks a little freedom
in modifying some of the bug fields.
PROPOSAL: For the Buildsys and CICO projects -only- allow Reporters to
Close, Reopen, and Update their own issues. This would leave the Distro
and SIG projects unaffected.
I can make these changes if we're all happy. Are there any objections?
--
Brian Stinson
CentOS Infrastructure Team
If you would like to have anything in the December newsletter, please
get me something by Monday. The newsletter will go out on Tuesday,
December 4th.
Thanks.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
Hello all,
I've released livecd-tools v26.0 and it is making its way to Fedora
and Mageia now.
It is currently available in Rawhide, and will be in updates-testing
for Fedora 28 and 29 soon.
For Mageia, I've pushed it into Cauldron. It will be part of the
upcoming Mageia 7.
## What's new
This update adds some small changes to re-introduce compatibility with
EL7 distributions, such as Red Hat Enterprise Linux 7, CentOS 7, and
so on. This was made possible by the inclusion of DNF into Red Hat
Enterprise Linux 7.6. The changes were contributed by Pablo Greco from
the CentOS Project. Builds of livecd-tools and appliance-tools will be
provided in CentOS Extras at some point in the near future by Pablo.
ISO creation is now done using GNU Xorriso rather than cdrkit. This
was done because Xorriso is actively developed and receiving new
features. Also now, if the target distribution supports it, ISOs can
be created with ia32 and x64 UEFI support.
In addition, appliance-tools is now Python 3 compatible. The
ec2-converter tool is deprecated and slated for removal in the next
release, due to lack of maintenance and being utterly broken. If there
are any users of this tool, patches and pull requests welcome on
pagure.io: https://pagure.io/appliance-tools
RISC-V is now experimentally supported, thanks to David Abdurachmanov
of the Fedora RISC-V group.
Python 2 packaging of the imgcreate module has been dropped in Fedora
30+ and Mageia 7. It is still supported for CentOS 7.
## Now what?
Please check out the new release!
If you have any issues with livecd-tools or appliance-tools, please
file them either in Fedora or Mageia bug trackers, or preferably at
the appropriate project issue trackers:
* livecd-tools: https://github.com/livecd-tools/livecd-tools/issues
* appliance-tools: https://pagure.io/appliance-tools/issues
Have fun making live Linux systems!
Best regards,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
I am hitting infra issues with OpenShift running on CentOS CI.
Is it the right group to address those kind of issue? or maybe you can
refer me to an appropriate ML.
Thanks in advance,
Liora
--
*Liora Milbaum*
Senior Principal Software Engineer
RHV/CNV DevOps
EMEA VIRTUALIZATION R&D
T: +972-54-6560051
<https://red.ht/sig>