Re: [CentOS] How to encourage maintainers to update their software

[H]

On 10/28/2017 06:42 PM, Frank Cox wrote:
> On Sat, 28 Oct 2017 17:15:01 -0400
> H wrote:
>
>> The graphical configuration utility for fcitx (fcitx-configtool) is missing 
> I don't know anything about Chinese text rendering.
>
>> - The geany editor is missing the markdown plugin, this however, may shortly
>> be resolved.
> Check on my website. :)
>
> The rest of your stuff is easily dealt with by compiling the relevant Fedora 
> rpms.
>
>> I'd love to have keepassx updated
> Download this:
>
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
>
> and you can have this:
>
> keepassx-2.0.3-1.el7.centos.x86_64.rpm
>
> I just tried it and it took only a few minutes.
>
>> - pdfshuffler is not available for CentOS 7, only CentOS 6.
> I just compiled this
>
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
>
> It took about three seconds to do the whole job and now I have this:
>
> pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
>
> You can easily do the same if you wish.  Just install rpmdevtools and any 
> necessary dependencies for the rpm that you want to compile and  off you go.  
> The rpmbuild command will even tell you about any missing dependencies.  For 
> example, my first attempt at compiling keepassx told me:
>
> error: Failed build dependencies:
>   libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
>   libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
>
> To fix it I did this:
>
> yum install libXtst-devel libgcrypt-devel
>
> My next attempt to compile the keepassx rpm worked.
>
> This isn't a guaranteed solution for absolutely every rpm or program that you 
> might ever come across; sometimes you get into a dependency rabbit hole that 
> never seems to end and it becomes more work than it's worth to solve.  Other 
> times you get stuff that requires a newer or different version of something 
> that's way too much work to upgrade or change.  But in a lot of cases, you 
> can just download and compile your own rpm as needed.  As you see here, two 
> items on your wish list are easily handled this way in less than five 
> minutes.  It took me longer to write this email than it did to download and 
> compile those programs.
>
>
Thank you. I will set up the environment so I can compile apps on my computer.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Lamar Owen]

On 10/28/2017 01:28 PM, Japheth Cleaver wrote:
It didn't seem to use to be that case. IMO it makes a lot more sense 
to wrap distro-specific .spec file changes in conditionals and let the 
rpmbuild do the right thing than to post and maintain separate 
versions for Fedora, EPEL, and anything else. 
In my former role as package maintainer for the PostgreSQL development 
group several years ago, I was contracted to do RPMs for several 
different distributions.  And while this was several years ago, the 
basic RPM mechansims have not changed that significantly, and this kind 
of maintenance can become a rat's nest nightmare very quickly.  I found 
that, specifically for PostgreSQL, the complexity increase was not 
linearly proportional to the number of distributions and versions of 
distributions supported; rather, it was much more like a cubic or 
quartic relationship with multiple poles and zeroes (using Z transform 
terminology) and pitfalls everywhere.  The current PostgreSQL RPm 
maintainers do a great job supporting what they do, but it is not easy 
at all to support more than four distribution versions with one spec file.


Now, this thread is also talking about doing your own rebuilds, and, to 
a point, this works quite well.  Especially in cases where the EPEL 
maintainer simply refuses to update a package because it would cause a 
version bump of that particular package and 'version bumps require Deep 
Reasons' (paraphrased from an actual response).  My experience 
maintaining the PostgreSQL RPMs prepared me well for some of the things 
I have rebuilt (such as kicad) on C7.


HOWEVER, there is a hard and fast and totally inviolate rule to rolling 
your own rebuilds: "You break it, you keep it."  You are taking your own 
system's stability into your own hands; for some packages (like kicad, 
or gnuradio, or other relatively stand-alone packages that don't require 
major shared library replumbing) it's fairly easy and safe to do your 
own builds; for some packages it is going to be nearly impossible if the 
packages' upstream developers haven't made it easy to locally build 
their dependencies with the sometimes very specific version requirements 
(case in point: Ardour).  And some of these packages have no security 
footprint as far as updates are concerned (web browsers and email 
clients absolutely have major security footprints and need to stay 
updated, but something like kicad does not).


