DevHeads.net

Postings by Nico Kadel-Garcia

centos-7.7 or centos-cr brakages building python3 packages with EPEL enabled

I've started testing with the "cr" repositorory enabled, and we are
going to have a *lot* of problems building EPEL packages unless we get
well ahead of the game.

RHEl has elected to publish their python3 modules as "python3-module",
and to obsolete "python36-module" names. All well and good, this will
help provide upgrade paths from EPEL. The problem is that they've also
updated "pythone_pkgversion" to be "3", instead of "36".

Preliminary RHEL 8 review

I've noticed a few things that may help other people setting up test
environments.

1) The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern.
This means that if you try, like me, to mount a DVD image and use it
as local yum repo for testing out kickstart setups and mock builds,
you need to address the multiple necessary repositories with the new
names.

2) For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.

3) Mock is going to be....

What base OS should I run koji on?

I'm afraid thus is the third time I've tried to get koji working to submit packages for EPEL and Fedora, and once again I'm stuck. I've activated a fresh Fedora 23 build, gotten my bugzillas and credentials working, but cannot make even a scratch rebuild if an existing Fedora SRPM for proof of concept test.

What base OS are people using for Koji packaging?

Re: [CentOS-devel] Critical update for bash was released today.

Given the mod_cgi effects, especially for Nagios and other servers, I'd urge caution and stage environment testing before mass deployment.

Nico Kadel-Garcia
Email: <a href="mailto: ... at gmail dot com"> ... at gmail dot com</a>
Sent from iPhone

git.centos.org search problem

On Sat, Jul 5, 2014 at 1:30 PM, Christoph Galuschka < ... at tigalch dot org> wrote:

import patch for centos-git-common/show_possible_srpms.sh

I'd mentioned this in a previous note, on a thread that got long:

I tried to submit this at bugs.centos.org, but there's not a category
there for 'centos-git-common' that I could easily find.

Back on CentOS-devel to get some git.centos.org improvements

Morning, folks. Happy July 4th.

I'm hopping back onto centos-devel to raise some concerns about
git.centos.org components. Overall it's working. There are things I
don't like, but as things stand that's *my* problem. These issues,
however, affect others, and I don't see a good bugzilla mentioned at
git.centos.org itself.

1) Many repositories are being listed with excessive "/" in their
names.

Getting koji access for some Perl tools

Hi, folks.

I've been active enough that an intro probably isn't needed, but I've
not successfully worked my way through the Fedora access to manage
particular packages nor have I gotten koji access. I'd particularly
like to get the old "mkrdns" tool into Fedora and EPEL, since it's a
personal favorite for auto-managing reverse DNS and it's very stable.

Is there someone who can walk me through the Fedora koji access
procedures? I've got Fedora 19 running in a VM, with access to my
github repositories.

systemd vs. SysV init script in .spec files for new packages

Good morning, folks:

I've been publishing a few packages for Repoforge and sent occasional
updates to EPEL, and I'd be happy to start getting them into Fedora.
While I work out how koji works, I note that the new use of systemd
means that the same SRPM cannot be used for both Fedora 18, and for
anything that runs a daemon and should be ported to EPEL.

I'm happy to write tools that use init scripts, or systemd scripts,
based on OS version. But are there best practices?

Door not hitting me on my way out

Sorry, folks. I wish our release developers well, and hope that they
can open up their processes to allow much needed community involvment.
But I've hopped to Scientific Linux and find it much more usable due
to their willingness to publish updates even without the entire new
release bundled, and the much timelier updates from the upstream
vendor. php53 and bind97 are directly available for their verison 5.x
release, and their version 6.0 has now taken over my testing
environments.

The delays on CentOS 5.6 are causing EPEL incompatibilities

There are significant components of the upstream 5.6 release which are
stuck behind the CentOS 5.6 release process, but are now incorporated
in EPEL 5 components. In particular, the "php53" package is now
necessary for the "drupal6" EPEL components, due to the long out of
date PHP 5.1 in the default upstream vendor's codebase.

I see that some of these components are available in the "testing"
repository at <a href="http://dev.centos.org/centos/5/CentOS-Testing.repo" title="http://dev.centos.org/centos/5/CentOS-Testing.repo">http://dev.centos.org/centos/5/CentOS-Testing.repo</a>. But
this isn't published with centos-release. fasttrack is.

nx.spec file with updates for CentOS 5/CentOS 6

Is there a planned "nx" releae for CentOS 6 extras? This turned out to
be pesky to compile under RHEL 6 for tstingq, because the
"audiofile-devel" package is not in the core channels, it's in the
"optional" channel. I've also updated the 'naxgent' component, and
merged overlapping components from the varous centos_ver releases to
make the common components clearly listed, and the differences handled
separately.

Significant speedup of package building with mock from EPEL for RHEL 6, should definitely go in CentOS 5

The speedups in building RPM's with "mock" from the EPEL packages for
RHEL 6 are *profound*, especially if your environment is like mine and
you have thousands of user id's. The issue seems to be the handling of
"/var/log/lastlog" and similar files, which are otherwise quite large
and take significant time to compress and uncompress when laying out
new mock environments.

Karabhir, what are the odds of encouragng a switch to
<a href="http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm" title="http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm">http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm</a>, and
backporting it to centos/5/5/extras ?

Is there a "mock" setup or downloadable list of tweaked packages for testing CentOS 6 builds?

I may be able to pry time free to test CentOS 6 builds. But I don't
want to burn useful worktime with building mock files and manually
rebuilding all the SRPM's. I've got access to licensed RHEL 6 to use
as a build environment, and to do what gcc does: build a "staging"
setup, then do a clean rebuild with that staging, then do a final
rebuild to make sure material matches and look for discrepancies.

Is this already done somewhere I can get a copy, so that I don't have
to burn time re-inventing the wheel?

Old thread:how many people still use NIS?

Good morning!

I've been offlist for years, and hopping back on for various reasons,
I see a thread that I'd like to add to. There's an old thread on NIS
use in Centrify that I'd like to add some comments to. I'm still
forced to work with NIS for various reasons, including interaction
with heavy duty NAS's that require it for NFSv4.

I have been busy falling in serious love with Centrify
(<a href="http://www.centrify.com" title="www.centrify.com">www.centrify.com</a>) for this. For an environment that already has an
extensive Active Directory investment, it's a way to save weeks or
months of expensive engineering time and get on with your job.