[Bug 1536234] perl-BDB-1.92 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1536234

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-BDB-1.92-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-22 02:41:54



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Tomasz Kłoczko]

On 22 January 2018 at 02:12, R P Herrold  wrote:
[..]
>> If it is common in case of EL7/EL6 EPEL packages consumers it is perfect
>> reason to not bother EPEL on master branch because Fedora has noting out
>> from such end users and keeping all EL6/EL7 adjustments are only slowing
>> down Fedora development by making specs less readable.
>
> Tomasz
>
> Do you have statistics about the number of packages
> 'migrating' from Fedoraproject to RHEL, vs the number of EPEL
> packages doing the same

In case RHEL .. nope.
I've already been thinking about this however as I have no access to
devel RHEL source I cannot do this.
In case of EPEL packages as I already wrote flow of new/updated
packages to EPEL is minute compare to Fedora in recent months.
EPEL/EL7 has ~6.5k src.rpm were Fedora ~20k. Using this as reference
pints would be possible to expect that EPEL/EL7 flow should be around
1/4 of Fedora, but it is not like this.
EPEL/EL7 flow is way lower.

I can only guess that generally as RH is doing major update every few
years watching constantly on Fedora for RH people does not make to
much sense for them.
Best would be first hand some opinion someone from RH.
Still I hope that this tread will be read by someone from RH ..

> It is all well and good to have a fast moving playground
> environment, but some (and particularly, I) actually use both
> as sources for solving needs of paying customers

Problem only is that as Fedora is on the constant move but RH doesn't.
Main RH goal is delivery solid distro, then security fixes and some
other critical fixes. Only occasionally they are updating some set of
packages.
Just had a look on CentOS updates and I've took zsh src.rpm.
Spec from this package does not look at all like Fedora.
Last Fedora entry in %changelog is from 2013.
From this point in Fedora has been made about 30 changes than RH has
only 3 and there have not been copied from Fedora.
I've checked next few packages and situation looks the same.

So looks like RH already few years ago stopped using Fedora as set of
reference packages.

> and EPEL, for me, is the more fruitful one from which to build
> solutions on top of CentOS (and not Fedora's more short lived,
> properly 'not concerned' about long term supportability
> offerings)

In EPEL/EL7 is 6551 source packages. After remove %{rhel} <5 and
convert this to %{el6}/%{el7} it will be possible more precise to say
how many packages rally has for example el7 %ifings.
Compare those two numbers may deliver new data about EPEL health.
I would be not surprised if number of src.rpm packages will be
significantly greater than %{el7} %ifings which will be some kind of
sign that EPEL health on top of Fedora packages is not so good as many
people are thinking.

What I'm worry it is that this supportability is only kind of fata
morgana/ilution and RH effectively spitted long time ago from Fedora
without telling about this to Fedora developers.
More and more small evidences says me that it may be truth.
In other case it would be possible to see as well kind of RH feedback
about some crucial Fedora changes.
Simple I cannot find traces of such discussions (however maybe I'm
looking in wrong place).
Other fact which may cut this knot is volume EPEL related bugs/issues
reported over bugzilla.

Nevertheless I think that 2 out of my 8 points are ready to PRs.
As it will take some time to raise->approve->finish those changes
still is a lot of time to colect more facts and make some decisions
about other 6 points.

PS. If you have any propositions to do some analyse as I'm every day
syncing not only Fedora but few other distros packages (+all Fedora
git repos and Debian sources as well) it is easier for me to execute
some oneliner to produce some numbers.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL analyse/observation, some question, PR proposals/questions and more ..

[Tomasz Kłoczko]

On 22 January 2018 at 03:39, Neal Gompa  wrote:
[..]
>
> Multi-distro spec files in itself aren't that bad. In my experience,
> the things that drag you down are the Debian/Ubuntu and RHEL/SLE
> targets. But they eventually catch up. However, the sad reality is,
> you can only go so far without improvements (i.e. backports) to older
> distributions.

Of curse that it is not that bad :D

If you want I can show some example single spec can be used to build
el6, el7, Fedora, Amazon Linux and .. even Solaris 11.3 native IPS
packages
Solaris pkgbuild (it is quite simple perl script) uses rpm spec to
describe whole build process and at the end is generating from spec
%files .p5m file which is used kind of buildroot base directory on
export to IPS repository.
In IPS packages exist only in repo and there is no such thing like
package as the file/archinve. IPS allows export package to file which
can only be used to import in other repository.
Single package can support more than one architecture so for example
as well sharing files like documentation on install the same package
in 32 and 64 ABI is not a problem.
If you want you can peak on such multiarch package manifes in repo:
http://pkg.oracle.com/solaris/release/manifest/0/file%2Fmc@4.8.13%2C5.11-0.175.3.0.0.30.0%3A20150821T165151Z
In this manifest lines you can find:

file ba41c36ccd08352201bb13c6409ab013de19a308
chash=26520b34314cc2b0577809090182bd9a8c81d0d1 elfarch=i386 elfbits=64
elfhash=37e0b220d4cde4870763be86ac3ad6269586d02e group=bin mode=0555
owner=root path=usr/bin/mc pkg.csize=680939 pkg.size=1995352
variant.arch=i386

and