There are automated tools to do these sorts of things, such as the perl 
script 'smock' which does a reasonable job doing source build 
dependencies, as long as the buildrequires deps in the source RPM are 
proper and there are no hidden ones (experienced RPM rebuilders know I 
say that a bit tongue in cheek).  Whatever you do, do NOT rebuild as 
root.  Mock and similar tools make it possible to have reproducible 
builds, and it is strongly encouraged that these tools be used.


BUT, again, "you break it, you keep it" applies strongly because that 
package you built might have required a package that isn't currently in 
C7 but might be added at some future date, and your hand-built package 
might cause a real security update to fail in weird ways.  Caveat 
aedificator, perhaps?  You are then responsible to keep your hand-built 
dependency updated yourself.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[vychytraly .]

Thank you all very much for explaining this, it is very interesting topic :)

On Mon, Oct 30, 2017 at 12:27 PM, James Hogarth 
wrote:

> On 29 October 2017 at 13:40, vychytraly .  wrote:
> > Frank please could you explain how to create rpms for el7 from fedora
> > src.rpms?
> >
> >
>
> You may find this a useful read:
>
> https://www.hogarthuk.com/?q=node/11
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[James Hogarth]

On 29 October 2017 at 13:40, vychytraly .  wrote:
> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?
>
>

You may find this a useful read:

https://www.hogarthuk.com/?q=node/11
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Gregory P. Ennis]

On Sun, 29 Oct 2017 14:40:56 +0100
vychytraly . wrote:

> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?

The complexity of doing this will vary a lot with what you're trying to
compile, but for userland programs like email clients, text editors,
games and the like it can be very easy to do in a lot of cases.

As Johnny says, you don't really want to do this with core operating
system functions since you can end up with a Frankenstein system that
might not work properly any more.

In many cases (more than a few but by no means all) you can compile a
Fedora rpm for Centos using the following procedure.

.

Frank,

Thanks very much for explaining this process.  I would like to have
orthanc usable for Centos 7, but the epel repos only have it for Centos
6.  

I will give your outline a try!!!

Greg

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Frank Cox]

On Sun, 29 Oct 2017 14:40:56 +0100
vychytraly . wrote:

> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?

The complexity of doing this will vary a lot with what you're trying to 
compile, but for userland programs like email clients, text editors, games and 
the like it can be very easy to do in a lot of cases.

As Johnny says, you don't really want to do this with core operating system 
functions since you can end up with a Frankenstein system that might not work 
properly any more.

In many cases (more than a few but by no means all) you can compile a Fedora 
rpm for Centos using the following procedure.

You need to have rpmdevtools installed:

yum install rpmdevtools

Now set up the build directory structure in your home directory:

rpmdev-setuptree

After that, download the Fedora srpm, then run a rpmbuild command against the 
rpm you downloaded:

rpmbuild -ba nameofsourcerpm.src.rpm

Now you see what happens.  Sometimes the process will run and you'll end up 
with a rpm file in ~/rpmbuild/RPMS/.  If so, then you're done.  You've got the 
Centos rpm that you wanted.

If the process errors out then your next step depends on the nature of the 
error.  If it's a missing dependency then you might be able to simply install 
that dependency:

yum install nameofdependency

Then run the rpmbuild command again and see if it works.

If you can't find a pre-built rpm of the missing dependency then you might be 
able to build it yourself using the above process.  Or not.  It depends on the 
circumstances and what's missing.  If the program requires a newer version of a 
dependency that you already have installed, you might want to re-consier your 
plan at that point.  See above about creating a Frankenstein system.

If the process errors out due to something other than a missing dependency, 
things become a bit more complex at that point.  If you look in 
~/rpmbuild/SPECS you will find a .spec file for your rpm.  Crank up your text 
editor and inspect that and see what it's doing and where things go wrong.  
Sometimes it's useful to simply compile the original source file directly and 
see if that works.  (You can find that in ~/rpmbuild/SOURCES. )

