devel November 2018

devel@lists.centos.org

33 participants
29 discussions

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

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

16 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

Centpkg and the converged git project
by Brian Stinson 22 Feb '19

22 Feb '19

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

2 1

[CentOS-docs] Authorization to use CentOS logo in GNOME Boxes
by Ladar Levison 21 Feb '19

21 Feb '19

> 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

5 18

new repo for "centos-release-ceph-nautilus"
by Ken Dreyer 04 Dec '18

04 Dec '18

Hi Niels, I'm looking to create a new "centos-release-ceph-nautilus" package, like the "luminous" one we have today at https://github.com/CentOS-Storage-SIG/centos-release-ceph-luminous I'm wondering if it would be easier to keep all of these in a single "centos-release-ceph" repository, with per-release branches. Would you be up for creating a https://github.com/CentOS-Storage-SIG/centos-release-ceph repo? - Ken

6 13

Monday deadline to get something into the December newsletter
by Rich Bowen 30 Nov '18

30 Nov '18

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

1 0

SIGs: Possibility to drop EOL content at 7.6.1810 release time
by Anssi Johansson 28 Nov '18

28 Nov '18

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.

7 12

Some propsed changes in bugs.centos.org (permissions updates, and reorganization)
by Brian Stinson 28 Nov '18

28 Nov '18

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

3 3

SIG reports for December newsletter?
by Rich Bowen 27 Nov '18

27 Nov '18

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

1 0

Announcement: livecd-tools v26.0 and appliance-tools v009.0
by Neal Gompa 24 Nov '18

24 Nov '18

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!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel November 2018