file e8067864f4ada9ebb89de4118d51b60a3210f416
chash=f4b47ddfbb250c35a9613e320ca8225ef6e0cc07 elfarch=sparc
elfbits=64 elfhash=1fbb23058504895c30bd6e2eed284a6f4374b12c group=bin
mode=0555 owner=root path=usr/bin/mc pkg.csize=666593 pkg.size=1698664
variant.arch=sparc

Which describes file on exactly the same path but in two arch .. all
in single package.
As the same repository can keep multiple versions of the same package
automatically IPS repo shares/duplicates those files which have not
been changed between versions.


So (back to the subject) as you see it is really "aren't that bad".
There are only few not good consequences:
- as long as after upgrade package package to new and you have no
possibility instantly test all supported in spec distros or OSes
sooner or later some variants will be dead
- it is not possible to do such things on large scale because lets say
if such universal spec will be OK on Fedora but it will be failing on
other distros/OSess sooner or later people will start thinking that
such universality is not advantage but disadvantage/obstacle as it
adds some additional chunk of man/hour to maintain single package.
- keeping all variants in healthy state requires from all packagers at
least basic knowledge/skills on use/maintain other distros/OSess.

Writing universal spec will be kind "good intention" however some
saying says that "the road to hell is paved with good intentions".

For example distance between SLE and RH/Fedora in methodologies and
macros suits is so big that transferring source packages is not
possible.
Some time Fedora decided to spread all possible to use rpm macros from
redhat-rpm-config maaany development packages which can provide some
subsets of new macros.
Only this (and nothing more) started even bigger split between Fedora
and all other rpm distros as now no one is able to control or review
in single package all possible to use macros.
IMO it will take few year for all Fedora packages to realize how bad
such decision was (even for only Fedora).

Nevertheless all this is way off-topic of my original email :)

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL analyse/observation, some question, PR proposals/questions and more ..

[Tomasz Kłoczko]

On 22 January 2018 at 03:10, Stephen John Smoogen  wrote:

> On 21 January 2018 at 15:54, Tomasz Kłoczko 
> wrote:
>
[..]

> > 8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up
> to
> > ABI level so all this should be:
> >
> > a) removed
> > b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
> > c) if ContOS guys are using Fedora gir repos to preserve some CentOS
> > specific changes they should move all this stuff to own git (create
> project
> > on github it is not rocket science). IMO definitely %{centos} is next
> > candidate to remove from master branch.
>
> It might help to do some further research before speculating.


I've done my reserch.
These a, b and c points are not speculations.
They describes 3 only possibilities explanations about what needs to be
done.
Other facts which other people replaying on may email may only shorten this
list os possible to do scenarios.


> The CentOS 'guys' do maintain everything in their repo.


OK so here you just gave me +1 for a). Thx.

You are somehow
> assuming that other maintainers only maintain packages in Fedora for
> Fedora. They don't. They may use the same spec with slight changes in

all kinds of subprojects and tools, and Fedora is just yet another
> operating system to them. So I would go search for all kinds of things
> like mageia, suse, even debian in the spec files as they may show up
> because the maintainer wants that spec file to work elsewhere also.
>

Please discuss this with yourself because I had no such though even for
fraction of the second.
Please stop reading between the lines. Please read what I wrote straight.

The issue is that to a various developers, the package is just a step
> they need to fill out to get the package into Fedora, CentOS, RHEL,
> Mageia, etc.


So now you are assuming things taken from nowhere :)
Just checked and all specs from Fedora master and I found 3 Fedora specs
with Mageia %ifings.

[tkloczko@domek SPECS.fedora]$ for i in mageia; do grep '%{?'$i * |awk -F\.
'{print $1}' | uniq ; done
mock-core-configs
mock
rust-packaging

Just checked mock from Fedora master and Mageia.
In Fedora is mock 1.4.8. In Mageia 1.4.2. Mageia is using completely
different spec with removed all distro type or version %ifings.
It is not the same spec as this one in Fedora.
In Mageia mock-core-configs is in the same version but uses it uses
completely different spec.
rust-packaging as well as mock-core-configs is in the same version as in
Fedora but again .. spec is completely different.

Just one test:

$ diff -u rust-packaging.spec.mageia rust-packaging.spec | diffstat
 rust-packaging.spec |   82

 1 file changed, 51 insertions(+), 31 deletions(-)

Next time try to spend at least few seconds to verification something
before forming some speculations.

Thank you to point that remove Mageia %ifings is next possible (small this
time) thing to do.


> They pull in what they want to make it work and could
> give a care if it is readable to anyone else. They know it has to pass
> some rules, but beyond that anything that causes them more headaches
> like extra branching, etc is just a reason to tell the person who is
> pushing it to go jump in a lake. It has nothing to do with the EPEL
> project, the CentOS project, RHEL, or anything else. It has to do with
> the developer/maintainer of the package getting what they want for the
> least amount of effort because they have 10k other things they MUST
> work on instead.
>

I've just checked it and it is not true.
Mageia people are using own set of specs.
They've done what was not possible to do up to now in Fedora.
They are using in all specs the same indentation which is quite close to
style which I've proposed first time more than ~24 years ago submitting
biggest part  of the packages to RHCN.