If the original source file compiles but the rpm doesn't, then there's likely a 
fix that you need to do to the spec file to make it work.  Sometimes it's 
useful to compare the spec file for an older version that does work on Centos 
with the spec file for a newer version that doesn't, and see what changed.

If the source file doesn't compile then you have bigger problems to solve -- 
perhaps you need to patch the sources or perhaps it just plain won't work on 
Centos.  That's the place where I'll usually give up unless it's really 
important to me to get it to work.

If it is really important (that doesn't happen very often) then I keep a 
sacrificial Centos 7 Virtual Box image that I can use to experiment with 
changing some of the stuff that's under the hood without worrying about blowing 
up my main desktop.  But again, that doesn't happen very often.

Note that some Fedora stuff won't work on Centos.  Period.

But some stuff will work just fine.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Matthew Miller]

On Sat, Oct 28, 2017 at 12:36:33PM -0600, Frank Cox wrote:
> I don't want to tear my whole computer down and upgrade my operating
> system every six months, and I don't want to deal with the
> bleeding-edge stuff that might or might not work when it affects
> something like network connectivity or whether I actually get a
> picture on the screen when I boot up my computer. But for userland
> programs, why not run the latest version of Libreoffice or Cool
> Reader if it's easy to compile them and I can get a few new features
> out of it?

This is one of the reasons I'm in favor of bringing Flatpak to Fedora
(and presumably also eventually to CentOS). We have a project to
automatically convert Fedora packages to Flatpaks, which you could then
run on a CentOS base.

That's really just an approach for desktop apps, though. Fedora
Modularity aims to solve this for other software stacks, allowing you
to keep longer-lived streams for the stuff you don't want to change,
and faster streams for the stuff you do want different.

All that said, I do also feel *some* need to mention that Fedora gives
you a 13-month lifecycle, not six months. And, in most cases, you can
upgrade in under half an hour without no fuss.


-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Johnny Hughes]

On 10/29/2017 08:40 AM, vychytraly . wrote:
> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?
>

Well, I am not Frank, but you download the SRPM (I use wget) and put it
into a directory.

Then you extract it .. there are many ways to do that .. I do this:

rpm -Uvh --define "_topdir $(pwd)" --nodeps 

Then you have an exploded SRPM with a SPECS/ and SOURCES/ directory.
You then need to edit the SPECS/.spec file and verify each line in
the spec file will work with EL7 instead of fc25 (or whatever version of
Fedora you got the SRPM from).  This includes but is not limited to
knowing the differences in the rpm macros between that version of
Fedora's rpmbuild and CentOS 7's rpmbuild .. what the versions of shared
libraries (or other dependencies like python, etc.) are for that version
of Fedora and CentOS 7 .. which one of those shared dependencies are
required or can be degraded in version to the ones in CentOS 7.

Basically, the SRPMs from Fedora 18 generally had all the required
dependencies for RHEL / CentOS for the 7.0 release cycle source code ..
BUT with rebases in every point release since the 7.0 cycle,, that is no
longer true.  Now some components (like Gnome) have very newer
dependencies while others still have the dependencies from Fedora 18.

Fedora 18 stopped getting updates and went EOL on 2014-01-14 .. any
packages that you build based on those SRPMs need to get a new source
code stream so that you can continue to get security fixes .. or you
have to take the newer source code and backport the changes to the
Fedora 18 based SRPMS .. or you have to get newer versions of the
package and build it against the current CentOS 7 provided shared
dependencies, upgrading any dependencies that are too old.  THEN you
have to rebuild any other packages in CentOS that used the older
dependencies from CentOS 7 that you just upgraded.  THEN you need to
maintain not only the package that you wanted to build the way that you
just did .. now you also need to maintain all those dependencies that
way .. AND .. you need to maintain all of the new CentOS packages that
you had to rebuild based on those dependencies in the same way.  That
could mean that to add one thing, you now need to maintain 20 packages.

And if you are taking things from Fedora 25 (as an example) to CentOS 7,
you need to be concerned about things like .. a different location for
kernel install tools .. a different major version of python (python2 vs
python3) .. a majorly different version of GNOME and KDE, differences in
samba, in NFS, etc. etc.

Again, that is why Red Hat has thousands of engineers to maintain the
Enterprise Linux sources.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[vychytraly .]

Frank please could you explain how to create rpms for el7 from fedora
src.rpms?

On Sun, Oct 29, 2017 at 12:42 AM, Frank Cox  wrote:

> On Sat, 28 Oct 2017 17:15:01 -0400
> H wrote:
>
> > The graphical configuration utility for fcitx (fcitx-configtool) is
> missing
>
> I don't know anything about Chinese text rendering.
>
> > - The geany editor is missing the markdown plugin, this however, may
> shortly
> > be resolved.
>
> Check on my website. :)
>
> The rest of your stuff is easily dealt with by compiling the relevant
> Fedora rpms.
>
> > I'd love to have keepassx updated
>
> Download this:
>
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/
> Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
>
> and you can have this:
>
> keepassx-2.0.3-1.el7.centos.x86_64.rpm
>
> I just tried it and it took only a few minutes.
>
> > - pdfshuffler is not available for CentOS 7, only CentOS 6.
>
> I just compiled this
>
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/
> Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
>
> It took about three seconds to do the whole job and now I have this:
>
> pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
>
> You can easily do the same if you wish.  Just install rpmdevtools and any
> necessary dependencies for the rpm that you want to compile and  off you
> go.  The rpmbuild command will even tell you about any missing
> dependencies.  For example, my first attempt at compiling keepassx told me:
>
> error: Failed build dependencies:
> libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
> libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
>
> To fix it I did this:
>
> yum install libXtst-devel libgcrypt-devel
>
> My next attempt to compile the keepassx rpm worked.
>
> This isn't a guaranteed solution for absolutely every rpm or program that
> you might ever come across; sometimes you get into a dependency rabbit hole
> that never seems to end and it becomes more work than it's worth to solve.
> Other times you get stuff that requires a newer or different version of
> something that's way too much work to upgrade or change.  But in a lot of
> cases, you can just download and compile your own rpm as needed.  As you
> see here, two items on your wish list are easily handled this way in less
> than five minutes.  It took me longer to write this email than it did to
> download and compile those programs.
>
>
> --
> MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Johnny Hughes]

On 10/28/2017 05:42 PM, Frank Cox wrote:
> On Sat, 28 Oct 2017 17:15:01 -0400
> H wrote:
> 
>> The graphical configuration utility for fcitx (fcitx-configtool) is missing 
> 
> I don't know anything about Chinese text rendering.
> 
>> - The geany editor is missing the markdown plugin, this however, may shortly
>> be resolved.
> 
> Check on my website. :)
> 
> The rest of your stuff is easily dealt with by compiling the relevant Fedora 
> rpms.
> 
>> I'd love to have keepassx updated
> 
> Download this:
> 
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
> 
> and you can have this:
> 
> keepassx-2.0.3-1.el7.centos.x86_64.rpm
> 
> I just tried it and it took only a few minutes.
> 
>> - pdfshuffler is not available for CentOS 7, only CentOS 6.
> 
> I just compiled this
> 
> ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
> 
> It took about three seconds to do the whole job and now I have this:
> 
> pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
> 
> You can easily do the same if you wish.  Just install rpmdevtools and any 
> necessary dependencies for the rpm that you want to compile and  off you go.  
> The rpmbuild command will even tell you about any missing dependencies.  For 
> example, my first attempt at compiling keepassx told me:
> 
> error: Failed build dependencies:
>   libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
>   libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
> 
> To fix it I did this:
> 
> yum install libXtst-devel libgcrypt-devel
> 
> My next attempt to compile the keepassx rpm worked.
> 
> This isn't a guaranteed solution for absolutely every rpm or program that you 
> might ever come across; sometimes you get into a dependency rabbit hole that 
> never seems to end and it becomes more work than it's worth to solve.  Other 
> times you get stuff that requires a newer or different version of something 
> that's way too much work to upgrade or change.  But in a lot of cases, you 
> can just download and compile your own rpm as needed.  As you see here, two 
> items on your wish list are easily handled this way in less than five 
> minutes.  It took me longer to write this email than it did to download and 
> compile those programs.
> 
> 