Fedora has no standard on this area and most of the packagers are using
BecauseWeCan(tm) format/indentation.
Because Mageia people are using some standard (whatever this standard is)
looks like they are using Fedora spec only on start maintaining some new
packages.
In other words by definition they cannot share results of they own work.
Such standard on indentation is MAJOR OBSTACLE on sharing/reusing every
change between any distributions and Fedora.

Until you, Igor and others start engaging the maintainers to
> understand why doing those things solve problems for them.. and why
> they aren't moving to newer tools.. this is not going to end well.
>

Really sorry but this is EXACTLY what I'm doing here :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL analyse/observation, some question, PR proposals/questions and more ..

[Neal Gompa]

On Sun, Jan 21, 2018 at 10:10 PM, Stephen John Smoogen  wrote:
> On 21 January 2018 at 15:54, Tomasz Kłoczko  wrote:
>> As preface some oneliner result:
>>
>
>> 8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up to
>> ABI level so all this should be:
>>
>> a) removed
>> b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
>> c) if ContOS guys are using Fedora gir repos to preserve some CentOS
>> specific changes they should move all this stuff to own git (create project
>> on github it is not rocket science). IMO definitely %{centos} is next
>> candidate to remove from master branch.
>>
>
> It might help to do some further research before speculating. The
> CentOS 'guys' do maintain everything in their repo. You are somehow
> assuming that other maintainers only maintain packages in Fedora for
> Fedora. They don't. They may use the same spec with slight changes in
> all kinds of subprojects and tools, and Fedora is just yet another
> operating system to them. So I would go search for all kinds of things
> like mageia, suse, even debian in the spec files as they may show up
> because the maintainer wants that spec file to work elsewhere also.
>

I will heartily second this. I do my best to minimize the
conditionals, of course, but I do regularly build spec files that
build RPMs for Fedora, Mageia, openSUSE, and of course CentOS/RHEL.
Many of my spec files will also trivially build native Debian packages
with the "debbuild" tool for Debian and Ubuntu. And at $DAYJOB, we do
this literally all the time (Fedora / Ubuntu dual capability with spec
files and OBS).

While most of the non-RPM distro stuff tends to not be in my spec
files in Fedora, nearly all of my personal ones do support it.

> The issue is that to a various developers, the package is just a step
> they need to fill out to get the package into Fedora, CentOS, RHEL,
> Mageia, etc. They pull in what they want to make it work and could
> give a care if it is readable to anyone else. They know it has to pass
> some rules, but beyond that anything that causes them more headaches
> like extra branching, etc is just a reason to tell the person who is
> pushing it to go jump in a lake. It has nothing to do with the EPEL
> project, the CentOS project, RHEL, or anything else. It has to do with
> the developer/maintainer of the package getting what they want for the
> least amount of effort because they have 10k other things they MUST
> work on instead.
>

Personally, I'd like it to be easier to make multi-distro spec files
by leveraging the increasing commonality among distributions. It's
already not that bad these days, the main issue is what RPM features
are supported for each target distribution. Making things less ugly
for gracefully degrading would be very nice. :)

> Until you, Igor and others start engaging the maintainers to
> understand why doing those things solve problems for them.. and why
> they aren't moving to newer tools.. this is not going to end well.
>

Multi-distro spec files in itself aren't that bad. In my experience,
the things that drag you down are the Debian/Ubuntu and RHEL/SLE
targets. But they eventually catch up. However, the sad reality is,
you can only go so far without improvements (i.e. backports) to older
distributions.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL analyse/observation, some question, PR proposals/questions and more ..

[Stephen John Smoogen]

On 21 January 2018 at 15:54, Tomasz Kłoczko  wrote:
> As preface some oneliner result:
>

> 8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up to
> ABI level so all this should be:
>
> a) removed
> b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
> c) if ContOS guys are using Fedora gir repos to preserve some CentOS
> specific changes they should move all this stuff to own git (create project
> on github it is not rocket science). IMO definitely %{centos} is next
> candidate to remove from master branch.
>

It might help to do some further research before speculating. The
CentOS 'guys' do maintain everything in their repo. You are somehow
assuming that other maintainers only maintain packages in Fedora for
Fedora. They don't. They may use the same spec with slight changes in
all kinds of subprojects and tools, and Fedora is just yet another
operating system to them. So I would go search for all kinds of things
like mageia, suse, even debian in the spec files as they may show up
because the maintainer wants that spec file to work elsewhere also.

The issue is that to a various developers, the package is just a step
they need to fill out to get the package into Fedora, CentOS, RHEL,
Mageia, etc. They pull in what they want to make it work and could
give a care if it is readable to anyone else. They know it has to pass
some rules, but beyond that anything that causes them more headaches
like extra branching, etc is just a reason to tell the person who is
pushing it to go jump in a lake. It has nothing to do with the EPEL
project, the CentOS project, RHEL, or anything else. It has to do with
the developer/maintainer of the package getting what they want for the
least amount of effort because they have 10k other things they MUST
work on instead.

Until you, Igor and others start engaging the maintainers to
understand why doing those things solve problems for them.. and why
they aren't moving to newer tools.. this is not going to end well.

>
> Next will try to have closer look on %{rhel}, %{epel} and %{centos} %ifings
> to form more and/or more precise conclusions/observations.
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Stephen John Smoogen]

On 21 January 2018 at 15:07, Tomasz Kłoczko  wrote:
> On 21 January 2018 at 17:26, Stephen John Smoogen  wrote:
>>
>> On 20 January 2018 at 21:00, Tomasz Kłoczko 
>> wrote:
>> > On 20 January 2018 at 23:26, Stephen John Smoogen 
>> > wrote:
>> > [..]
>> >>
>> >> As EPEL is the only reason I stay in Fedora.. I would like to make
>> >> sure it doesn't cause developers that much problems. As such I would
>> >> be interested in seeing if the macros that Neal said could be better
>> >> implemented throughout the releases.
>> >
>> > Can you tell which one EPEL packages you are using?
>>
>>
>> There isn't one EPEL package I use. I help run the group and I 'use'
>> the packages that are in it for the Fedora Infrastructure to run. That
>> goes from everything from stuff on EL6 for the ask.fedoraproject.org
>> to EL7 for most other things.
>
>
> So (quoting you) "As EPEL is the only reason I stay in Fedora" you want to
> say that you are you are not interested at all Fedora but only some EL6/EPEL
> packages.
> Is that correct?

No that is not correct. I expect I am relying on a figure of speech
which does not translate well. I work in Fedora to make packages work
in EPEL because the people using EPEL are the ones I am interested in
serving. However, I realize that EPEL can cause problems for some
features and want to look for ways to make that less painful for the
organization as a whole.


> If it is common in case of EL7/EL6 EPEL packages consumers it is perfect
> reason to not bother EPEL on master branch because Fedora has noting out
> from such end users and keeping all EL6/EL7 adjustments are only slowing
> down Fedora development by making specs less readable.

I expect that you would find that even if EPEL were to go away, those
would stay there because a large number of developers want them there
for other needs. They will cargo cult what they had for many releases
because they know it works and whatever new method is going to cause
problems they don't have time to deal with. Trying to force them to do
this has never worked and constantly causes fights because no one is
listening to each other anymore.  What does happen is people having
spectacular flame-outs with epic temper tantrums before leaving in
disgust. I am trying to not have this happen by pointing out what does
work.

What does seem to work is showing them and training them that some new
method will help and then figure out what they were really trying to
solve with the 'magic script' they had before. Taking the time to
answer what may seem like stupid questions over and over again as they
unlearn what they were doing before.



>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[R P Herrold]

On Sun, 21 Jan 2018, Tomasz K?oczko wrote:

> If it is common in case of EL7/EL6 EPEL packages consumers it is perfect
> reason to not bother EPEL on master branch because Fedora has noting out
> from such end users and keeping all EL6/EL7 adjustments are only slowing
> down Fedora development by making specs less readable.

Tomasz

Do you have statistics about the number of packages 
'migrating' from Fedoraproject to RHEL, vs the number of EPEL 
packages doing the same

It is all well and good to have a fast moving playground 
environment, but some (and particularly, I) actually use both 
as sources for solving needs of paying customers

and EPEL, for me, is the more fruitful one from which to build 
solutions on top of CentOS (and not Fedora's more short lived, 
properly 'not concerned' about long term supportability 
offerings)

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unresponsive maintainer

[Greg Evenden]

you might even be better to catch him over on the SUSE IRC channels, it might 
be worth a shot to see if anyone in SUSE Packages those packages an are up to 
date an Grab the Source RPM's from there 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unresponsive maintainer

[Tao Zhao]

Hi Mamoru,

Thanks for the information! I've pinged his gmail. Let's see how it goes.

Regards,
Alick

On Sat, Jan 20, 2018 at 1:57 AM, Mamoru TASAKA
 wrote:
> Hello,
>
> alick9...@gmail.com wrote on 01/20/2018 12:59 PM:
>>
>> Hi All,
>>
>> As per
>> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
>> I am posting here to see if anyone know how to contact Christoph Wickert
>> (cwickert).
>>
>> The bug report is at https://bugzilla.redhat.com/show_bug.cgi?id=1530114
>>
>
> Maybe christoph.wickert _AT_ gmail.com would reach him.
>
> He no longer uses Fedora, ref:
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/YRLYVW2ZSYT7XSANF7RAGTEZMPE5GAYV/
>
> Regards,
> Mamoru
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build fails on s390x - complains about missing /usr/lib64/lib*.so* file

[Alexander Ploumistos]

Thanks Artur, Antonio Trande has also made some suggestions in the
review, I will try them and if nothing changes, I will report the
issue upstream.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

EPEL analyse/observation, some question, PR proposals/questions and more ..

[Tomasz Kłoczko]

As preface some oneliner result:

[tkloczko@domek SPECS.fedora]$ for i in el4 el5 el6 el7 rhel centos epel;
do echo -n "$i "; grep '%{?'$i * | wc -l; done
el4 10
el5 243
el6 265
el7 281
rhel 5428
centos 239
epel 45

1) Shortly I'm going to create PR with mass change request to remove all
EL4 and EL5 conditional builds as EL{5,6} are no longer supported.

2) Looks like in recent months number of new/updated EPEL EL6/EL7 packages
dropped down to between few to about 20 a month with sometimes tents
thousands a month Fedora updates on master weight/cost of all EPEL %ifings
is few magnitudes higher than real outcome.

FTR: I'm going to add this to final list of arguments/facts why all EPEL
maintenance should be moved to branches when I'll be sending email with
list of arguments about why EPEL support should be removed from master.

3) When PR with request to remove from master EL{4,5} support will be
finished I'm going to raise next mass change request will be about remove
all <= F25 as all those Fedora versions as well should be no longer
supported on master.

4)  I think that Fedora procedures should be updated when some older
version passes EOS. Just after this automatically should be dome mass
update removing support such EOSed version.

5) kind of proposal about change general policy
In many specs I found some commented lines with notes like "Remove before
F".

[tkloczko@domek SPECS.fedora]$ grep -i "remove before f" * | wc -l
161

I think that making such notes should be forbidden and exact set of lines
should be wrapped by %ifing (without addition comments),
This will make cyclic all legacy stuff cleanups easier/possible to perform
using very simple script/oneliner.
Q: is it enough to raise next PR about update Fedora doc about above?

6) I think that all %{rhel} %ifings should be removed or replaced by %{el6}
and %{el7}.
Reason: it duplicated description of the same things.
Q: PR?

7) Like in 6) the same is with %{epel} %ifings

8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up to
ABI level so all this should be:

a) removed
b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
c) if ContOS guys are using Fedora gir repos to preserve some CentOS
specific changes they should move all this stuff to own git (create project
on github it is not rocket science). IMO definitely %{centos} is next
candidate to remove from master branch.


Next will try to have closer look on %{rhel}, %{epel} and %{centos} %ifings
to form more and/or more precise conclusions/observations.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Tomasz Kłoczko]

On 21 January 2018 at 17:26, Stephen John Smoogen  wrote:

> On 20 January 2018 at 21:00, Tomasz Kłoczko 
> wrote:
> > On 20 January 2018 at 23:26, Stephen John Smoogen 
> wrote:
> > [..]
> >>
> >> As EPEL is the only reason I stay in Fedora.. I would like to make
> >> sure it doesn't cause developers that much problems. As such I would
> >> be interested in seeing if the macros that Neal said could be better
> >> implemented throughout the releases.
> >
> > Can you tell which one EPEL packages you are using?
>
>
> There isn't one EPEL package I use. I help run the group and I 'use'
> the packages that are in it for the Fedora Infrastructure to run. That
> goes from everything from stuff on EL6 for the ask.fedoraproject.org
> to EL7 for most other things.
>

So (quoting you) "As EPEL is the only reason I stay in Fedora" you want to
say that you are you are not interested at all Fedora but only some
EL6/EPEL packages.
Is that correct?
If it is common in case of EL7/EL6 EPEL packages consumers it is perfect
reason to not bother EPEL on master branch because Fedora has noting out
from such end users and keeping all EL6/EL7 adjustments are only slowing
down Fedora development by making specs less readable.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: make yum repo when we build things in koji

[Lars Seipel]

On Fri, Jan 19, 2018 at 10:53:30PM -0500, Dusty Mabe wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
> On 01/19/2018 10:39 PM, Reindl Harald wrote:
> > 
> > 
> > [harry@srv-rhsoft:~]$ cat /etc/yum.repos.d/koji.repo
> > [koji]
> > name=Koji Repo
> > baseurl=https://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/
> > enabled=0
> > skip_if_unavailable=1
> > gpgcheck=0
> > sslverify=0
> 
> Thanks!
> I didn't know about this, but it's not exactly what I'm looking for because 
> that seems
> to includ everything that has been built. I'm looking more specifically for 
> just a repo
> with a particular rpm in it.

Use includepkgs in the repo definition?

> includepkgs Inverse of exclude, yum will exclude any package in the  repo.  
> that  doesn't  match  this
> list.  This  works  in  conjunction with exclude and doesn't override it, so 
> if you exclude=*.i386 and
> includepkgs=python* then only packages starting with python that do not have 
> an  i386  arch.  will  be
> seen by yum in this repo.

See yum.conf(5).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Stephen John Smoogen]

On 21 January 2018 at 14:06, Howard Howell  wrote:
> On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
>> Folks, please move this discussion to us...@lists.fedoraproject.org.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> HI, Igor,
> I posted here on purpose.  Users cannot change the direction of
> Linux, only you guys, the developers, have that capability.  I like the
> direction the discussion has taken. I want the group to think
> responsibily about the users.  Not just the technology, because
> technology that is not useful on a widely distributed operating system
> is not beneficial to anyone.
>

Posting a diatribe to the devel list usually has the opposite effect
than getting people to think about things.

First off this list does not develop Wayland. It does not develop
GNOME or KDE. It may incorporate those into the finished OS but it is
too late in the process to change the direction.

Second, most of the people on this list have no say in what is going
on there and have no way to 'change direction'. The people who agree
with you on this aren't doing anything to change direction.. saying "I
agree" doesn't mean that anyone is fixing anything or finding why
something is crashing, etc. It doesn't mean that any developer who
actually works on the stuff is going to see your emails.

Third, if you actually wanted to change people's opinions you would
not have come into this list like a drunk with a broken bottle.
Calling a project a disaster, mis-spelling it constantly like it was a
slur, and not actually putting any details like bug reports screams "I
am just here to abuse you for your work." It says to the people who
might actually have the power to fix to ignore it  and send the thread
to spam. Yes you have people saying "I agree" but they aren't actually
moving the conversation forward... they are just echoing empty
affirmation. It doesn't mean anyone is going to do anything.. and
thinking that it does is foolish.

> As to my misspelling of Wayland, that is ignorance on my part.
> I regret that, but as they say, it's on the internet, and immortal.
>

Thank you for the apology. I would say to start this over again do the
following:

1. Research your actual problems. Get bug reports. If you are having
problems figuring them out ask on the appropriate list "Hey I am
having a problem using Wayland on my . It is crashing when I do . I don't
know how to debug this better."
2. Don't post an email with a drama queen title calling something a
disaster or "end of the world". Be clear and concise.


> Regards,
> Les H
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Chris Murphy]

On Sun, Jan 21, 2018 at 5:06 AM, Graham Leggett  wrote:
> On 20 Jan 2018, at 8:24 PM, Alec Leamas  wrote:
>
>>>  I'm sorry, but wyland is a disaster for me.  I do work on lots
>>> of different software platforms, and things are just not working well.
>>> They kind-of-work, which is the really worst condition one can have.
>>
>> For me, this looks more like a support issue and as such doesn't not
>> belong to this development list. I suggest that you:
>
> I disagree, this looks like an overarching observation of interest to the 
> development community. Anyone else seen this as a pattern?


Not really. There are no cited bug reports. The description lacks any
specificity pointing toward a graphics driver problem vs a particular
Wayland compositor problem vs a bug related to legacy applications
interfacing with XWayland?

Now if you want to go down the rabbit hole of how tedious it is for
users to file bugs...


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Howard Howell]

On Sun, 2018-01-21 at 15:25 +0100, Igor Gnatenko wrote:
> Folks, please move this discussion to us...@lists.fedoraproject.org.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
HI, Igor,
I posted here on purpose.  Users cannot change the direction of
Linux, only you guys, the developers, have that capability.  I like the
direction the discussion has taken. I want the group to think
responsibily about the users.  Not just the technology, because
technology that is not useful on a widely distributed operating system
is not beneficial to anyone.

As to my misspelling of Wayland, that is ignorance on my part. 
I regret that, but as they say, it's on the internet, and immortal.

Regards,
Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1536694] perl-Catalyst-Runtime-5.90116 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1536694

Emmanuel Seyman  changed:

   What|Removed |Added

External Bug ID||CPAN 124136



--- Comment #1 from Emmanuel Seyman  ---
This release fails on multiple systems (including Fedora).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Build fails on s390x - complains about missing /usr/lib64/lib*.so* file

[Artur Iwicki]

I took a quick look at build.log for i686, x86_64 and s390x and one thing I've 
noticed is that during make install, the s390x build puts the .so files in 
%{buildroot}/usr/lib, not %{buildroot}/usr/lib64. The only thing that comes to 
my mind now is the qmake script (or some other part of the build process) not 
recognizing s390x's bitness properly, thus installing the .so files in the 
wrong directory.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1531386] Upgrade perl-File-Copy-Recursive to 0.39

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1531386



--- Comment #1 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c81167e5c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1531386] Upgrade perl-File-Copy-Recursive to 0.39

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1531386



--- Comment #2 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-1.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c4fad2711

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Build fails on s390x - complains about missing /usr/lib64/lib*.so* file

[Alexander Ploumistos]

Hello,

I submitted a package for review[0] about an hour ago and when I ran a
scratch build in koji[1] there was a failure with this message in
build.log:

error: File not found:
/builddir/build/BUILDROOT/molsketch-0.5.1-2.fc28.s390x/usr/lib64/lib*.so*

I had built previous versions of the same package successfully in the
past, with the last successful build either in late December or early
January. Other than irrelevant code changes upstream, the only thing
that changed between then and now was the removal of the
gtk-update-icon-cache scriptlets.
Can anyone shed some light on this?

Regards,
Alex


0. https://bugzilla.redhat.com/show_bug.cgi?id=1536852
1. https://koji.fedoraproject.org/koji/taskinfo?taskID=24348629
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1534797] perl-Mojolicious-7.61 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1534797

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.61-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2018-01-21 12:49:38



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1019619

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Stephen John Smoogen]

On 20 January 2018 at 21:00, Tomasz Kłoczko  wrote:
> On 20 January 2018 at 23:26, Stephen John Smoogen  wrote:
> [..]
>>
>> As EPEL is the only reason I stay in Fedora.. I would like to make
>> sure it doesn't cause developers that much problems. As such I would
>> be interested in seeing if the macros that Neal said could be better
>> implemented throughout the releases.
>
>
> Can you tell which one EPEL packages you are using?
>

There isn't one EPEL package I use. I help run the group and I 'use'
the packages that are in it for the Fedora Infrastructure to run. That
goes from everything from stuff on EL6 for the ask.fedoraproject.org
to EL7 for most other things.


> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Folks, please move this discussion to us...@lists.fedoraproject.org.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpkotIACgkQaVcUvRu8
X0wsgg/9FSdQ+lpGrm8DdSU62Ie7p7Wp2hRTzT69aXavOBYIJ3ecEsjFNIo1VUEJ
AUaP7p7fn0ckROs8vgcx/KXEPXwEm5QnI4fWk2biOie3cyTGi+ejeycpeQCIObNd
o9xVoMnM8PMKWGUKdjmkq0/S53o+1b+Yzobv/gPtqM2qJ5qjLVyR0KEyHyUQJtYS
gSLwIrWRzPzPUZ90N1O8NJjCjTic20rSwl5a+Vf411W8TublFRIlQ+6845zgLdKL
r5kFg3JfOaxNzvBp/rCV381h7YVOQpj19fXG46BtpCVAwIsZcYDB+ClFyyjT9LP6
SeHObNUQd2E5JVerLGw3wRGjfZSx/c5oAdXofTV6K1KpU2BOwy8LI8k2Pc47lUot
xf/4jHb/KadVkm4uwbu1T9kg1JWpAjVW1ybLnkYG79LqBBFGXQ7VZQKq3gi7lI7u
vgQAZ/+apJtkRx12Fy7nSgYHG/9yWOkIkPzXURoX0kEpBdNjcCPq7k7O+5nLYkeC
j8oiliHLSZ5JPUb0Fkdnas5hx9HMzoeMCQ1Ra6+J9Pq6hGBkxUciq9iTV+kY19XT
wl9OZf6fbmkMyh20OhjPV5H4H3FDFVXbGPQAAnaC1j2k+ZTw05KgfUZmJhJlcEir
wP7gBRglV1ueYdw8rA8WcMobQyInS9qoZ0qhr40SPfyzLUgkCOI=
=qK0H
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Francesco Frassinelli]

On 21/01/18 13:06, Graham Leggett wrote:
> On 20 Jan 2018, at 8:24 PM, Alec Leamas  wrote:
>
>>> I'm sorry, but wyland is a disaster for me.  I do work on lots
>>> of different software platforms, and things are just not working well. 
>>> They kind-of-work, which is the really worst condition one can have. 
>> For me, this looks more like a support issue and as such doesn't not
>> belong to this development list. I suggest that you:
> I disagree, this looks like an overarching observation of interest to the 
> development community. Anyone else seen this as a pattern?
I started to see it when I realized that most of the crashes that where
reported to me by users (forums, chats, face-to-face) were related
(directly or indirectly) to Wayland: every time that I heard someone
with an application that won't start or crashes every time after a few
clicks, I suggest to report the bug (and a strange Gnome Abrt pops-up
with two or three buttons labeled "Report" "Report" "Report") and switch
temporary to Xorg, which fixes the problem most of the time.

When users see that a Xorg session works as expected and they gain
nothing valuable to them from using Wayland, they stick with Xorg. They
realize that their crashes are not related to bugs in their code (many
of them don't, so they blame Audacity, Pitivi, Steam, etc.), but to
Wayland or some other related component, they start to avoid the
Gnome/Wayland session and it is reasonable to receive mails like the one
from Howard Howell (the user who started this discussion).

Note: some users have a password-less account, and it is not possible to
set an alternative session from GDM if you have no password (the gear
icon appears only when GDM prompts for the password), so the user should
set a password first, log out, select Gnome with Xorg, log in, remove
the password (this is not related with Wayland, it is just a usability
issue with GDM and/or with the Gnome user settings control panel).


Cheers,
Frafra
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Things which are on collision course between Fedora and RHEL/EPEL on master branch

[Paul Howarth]

On Sat, 20 Jan 2018 16:43:23 +0100
Igor Gnatenko  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, 2018-01-20 at 15:27 +, Tomasz Kłoczko wrote:
> > Just for the record list of things which are now on crash course
> > with EPEL/RHEL Fedora which are widely used in Fedora specs:
> > On EPEL/RHEL in spec must be present in spec:
> > - BuildRoot
> > - %clean
> > - %defattr() in %files
> > 
> > NO ONE adds now any %ifings around those parts of the specs (just
> > please do not propose start doing this )
> > Especially remove %defattr() breaks RHEL/EPEL compatibility causing
> > that in case of many packages files no longer will be owned by
> > root:root but by user on which package is built.  
> 
> That's not true. Those are not needed since RHEL6.

And %defattr wasn't even needed on RHEL5.

Another thing that can safely be removed from EPEL-6 specs is the
Group: tag.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1049  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 811  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 393  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 291  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 123  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  60  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28611aa33f   
python-bottle-0.12.13-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-885bb5ec89   
poco-1.6.1-3.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-85e532c970   
transmission-2.92-11.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73feedd767   
wordpress-4.9.2-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-11ba3bced1   
clamav-0.99.2-18.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

adapta-gtk-theme-3.93.0.66-1.el7
liferea-1.12.1-1.el7
lightdm-1.25.1-5.el7
lynis-2.6.0-1.el7
mint-y-theme-1.2.4-1.el7
perl-IPTables-ChainMgr-1.6-5.el7
python-msgpack-0.5.1-1.el7
s3cmd-2.0.1-1.el7

Details about builds:



 adapta-gtk-theme-3.93.0.66-1.el7 (FEDORA-EPEL-2018-9789110634)
 An adaptive Gtk+ theme based on Material Design Guidelines

Update Information:

- Initial rpm release - New upstream release

References:

  [ 1 ] Bug #1535991 - adapta-gtk-theme-3.93.0.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1535991
  [ 2 ] Bug #1535451 - adapta-gtk-theme-3.93.0.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1535451
  [ 3 ] Bug #1534976 - adapta-gtk-theme-3.93.0.49 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1534976
  [ 4 ] Bug #1534246 - adapta-gtk-theme-3.93.0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1534246
  [ 5 ] Bug #1529593 - Review Request: adapta-gtk-theme - An adaptive Gtk+ 
theme based on Material Design Guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=1529593




 liferea-1.12.1-1.el7 (FEDORA-EPEL-2018-132fb29c05)
 An RSS/RDF feed reader

Update Information:

Add liferea to EPEL 7

References:

  [ 1 ] Bug #1431067 - [RFE] Please build this for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1431067




 lightdm-1.25.1-5.el7 (FEDORA-EPEL-2018-ecc5aba2bf)
 A cross-desktop Display Manager

Update Information:

* New upstream release * Several fixes for claiming DBus service name

References:

  [ 1 ] Bug #1428379 - start lightdm after dbus
https://bugzilla.redhat.com/show_bug.cgi?id=1428379
  [ 2 ] Bug #1535730 - lightdm-1.25.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1535730




 lynis-2.6.0-1.el7 (FEDORA-EPEL-2018-3cdbd5ed53)
 Security and system auditing tool

Update Information:

Update to 2.6.0 (rhbz #1536241)    Update to 2.5.9 (rhbz #1534521)

References:

  [ 1 ] Bug #1536241 - lynis-2.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1536241
  [ 2 ] Bug #1534521 - lynis-2.5.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1534521

[Bug 1389064] EPEL7 branch missing (required for psad)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1389064

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-IPTables-ChainMgr-1.6-5.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-89e4f0f7f9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 921  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 811  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 783  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 393  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 123  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fde8252ab7   
python-bottle-0.12.13-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ba6bfc5d8   
wordpress-4.9.2-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

lynis-2.6.0-1.el6

Details about builds:



 lynis-2.6.0-1.el6 (FEDORA-EPEL-2018-662dedbc1f)
 Security and system auditing tool

Update Information:

Update to 2.6.0 (rhbz #1536241)    Update to 2.5.9 (rhbz #1534521)

References:

  [ 1 ] Bug #1536241 - lynis-2.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1536241
  [ 2 ] Bug #1534521 - lynis-2.5.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1534521

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 20, 2018 at 08:53:17AM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, 2018-01-20 at 00:51 +, Tim Landscheidt wrote:
> > Igor Gnatenko  wrote:
> > 
> > > […]
> > > > I was not fully aware of this and I've personally hit this difficulty
> > > > not on my proposal of the remove hicolor icon caches but on proposing,
> > > > for example, OpenIPMI or readline changes.
> > > > Most of my changes were by those packages maintainers simple discarded
> > > > (readline 100% and in case OpenIPMI ~50%).
> > > > I'm not trying to blame anyone here but all this only *result* of some
> > > > assumptions that master branch must be fully compatible with more than
> > > > one distribution or more than one distribution versions.
> > > Well, I think because this is simply easy. If we separate changelog to
> > > other
> > > file / make it auto-generated, then it should be easier for people to
> > > maintain
> > > f26/f27/master branches separately. Right now, cherry-picking is never
> > > cleanly
> > > applies due to changelog. Well, we need to do something with Release field
> > > as
> > > well, I don't know why it is still not auto-generated...
> > > […]
> > 
> > GNU had the same problem in various projects and came up
> > with a Git merge driver for changelogs
> > (http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-chan
> > gelog.c).
> > Now that is a text parsing orgy in C, probably provably cor-
> > rect, but it suggests that a simpler solution for RPM spec
> > files should be very feasible.
> 
> OMG!
> 
> Would you be interested to write such driver for RPM specs?

The gnulib changlog driver is already packaged as git-merge-changelog,
if that helps in any way.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1531386] Upgrade perl-File-Copy-Recursive to 0.39

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1531386
Bug 1531386 depends on bug 1531380, which changed state.

Bug 1531380 Summary: Review Request: perl-Path-Iter - Simple Efficient Path 
Iteration
https://bugzilla.redhat.com/show_bug.cgi?id=1531380

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Tom Hughes]

On 21/01/18 12:06, Graham Leggett wrote:

On 20 Jan 2018, at 8:24 PM, Alec Leamas  wrote:


I'm sorry, but wyland is a disaster for me.  I do work on lots
of different software platforms, and things are just not working well.
They kind-of-work, which is the really worst condition one can have.


For me, this looks more like a support issue and as such doesn't not
belong to this development list. I suggest that you:


I disagree, this looks like an overarching observation of interest to the development community. 


Not really. It's a grab bag of different things that may or not be 
related to Wayland.


As Alec said, it's a support issue for now where each point needs to be 
investigated to determine a cause.



Anyone else seen this as a pattern?


No.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Graham Leggett]

On 20 Jan 2018, at 8:24 PM, Alec Leamas  wrote:

>>  I'm sorry, but wyland is a disaster for me.  I do work on lots
>> of different software platforms, and things are just not working well. 
>> They kind-of-work, which is the really worst condition one can have. 
> 
> For me, this looks more like a support issue and as such doesn't not
> belong to this development list. I suggest that you:

I disagree, this looks like an overarching observation of interest to the 
development community. Anyone else seen this as a pattern?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org