The problem with compiling the relevant fedora SRPMs is .. once fedora
moves to a version (in their tree) that no longer compiles on CentOS
because of shared library issues, any security updates dry up.  If you
have not found an upstream (of Fedora) source for updates for that
version of the software in question, you either have to learn how to
backport (https://access.redhat.com/security/updates/backporting), live
with software that contains security issues, or compile a newer version
of Fedora's software.  Many times, that means adding in a newer version
of dependent shared libraries.  And that can mean having to recompile
other things that depended on the shared libraries that you upgraded (or
building statically, etc.).

I recently had to go through that with the 3.18.x kernel that we used in
the Xen4CentOS repo in the Virt SIG.  I worked on another LTS kernel
(4.9.x) for about a month before 3.18.x went EOL from kernel.org .. then
it took us about another 2 months of testing in the Virt SIG to get a
fairly stable kernel build that worked for the xen Dom0 kernel.

The reason that every package in Fedora which is removed from RHEL is
not in EPEL is that it is very hard to properly backport items and find
new streams of updates that can keep older ABI/API compatibility and
main software secure after the project that maintains it moves on.  It
is also a major reason Red Hat employs thousands of engineers to do it
and why people pay them billions of dollars a year to maintain it.

So yes, it can be done .. but if you are trying to do it for 10 or so
years, it is not easy.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Johnny Hughes]

On 10/28/2017 01:36 PM, Frank Cox wrote:
> On Sat, 28 Oct 2017 13:07:41 -0500
> Johnny Hughes wrote:
> 
>>  But trying to convert CentOS Linux into Fedora is not only redundant
>> (Fedora already exists .. use it) .. a bastardized version of CentOS
>> with hundreds of newer manually maintained components is not really
>> CentOS, and Fedora is likely more stable than that monstrosity anyway.
> 
> There's a difference between upgrading core operating system functionality 
> and a changing a few userland programs.  I compile the latest versions of 
> Sylpheed and astyle (for example) and use those programs on my Centos 7 
> desktop computer.  I don't see any issue with doing things like this and 
> don't believe that it decreases the stability of the system.
> 
> I don't want to tear my whole computer down and upgrade my operating system 
> every six months, and I don't want to deal with the bleeding-edge stuff that 
> might or might not work when it affects something like network connectivity 
> or whether I actually get a picture on the screen when I boot up my computer. 
>  But for userland programs, why not run the latest version of Libreoffice or  
> Cool Reader if it's easy to compile them and I can get a few new features out 
> of it?
> 

And as long as that works and they compile against the base shared
libraries, that is fine.

But that is usually NOT the case and newer versions of LibreOffice or
the others usually need a newer gtk or newer something else, etc.

I am all for adding content that does not exist .. if there is a long
term upstream for it.  I am, for example, adding a 4.9.x LTS kernel for
newer x86_64 or i386 embedded type boards that can also be used on newer
hardware if required
(https://wiki.centos.org/SpecialInterestGroup/AltArch/i386 , see
Experimental Repository)

But, it took me longer (and more effort) to make that one package work
with CentOS Linux 7 than it took for me to create the first 7.0.1406 tree.




signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Frank Cox]

On Sat, 28 Oct 2017 17:15:01 -0400
H wrote:

> The graphical configuration utility for fcitx (fcitx-configtool) is missing 

I don't know anything about Chinese text rendering.

> - The geany editor is missing the markdown plugin, this however, may shortly
> be resolved.

Check on my website. :)

The rest of your stuff is easily dealt with by compiling the relevant Fedora 
rpms.

> I'd love to have keepassx updated

Download this:

ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm

and you can have this:

keepassx-2.0.3-1.el7.centos.x86_64.rpm

I just tried it and it took only a few minutes.

> - pdfshuffler is not available for CentOS 7, only CentOS 6.

I just compiled this

ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm

It took about three seconds to do the whole job and now I have this:

pdfshuffler-0.6.0-9.el7.centos.noarch.rpm

You can easily do the same if you wish.  Just install rpmdevtools and any 
necessary dependencies for the rpm that you want to compile and  off you go.  
The rpmbuild command will even tell you about any missing dependencies.  For 
example, my first attempt at compiling keepassx told me:

error: Failed build dependencies:
libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64

To fix it I did this:

yum install libXtst-devel libgcrypt-devel

My next attempt to compile the keepassx rpm worked.

This isn't a guaranteed solution for absolutely every rpm or program that you 
might ever come across; sometimes you get into a dependency rabbit hole that 
never seems to end and it becomes more work than it's worth to solve.  Other 
times you get stuff that requires a newer or different version of something 
that's way too much work to upgrade or change.  But in a lot of cases, you can 
just download and compile your own rpm as needed.  As you see here, two items 
on your wish list are easily handled this way in less than five minutes.  It 
took me longer to write this email than it did to download and compile those 
programs.


-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[H]

On 10/28/2017 02:07 PM, Johnny Hughes wrote:
> On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
>> On 10/27/2017 2:54 PM, Frank Cox wrote:
>>> I do that with a number of packages that are either newer or simply
>>> not available in the various Centos repos.  In many cases it's as easy
>>> as downloading a new tar source file and adding it to the existing
>>> source rpm, doing three seconds of editing on the spec file to account
>>> for the new update, and compiling the result.  Sometimes it's even
>>> easier -- just download a newer Fedora rpm and compile that on your
>>> Centos system.
>>>
>> It would be nice if this remained even a *suggestion* at the Fedora
>> layer, but there seems to be from occasional obliviousness to outright
>> hostility to the idea of keeping spec files broadly compatible across a
>> range of downstream releases and for other RPM-based distributions, or
>> not ripping out compatibility at Fedora-speed. (Even leaving aside
>> "burn-the-ships" actions like outright banning SysV init scripts.)
>>
>> It didn't seem to use to be that case. IMO it makes a lot more sense to
>> wrap distro-specific .spec file changes in conditionals and let the
>> rpmbuild do the right thing than to post and maintain separate versions
>> for Fedora, EPEL, and anything else.
> If people want all the newer packages that exist in Fedora .. why not
> just use Fedora?
>
> Enterprise distributions are designed to be maintained for 10 years so
> when you make an investment of X million dollars in a piece of software,
> you can use it for an extended period of time.  Having all the latest
> packages is not what Enterprise Linux is about.  That is what Fedora is
> about.
>
> Fedora has introduced a new feature called modularity
> (https://docs.pagure.org/modularity/).  Eventually, when / if modularity
> is rolled into Red Hat Enterprise Linux, you will get some more
> flexibility in RHEL (and therefore CentOS as we use RHEL sources).
>
> CentOS Linux is a great Linux distribution.  We want everyone to use it.
>  But trying to convert CentOS Linux into Fedora is not only redundant
> (Fedora already exists .. use it) .. a bastardized version of CentOS
> with hundreds of newer manually maintained components is not really
> CentOS, and Fedora is likely more stable than that monstrosity anyway.
>
> There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG,
> etc.), and those can be done now and integrated into the Enterprise
> Distro.  If those are what you need, that is what they're for.
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

Well, I am trying to get a couple of applications compiled that I believe are 
quite compatible with the positioning of CentOS:

- The graphical configuration utility for fcitx (fcitx-configtool) is missing 
and any configuration presently has to be done by manually editing the complex 
configuration files which are very poorly documented. Thus configuration of 
fcitx for e.g. entering/editing Chinese text took a long time and I still have 
a couple of issues that I have been unable to resolve.

- The geany editor is missing the markdown plugin, this however, may shortly be 
resolved.

- I'd love to have keepassx updated so bugs are fixed and the file format 
becomes compatible with the file format used by its Windows counterpart and 
files thus interchanged without any problems.

- pdfshuffler is not available for CentOS 7, only CentOS 6.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Frank Cox]

On Sat, 28 Oct 2017 13:07:41 -0500
Johnny Hughes wrote:

>  But trying to convert CentOS Linux into Fedora is not only redundant
> (Fedora already exists .. use it) .. a bastardized version of CentOS
> with hundreds of newer manually maintained components is not really
> CentOS, and Fedora is likely more stable than that monstrosity anyway.

There's a difference between upgrading core operating system functionality and 
a changing a few userland programs.  I compile the latest versions of Sylpheed 
and astyle (for example) and use those programs on my Centos 7 desktop 
computer.  I don't see any issue with doing things like this and don't believe 
that it decreases the stability of the system.

I don't want to tear my whole computer down and upgrade my operating system 
every six months, and I don't want to deal with the bleeding-edge stuff that 
might or might not work when it affects something like network connectivity or 
whether I actually get a picture on the screen when I boot up my computer.  But 
for userland programs, why not run the latest version of Libreoffice or  Cool 
Reader if it's easy to compile them and I can get a few new features out of it?

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Johnny Hughes]

On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
> On 10/27/2017 2:54 PM, Frank Cox wrote:
>>
>> I do that with a number of packages that are either newer or simply
>> not available in the various Centos repos.  In many cases it's as easy
>> as downloading a new tar source file and adding it to the existing
>> source rpm, doing three seconds of editing on the spec file to account
>> for the new update, and compiling the result.  Sometimes it's even
>> easier -- just download a newer Fedora rpm and compile that on your
>> Centos system.
>>
> It would be nice if this remained even a *suggestion* at the Fedora
> layer, but there seems to be from occasional obliviousness to outright
> hostility to the idea of keeping spec files broadly compatible across a
> range of downstream releases and for other RPM-based distributions, or
> not ripping out compatibility at Fedora-speed. (Even leaving aside
> "burn-the-ships" actions like outright banning SysV init scripts.)
> 
> It didn't seem to use to be that case. IMO it makes a lot more sense to
> wrap distro-specific .spec file changes in conditionals and let the
> rpmbuild do the right thing than to post and maintain separate versions
> for Fedora, EPEL, and anything else.

If people want all the newer packages that exist in Fedora .. why not
just use Fedora?

Enterprise distributions are designed to be maintained for 10 years so
when you make an investment of X million dollars in a piece of software,
you can use it for an extended period of time.  Having all the latest
packages is not what Enterprise Linux is about.  That is what Fedora is
about.

Fedora has introduced a new feature called modularity
(https://docs.pagure.org/modularity/).  Eventually, when / if modularity
is rolled into Red Hat Enterprise Linux, you will get some more
flexibility in RHEL (and therefore CentOS as we use RHEL sources).

CentOS Linux is a great Linux distribution.  We want everyone to use it.
 But trying to convert CentOS Linux into Fedora is not only redundant
(Fedora already exists .. use it) .. a bastardized version of CentOS
with hundreds of newer manually maintained components is not really
CentOS, and Fedora is likely more stable than that monstrosity anyway.

There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG,
etc.), and those can be done now and integrated into the Enterprise
Distro.  If those are what you need, that is what they're for.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Japheth Cleaver]

On 10/27/2017 2:54 PM, Frank Cox wrote:


I do that with a number of packages that are either newer or simply not 
available in the various Centos repos.  In many cases it's as easy as 
downloading a new tar source file and adding it to the existing source rpm, 
doing three seconds of editing on the spec file to account for the new update, 
and compiling the result.  Sometimes it's even easier -- just download a newer 
Fedora rpm and compile that on your Centos system.

It would be nice if this remained even a *suggestion* at the Fedora 
layer, but there seems to be from occasional obliviousness to outright 
hostility to the idea of keeping spec files broadly compatible across a 
range of downstream releases and for other RPM-based distributions, or 
not ripping out compatibility at Fedora-speed. (Even leaving aside 
"burn-the-ships" actions like outright banning SysV init scripts.)


It didn't seem to use to be that case. IMO it makes a lot more sense to 
wrap distro-specific .spec file changes in conditionals and let the 
rpmbuild do the right thing than to post and maintain separate versions 
for Fedora, EPEL, and anything else.



-jc

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Johnny Hughes]

On 10/28/2017 11:33 AM, H wrote:
> On October 27, 2017 5:54:45 PM EDT, Frank Cox  wrote:
>> On Fri, 27 Oct 2017 17:32:03 -0400
>> H wrote:
>>
>>> How do I best encourage maintainers to update the software they are
>>> responsible for in various repositories?
>>
>> If it's something that you need or want and it's not available in a
>> repo that you currently use you can compile it yourself.
>>
>> I do that with a number of packages that are either newer or simply not
>> available in the various Centos repos.  In many cases it's as easy as
>> downloading a new tar source file and adding it to the existing source
>> rpm, doing three seconds of editing on the spec file to account for the
>> new update, and compiling the result.  Sometimes it's even easier --
>> just download a newer Fedora rpm and compile that on your Centos
>> system.

In a lot of instances, the upstream program's project that maintains it
prohibits upgrades / updates by the requirements for their software.

Sometimes it will require a newer gcc to compile, or a newer php to run,
or newer gtk+ or newer something else.  This would require many changes
to build on older versions of shared libraries in Enterprise Linux
distros.  This is a choice by the project that controls that software.

Backporting (https://access.redhat.com/security/updates/backporting) is
very difficult, and is a main reason that RHEL needs to be a paid for
service.  People want stable, long lived software that is secure for the
enterprise.  That is the whole purpose of this type of distribution.
You can't really expect repo maintainers to have the skills or time to
backport newer software to an Enterprise distro.  If the project that
maintains that software wants it to work in the enterprise, they should
maintain long term support for their software.





signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[H]

On October 27, 2017 5:54:45 PM EDT, Frank Cox  wrote:
>On Fri, 27 Oct 2017 17:32:03 -0400
>H wrote:
>
>> How do I best encourage maintainers to update the software they are
>> responsible for in various repositories?
>
>If it's something that you need or want and it's not available in a
>repo that you currently use you can compile it yourself.
>
>I do that with a number of packages that are either newer or simply not
>available in the various Centos repos.  In many cases it's as easy as
>downloading a new tar source file and adding it to the existing source
>rpm, doing three seconds of editing on the spec file to account for the
>new update, and compiling the result.  Sometimes it's even easier --
>just download a newer Fedora rpm and compile that on your Centos
>system.
>
>-- 
>MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
>___
>CentOS mailing list
>CentOS@centos.org
>https://lists.centos.org/mailman/listinfo/centos

These are software packages listed in various repositories, thus ostensibly 
maintained...
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[Frank Cox]

On Fri, 27 Oct 2017 17:32:03 -0400
H wrote:

> How do I best encourage maintainers to update the software they are
> responsible for in various repositories?

If it's something that you need or want and it's not available in a repo that 
you currently use you can compile it yourself.

I do that with a number of packages that are either newer or simply not 
available in the various Centos repos.  In many cases it's as easy as 
downloading a new tar source file and adding it to the existing source rpm, 
doing three seconds of editing on the spec file to account for the new update, 
and compiling the result.  Sometimes it's even easier -- just download a newer 
Fedora rpm and compile that on your Centos system.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos