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

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-22 at 07:40 +, Tomasz Kłoczko wrote:
> 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.

Note that RHEL/CentOS doesn't have to copy specs 1:1. AFAIK it never was that
specs were 100% same. However, I'm pretty sure that "branching" RHEL is
happening from Fedora.

> 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.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlplmbQACgkQaVcUvRu8
X0zWaBAApug1T/3LJIo8g2O10wFkzhnIMyDnrgmMv5kF+Qo8ViHojHNAWLJ3JG7p
yeqRJSQGXz90GTYviUNgUDC2CHusXFQZO1NDevrqy8pK39N2aqOgTxsnvBB7De+E
hE2jYvTgF676uTQXNuSla/1zUXkwS/ptgwyY6pIx/UL2CMPvoFRfSS6Be8LxHHya
c2gms6sz9qt4iNywUDGtDjB+bJb9hcVFpHYR5D8LyvPBUZ+oC4V0ur/10RXRoibM
9Ct8JSb859M2DqDFN8Q3ENxvj+lv21L0xc4SqDarqYGoSIvdmPRrPNHqqhIuXcQ0
guDf0kpfW0440gY0MHp53dsHhkGFUWEiLuCQ4c1awn/mU+WeoimG1sbdmr3hpr2/
4aLTO0NW4ePkssHlGHhZVvrvbxRdaqV9nVyOvhdfOQUe79XWD5nhi1N/uq82C2O8
6qnwQZLvDFCaX2XkCNSEmhQrEnJfKsEi0JYMGq2XCEvpxlQ3Nz9UO0WDQXeGDjb6
CNiD2fz85vsAm+OwBV4ugwEZU7CFrSAkVqP4TmFcj0KZgEI6facikHdZX267z+Sp
os/m/A6j191at5Wwzp2kZ/5WQXXTuYTWpZHYAu8NumlyorCXeP22OK1j/kpUEOTi
C3muNc4pn6Ur2LwP/zotrSgzJcm44A

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

[Tomasz Kłoczko]

On 22 January 2018 at 07:58, Igor Gnatenko
 wrote:
[..]
>> On 22 January 2018 at 02:12, R P Herrold  wrote:
>> [..]
>> 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.
>
> Note that RHEL/CentOS doesn't have to copy specs 1:1. AFAIK it never was that
> specs were 100% same. However, I'm pretty sure that "branching" RHEL is
> happening from Fedora.

It happens only when next major EL release is made.
https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_with_Fedora
After make major release no one cares what happen next in Fedora.
Looking on the graph on the wiki I think that EL8 will be released
more likely within 2 years if not three.

Effectively Fedora has not to much from relation with RH *between*
major EL releases in form of straight contribution to Fedora constant
changes. They may be sending back some fixes done for RHEL customers
but that is all. However as we are talking about CVEs and other
critical changes it is IMO more likely that after submitting such
fixes to original source code maintainers most of those changes are
coming to Fedora in form of next version source tar balls than
patches.

However looks like most of the whole weight on Fedora comes not from
RH relation but from maintenance EPEL packages. As all those changes
looks like must be done for EPEL/EL{6,7} it adds next level of
complexity.

I'm not proposing to remove EPEL changes completely but move 100% to
separated branches without any traces on the master branch.
Now with git syncing time to time some selected Fedora changes
is/should be way easier.
Remove as many %ifings as possible coming from all el*, centos, rhel
(with converting them on first stage to el %ifings) will allow bring
much easier to read/analyse/improve state of all specs.

Nevertheless looks like next thing which could be done is review
branches in Fedora repos and generate few numbers. Will try to do this
in next few days.

Still have no clear answer what was behind centos and epel %ifings,
and I'm looking for new facts or stories to tell by people introducing
those %ifings.

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)

[Mark Wielaard]

On Sat, Jan 20, 2018 at 12:27:38PM +0100, Igor Gnatenko wrote:
> Why I'm writing this? I want to hear from you if you think it would be
> good to prohibit (or advise, or whatever mechanism would work) usage if
> conditionals in (at least) master branch to allow us to develop features
> faster. Thoughts?  Suggestions?

Personally I try to keep my package spec files buildable as is on
Fedora, CentOS and for SCL (DTS devtoolset). To me this is really
useful because it means I can easily provide the latest and greatest
features of my package once fixes hit Fedora rawhide. You can then just
automatically provide them to users through copr for older Fedora/CentOS.
By having some small SCL macros you can then also provide them as
part of a software collection. If newer rpm spec features would be
backported (or maybe provided as SCL?) on CentOS 6 and 7 then I would
certainly use them.

Cheers,

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

Re: Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Dennis Gilmore]

El jue, 18-01-2018 a las 14:33 -0500, Matthew Miller escribió:
> On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer wrote:
> > > Given that Python 2 is going EOL in about two years, I don't
> > > think we
> > > want it in EPEL proper. If we do provide it, it should be in a
> > > module.
> > 
> > You're referring to EPEL > 7, right? 
> 
> For Python, yes.
> 
> >   Also, that last part is kind of
> > a leap in assumption.  Perhaps it's because I'm not up to speed on
> > EPEL plans, but do we have timelines for when/if modules will be
> > created for and available for EPEL?

> It's the plan of record that by default, all modules will be built
> across all available buildroots. I'm not sure if that means EPEL7
> will
> be an available option for technical reasons, but I hope so. This
> will
> possibly require a modular-capable DNF in EPEL proper or in a side-
> repo
> of some sort -- TBD. But if that works, we'll start having modular
> content for EL right along with the F28 release.

If this is something we want to do in that timeline things need to be
getting put in place now. We should have a discssion about what we
would like, what timelines we would do it on, and how it would all look
and work. The DNF and RPM teams probably need to chime in to let us
know what is practical. in order to have it in the F28 timeline we need
to get it enabled in the next 6-8 weeks.

> If not, it'll have to wait for the "higher than 7" RHEL release, but
> should be able to enable module building for that pretty quickly once
> the target OS is available.

What EPEL greater than 7 looks like will be a discussion to be had when
 there is something to build against relased publicly, until we see
what the base looks like we can not determine what EPEL will look like.

> I know that many of us Fedora packagers stay away from EPEL, but at
> least for me, that's largely because I'm not confident about
> committing
> to the long lifecycle, because to keep packages stable I'd have to
> diverge from Fedora, and because rpm abilities lag so much.

This is a big issue, it is a commitment, people have thier own ideas on
what stable and supported in EPEL means. 

> With modules, the first two concerns are handled (because I can
> maintain my modules with whatever commitments I feel comfortable
> with,
> even with an EL target). And at least initially the RPM/DNF
> functionality
> should be on par with modern Fedora.
agreed.

Dennis


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Infrastructure manager change

[Dennis Gilmore]

El mié, 17-01-2018 a las 07:00 -0800, Jim Perrin escribió:
> Hello  Fedora developers,
> I know some of you may not be familiar with me[1] unless you’re also
> working with CentOS or EPEL, but I’d like to take this opportunity to
> introduce myself a bit more formally on the list.
> 
> As of 1 February, I’ll be the reporting manager for the Fedora
> Infrastructure Administration team, and the Fedora Infrastructure
> Applications team[2], as well as the CentOS engineering team internal
> to
> Red Hat.  For the most part, this is a Red Hat internal
> organizational
> change that doesn’t really impact anything in the community. Paul
> Frields set a good example of being transparent with the community,
> and
> I want to continue that with this transition. Paul won’t be going too
> far as part of this transition, as he’s taking a promotion of his
> own,
> and I’ll be reporting to him as part of the new structure.
> 
> 
> This is a fantastic group of people, and I’m excited to be working
> with
> them. There will be a bit of transition time as Paul and I work
> through
> the team organization and update the wiki to reflect the changes, but
> you’ll probably be seeing a bit more of me around here.
> You may now return to your regularly scheduled mailing list.
> 
> 1. https://fedoraproject.org/wiki/User:Jperrin
> 2. https://fedoraproject.org/wiki/Fedora_Engineering

Hi Jim,

Nice yto see you on the blue side of the Fence :D I am looking forward
to  seeing how Fedora and CentOS can work better together 

Dennis

signature.asc
Description: This is a digitally signed message part
___
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 ..

[nicolas . mailhot]

Hi,

I can get a few hundreds of those disappear if the Go packaging guidelines I 
posted get accepted

Otherwise, they are a symptom of technical debt accumulation in EL, nothing more

Regards,

-- 
Nicolas Mailhot
___
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)

[Mark Wielaard]

On Mon, 2018-01-22 at 08:38 +, Tomasz Kłoczko wrote:
> Effectively Fedora has not to much from relation with RH *between*
> major EL releases in form of straight contribution to Fedora constant
> changes. They may be sending back some fixes done for RHEL customers
> but that is all. However as we are talking about CVEs and other
> critical changes it is IMO more likely that after submitting such
> fixes to original source code maintainers most of those changes are
> coming to Fedora in form of next version source tar balls than
> patches.

I think this depends on the team(s) that are maintaining the Fedora and
RHEL packages, and whether they are the same or different people. For
the packages I maintain personally in both Fedora and RHEL I make sure
any update to the RHEL (or DTS) package, first goes upstream and then
into the Fedora package. Only after that will it hit the RHEL or DTS
package as a bug fix (through a simple merge, because the spec files
are kept in sync).

Cheers,

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

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

[nicolas . mailhot]

- Mail original -
De: "Stephen John Smoogen"

> They pull in what they want to make it work and could
> give a care if it is readable to anyone else.

The problem is that past a certain point those become effectively 
unmaintainable and start dragging Fedora in the EL blackhole instead of Fedora 
pulling EL forward.

It's real easy to get there, just accumulate enough EL-related cruft making any 
change is a PITA, and then hope 'something' in the next EL will clean up things 
(it won't because Fedora is El's upstream and reverting the relationship 
deadlocks)

Regards,

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

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

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa" 

>  the main issue is what RPM features
are supported for each target distribution. Making things less ugly
for gracefully degrading would be very nice. :)

Well it would be really nice if someone @downstream watched for Fedora 
packaging guidelines changes and made sure the prerequisites were merged 
downstream (every time it's just tooling enhancements, not a major glibc 
release of course)

This would do wonders for the whole ecosystem velocity

Regards,

-- 
Nicolas Mailhot
___
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)

[Josh Boyer]

On Mon, Jan 22, 2018 at 3:38 AM, Tomasz Kłoczko
 wrote:
> On 22 January 2018 at 07:58, Igor Gnatenko
>  wrote:
> [..]
>>> On 22 January 2018 at 02:12, R P Herrold  wrote:
>>> [..]
>>> 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.
>>
>> Note that RHEL/CentOS doesn't have to copy specs 1:1. AFAIK it never was that
>> specs were 100% same. However, I'm pretty sure that "branching" RHEL is
>> happening from Fedora.
>
> It happens only when next major EL release is made.
> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_with_Fedora

Let's keep in mind that the info represented in that wiki page is all
derived from after the fact information.  It is not predictive of how
RHEL is developed or even how its development might change.

> After make major release no one cares what happen next in Fedora.

This is false.  Even by your own reasoning, lots of people certainly
care in the context of the release after the current one.  However
even the period between major RHEL releases is important in terms of
Fedora and RHEL.

> Looking on the graph on the wiki I think that EL8 will be released
> more likely within 2 years if not three.
>
> Effectively Fedora has not to much from relation with RH *between*
> major EL releases in form of straight contribution to Fedora constant

We can argue all day about whether or not this is reality (I would
contest that it isn't), but let's step back for a second.

If that is the mentality people are taking when approaching the Fedora
and RHEL relationship, on either side of the fence, that is a
*problem*.  Fedora and RHEL are symbiotic, and I would strongly argue
that we need to strengthen that relationship if anything.  Without
doing that, Fedora loses relevance to its primary sponsor and RHEL
loses the ability to derive benefit from Fedora.  The benefit goes
beyond spec files and patches.

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

Re: Wyland is a disaster

[Charalampos Stratakis]

- Original Message -
> From: "Stephen John Smoogen" 
> To: hlhow...@pacbell.net, "Development discussions related to Fedora" 
> 
> Cc: "Francesco Frassinelli" 
> Sent: Sunday, January 21, 2018 8:42:46 PM
> Subject: Re: Wyland is a disaster
> 
> 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  description>. 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
> 

While you are correct with your observations I'd like to point out that OP 
might just be frustrated with the unusability of wayland and that's his way of 
communicating it.

And i'm saying that because wayland has been for me also an absolutely 
frustrating experience (on F27 that is). F26 was fine on wayland and xorg, 
however currently on F27 with the same setup (T450s with docking station and 
two monitors) wayland is unusable due to crashes and xorg just makes 
gnome-shell crash less. And at the same time I have tried to debug the issues, 
filed reports, compiled rpm's with various fixes, but it just seems that 
gnome-shell keeps crashing for a different reason each time.

Again that was not the case with F26, so I keep wondering what went wrong with 
the latest gnome (or wayland), on F27.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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)

[Florian Weimer]

On 01/22/2018 08:40 AM, Tomasz Kłoczko wrote:

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.


It really depends on the package.  Some packages see frequent rebases 
and can even be ahead of what is in Fedora releases.


People who need absolute stability use EUS, and not the mainstream 
y-stream and z-stream updates for Red Hat Enterprise Linux.  The amount 
of changes that go into the distribution can be quite surprising, 
especially who have previously used Debian stable (which is more like 
EUS in the amount of updates that happen).


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

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

[Fabio Valentini]

On Jan 22, 2018 11:32,  wrote:



- Mail original -
De: "Stephen John Smoogen"

> They pull in what they want to make it work and could
> give a care if it is readable to anyone else.

The problem is that past a certain point those become effectively
unmaintainable and start dragging Fedora in the EL blackhole instead of
Fedora pulling EL forward.


My thoughts exactly. By maintaining "compatibility" with downstream/ other
distros at any cost, no meaningful improvements can ever be made, because
fedora's downstreams won't implement new things earlier than fedora itself.

I'm particularly looking forward to improvements regarding golang. The
automated .spec generation is nice for getting new packages started, but
maintaining those packages currently is a small nightmare in itself due to
brittle scripts and a ton of unnecessary, nested conditionals.

Fabio

It's real easy to get there, just accumulate enough EL-related cruft making
any change is a PITA, and then hope 'something' in the next EL will clean
up things (it won't because Fedora is El's upstream and reverting the
relationship deadlocks)

Regards,

--
Nicolas Mailhot
___
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: EPEL support in "master" branch (aka speeding up Fedora development)

[Florian Weimer]

On 01/22/2018 09:38 AM, Tomasz Kłoczko wrote:

After make major release no one cares what happen next in Fedora.


Again, that really depends on the package.  Some are not even fully 
branched.  For some of the totally branched packages, package 
maintainers create separate backports of downstream changes because they 
are equally useful to past Fedora releases.  And these changes get much 
broader pre-release testing coverage as a result (at least at a feature 
level), so it is a win for everyone.


Thanks,
Florian
___
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)

[Vít Ondruch]

Dne 20.1.2018 v 14:30 Igor Gnatenko napsal(a):
>
> > It would be really useful to have a wiki page outlining where the
> > Guidelines for stable branches are different to the most recent
> version of
> > the Packaging Guidelines (if such a page already exists, please
> ignore this
> > and point me to it).
>
> I think Jason Tibbs said somewhere that packaging guidelines are
> targeting only
> rawhide. But I'm not sure if there is sentence written somewhere.

I think FPC does not know. Let me quote from Ruby guidelines update [1]
which initially aimed on Rawhide, now it covers all supported Fedoras,
but it is still not approved after almost 5 months, because ... Actually
I'm not sure why, may be because of EPEL (in)compatibility?

https://meetbot.fedoraproject.org/fedora-meeting-1/2017-09-14/fpc.2017-09-14-16.00.log.html

> 16:36:30  Publishing new guidlines now that break on F26
seems like a bad idea.
> 16:41:06  I don't object to mentioning that "in F27+, you can
do this instead" or "For <= F26, you must do this instead".
> 16:41:28  But just saying "for actual current Fedora releases,
read this other thing" isn't particularly friendly.

https://meetbot.fedoraproject.org/fedora-meeting-2/2017-11-29/fpc.2017-11-29-18.00.log.html

> 18:46:28  His complaint about how we should branch the
guideline ignores the reality that the people actually doing packaging
don't want to have to read six different guideline documents (one
for each of rawhide, F27, F26, F27, EL7, EL6).
> 18:47:38  I fail to understand it.  You wait until something is
"broadly usable" and then you document the exceptions.
> 18:48:11  But what good does that do people who just want to
know how to package?
> 18:48:35  You get something which works on rawhide but isn't
useful on any released Fedora version.
> 18:48:40  Packagers just don't want that.

And from my other fedora-devel thread

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7JQEQCGK3UNGGPSBQQM3CKP2BYGGCHOV/

> It is my understanding that the unwritten rule is that the guidelines
> are targeted at rawhide and we (FPC) try to maintain notes documenting
> which releases need exceptions or don't support some things.
>
> Regards,
> Dominik

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H4ZP36RZJCDZNQLNBDS5AHKZA2LXWTVS/

> IMHO, mixing epel specs with fedoras specs is a lost battle. It's
error-prone at best and hardly possible in "more than trivial" cases.
>
> Ralf



Vít




[1] https://pagure.io/packaging-committee/issue/710



signature.asc
Description: OpenPGP digital signature
___
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)

[Vít Ondruch]

Dne 22.1.2018 v 11:50 Florian Weimer napsal(a):
> On 01/22/2018 08:40 AM, Tomasz Kłoczko wrote:
>> 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.
>
> It really depends on the package.  Some packages see frequent rebases
> and can even be ahead of what is in Fedora releases.

In this context, I would like to point out that we should not speak
about EPEL{6,7} guidelines, because they might evolve between RHEL minor
releases.

For example, Ruby in RHEL 7.4 has backported most of the macros
available for packaging rubygem -packages in the most recent Fedora. But
there macros are not available in RHEL 7.3.

Also, I would like to point out that FPC or whoever else in community
has hardly anything to say into something like EPEL Ruby guidelines,
because these guidelines are driven purely by RHEL (although I want to
make the packaging as similar as possible with Fedora).


Vít

>
> People who need absolute stability use EUS, and not the mainstream
> y-stream and z-stream updates for Red Hat Enterprise Linux.  The
> amount of changes that go into the distribution can be quite
> surprising, especially who have previously used Debian stable (which
> is more like EUS in the amount of updates that happen).
>
> Thanks,
> Florian
> ___
> 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: Wyland is a disaster

[Christian Fredrik Schaller]

Hi there,
I am sad to hear that people are having issues when using Wayland (and even
the X.org session). Be aware though that we have devs dedicated at RH to
look at Fedora Wayland bugs, so if you file bugs we will try our best to
look at them and figure out what is happening. It obviously works well for
many of us, including the devs themselves, so there must be some specific
hardware and or software combinations triggering these problems. So please
file bugs against Wayland in the Fedora bugzilla and we will try our best
to take a look.

Sincerely,
Christian Schaller

On Mon, Jan 22, 2018 at 5:43 AM, Charalampos Stratakis 
wrote:

>
>
> - Original Message -
> > From: "Stephen John Smoogen" 
> > To: hlhow...@pacbell.net, "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Cc: "Francesco Frassinelli" 
> > Sent: Sunday, January 21, 2018 8:42:46 PM
> > Subject: Re: Wyland is a disaster
> >
> > 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  > description>. 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
> >
>
> While you are correct with your observations I'd like to point out that OP
> might just be frustrated with the unusability of wayland and that's his way
> of communicating it.
>
> And i'm saying that because wayland has been for me also an absolutely
> frustrating experience (on F27 that is). F26 was fine on wayland and xorg,
> however currently on F27 with the same setup (T450s with docking station
> and two monitors) wayland is unusable due to crashes and xorg just makes
> gnome-shell crash less. And at the same time I have tried to debug the
> issues, filed reports, compiled rpm's with various fixes, but it just seems
> that gnome-shell keeps crashing for a different reason each tim

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

[Miroslav Suchý]

Dne 20.1.2018 v 12:27 Igor Gnatenko napsal(a):
> Why I'm writing this? I want to hear from you if you think it would be good to
> prohibit (or advise, or whatever mechanism would work) usage if conditionals 
> in
> (at least) master branch to allow us to develop features faster. Thoughts?

-1

If this were ever approved, I would orphan a lot of packages because I will not 
have time to maintain them.

> Given all these, it is very hard to get any new feature in "production" 
> because
> everyone wants to support 10 years old thing (even if they don't think so).

Can you give a specific example? Everything you mentioned can be easily 
conditionalized on RHEL7+.

For me (as an upstream author who maintains the spec file as well) the 
conditionals are useful. When I see something like:

  %if 0%{?rhel} < 6

then I know I can wipe it now and **remove the relevant code** in the 
application as well.

Maintaining 3 spec files for Fedora and 1-2 spec files for EPEL is much much 
bigger overhead. Especially when they are
mostly identical and differ only in few lines.

Mirek



signature.asc
Description: OpenPGP digital signature
___
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)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 20, 2018 at 06:47:50PM +0100, Alec Leamas wrote:
> 
> 
> On 20/01/18 13:52, Fabio Valentini wrote:
> > On Jan 20, 2018 12:29, "Igor Gnatenko"  
> >> TL;DR:
> >> - We need an authoritative source that tells us packagers which
> >> Guidelines apply to which branch (or what has to be done differently -
> >> or can be done better - in, for example, f26 when compared to the
> >> current Packaging Guidelines).
> 
> Agreed, fully. But this is basically to version the GL, and that idea
> was turned down when I approached the FPC with it [1]. My perspective at
> that point was how to update fedora-review to match the changed GL, but
> the solution was more or less the same.

Versioned guidelines are much harder to use, because, essentially,
you have to have multiple versions in front of you when developing
for multiple Fedora releases.

I think the right solution is what Python does in its docs: always
specify which is the minimum version where something is available
(or applies, in case of guidelines). This is actually fairly easy
to do by simply always including information when adding new
guidelines. I think our Guidelines already do that in various places,
although possibly not everywhere where they should.

Zbyszek

> It's a bit depressing to compare this very feature with Debian, which
> has this Standards-Version thing in their "spec", basically a checkmark
> for the last "GL" version the "spec" has been updated to.
___
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)

[Vít Ondruch]

Dne 22.1.2018 v 12:31 Miroslav Suchý napsal(a):
> Dne 20.1.2018 v 12:27 Igor Gnatenko napsal(a):
>> Why I'm writing this? I want to hear from you if you think it would be good 
>> to
>> prohibit (or advise, or whatever mechanism would work) usage if conditionals 
>> in
>> (at least) master branch to allow us to develop features faster. Thoughts?
> -1
>
> If this were ever approved, I would orphan a lot of packages because I will 
> not have time to maintain them.
>
>> Given all these, it is very hard to get any new feature in "production" 
>> because
>> everyone wants to support 10 years old thing (even if they don't think so).
> Can you give a specific example? Everything you mentioned can be easily 
> conditionalized on RHEL7+.
>
> For me (as an upstream author who maintains the spec file as well) the 
> conditionals are useful. When I see something like:
>
>   %if 0%{?rhel} < 6
>
> then I know I can wipe it now and **remove the relevant code** in the 
> application as well.
>
> Maintaining 3 spec files for Fedora and 1-2 spec files for EPEL is much much 
> bigger overhead. Especially when they are
> mostly identical and differ only in few lines.
>
> Mirek

You took pretty basic example without context. So let me give you
different example.

There were attempts to get Ruby on Rails into EPEL. It is around 80
packages. Some packages were RHEL contidiontalized. But the effort to
get Ruby on Rails was never successful. Even if it was successful,
nobody maintained/updated it later, for example because more recent Ruby
on Rails, developers decided to drop support for older Ruby which are in
RHEL. That left some Fedora packages with some RHEL conditions and makes
every update of such package pain. These conditionals won't be ever used
again.

Also, from my experience maintaining Ruby in RHEL and RHSCL, in 90 %
percent of cases cherry-pick of the specific fix I want to get from
Fedora works without conflicts and if there are conflicts, they are just
in changelog.


Vít



signature.asc
Description: OpenPGP digital signature
___
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 Mon, Jan 22, 2018 at 12:29 AM, Tomasz Kłoczko
 wrote:
> 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.
>

No he didn't. He's telling you that CentOS packages have their own
Dist-Git for packages they get from RHEL. RHEL people maintain
packages in Fedora, and those often have conditionals for everything.

>> 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.
>

This is not completely true. Actually, a good number of spec files in
Mageia differ from Fedora only in three things:

1. %mkrel 1 instead of 1%{?dist}
2. Indentation (sometimes, I personally don't mess with that)
3. libification (each shared library gets its own subpackage)

There are many packages and package stacks synced from Fedora on a
regular basis. For example, the entire Java and MinGW stack is sourced
from Fedora, with minimal changes done. I also personally synchronize
the SELinux stack from Fedora (including selinux-policy).

I am the packager for mock and mock-core-configs in Mageia, and it
differs from Fedora only because originally the scriptlets were quite
different for detecting whether something is Mageia vs what is Fedora.
They are more similar now because I contributed that work back to the
Fedora packages. In fact, "mock-core-configs" was the name *I* came up
with, because we have extra configs for mock as "mock-mageia-configs"
and Miroslav Suchy needed a name for the package containing the split
out configs.

The entire Rust packaging stack is nearly *identical* because the
Fedora Rust SIG includes myself and Rémi Verschelde, both of whom are
also Mageia packagers. And for the Rust stack, we just add %mageia
conditionals and leave things alone, because keeping everything in
total sync is important for the maintainability of it. Fortunately,
the two distributions are more similar than different and when we're
starting from zero, we've been able to leverage RPM features from this
decade.

The package for RPM in Mageia is also designed to be able to build on
Fedora, and our packaging is pretty much synchronized with Fedora's.
Packages that are synchronized with Fedora often have "Warning: This
package is synchronized with Fedora" or "Warning: This package is
synchronized with FC" (yes, yes, Fedora Core, a thing that hasn't
existed in ten years...). There's a number of core packages with this
warning, as well as a few other random ones (like Flatpak and
whatnot).

From time to time, we also contribute improvements to pac

Re: Wyland is a disaster

[Christian Fredrik Schaller]

Sorry for responding to myself here, but I thought it could also be
worthwhile to mention that one of our primary tools for identifying
problems is the Fedora ABRT server. Looking at the current stats it looks
to me like F27 is actually doing better than F26 used to in
terms of minimizing crashers: https://goo.gl/babuJx

There is always a chance ABRT is not catching the issues of course for some
reason, but since the initial email did claim developers
don't care about making sure things works well I thought it would be
worthwhile pointing out some of the tools we use to try to
ensure that things work well.

Christian

On Mon, Jan 22, 2018 at 6:29 AM, Christian Fredrik Schaller <
cscha...@redhat.com> wrote:

> Hi there,
> I am sad to hear that people are having issues when using Wayland (and
> even the X.org session). Be aware though that we have devs dedicated at RH
> to look at Fedora Wayland bugs, so if you file bugs we will try our best to
> look at them and figure out what is happening. It obviously works well for
> many of us, including the devs themselves, so there must be some specific
> hardware and or software combinations triggering these problems. So please
> file bugs against Wayland in the Fedora bugzilla and we will try our best
> to take a look.
>
> Sincerely,
> Christian Schaller
>
> On Mon, Jan 22, 2018 at 5:43 AM, Charalampos Stratakis <
> cstra...@redhat.com> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Stephen John Smoogen" 
>> > To: hlhow...@pacbell.net, "Development discussions related to Fedora" <
>> devel@lists.fedoraproject.org>
>> > Cc: "Francesco Frassinelli" 
>> > Sent: Sunday, January 21, 2018 8:42:46 PM
>> > Subject: Re: Wyland is a disaster
>> >
>> > 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 > > description>. 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.
>> > 

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

[nicolas . mailhot]

- Mail original -
De: "Fabio Valentini" 

Hi,

> I'm particularly looking forward to improvements regarding golang. The
> automated .spec generation is nice for getting new packages started, but
> maintaining those packages currently is a small nightmare in itself due to
> brittle scripts and a ton of unnecessary, nested conditionals.

FYI, I've already posted a Go packaging guidelines update that removes most of 
those scripts and conditionals, and will post soonish a spec dump that 
implements those updates on a  ~420 spec set, and updates the golang core to 
current golang/x/foo, current APIs for most cloud services, current grpc, all 
with mostly complete unbundling and working inter-package autodeps.

To give an idea of the cope, I count 489 Go source packages in Fedora right 
now. So that's a reboot weighting 86% the Fedora Go universe, even though it's 
an overlapping set, not a subset of what's in Fedora

(I could publish it sooner if people are interested in contributing to 
finishing up the bootstrap, the big item not completely done is moby and its 
deps)

And then that will be a take it or leave it, if no one's interested I'll finish 
my private Fedora/EL Go fork and forget about the crumbling state of Go in 
Fedora. And people can continue to bikeshed if using a variable named commit to 
hold the commit hash is ok or not. I'm certainly not interested in this 
conversation anymore.

Regards,

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

GSoC Ideas Time

[Brian Exelbierd]

Our Application for GSoC is ready and we will make the submission deadline 
tomorrow.  Therefore we should start working on ideas.

See 
https://docs.stg.fedoraproject.org/mentored-projects/gsoc/2018/#mentor-information
 for details.  Text is also below.

regards,

bex

How to Propose a Project

If you want to mentor a specific project, think carefully about several things:

Do you have enough time to work on this with the student during the entire 
project. You will be helping someone else when they get stuck. You don’t want 
to become a blocker because you’re busy.

It is harder to find success when you are completely certain of how an idea 
needs to be implemented; finding a student with the skills and interest to 
implement a specific solution is a lot harder than finding a student with 
enough skills to respond to a use case need. Also, students learn more when 
they help design and guide the project. In other words, provide guidance and 
direction but let the student do some of the "driving."

Where you can have looser ideas, you may be able to find a student who 
works as a sort-of intern who can implement a solution to a use case you have. 
In past experiences, students going after a use case are more likely to get 
somewhere with self-direction and support from you.

Who can help you? Try to find a second mentor for the project.

If you’re interested in working with a student on a specific project you should 
post your idea to the Mentored Projects Issue Tracker[1]. Your issue should be 
tagged GSoC and use the Google Summer of Code template. We strongly encourage 
you to find a second person to help with mentoring and to solicit feedback on 
your proposal


Can I be a Mentor Without a Project?

Yes! You can either:

Work with a student who brings an idea to your sub-project. This requires a 
different level of communication throughout the project, but can be the most 
rewarding.

Be a general mentor. This is a person who works with all students 
regardless of their project. To become a general mentor please open an issue in 
the Mentored Projects Issue Tracker[1] offering your help. Please tag the issue 
with the GSoC tag.


1: https://pagure.io/mentored-projects/issues
___
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:
[..]
> 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. :)

As long as you are joking I'm ONE HUNDRED PERCENT sure that is is not true
and I can prove this 😀

Proof:
When I've been leading PLD development I had around few really talented and
brilliant people.
In many occasions, we found that standard rpm set of macros have some
issues or those macros had not enough functionalities.
So completely institutionally we started adding some macros or patching
those macros.
For quite long time we have been trying to push as much as possible to rpm
original source code,
You may don't know this but guess who exactly for example discovered %bcond
.. Pawel Gajda or Arkadiusz Miśkiewicz (probably second one but I may be
wrong).
Only when handling %bcond has been accepted and provided by original rpm in
relatively short time we started using it in many specs files.
So yes ..  %bcond it is/was ORIGINAL PLD invention.
%bcond handling it is/was only two lines patch!! 
After this was second patch next two lines with %{with {:},
%{without [:]}

Even today after ~15 years integrate %bcond in rpm many Fedora packagers
are refusing patches switching to %bcond.
Another PLD useful %bcond related feature about how it was used ..
IN PLD %bconds declaration was ALWAYS on the top of the spec after first
(commented) line (with CVC/RCS tokens).
In Fedora %bconds declarations is possible to find almost EVERYWHERE 
OK .. in most cases it is on the top but there is no Fedora standardization
about indenting those declarations which usually makes those declarations
not easy to read and quickly understand.

The similar history was with many other things like start populating
LDFLAGS, CFLAGS, CPPFLAGS, FFLAGS to %configure.
The same was with pushing CC, CXX ant other.
In CVS repo with all specs we had example.spec file which was necessary to
modify/update if something new was introduced.
This spec had no single line of comment and was used as reference for other
committers how to use some features/macros, how to format spec
in Fedora there is no such self-explanatory spec and all crucial details
are spread across many different corners of the Fedora documentation.
Because all those details are not on the single web page there is some
number of contradictions in such documentation.

Back to PLD and what caused so many variations of using this software ..

Initially, %confiigure was only "naked" macro wrapping configure and some
set of --dir=%{_dir}. Initially many --dir=%{_dir}
mapping was missing and in PLD first started fixing this and pushing to the
rpm source tree ..
Since we've integrated those changes in RPM it started speeding like a fire
across other distributions.
>From this time in PLD comes exact way of overwriting those flags and
compilers/linker like:

%configure \
   CFLAGS="" \
   LDFLAGS="" \
   

Why it was and IMO still IS!! *better* than using sometimes few exports
before %configure? 🤔
Because if it was an issue caused by altering those flags in the exact
package it WAS ALWAYS possible to *guess* where something needs to be fixed
(even typo)!!!
Instead of asking yourself "bl*dy he*ll .. where those altering
compilation/linking flags is? .. in which one export line and how fare
before %configure?😨".
No .. no such losing the time!!!

GUYS .. STANDARD SPECS FORMAT/INDENTATION saves a lot of time even for
single packager!!!
This is why I've mentioned about this few times in last few days (in
slightly different contexts) and *trust me I'll be nagging* about this on
any possible occasion 😎
This may speed up whole Fedora development DRAMATICALLY!!! despite other
"deposits" of such development improvement which I'm already trying to
explore ..

So .. I would be really glad to see in Fedora specs like ONLY above
altering %configure as it is in above example. Why? because this precise
place in specs where using editor we need to jump to correct those
altering😎

Again "ab ovo" ..
So what was the strategy or real movements of the RedHat people?
I may be not 100% correct but I think that just before rewrite rpm from
perl to C they've started to ignore what is in standard macros set and they
formed redhat-rpm-config package which is just dropping few files in some
directories which are overwriting.
I'm not sure why RH stopped pushing own macros to rpm source tree .. JFDI?
lack of proper communication and understanding rpm developer needs of
large-scale using rpm? Usual Linux NIH syndrome or just fact that quite
early into rpm main "macros" file has been added possibility to include at
the end per distribution extensions?

I think that because those standard macros at this time started to require
very frequent/instant 

Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Sun, Dec 17, 2017 at 2:11 AM,   wrote:
> Hi,
>
> I am proposing for inclusion a set of rpm technical files aimed at automating 
> the packaging of forge-hosted projects.
>
> - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
> - https://pagure.io/packaging-committee/issue/734
> - go-srpm-macros RFE with the technical files: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1526721
>
> This proposal is integrated with and depends on the 
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation 
> draft
> It builds on the hard work of the Go SIG and reuses the rpm automation of 
> https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and 
> produces compatible packages.
>
> What it does:
>
> - drastically shorter spec files, up to 90% in some cases, often removing 
> hundreds of lines per spec.
> - simple, packager-friendly spec syntax
> - automated package naming derived from the native identifier (import path). 
> No more packages names without any relation with current upstream naming.
> - working Go autoprovides. No forgotten provides anymore.
> - working Go autorequires. No forgotten requires anymore.
> - strict automated directory ownership (used by autorequires and 
> autoprovides).
> - centralized computation of source URLs (via Forge-hosted projects packaging 
> automation). No more packages lacking guidelines. No more broken guidelines 
> no one notices.
> - easy switch between commits, tags and releases (via Forge-hosted projects 
> packaging automation). No more packages stuck on commits when upstream starts 
> releasing.
> - guidelines-compliant automated snapshot naming, including snapshot 
> timestamps (via Forge-hosted projects packaging automation). No more packages 
> stuck in 2014.
> - guidelines-compliant bootstraping.
> - systematic use of the Go switches defined by the Go maintainer. Easy to do 
> changes followed by a mass rebuild.
> - flexibility, do the right thing transparently by default, leave room for 
> special cases and overrides.
> - no bundling (a.k.a. vendoring) due to the pain of packaging one more Go 
> dependency.
> - centralized Go macros that can be audited and enhanced over time.
> - aggressive leverage of upstream unit tests to detect quickly broken code.
>
> Please consult packaging draft for full information.
>
> The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go 
> packages. This set is a mix of current Fedora packages, bumped to a more 
> recent version, rewrites of Fedora packages, and completely new packages.
>
> I hope posting the second part of the automation will answer some questions 
> people had on the 
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation 
> draft
>

I really do like this. There are only two issues I have with it:

1. This seems to mandate that all packages must be named by their
import path. My golang package (snapd) is not, intentionally so. I
don't want to change this.

2. Mandating a forge is going to be tricky for self-hosted stuff, or
people who release Go code as tarballs (it's rare, but it happens).
How do you deal with that?



-- 
真実はいつも一つ！/ 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: Proposed Fedora packaging guideline: More Go packaging

[Dridi Boukelmoune]

> I really do like this. There are only two issues I have with it:
>
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
>
> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> people who release Go code as tarballs (it's rare, but it happens).
> How do you deal with that?

By not using the macros for packages not fitting the model?

I think this is very helpful especially when it's the common practice,
and I certainly won't blame anyone doing proper releases and not
just a git tag with github releases notes ;)

Regarding naming, I think python packages must be prefixed with
python[23]- and can Provides: the upstream project name. On the
other hand we have packages like docker that are clearly named
after upstream's name, so I don't think that would be a problem for
snapd. (and maybe an exception needs to be granted?)

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

Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
 wrote:
>> I really do like this. There are only two issues I have with it:
>>
>> 1. This seems to mandate that all packages must be named by their
>> import path. My golang package (snapd) is not, intentionally so. I
>> don't want to change this.
>>
>> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
>> people who release Go code as tarballs (it's rare, but it happens).
>> How do you deal with that?
>
> By not using the macros for packages not fitting the model?
>

The issue is that the new Go macros are tightly wound into the forge
macros. I just want to be sure that we can leverage things like the
dependency generators without all the other stuff.

> I think this is very helpful especially when it's the common practice,
> and I certainly won't blame anyone doing proper releases and not
> just a git tag with github releases notes ;)
>
> Regarding naming, I think python packages must be prefixed with
> python[23]- and can Provides: the upstream project name. On the
> other hand we have packages like docker that are clearly named
> after upstream's name, so I don't think that would be a problem for
> snapd. (and maybe an exception needs to be granted?)
>

This rule only applies to Python packages that have modules that are
designed to be imported by other Python code. Otherwise, this is not
necessary.



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

[HEADS UP] rust-pest changes license from MPLv2.0 to MIT or ASL 2.0

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks for attention.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpl8mAACgkQaVcUvRu8
X0zq+w//fSiqqAkXyQtnKuGyMAkc9VwbROgyu0LVmToAZZ9VDhvj9gbX4wP7Gz4P
qmf5cBEFHnkl37t0WFmvEoZheR5GX0hepPuTNVbWaY8+N8z+4oqGqNQydgbNsLZC
OCnF5ho9+oUB/bNwN7Lc2hZT/LpZVNZtifN3n9vFqrNBsSXoWZirstITsUv2Oef8
kZ2eVEmzhF84eE6fALfuQWNMPyNhL18poG+Gl9fJvlAvYYNzWKhL/JhlB73wpYXq
GhTnFCowwzGpUJ3mBHKrg4qLcgqulKesxKsJeG9UUWwdkd0eZHG5KXPVvitXtpe3
ZyeZEETOtGUgdV3Bedvz0/SftpcO4OIzxv4ignNuERmVteCwJq0WRZ+SpJLBh8rj
mQuvd72Uxp/qfpUQe/1dYKlmOuFBEzjXgkUqh1vStrlOFsc0hHmAMaFhS7+90eBT
PTLHPJ5hvpnSMhHWA1W/wa7HXBmKh2HqCD+Erv8TT2zdNMWmaRpBvjS/Al2ifsVn
OiQ5Dc6HzXFK8cCxw+D9lrwThucE8+09rSwoDWDwQZsmifoUZUznoGWgZo9I/C07
dHVuyVF7lXX9CtbVI3O3JY9UA+R6g/9m17A+HMRpDD+k5Lc0q3NJkryAtSlnEsJl
Q9BUAJi25b761yThXY56loeaZocGMkHhAoF1GwwuiTZ7+N1LUWE=
=XcMN
-END PGP SIGNATURE-
___
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 12:10, Neal Gompa  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.
>
[..]

> >> The CentOS 'guys' do maintain everything in their repo.
> >
> >
> > OK so here you just gave me +1 for a). Thx.
> >
>
> No he didn't. He's telling you that CentOS packages have their own
> Dist-Git for packages they get from RHEL. RHEL people maintain
> packages in Fedora, and those often have conditionals for everything.


So again .. +1 to a) to remove all %{centos} macros and %ifings using those
macros 😀
You just said that none of the CentOS developers are pushing back any
changes to Fedora because they are using as baseline RHEL, and RHEL only
every few years (+5yeas to be more precise) are shapshoting Fedora to start
next major EL release ..

<<>>

[..]

> This is not completely true. Actually, a good number of spec files in
> Mageia differ from Fedora only in three things:
>
> 1. %mkrel 1 instead of 1%{?dist}
> 2. Indentation (sometimes, I personally don't mess with that)
> 3. libification (each shared library gets its own subpackage)
>

Point 2 is deal breaker and only by this Mageia packages have closed way
completely to start contributing back to some changes Fedora on specs level.

Mageia has many only in this distribution found patches.
Let's say it straight: Mageia people have 0/NULL added value to on
development if they would enforcing people pushing back ANY changes.
If someone will be pushing on porting back they ill slow down own
development to snail speed.

Those three points are not only difference.
Mageia has own %changelog.
Look on attached rust-packaging.spec.diff.
Even in case this quite simple spec

BTW. adding %mkrel was IMO stupidest ever thing possible to do because all
what was necessary to do was change ONLY %dist macro VALUE to mga7 or mga6
instead introducing yet-another-our-own-olny macro.
I see here NIH syndrome 😎

There are many packages and package stacks synced from Fedora on a
> regular basis. For example, the entire Java and MinGW stack is sourced
> from Fedora, with minimal changes done. I also personally synchronize
> the SELinux stack from Fedora (including selinux-policy).
>

But it has nothing to do with sharing specs. Really .. it is end of story.
Sorry ..

The package for RPM in Mageia is also designed to be able to build on
> Fedora,


Even it it is possible for some non-empty set of specs what I saw already
is enough to it will be few obstacles in macros suit.
I'm sure that it will be already quite big number of such specs files which
will fail.
More important is that we are talking almost 100% specs which are already
in Fedora so borrowing them from Mageia will be probably last thing about
which typical joe-Fedora-packager will be thinking.
Do you see this?


> and our packaging is pretty much synchronized with Fedora's.
>

Show me some example(s).
How this synchronization is done and Fedora specs are only used on
occasions like "OK they've (Fedora) added this or updated package  so
we will to the same something simillar". During this process no one is
using git on "borrowing" fedora specs diffs (between older and new version
of the Fedora spec).
Am I right?
As result if someone from Mageia will be able to update some packages
quicker than it will happen in Fedora NO-ONE-WILL-CARE about pushing back
to Fedora similar update
Am I right?
Above is even probably used as kind of the argument to convince end users
use Mageia in something like: "look we are Better(tm) than Fedora!" 😀
(it is nothing wrong with this .. it is just marketing)
Am I right?

If it will be three times "yes" it ill be straight prove that connection
between Fedora and Mageia is not *bidirectional* but whole stuff goes only
in *one direction*!!
Do you see it now?
If it is true it is only necessary argument to remove Mageia %ifings from
Fedora master.

> 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.
> >
>
> Trust me, I know what I'm talking about when it comes to rust-packaging.
>

Sorry to not trusting you
As long checking this took me few seconds (look on the attachment) I know
that it is not tru

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

[Tomasz Kłoczko]

On 22 January 2018 at 10:22, Mark Wielaard  wrote:
[..]

> I think this depends on the team(s) that are maintaining the Fedora and
> RHEL packages, and whether they are the same or different people. For
> the packages I maintain personally in both Fedora and RHEL I make sure
> any update to the RHEL (or DTS) package, first goes upstream and then
> into the Fedora package. Only after that will it hit the RHEL or DTS
> package as a bug fix (through a simple merge, because the spec files
> are kept in sync).
>

That is *probably* correct guess 😀
Problem only is that I don't want to guess because on raising PR such PR
will be easy to turn into rubble ("because you've been guessing" 😎)
I don't wan to waste other people time that way.

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: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Marcin Dulak]

On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa  wrote:

> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>  wrote:
> >> I really do like this. There are only two issues I have with it:
> >>
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (snapd) is not, intentionally so. I
> >> don't want to change this.
> >>
> >> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> >> people who release Go code as tarballs (it's rare, but it happens).
> >> How do you deal with that?
> >
> > By not using the macros for packages not fitting the model?
> >
>
> The issue is that the new Go macros are tightly wound into the forge
> macros. I just want to be sure that we can leverage things like the
> dependency generators without all the other stuff.
>
> > I think this is very helpful especially when it's the common practice,
> > and I certainly won't blame anyone doing proper releases and not
> > just a git tag with github releases notes ;)
> >
> > Regarding naming, I think python packages must be prefixed with
> > python[23]- and can Provides: the upstream project name.


I'm not sure if this matters in this discussion but an example Python3 part
of a spec file https://fedoraproject.org/wiki/Packaging:Python
to accommodate also EPEL (which on CentOS7 prefixes Python3 packages with
python34 and not python3) would look like:

%package -n python%{python3_pkgversion}-%{pname}
%{?python_provide:%python_provide python%{python3_pkgversion}-%{pname}}

Macin


> On the
> > other hand we have packages like docker that are clearly named
> > after upstream's name, so I don't think that would be a problem for
> > snapd. (and maybe an exception needs to be granted?)
> >
>
> This rule only applies to Python packages that have modules that are
> designed to be imported by other Python code. Otherwise, this is not
> necessary.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Marcin Dulak" 
> To: "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" 
> Sent: Monday, January 22, 2018 4:04:19 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More 
> Go packaging
> 
> 
> 
> On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa < ngomp...@gmail.com > wrote:
> 
> 
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> < dridi.boukelmo...@gmail.com > wrote:
> >> I really do like this. There are only two issues I have with it:
> >> 
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (snapd) is not, intentionally so. I
> >> don't want to change this.
> >> 
> >> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> >> people who release Go code as tarballs (it's rare, but it happens).
> >> How do you deal with that?
> > 
> > By not using the macros for packages not fitting the model?
> > 
> 
> The issue is that the new Go macros are tightly wound into the forge
> macros. I just want to be sure that we can leverage things like the
> dependency generators without all the other stuff.
> 
> > I think this is very helpful especially when it's the common practice,
> > and I certainly won't blame anyone doing proper releases and not
> > just a git tag with github releases notes ;)
> > 
> > Regarding naming, I think python packages must be prefixed with
> > python[23]- and can Provides: the upstream project name.
> 
> I'm not sure if this matters in this discussion but an example Python3 part
> of a spec file https://fedoraproject.org/wiki/Packaging:Python
> to accommodate also EPEL (which on CentOS7 prefixes Python3 packages with
> python34 and not python3) would look like:
> 
> %package -n python%{python3_pkgversion}-%{pname}
> %{?python_provide:%python_provide python%{python3_pkgversion}-%{pname}}
> 
> Macin
> 

Hopefully something like this will never happen as generally I'm strongly 
against shipping multiple versions(of one implementation) of Go concurrently.

JC

> 
> On the
> > other hand we have packages like docker that are clearly named
> > after upstream's name, so I don't think that would be a problem for
> > snapd. (and maybe an exception needs to be granted?)
> > 
> 
> This rule only applies to Python packages that have modules that are
> designed to be imported by other Python code. Otherwise, this is not
> necessary.
> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> 
> 
> ___
> 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: EPEL support in "master" branch (aka speeding up Fedora development)

[Tomasz Kłoczko]

On 22 January 2018 at 10:42, Josh Boyer  wrote:
[..]

> > After make major release no one cares what happen next in Fedora.
>
> This is false.  Even by your own reasoning, lots of people certainly
> care in the context of the release after the current one.  However
> even the period between major RHEL releases is important in terms of
> Fedora and RHEL.


So far I've checked quite big number of latest CentOS 7.x specs files and
so far I didn't saw any new pulls from Fedora made after major EL snapshot
even if source tar ball has been updated.
Can you point to some exact examples? (packages names will be enough ..
mare than better😎)

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

-z defs linker flag activated in Fedora rawhide

[Florian Weimer]

I updated redhat-rpm-config to instruct ld to reject linking shared 
objects with undefined symbols.  Such undefined symbols break symbol 
versioning because the are not necessarily bound to the correct symbol 
version at run time.  (rhbz#1535422)


### Disable strict symbol checks in the link editor (ld)

By default, the link editor will refuse to link shared objects which
contain undefined symbols.  In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.  In this case, you can
add

%undefine _strict_symbol_defs_build

to the RPM spec file to disable these strict checks.  Alternatively,
you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
command line).  The latter needs binutils 2.29.1-12.fc28 or later.


This is also part of the build flags documentation at:



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

Re: Wyland is a disaster

[Jerry James]

On Mon, Jan 22, 2018 at 4:29 AM, Christian Fredrik Schaller
 wrote:
> I am sad to hear that people are having issues when using Wayland (and even
> the X.org session). Be aware though that we have devs dedicated at RH to
> look at Fedora Wayland bugs, so if you file bugs we will try our best to
> look at them and figure out what is happening. It obviously works well for
> many of us, including the devs themselves, so there must be some specific
> hardware and or software combinations triggering these problems. So please
> file bugs against Wayland in the Fedora bugzilla and we will try our best to
> take a look.

Thanks, Christian.  It's good to know that people are working on these issues.

One configuration that appears to be particularly unstable is a
dual-monitor setup with nouveau.  I experience frequent system hangs
with that setup, and don't seem to be alone; e.g.,
https://bugzilla.redhat.com/show_bug.cgi?id=1491565.  (Note that I do
not have a HiDPI monitor, but I also don't see all of the issues the
reporter of that bug noted.)  I'm going to try using X sessions this
week to see if that helps at all.  If not, they are probably nouveau
bugs unrelated to Wayland.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Tom Hughes]

On 22/01/18 15:26, Jerry James wrote:

On Mon, Jan 22, 2018 at 4:29 AM, Christian Fredrik Schaller
 wrote:

I am sad to hear that people are having issues when using Wayland (and even
the X.org session). Be aware though that we have devs dedicated at RH to
look at Fedora Wayland bugs, so if you file bugs we will try our best to
look at them and figure out what is happening. It obviously works well for
many of us, including the devs themselves, so there must be some specific
hardware and or software combinations triggering these problems. So please
file bugs against Wayland in the Fedora bugzilla and we will try our best to
take a look.


Thanks, Christian.  It's good to know that people are working on these issues.

One configuration that appears to be particularly unstable is a
dual-monitor setup with nouveau.  I experience frequent system hangs
with that setup, and don't seem to be alone; e.g.,
https://bugzilla.redhat.com/show_bug.cgi?id=1491565.  (Note that I do
not have a HiDPI monitor, but I also don't see all of the issues the
reporter of that bug noted.)  I'm going to try using X sessions this
week to see if that helps at all.  If not, they are probably nouveau
bugs unrelated to Wayland.


Does wayland actually support that?

I have a triple monitor setup with nouveau on one machine and that has 
always fallen back to X so I just assumed wayland didn't support that yet.


My machines which are using wayland, which admittedly aren't using 
nvidia graphics at all, seem perfectly fine with it.


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

[Tom Hughes]

On 22/01/18 15:34, Tom Hughes wrote:

On 22/01/18 15:26, Jerry James wrote:


One configuration that appears to be particularly unstable is a
dual-monitor setup with nouveau.  I experience frequent system hangs
with that setup, and don't seem to be alone; e.g.,
https://bugzilla.redhat.com/show_bug.cgi?id=1491565.  (Note that I do
not have a HiDPI monitor, but I also don't see all of the issues the
reporter of that bug noted.)  I'm going to try using X sessions this
week to see if that helps at all.  If not, they are probably nouveau
bugs unrelated to Wayland.


Does wayland actually support that?

I have a triple monitor setup with nouveau on one machine and that has 
always fallen back to X so I just assumed wayland didn't support that yet.


Actually thinking about it I think it's the fact that two of the 
monitors have a rotation applied that blocks wayland.


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: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa" 

Hi,

Thanks for the review !

> I really do like this. There are only two issues I have with it:

> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.

Well that was not the intent, I probably need to clarify things a bit more. The 
*devel* package must absolutely be named after the import path (for sanity 
sake). The core package can be named something else (usually because it's the 
packaging of an app)

For example in my etcd spec

Name:etcd ← well-known app name
%package   -n %{goname}-devel ← go naming for go devel stuff

> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> people who release Go code as tarballs (it's rare, but it happens).
> How do you deal with that?

The proposal automates integration with forges, it does not mandate it

You can declare manually archivename archiveurl and forgesetup before calling 
the %gometa macro and 
you should benefit from the rest of the automation even on an hosting site it 
does not know anything about. The whole code tries very hard to let the 
packager pre-define everything it may guess wrong or not know about to avoid 
giving up on all the automation just because a little part is wrong.

And even after that you can still declare Source manually and pass arguments to 
setup the old way it that's what you want

Not calling %gometa at all will kill stuff like goname which is kind of 
mandatory for consistency.

Regards,

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

Re: Wyland is a disaster

[Adam Williamson]

On Mon, 2018-01-22 at 07:16 -0500, Christian Fredrik Schaller wrote:
> Sorry for responding to myself here, but I thought it could also be
> worthwhile to mention that one of our primary tools for identifying
> problems is the Fedora ABRT server. Looking at the current stats it looks
> to me like F27 is actually doing better than F26 used to in
> terms of minimizing crashers: https://goo.gl/babuJx
> 
> There is always a chance ABRT is not catching the issues of course for some
> reason,

Well, see my mails from last month or so to desktop@ . There's several
problems with how abrt interacts with GNOME and Wayland; I'm not sure
to what extent these distort the figures.

First problem: abrt considers *lots* of actually-unrelated crashes to
be duplicates, because their tracebacks look similar - this happens
because glib has a special 'logging' function which actually means
(more or less) 'die intentionally, with this log message'. abrt tends
to interpret many bugs that crash along that path as dupes of each
other, even if the actual cause of the crash - whatever triggers that
special log message call - is different in each case. I've filed a
couple of variants of this at:
https://bugzilla.redhat.com/show_bug.cgi?id=1509086

Second problem: I *think* there's a similar issue with the recently-
introduced `dump_gjs_stack_on_signal_handler` path; I've found at least
some cases of apparently-unrelated bugs being marked as dupes due to
that path. Details:
https://github.com/abrt/satyr/issues/272

Third problem: abrt doesn't do a very good job of reporting any crash
that's caused by Xwayland dying. All you get is a backtrace that
basically tells you "Xwayland crashed", but no useful information about
why. Sometimes the system log extract that abrt captures happens to
shed some light on the reason, but sometimes it doesn't. Details:
https://github.com/abrt/satyr/issues/271

I did some cleanup on false dupes and things caused by these problems,
but it's necessarily incomplete, and I know more dupes have been filed
since I did the cleanup...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
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 22 January 2018 at 00:29, Tomasz Kłoczko  wrote:
> 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.
>

No I didn't. It is clear that our versions of English are not syncing
up so I am not sure how to communicate clearly with you. You think I
am reading in between the lines, but I think I am reading what you are
saying as direct and to the point of what you are wanting to do.
However they are not matching up and you seem to be taking offence
when I was thinking I was being helpful. Since that isn't happening, I
am ending my part of the conversation until such time as I can figure
out how to communicate better with you.

-- 
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)

[Josh Boyer]

On Mon, Jan 22, 2018 at 10:18 AM, Tomasz Kłoczko
 wrote:
>
> On 22 January 2018 at 10:42, Josh Boyer  wrote:
> [..]
>>
>> > After make major release no one cares what happen next in Fedora.
>>
>> This is false.  Even by your own reasoning, lots of people certainly
>> care in the context of the release after the current one.  However
>> even the period between major RHEL releases is important in terms of
>> Fedora and RHEL.
>
>
> So far I've checked quite big number of latest CentOS 7.x specs files and so 
> far I didn't saw any new pulls from Fedora made after major EL snapshot even 
> if source tar ball has been updated.
> Can you point to some exact examples? (packages names will be enough .. mare 
> than better)

You are conflating technical implementation of change with a
relationship.  If you meant to say "Fedora spec changes are not pulled
into a RHEL release directly after a major change", that's fine.  That
isn't what you said though.  My response was to point out that A LOT
of people still care.

Even on the technical part, the spec files might not be directly
imported but as others have indicated elsewhere, Fedora changes
between major RHEL releases are still relevant to a number of
packagers.  The same change might be reflected in both places in
different ways due to different requirements and process.

Perhaps that is a bit of a higher level conversation than what you
were focusing on, but I really want people to understand this
importance.  Seeing statements that indicate otherwise paints an
incorrect picture.

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

Re: Wyland is a disaster

[Adam Williamson]

On Mon, 2018-01-22 at 08:26 -0700, Jerry James wrote:
> 
> One configuration that appears to be particularly unstable is a
> dual-monitor setup with nouveau.  I experience frequent system hangs
> with that setup, and don't seem to be alone; e.g.,
> https://bugzilla.redhat.com/show_bug.cgi?id=1491565.

On the other hand, I'm running Rawhide on a dual-monitor setup with
"nouveau" and not hitting that at all. (Though it recently stopped
being able to resume from suspend successfully).

Point being, 'nouveau' is insufficiently specific. The main graphics
drivers these days support a huge range of hardware, and have very
different codepaths depending on what your particular adapter is. So,
you need to ensure that a report of this precisely identifies your
hardware, and ideally includes at least a log from booting with
'drm.debug=14'.

And yeah, it doesn't sound like this is necessarily related to Wayland
at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Adam Williamson]

On Mon, 2018-01-22 at 15:39 +, Tom Hughes wrote:
> On 22/01/18 15:34, Tom Hughes wrote:
> > On 22/01/18 15:26, Jerry James wrote:
> > 
> > > One configuration that appears to be particularly unstable is a
> > > dual-monitor setup with nouveau.  I experience frequent system hangs
> > > with that setup, and don't seem to be alone; e.g.,
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1491565.  (Note that I do
> > > not have a HiDPI monitor, but I also don't see all of the issues the
> > > reporter of that bug noted.)  I'm going to try using X sessions this
> > > week to see if that helps at all.  If not, they are probably nouveau
> > > bugs unrelated to Wayland.
> > 
> > Does wayland actually support that?
> > 
> > I have a triple monitor setup with nouveau on one machine and that has 
> > always fallen back to X so I just assumed wayland didn't support that yet.
> 
> Actually thinking about it I think it's the fact that two of the 
> monitors have a rotation applied that blocks wayland.

I have a dual monitor setup with both monitors rotated, using an NVIDIA
adapter (9600 GT). Works fine, uses Wayland. Again, you need to be
*very specific* about graphics issues. They are very often very
specific to the exact hardware in use - down to the model of the
graphics card and which specific outputs are used.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
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)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-22 at 12:31 +0100, Miroslav Suchý wrote:
> Dne 20.1.2018 v 12:27 Igor Gnatenko napsal(a):
> > Why I'm writing this? I want to hear from you if you think it would be good
> > to
> > prohibit (or advise, or whatever mechanism would work) usage if
> > conditionals in
> > (at least) master branch to allow us to develop features faster. Thoughts?
> 
> -1
> 
> If this were ever approved, I would orphan a lot of packages because I will
> not have time to maintain them.
> 
> > Given all these, it is very hard to get any new feature in "production"
> > because
> > everyone wants to support 10 years old thing (even if they don't think so).
> 
> Can you give a specific example? Everything you mentioned can be easily
> conditionalized on RHEL7+.
> 
> For me (as an upstream author who maintains the spec file as well) the
> conditionals are useful. When I see something like:
> 
>   %if 0%{?rhel} < 6
> 
> then I know I can wipe it now and **remove the relevant code** in the
> application as well.
> 
> Maintaining 3 spec files for Fedora and 1-2 spec files for EPEL is much much
> bigger overhead. Especially when they are
> mostly identical and differ only in few lines.

Better to introduce bugs?

mock-core-config now requires yum on Fedora because you made wrong if in
spec...

https://bugzilla.redhat.com/show_bug.cgi?id=1537193
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpmEF0ACgkQaVcUvRu8
X0wXKA//cycdU9rYq1Zxd8+x+CqorZQVgIJcdppOWP8V6QCXHyoNz7ejnhUb395S
vcWI9cpmzZ1BficgP37f9drSxSr3H/GRXKOEwt7aeAO3ApPwVFPpTKswnfun53Jn
5sFHkLzRISb4fXQurbrdUP2zx3POOkT0GvlTgq4Q30zjWkYvpKmcMdQUvBJYuH2E
Jtl0f1x0nwcS1XUrPVwV9AmB/AdzqwCX02zVHhzudJ/nbeXqWokqA/Ojl3LM1A+1
BRMsIc4CgB5TjiEPtwUHAH4q8/XFcLSVQk+92S9zAhiG2LYz22SG2z6NbRihOlpe
mO83nkaTngqgVo9W9y5xos6Hev5HHCcddI7bhfMaimabtHBry6lYFcUKyApQcFCO
yatsu2MRfjepNdI+53gbQGUag5uFR69jPXGe4b4OxgJV8wWpfOXWJQfGeTL3+Zpt
OittwnKohzBaFbyuQN/b0ogpOdC1YBCzU9C2CAE7PTKZ0a0F8kFBhRCt/CFVz1lG
VWY1df9w3kW0X3s3TjXQhOX9TU2k0e06GdtPNbrKPDkGihvHoiCIHOaHnYcmaL7C
tNwy9XZBp1I+5dmEmHqTXsihrOiZWnzOPRnmcPAs1iirj4aNvPwdyzGm3Tf6b/a2
fIMFt1unknb+qojOQI+LCoGF8KUB4H4q5IUsE4gENAygBgwNAoc=
=WMFv
-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

[Olivier Fourdan]

Hi

On Mon, Jan 22, 2018 at 4:54 PM, Adam Williamson  wrote:

> On Mon, 2018-01-22 at 07:16 -0500, Christian Fredrik Schaller wrote:
> > Sorry for responding to myself here, but I thought it could also be
> > worthwhile to mention that one of our primary tools for identifying
> > problems is the Fedora ABRT server. Looking at the current stats it looks
> > to me like F27 is actually doing better than F26 used to in
> > terms of minimizing crashers: https://goo.gl/babuJx
> >
> > There is always a chance ABRT is not catching the issues of course for
> some
> > reason,
>
> Well, see my mails from last month or so to desktop@ . There's several
> problems with how abrt interacts with GNOME and Wayland; I'm not sure
> to what extent these distort the figures.
>
> First problem: abrt considers *lots* of actually-unrelated crashes to
> be duplicates, because their tracebacks look similar - this happens
> because glib has a special 'logging' function which actually means
> (more or less) 'die intentionally, with this log message'. abrt tends
> to interpret many bugs that crash along that path as dupes of each
> other, even if the actual cause of the crash - whatever triggers that
> special log message call - is different in each case. I've filed a
> couple of variants of this at:
> https://bugzilla.redhat.com/show_bug.cgi?id=1509086
>
> Second problem: I *think* there's a similar issue with the recently-
> introduced `dump_gjs_stack_on_signal_handler` path; I've found at least
> some cases of apparently-unrelated bugs being marked as dupes due to
> that path. Details:
> https://github.com/abrt/satyr/issues/272
>
> Third problem: abrt doesn't do a very good job of reporting any crash
> that's caused by Xwayland dying. All you get is a backtrace that
> basically tells you "Xwayland crashed", but no useful information about
> why. Sometimes the system log extract that abrt captures happens to
> shed some light on the reason, but sometimes it doesn't. Details:
> https://github.com/abrt/satyr/issues/271
>
> I did some cleanup on false dupes and things caused by these problems,
> but it's necessarily incomplete, and I know more dupes have been filed
> since I did the cleanup...
>

Regarding the characterization of issues with Wayland, there is a bit of
history behind all this, and are a couple things to consider as well.

With GNOME on Wayland, gnome-shell/mutter is the display server and
gnome-shell/mutter still depends on Xwayland to run [1] and cannot survive
a crash in Xwayland.

Xwayland is an X server for the X11 clients but a Wayland client as well,
so if gnome-shell/mutter crashes, Xwayland will lose its connection to the
Wayland compositor and therefore dies as well.

So both components (gnome-shell/mutter and Xwayland) are tightly coupled
and cannot survive one each other (in GNOME).

That alone makes automatically (or even manually) root causing an issue
afterwards a bit of a challenge sometimes, one has first to determine which
of the two components has died first and taken the other with it.

To make things slightly more challenging, Xwayland would not generate a
core file on a crash, just a self-generated backtrace that could be found
in journalctl, so in some case, it would be almost impossible to tell why
the Wayland session crashed as no core file for Xwayland would be available
(and the self-generated backtrace is rarely of much help, sadly).

So gnome-shell/mutter added “-core” to the Wayland command line (Xwayland
being started automatically by gnome-shell/mutter) so that we could capture
a core file every time Xwayland would crash [2].

Unfortunately, using “-core” instructs Xwayland to generate a core file
each time a fatal error occurs, and losing the connection to the Wayland
compositor is a fatal error for Xwayland, so now each time
gnome-shell/mutter crashes, we also get a core file for Xwayland and get
reports about a bug in Xwayland whereas the issue come from
gnome-shell/mutter. That alone generates a lot of false positive for
Xwayland, and a lot of duplicates (the backtrace usually contains
“xwl_read_events()”)

The way to solve that problem is to change Xwayland to not call
FatalError() when the Wayland compositor dies so that no core is generated
in this case, a patch for this has already landed in the xserver master
branch upstream [3].

With this, we should get a core file for “real” crashes but not when
Xwayland is aborting because the Wayland compositor (gnome-shell/mutter)
has crashed, hopefully that will help with a better characterization of
Wayland issues in the future.

HTH,

Cheers,
Olivier

[1] https://bugzilla.gnome.org/show_bug.cgi?id=759538
[2] https://bugzilla.gnome.org/show_bug.cgi?id=789086
[3] https://cgit.freedesktop.org/xorg/xserver/commit/?id=
fe46cbea0f19959d469ca4d1f09be379dc7b1e45
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] Manging shebangs in Rawhide

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I'm planning to merge PR[0] somewhere later this week. Essentially it does:

For each executable files:
* Replaces /usr/bin/env foo with /usr/bin/foo
* Replaces /usr/bin/python with /usr/bin/python2
* Removes exectuable bit (and shows warning) for files where there are no
shebang
* Errors when shebang doesn't start with slash (because it is really incorrect)

To disable, you can do %undefine __brp_mangle_shebangs.


Just to remind you, depending on /bin/env in system packages is wrong because
under some conditions it will stop working and what we are trying to do is that
packaged applications ALWAYS WORK.

[0] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/9
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpmEygACgkQaVcUvRu8
X0yT9xAAiiJjtMHUzmd+5VHfOCbzrEoTXJrfma+WUPsL+V0DnP43Yht7XTS4MsSw
kbwKI+Xlwk1QB2z2tQQY70UeYaWdfGQ2VtQ2485MEVUh8i7EWgUrrlXbY+YlPMEV
73wuzGICm1Eb9SVvZqmxC6gceNLhFGtDFqFHp8LVhidWU7la0zg7PMj6WRd5781s
iwRFSn1xkQM64ojdtbjZH+Pe0VvgqSqktpDBTI1849cRWagiJNIMVBj2K6bg3XSV
tmRTceeRkJ/eUYGFC9DQ8aV8FnRWVs0OUi8Fe9NhIK0KzHJAKvWR/J25+BOGYMWG
fR4wJ2ZRLsQg/HJ3VL3ESsmCE1baqfYLdnBt0uz4JKmZmduezEn6mJiUYdBCOh1u
yF3VIxSartbTzxKO0UxF8krc57mxsiVA+jwTFiTtcgeEmpbPfYtclsiT2Z0d7VT3
/fkcee/y2ndmEtFa0yLLUtdOdCghRxnZnG/emJnRmEKVPR5WFEaXW2c1RoaG9Z4/
8XcKDRFWzJkWvsp9VCJgWIoqPNbMJGDiqRr3aJCQFd968eeudxKycbniCPUBtGxI
s4KqvU6b+6QtOFdClk/dzcaF1P/6FMk/64NZaNcI6kZAfCcfOfmn9Hbh9DlIw8ar
BlBQ+o1mav00QVsRHA0uDURbRuoFASkGaDS2Ri1WixnX+MDPvME=
=1Nbs
-END PGP SIGNATURE-
___
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 15:53, Stephen John Smoogen  wrote:
[,,]

> > OK so here you just gave me +1 for a). Thx.
> >
>
> No I didn't. It is clear that our versions of English are not syncing
> up so I am not sure how to communicate clearly with you. You think I
> am reading in between the lines, but I think I am reading what you are
> saying as direct and to the point of what you are wanting to do.
> However they are not matching up and you seem to be taking offence
> when I was thinking I was being helpful. Since that isn't happening, I
> am ending my part of the conversation until such time as I can figure
> out how to communicate better with you.


Why you are using rhetoric ("argumentum ad hominem/personam" to be more
precise) against me and not using exact specs from CentOS showing that I'm
wrong?
Maybe it is not obvious but rhetoric newer was, isn't and never will be
toll of proving/disproving anything.
It is pure distracting tool and I know how to recognize it .. instantly.
*If you don't know what you just used here is the explanation/description *
https://en.wikipedia.org/wiki/Ad_hominem

Yes, my English is not perfect buy how I'm using English has nothing to do
with subject, CentOS and/or Fedora specs files. Isn't it?

So back to subject.
Show me pairs of Fedora and CentOS specs files.
This ONLY few ways which can change result of the discussion.
Just for the record: during discussions we should be using arguments or
counterarguments.
No impressions, no "I", no "you", ways thinking, guesses. assumptions ..
etc.
Just pure facts .. *please*.
If you agree to stand on such platform you don't even need English to
communicate with me.
Use example spec files. It is really so simple.

Other possible way which you can use. Try to answer on below questions.

Are you one of the few persons who added in the past to Fedora specs CentOS
%ifings?
Do you know what was the propose of those %ifings?
In what kind of context they have been used?
Is this context still applicable to current state of the Fedora and CentOS?
Are those %ifings still in use by someone?

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: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Adam Jackson]

On Fri, 2018-01-05 at 12:19 +0100, Jan Kurik wrote:
> = System Wide Change:Removal of Sun RPC Interfaces From glibc =
> https://fedoraproject.org/wiki/Changes/SunRPCRemoval
> 
> Change owner(s):
> * Florian Weimer fweimer AT redhat DOT com>
> 
> 
> This system-wide change covers the removal of interfaces related to
> Sun RPC from glibc.

I'm trying to prepare xserver for this change, and it seems to provoke
an awkward warning when building on F27:

In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
 extern int bindresvport(int, struct sockaddr_in *);
^~~~
In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
 from ../os/rpcauth.c:47:
/usr/include/netinet/in.h:502:12: note: previous declaration of ‘bindresvport’ 
was here
 extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) __THROW;
^~~~

Is there any reasonable fix for this? I assume this wouldn't happen in
F28 because glibc (providing ) would not provide that
decl anymore, though I've not tried.

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

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Florian Weimer]

On 01/22/2018 06:26 PM, Adam Jackson wrote:

On Fri, 2018-01-05 at 12:19 +0100, Jan Kurik wrote:

= System Wide Change:Removal of Sun RPC Interfaces From glibc =
https://fedoraproject.org/wiki/Changes/SunRPCRemoval

Change owner(s):
* Florian Weimer fweimer AT redhat DOT com>


This system-wide change covers the removal of interfaces related to
Sun RPC from glibc.


I'm trying to prepare xserver for this change, and it seems to provoke
an awkward warning when building on F27:

In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
  extern int bindresvport(int, struct sockaddr_in *);
 ^~~~
In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
  from ../os/rpcauth.c:47:
/usr/include/netinet/in.h:502:12: note: previous declaration of ‘bindresvport’ 
was here
  extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) __THROW;
 ^~~~

Is there any reasonable fix for this?


Redeclarations in system headers are expected.  Do you compile with 
-Wsystem-headers?  Or do you something else which is unusual, such as 
running the preprocessor separately?


Thanks,
Florian
___
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 22 January 2018 at 15:54, Josh Boyer  wrote:

> On Mon, Jan 22, 2018 at 10:18 AM, Tomasz Kłoczko
>  wrote:
> >
> > On 22 January 2018 at 10:42, Josh Boyer 
> wrote:
> > [..]
> >>
> >> > After make major release no one cares what happen next in Fedora.
> >>
> >> This is false.  Even by your own reasoning, lots of people certainly
> >> care in the context of the release after the current one.  However
> >> even the period between major RHEL releases is important in terms of
> >> Fedora and RHEL.
> >
> >
> > So far I've checked quite big number of latest CentOS 7.x specs files
> and so far I didn't saw any new pulls from Fedora made after major EL
> snapshot even if source tar ball has been updated.
> > Can you point to some exact examples? (packages names will be enough ..
> mare than better)
>
> You are conflating technical implementation of change with a
> relationship.  If you meant to say "Fedora spec changes are not pulled
> into a RHEL release directly after a major change", that's fine.  That
> isn't what you said though.  My response was to point out that A LOT
> of people still care.
>
[..]

Sorry but this is not what I'm trying to say.
I'm not conflating/combining more than one things.
It is only one thing which is connected to the subject which is connected
with the answer on the question: why CentOS %ifings are in Fedora specs?
Do you know the answer?
if CentOS on star working on next EL major release is not using Fedora
specs but already forked and adapted to RHEL and CentOS by definition is
"free to use RHEL" so it must be 100% compatible with EL why those %ifings
are in Fedora on such big scale? (239 Fedoora specs)

Sorry to say this but I don't want to continue conversation on any
"perhaps" because it is no longer discussion but only conversation.


Last min update ..
Writing above just finished exacting all specs from latest CentOS 7 src.rpm
packages.
Eureka!!! There is no %{centos} %ifings in those specs.
I've had as well one more time on raw grep result on Fedora specs and .. I
found that that I was a bit wrong (shame ..) about scale of using CentOS
%ifings 😎
Almost all %{centos} macros are in exactly the same COMMENTED 🤔line which
looks like:

douceur.spec:# rhel specific macros, you can use %%if 0%%{?rhel} &&
0%%{?centos} == 0 condition.

There only few specs which are actually using %{centos} in %ifing and I'm
~100% sure that it will be possible remove all CentOS traces from Fedora
because theey are duplicationg %{rhel} macro.
Result of exact command and result of the command which shows exactly about
what is going on in context CentOS %ifings.

[tkloczko@domek SPECS.fedora]$ (for i in centos ; do echo -n "$i "; grep
'%{?'$i * ; done) | grep -v "rhel specific macros"
ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )
ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )
cockpit.spec:%if 0%{?centos}
cockpit.spec:%if 0%{?centos}
cockpit.spec:%if (0%{?rhel} == 7 && "%{os_version_id}" == "7.4") ||
0%{?centos} == 7
cockpit.spec:%if 0%{?rhel} >= 8 || 0%{?centos} >= 8 || 0%{?fedora} >= 27
cockpit.spec:%if 0%{?rhel}%{?centos} == 0
container-selinux.spec:%if 0%{?fedora} || 0%{?centos} || 0%{?rhel} > 7
cri-o.spec:%if 0%{?centos}
docker-latest.spec:%if 0%{?fedora} || 0%{?centos}
docker-latest.spec:%else %if 0%{?centos}
docker.spec:%if 0%{?centos}
docker.spec:%if 0%{?fedora} || 0%{?centos} || 0%{?rhel} > 7
docker.spec:%else %if 0%{?centos}
godep.spec:%if 0%{?centos}
pdc-client.spec:%if (0%{?rhel} && 0%{?rhel} <= 6) || (0%{?centos} &&
0%{?centos} <= 6)
php-libvirt.spec:%if 0%{?rhel} == 7 && 0%{?centos} == 0
rear.spec:%if %{?centos_version:1}%{?fedora:1}%{?rhel_version:1}0
resource-agents.spec:%if 0%{?fedora} || 0%{?centos_version} || 0%{?rhel}
resource-agents.spec:%if 0%{?fedora} || 0%{?centos_version} || 0%{?rhel}
resource-agents.spec:%if 0%{?fedora} || 0%{?centos_version} || 0%{?rhel}
resource-agents.spec:%if 0%{?fedora} > 18 || 0%{?centos_version} > 6 ||
0%{?rhel} > 6
resource-agents.spec:%if 0%{?suse_version} == 0 && 0%{?fedora} == 0 &&
0%{?centos_version} == 0 && 0%{?rhel} == 0
resource-agents.spec:%if 0%{?fedora} >= 11 || 0%{?centos_version} > 5 ||
0%{?rhel} > 5
runc.spec:%if ! 0%{?centos}
skopeo.spec:%if 0%{?centos}
strace.spec:%if 0%{?fedora} >= 20 || 0%{?centos} >= 8 || 0%{?rhel} >= 8 ||
0%{?suse_version} >= 1300
vdsm.spec:%if ! 0%{?centos}

At least one or two above %ifings on first look does not make any sense ..

So .. CentOS sub subject and point is officially *done*.
In few days when I'll be raising PR I'm sure that I'll be able to change it
to "done, done".

Still other 5 points out of my original 8 are waiting on some additional
facts .. 🤔😎
Please help me find what I'm looking for ..

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)

[R P Herrold]

On Mon, 22 Jan 2018, Tomasz K?oczko wrote:

> [tkloczko@domek SPECS.fedora]$ (for i in centos ; do echo -n "$i "; \
grep '%{?'$i * ; done) | grep -v "rhel specific macros"
> ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )

> ceph.spec:%if ( ( 0%{?rhel} && 0%{?rhel} <= 7) && ! 0%{?centos} )
> cockpit.spec:%if 0%{?centos}

> container-selinux.spec:%if 0%{?fedora} || 0%{?centos} || 0%{?rhel} > 7
> cri-o.spec:%if 0%{?centos}
> docker-latest.spec:%if 0%{?fedora} || 0%{?centos}

> docker.spec:%if 0%{?centos}

> godep.spec:%if 0%{?centos}
> pdc-client.spec:%if (0%{?rhel} && 0%{?rhel} <= 6) || (0%{?centos} &&
> 0%{?centos} <= 6)
> php-libvirt.spec:%if 0%{?rhel} == 7 && 0%{?centos} == 0
> rear.spec:%if %{?centos_version:1}%{?fedora:1}%{?rhel_version:1}0
> resource-agents.spec:%if 0%{?fedora} || 0%{?centos_version} || 0%{?rhel}

> runc.spec:%if ! 0%{?centos}
> skopeo.spec:%if 0%{?centos}
> strace.spec:%if 0%{?fedora} >= 20 || 0%{?centos} >= 8 || 0%{?rhel} >= 8 ||
> 0%{?suse_version} >= 1300
> vdsm.spec:%if ! 0%{?centos}

you may wish to add a:
| awk -F: {'print $1'} | uniq


I am not quite sure what point you are trying to make -- in an 
'ad hoc' local collection of a bit under 2000 .specs, I turn 
up an additional match:

[herrold@centos-7 SPECS]$ (for i in centos ; do echo -n "$i "; \
grep '%{?'$i * ; done) | grep -v "rhel specific macros"
qpdfview.spec:%if 0%{?centos_version}
qpdfview.spec:%if 0%{?centos_version}
rear.spec:%if 
%{?centos_version:1}%{?fedora_version:1}%{?rhel_version:1}0
[herrold@centos-7 SPECS]$ 


and very curiously as to 'strace' in your list, of course 
there ** is no **
'0%{?centos} >= 8

nor a released rhel at that number either ;)

We might speculate, given the component ('cockpit' and 
'strace') it relates to that internal candidates inside RHEL 
engineering that find using that number '8' useful, however, 
for doing development


I am presently standing for the elected office on 'council', 
and really part of my 'platform' locked in last November of 
December was working at 'healing' the fissures between Fedora 
and EPEL

I do not see that the rapid fire posts in which you have 
engaged in the last few days really _help_ that goal, but 
rather they seem strident and divisive, and seem to make 
harder such 'healing'

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

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

[Matthew Miller]

On Sat, Jan 20, 2018 at 08:51:15AM +0100, Igor Gnatenko wrote:
> > As you know, I want to go the other way. I want to bring Fedora
> > improvements to Fedora packages built for EL _more quickly_. That may
> > not be possible with EL7 and certainly not with EL6, but let's not
> > close ourselves off from a better future.
> That would be nice, but what to do with el6/el7 which will be supported for
> next N years? It is definitely not possible to get any RPM features (to my
> knowledge) in there because it is system-critical component and there is no
> even DNF (YUM doesn't work with rich dependencies).

EL6 is probably a lost cause. So ancient. :)

For EL7, I'm thinking that perhaps we'll need new repository (Robyn's
EPIC!) that sits next to EPEL and allows people to opt in to more
adventure.



-- 
Matthew Miller

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

Re: Unresponsive maintainer

[Matthew Miller]

On Sun, Jan 21, 2018 at 05:38:12PM -0600, Tao Zhao wrote:
> Thanks for the information! I've pinged his gmail. Let's see how it goes.

I saw him mention that he'll be at DevConf.cz, so maybe someone can
catch him there.

-- 
Matthew Miller

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

Re: Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Mon, Jan 22, 2018 at 02:55:37AM -0600, Dennis Gilmore wrote:
> > It's the plan of record that by default, all modules will be built
> > across all available buildroots. I'm not sure if that means EPEL7
> > will be an available option for technical reasons, but I hope so.
> > This will possibly require a modular-capable DNF in EPEL proper or
> > in a side- repo of some sort -- TBD. But if that works, we'll start
> > having modular content for EL right along with the F28 release.
> If this is something we want to do in that timeline things need to be
> getting put in place now. We should have a discssion about what we
> would like, what timelines we would do it on, and how it would all look
> and work. The DNF and RPM teams probably need to chime in to let us
> know what is practical. in order to have it in the F28 timeline we need
> to get it enabled in the next 6-8 weeks.

Good point -- I'm not sure this got into the "todo list" when we had
the last discussion about it. To be clear, this definitely shouldn't
hold up any work on getting the basic functionality for F28 in place.
We might have to scale back my dream to "right along with the F29
release" -- but I hope not.


-- 
Matthew Miller

Fedora Project Leader
___
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)

[Matthew Miller]

On Sat, Jan 20, 2018 at 02:23:16PM +0100, Igor Gnatenko wrote:
> What I'm trying to say here is that each time we want to implement
> some feature in Fedora, we either need to have some replacement in
> EPEL or diverge Fedora branches from EPEL branches. Having
> replacement is not always possible, especially if we start utilizing
> new (actually 8 years old) features of RPM.

I'd really like to see us tend towards coming up with macros that
provide elegant fallbacks on EPEL. (The %license macro is a good
example.)

I get the frustration with older stuff holding us back, but we really
have a _lot_ of users who get value from doing so.
https://twitter.com/mattdm/status/936243506355621888

-- 
Matthew Miller

Fedora Project Leader
___
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 22 January 2018 at 12:21, Tomasz Kłoczko  wrote:
> On 22 January 2018 at 15:53, Stephen John Smoogen  wrote:
> [,,]
>>
>> > OK so here you just gave me +1 for a). Thx.
>> >
>>
>> No I didn't. It is clear that our versions of English are not syncing
>> up so I am not sure how to communicate clearly with you. You think I
>> am reading in between the lines, but I think I am reading what you are
>> saying as direct and to the point of what you are wanting to do.
>> However they are not matching up and you seem to be taking offence
>> when I was thinking I was being helpful. Since that isn't happening, I
>> am ending my part of the conversation until such time as I can figure
>> out how to communicate better with you.
>
>
> Why you are using rhetoric ("argumentum ad hominem/personam" to be more
> precise) against me and not using exact specs from CentOS showing that I'm
> wrong?

I am not meaning to use rhetoric tricks, and I will try to be clearer.

I am saying that interpreting my statements as giving you a +1 is
wrong. Nothing about what you proposed earlier.  If I am going to give
you a +1 I will do so clearly and with my own typing. Taking my words
out of context is all I am disagreeing with you.

That said, I am not agreeing with you either. We have a trilogic
position. +1 I agree, 0 I have not made up my mind, -1 I disagree. I
am at 0 . I have reservations mainly out of a history of dealing with
the n hundred Fedora maintainers  on past cleanups and how many times
the cleanup fails not because the fix wasn't needed but because the
people pushing the fix didn't do the groundwork needed. That
groundwork is not about showing how bad stuff is or how illogical
something is. It has to do with convincing N hundred developers that
they have less work and more control if they do it the new way.

The reason I want to know is that it is a lot of work and it depends
on how the proposer deals with people who can't see exactly what the
proposer is saying. When it works it goes well. When it does not it is
just constant garbage battles and flame wars. The problem I am seeing
here is that I am someone who knows what work you have done in PLD and
have been very much wanting to work with you on better packaging for
years. I have looked at what you did for some package and then moved
it over to a spec file I needed when I ran into some sort of problem.
You should have had no problem convincing me that what you want is a
good idea. Instead I am at the point of screaming obscenities at my
keyboard.

-- 
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)

[Matthew Miller]

On Sun, Jan 21, 2018 at 08:07:29PM +, Tomasz Kłoczko wrote:
> 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?

Remember that EPEL is _part of Fedora_. Someone with primary (or sole!)
interest in providing packages on that base is _also_ part of Fedora.

Fedora is a project that does a lot of hard, generally thankless work.
Packaging for an OS is no longer generally regarded as the "cool kid"
thing to do in the open source ecosystem. (Even though I think you're
cool, y'all.) So, let's figure out how we can include more people to
better work together, rather than saying that some parts of the project
don't count.


-- 
Matthew Miller

Fedora Project Leader
___
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)

[Matthew Miller]

On Mon, Jan 22, 2018 at 08:38:56AM +, Tomasz Kłoczko wrote:
> It happens only when next major EL release is made.
> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_with_Fedora
> After make major release no one cares what happen next in Fedora.

This might have been a past pattern, but we (Fedora leadership working
at Red Hat, along with RH counterparts) are working to make this
better. (See the "What does Red Hat want?" talks from previous
DevConf.cz and Flock conferences.)

-- 
Matthew Miller

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

F28 Self Contained Change: Enabling Python Generators

[Jan Kurik]

= Proposed Self Contained Change: Enabling Python Generators =
https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators

Change owner(s):
* Igor Gnatenko 
* Neal Gompa 

This change enables the ability to choose to use the Python module
dependency generator for packages that provide Python Egg/Wheel
metadata.


== Detailed Description ==
There is RPM dependency generator which is able to automatically add
Requires/Provides and other types of dependencies based on egg/wheel
metadata. The part which is generating Provides has been used in
Fedora since Jun 2016 which means by now all packages which provide
egg/wheel metadata have Provides: pythonX.Ydist(xyz) added
automatically. With this change proposal we allow people to opt-in for
using automatic generation of Requires.

All dependencies which are added are generated out of metadata which
means in order to fix them - you need to fix metadata (usually
setup.py or requirements.txt).

Other distributions (such as Mageia, OpenMandriva, and PLD) have been
using this dependency generator for long time already.

In F29 we plan to propose to make generator opt-out.


== Scope ==
* Proposal owners:
Add macros to python-rpm-macros package which enables dependency generator.

* Other developers:
Packagers are advised to replace their hand-crafted list of
dependencies on python libraries with simple macros.

* Release engineering:
#7276: https://pagure.io/releng/issue/7276

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
Packaging:Python Guidelines need to reference how to turn on the
feature (simple variable override). #740:
https://pagure.io/packaging-committee/issue/740 .

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Tom Hughes]

On 22/01/18 15:58, Adam Williamson wrote:


I have a dual monitor setup with both monitors rotated, using an NVIDIA
adapter (9600 GT). Works fine, uses Wayland. Again, you need to be
*very specific* about graphics issues. They are very often very
specific to the exact hardware in use - down to the model of the
graphics card and which specific outputs are used.


1 x NVIDIA Corporation G84 [GeForce 8600 GT]

with DVI-I-1 connected to 2560x1600 panel
and DVI-I-2 connected to 1600x1200 panel rotated right

1 x NVIDIA Corporation GT218 [GeForce 210]

with DVI-I-1-3 connected to 1600x1200 panel rotated right

I can't see any obvious indication in the logs of why it fell back but 
if it's not rotation maybe it's having multiple cards?


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: EPEL support in "master" branch (aka speeding up Fedora development)

[Tomasz Kłoczko]

On 22 January 2018 at 19:11, R P Herrold  wrote:
[..]

> and very curiously as to 'strace' in your list, of course
> there ** is no **
> '0%{?centos} >= 8
>
> nor a released rhel at that number either ;)
>

First possible explanation is that here it is some kind of mistake ("s*t
happens .. sometimes" 😀).

Other people already mention that CentOS is using own git so theoretically
only by this it should be no CentOS %ifings.
Simple I don't see any reason to introduce %{centos} as CentOS must be by
definition free RHEL deriv.
Logic says that only %{rhel} or even better %{el6}, %{el7} (and so on)
should be in use.

As long as we are talking not few hundreds but only few specs it will be
not a big deal to *verify* all left specs "manually" .. one by one (even
contacting with people which made exact commits).
If you want to take care of this small part .. feel free 😀
I'll have one point less on my ToDo list 😋

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 22 January 2018 at 20:06, Tomasz Kłoczko 
wrote:
[..]

> Logic says that only %{rhel} or even better %{el6}, %{el7} (and so on)
> should be in use.
>

Yet anther thought ..
As long as between major EL releases is huge "distance" in differences
using %{rhel} within %ifings operators like <, <=, >, >= does not make to
much sense.
If this assumption can cover all possible current cases conciliation IS
that %{rhel} should be possible with only with "="  %if operator
Conclusion: to introduce shorter notation better would be use %{el6},
%{el7} and so on.
Introduce such patter will slightly reduce current Fedora specs
"entropy"  😀

Above needs to be verified/proven and as long I or someone else will not do
this I'm going to say that what is in above paragraph is truth 😋
It is ONLY working hypothesis ..

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 22 January 2018 at 19:40, Matthew Miller 
wrote:

> On Sun, Jan 21, 2018 at 08:07:29PM +, Tomasz Kłoczko wrote:
> > 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?
>
> Remember that EPEL is _part of Fedora_. Someone with primary (or sole!)
> interest in providing packages on that base is _also_ part of Fedora.
>

Please remember that I'm not going to propose any actions to kick out EPEL
from Fedora.
So far my working hypothesis is that EPEL would be better to maintain not
on master but on separated branch or branches (el6. el7 ..).
As long as every Fedora spec on master branch will be free it would be
possible to punch much harder Fedora "gas pedal" ..
git makes such branches maintenance backports veeery easy. So everything
around already is in place.
Maybe few people will need some help to learn few tricks but that is all ..
theoretically.

I can only say that with every hour I'm more and more convinced that
actually above "may be truth"😎
And/or this thesis on my list still is in WIP state.

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 22 January 2018 at 19:45, Matthew Miller 
wrote:
[..]

> This might have been a past pattern, but we (Fedora leadership working
> at Red Hat, along with RH counterparts) are working to make this
> better. (See the "What does Red Hat want?" talks from previous
> DevConf.cz and Flock conferences.)


I have no such insight so please share ASAP whatever you will learn new.

Are you talking about
https://flock2017.sched.com/event/Bvps/what-does-red-hat-want ?
If yes, I don't see to to much  what I can try to study ..

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

ABI gate: internal-only shared object

[Jerry James]

Here's something I didn't expect from the new ABI gate.  Which, before
I go further, I think will be a great idea nearly all of the time.  I
think avoiding unintentional ABI breaks in stable releases is a worthy
goal.

But ... I maintain a package called gap.  It provides what amounts to
a scripting language for doing certain types of math.  It comes with a
bunch of addon packages that provide specific mathematical
capabilities.  Most of them are written solely in the scripting
language, but a few have to interface with external libraries.  When
that is required, these packages build a small internal-only shared
object to act as the glue between the external library and the
scripting language.

I've got a pending update for one of these packages that fixes some
bugs.  It has been caught by the ABI gate:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7

There is no danger in pushing this to stable, since the only consumer
of the changed ABI is inside the same package.  Now what do I do?  Are
ABI changes completely disallowed in all circumstances?  Is there a
button somewhere that says, "I am aware of the danger of pushing this
to stable and I have verified that nothing will break in this case"?

Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
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)

[Matthew Miller]

On Mon, Jan 22, 2018 at 08:21:19PM +, Tomasz Kłoczko wrote:
> Yet anther thought ..
> As long as between major EL releases is huge "distance" in differences
> using %{rhel} within %ifings operators like <, <=, >, >= does not make to
> much sense.

That's likely true. But I think it'd be even better to avoid
base-os-name conditionals and use something like %{have_soft_deps} or
something like that.


-- 
Matthew Miller

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

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Adam Jackson]

On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote:
> On 01/22/2018 06:26 PM, Adam Jackson wrote:
> > 
> > I'm trying to prepare xserver for this change, and it seems to provoke
> > an awkward warning when building on F27:
> > 
> > In file included from ../os/rpcauth.c:47:0:
> > /usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
> > ‘bindresvport’ [-Wredundant-decls]
> >   extern int bindresvport(int, struct sockaddr_in *);
> >  ^~~~
> > In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
> >   from ../os/rpcauth.c:47:
> > /usr/include/netinet/in.h:502:12: note: previous declaration of 
> > ‘bindresvport’ was here
> >   extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) 
> > __THROW;
> >  ^~~~
> > 
> > Is there any reasonable fix for this?
> 
> Redeclarations in system headers are expected.  Do you compile with 
> -Wsystem-headers?  Or do you something else which is unusual, such as 
> running the preprocessor separately?

Not that I'm aware of. The generated cc line is:

ninja: Entering directory `build'
[1/17] ccache cc  -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes
-Irender -I../render -Irandr -I../randr -Ipresent -I../present -Iinclude
-I../include -Idri3 -I../dri3 -Idbe -I../dbe -Imiext/sync -I../miext/sync
-Imiext/shadow -I../miext/shadow -Imiext/damage -I../miext/damage -Imi -I../mi
-Iglamor -I../glamor -Ifb -I../fb -Iexa -I../exa -Idamageext -I../damageext
-Icomposite -I../composite -IXi -I../Xi -IXext -I../Xext -I/usr/include/X11/dri
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/tirpc -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -std=gnu99 -O2 -g -DHAVE_DIX_CONFIG_H -fno-strict-aliasing
-fvisibility=hidden -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast
-Wold-style-definition -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn
-Wmissing-format-attribute -Wredundant-decls -Werror=implicit -Werror=nonnull
-Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point
-Werror=return-type -Werror=trigraphs -Werror=array-bounds
-Werror=write-strings -Werror=address -Werror=int-to-pointer-cast
-Werror=pointer-to-int-cast -fPIC -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT -MMD -MQ 'os/libxserver_os@sta/rpcauth.c.o' -MF
'os/libxserver_os@sta/rpcauth.c.o.d' -o 'os/libxserver_os@sta/rpcauth.c.o' -c
../os/rpcauth.c
In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
# ...

Is -Wredundant-decls just not a thing one should try to use?

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

Re: F28 Self Contained Change: Enabling Python Generators

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 22, 2018 at 08:51:43PM +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Enabling Python Generators =
> https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators

It's great that this is finally happening.

> == Detailed Description ==
> There is RPM dependency generator which is able to automatically add
> Requires/Provides and other types of dependencies based on egg/wheel
> metadata. The part which is generating Provides has been used in
> Fedora since Jun 2016 which means by now all packages which provide
> egg/wheel metadata have Provides: pythonX.Ydist(xyz) added
> automatically. With this change proposal we allow people to opt-in for
> using automatic generation of Requires.

What about BuildRequires? Quite often that list even more work
to generate, and your proposal does not address it in any way.
Do you foresee a separate generator that would be run manually
or some other solution?

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

[Fedocal] Reminder meeting : Modularity WG (once every two weeks)

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG (once every two weeks) on 2018-01-23 from 10:00:00 to 11:00:00 
US/Eastern
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](https://board.net/p/modularity-wg-agendas).



Source: https://apps.fedoraproject.org/calendar/meeting/5249/

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

Re: ABI gate: internal-only shared object

[Rex Dieter]

Jerry James wrote:

> Are ABI changes completely disallowed in all circumstances?

no.

As far as I know and can tell, those gating things are advisory only at this 
point.

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

[HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

I'd like to notify you that today I've finished my works on date
formatting in glibc, that means upstream. These changes are already
arriving to Fedora Rawhide (they should be there tomorrow) and will
be part of Fedora 28. They will be included in glibc 2.27 (to be
released on February 1), or in pre-release upstream version
2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).

What has been changed:

* strftime() family (including stftime_l(), wcstime(), wcstime_l(),
strptime() etc.): there are new format specifiers: %OB, %Ob, %Oh.
It has been specified that the currently existing format specifiers:
%B, %b, and %h generate the month names (%B--full month names, %b
and %h--abbreviated month names) in a grammatical form required when
the month is used as a part of a complete date (that means: together
with the day number) while the new format specifiers with %O (note:
this is O letter, the uppercase o, not the zero digit, 0) will generate
the month names in a grammatical form required when the month is named
by itself (without a day number, usually standalone). In most of the
languages there is no difference between those two forms. However,
there is a group of languages (about 20) where the correct form used in
the full date is a genitive case while standalone months must be
in a nominative case.

* strptime(): just accepts the new format specifiers: %OB, %Ob,
and %Oh; each of them recognizes any form of the month name.

* nl_langinfo() family (including nl_langinfo_l()): there are new
constants supported: ALTMON_1, ALTMON_2, … ALTMON_12, and also (kinda
undocumented): _NL_WALTMON_1, _NL_WALTMON_2, …, _NL_WALTMON_12;
_NL_ABALTMON_1, _NL_ABALTMON_2, …, _NL_ABALTMON_12; _NL_WABALTMON_1,
_NL_WABALTMON_2, …, _NL_WABALTMON_12. These new constants generate
the same month names as strftime() with %OB, %Ob, and %Oh format
specifiers (month names standalone, which means a nominative case
in some languages). The old constants MON_1, MON_2, …, MON_12,
ABMON_1, ABMON_2, …, ABMON_12 generate the same month names
as strftime() with %B, %b, and %h format specifiers--nothing new,
it has been the same since forever. But from now these constants
will generate the month names in a form used when the month name
is a part of a complete date. That means they are unsuitable to
generate the list of months standalone.

What needs to be changed:

* In Fedora: literally, nothing. The changes belong to upstreams
and I'm writing here in hope that some upstream developers are here
as well or you can forward the message to them. But of course
upstream software eventually lands in Fedora (as well as in other
distros). You may add "Requires: glibc >= 2.27" to the packages
which rely on this new feature, that means if their upstreams required
any changes in nl_langinfo() or strftime() calls.

* Translators: if you want this feature to be supported in your
language please notify me ASAP. There will be no change in the
languages for which the locale data in glibc are not changed.
So far only Polish language has been updated. Here is the list of
languages which probably need the update (the list may be incomplete):
Armenian, Asturian, Belarusian, Catalan, Croatian, Farsi, Greek,
Kashubian, Lithuanian, Ossetian, Russian, Scottish Gaelic,
Silesian, Sorbian (Upper and Lower), Ukrainian, Walloon.
These languages probably do not need the change but should put
their attention: Bosnian, Czech, Finnish, Serbian, Slovak.

* Applications using nl_langinfo() to display months: well, you
shouldn't use this function. This is a low-level function useful
to implement strftime(). But if you really want to you can but
you should stop using MON_* (and ABMON_*) and switch to ALTMON_*
(and _NL_ABALTMON_*) instead. You should detect whether it is
supported at compile time or at runtime. Well, it's tricky,
isn't it? Therefore it's better to use strftime().

* Applications using strftime() to format dates: if you display
a full date, including both the day number and the month name,
that is when the format specifier is "%d %b %Y" or "%B %e %Y"
or anything looking like that--no change is required. The only
case is when you display the month name standalone, whether it's
full ("%B") or abbreviated ("%b", "%h"), even when the year
number is included ("%B %Y"). This should be changed to "%OB"
and "%Ob".

* Other libraries than glibc which wrap or reimplement the same API
(like glib2 or gnulib): should enable this or apply the changes
to their implementation. By "enable" I mean "define the new
constants and do not raise an error when you see them or when
you see the %O[Bbh] format specifiers in strftime()".

* Other programming languages: the same as above, that means:
if your language just calls nl_langinfo() and strftime()
then make sure it calls it properly, defines the new constants
and does not raise errors, or if it implements the same feature
then the changes must be applied to your implementation.

* Testers: make sure the dates are displayed correctly, especially
i

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

[Tomasz Kłoczko]

On 22 January 2018 at 20:58, Matthew Miller 
wrote:

> On Mon, Jan 22, 2018 at 08:21:19PM +, Tomasz Kłoczko wrote:
> > Yet anther thought ..
> > As long as between major EL releases is huge "distance" in differences
> > using %{rhel} within %ifings operators like <, <=, >, >= does not make to
> > much sense.
>
> That's likely true. But I think it'd be even better to avoid
> base-os-name conditionals and use something like %{have_soft_deps} or
> something like that.
>

So looks  you understand at least this part.
OK .. good  .. very good ... PERFECT! 🙃

== assumption ==
So now try to assume (temporary only) that it has been already proven that
at least new branches based approach will be not more complicated to
maintain EPEL corrections/adjustments as it is now with %ifings.
==

Got it? ... next ..
So I think that we can expect some god/funny/interesting consequences:

- master and EPEL branches will have ONLY local package %bconds.
- Fedora and EPEL packagers will have 100% freedom of making any necessary
changes without asking themselves "does my Fedora change will affect EPEL
or not?" or "does my EPEL change will affect Fedora or not?" Only this
will/can make whole ecosystem IMO muuuch more robust.
- EPEL maintainers can form separated task-force inside Fedora and even if
they will vote on turn EPEL specs up side down it will not have any Fedora
consequences and vice versa
- EPEL packagers will be making CONCISELY decisions about backporting some
master branch changes and someone will really spend some time with own
computer to test changes
- and last: .. funny but looks like probably we don't need ANY new macros.
Eureka!! 😎

It is yet another interesting consequence which may attract RH developers.
As long as they will be snapshoting Fedora to create new major EL release
thy can use straight Fedora git repo. If they will choose this way it may
be potentially costs savings argument on maintaining necessary
infrastructure.
If they will decide do this Fedora packagers will have straight access to
all RH made changes. All without any kind of formalized communication!!!
I'm not sure is it possible to add git watch alarm on the branch.
If yes it will be devel platform with best possible cohabitation.

IMO whole concept stands firmly on KISS principle or IS with this principle
compliant.

Every above point may have non-zero or at least positive impact .. but
again: ONLY if top assumption is TRUE.

I'm only asking for help to prove or disprove this top assumption.
How to do this? I have no clear idea so far ..

Nevertheless I think that above is/must be truth (basing on my quite long
exp) and I'm fully aware that cannot use this as curricula argument.
Maybe we need a bit more time to have whole subject "hanging on back of our
heads". Maybe it will require few experiments as well.
There are few "maybe" here ..

However what I'm sure is that no one of us should be rushing 😀 "Rush"
usually is very bad advisor.
There are sill many potential mass changes which can make general Fedora
specs condition better.
>From general strategy point of view we (definitely I) can deal with this by
focus on very simple short term targets/mass changes.

Try to think about what I've already told about "undo thousands cuts" ..
all those mass changes should be done with such goal.😋

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: ABI gate: internal-only shared object

[Jerry James]

On Mon, Jan 22, 2018 at 3:49 PM, Rex Dieter  wrote:
> As far as I know and can tell, those gating things are advisory only at this
> point.

I am logged into bodhi.  I am looking at the page for the gap-pkg-io
update I mentioned earlier:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7

There is no button to push to batched.  There are only two buttons:
Edit and Unpush.  On the right hand side, I see:

Test Gating Status
Tests Failed
1 of 2 required tests failed

The "1 of 2 required tests failed" text is linked to a page that has
this text at the top:

Automated Test Results
The update can not be pushed: 1 of 2 required tests failed


If the gate is supposed to be advisory only at this time, then where
is the button to push to batched?  I do not see it anywhere.
-- 
Jerry James
http://www.jamezone.org/
___
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:42, Stephen John Smoogen  wrote:
> 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.
>

I am apologizing to the readers of the list and to Les. My comments
were not helpful and were rather hurtful in several parts. I was wrong
to have compared the post to a drunk with a broken bottle.



-- 
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

[Howard Howell]

On Mon, 2018-01-22 at 18:57 -0500, Stephen John Smoogen wrote:
> On 21 January 2018 at 14:42, Stephen John Smoogen 
> wrote:
> > 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 users@lists.fedoraproject
> > > > .org.
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-leave@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.
> > 
> 
> I am apologizing to the readers of the list and to Les. My comments
> were not helpful and were rather hurtful in several parts. I was
> wrong
> to have compared the post to a drunk with a broken bottle.
> 
> 
> 
No worries, Stephen, 
I have sometimes experienced hoof in mouth disease myself. 
Maybe this is kind of one of those times, for me, too.  I just really
really like Fedora.  I have been with the system for a long time, at
least since 5 or something like that.  I cannot contribute much, but I
do what I can.

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

Re: F28 Self Contained Change: Enabling Python Generators

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> What about BuildRequires? Quite often that list even more work to
ZJ> generate, and your proposal does not address it in any way.

Does any dependency generation we use currently (i.e. Perl or even just
the plain C/C++ stuff) do anything for build dependencies?  I'm pretty
sure they don't.

I don't see why any proposal for automating runtime dependencies would
need to address that.  Especially given that for Python you generally
don't need much more than setuptools to install a module unless it has a
test suite, unlike, say, C or C++ where you need -devel packages.

 - J<
___
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)

[Jason L Tibbitts III]

> "VO" == Vít Ondruch  writes:

VO> I think FPC does not know.

Certainly we know what we generally try to do, but Fedora changes
quickly and some things aren't always stated as well as they could be.
Plus the experts who draft the more esoteric guidelines often have other
ideas.

The guidelines cover everything from the oldest supported release to
rawhide.  Where they don't we try to indicate that.  When sections get
outdated, I will generally remove them (and shift them to the EPEL packaging
page) but sometimes I miss something.

VO> Let me quote from Ruby guidelines update [1] which initially aimed
VO> on Rawhide, now it covers all supported Fedoras,

I personally wasn't aware that it does.  To be completely honest you
were pretty argumentative about the whole issue and I personally decided
to concentrate on other things and haven't gotten back to looking at it.

VO> ... Actually I'm not sure why, may be because of EPEL
VO> (in)compatibility?

The guidelines generally aren't concerned about EPEL compatibility.  I
mean, when it's possible and someone proposes a reasonable solution
which lets things remain compatible, I think we're all happy to consider
it but the guidelines are about the current two or three Fedora releases
plus rawhide.

But to the question at hand, it's often simply not possible to have a
"clean" spec and keep backwards compatibility all the way to EPEL.  I
find it surprising how much confusing conditional macro stuff people are
willing to deal with just to avoid having a couple of different spec
files.  To me the maintenance overhead of that stuff is far greater than
the work required to just maintain the specs separately, but I guess
others feel differently.

Even if we somehow officially discouraged some of the more hideous stuff
people do in pursuit of the "everything spec", I just can't see it being
banned because people like it too much.

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

Re: ABI gate: internal-only shared object

[Scott Talbert]

> On Mon, Jan 22, 2018 at 3:49 PM, Rex Dieter  
> I am logged into bodhi.  I am looking at the page for the gap-pkg-io
> update I mentioned earlier:
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7
> 
> There is no button to push to batched.  There are only two buttons:
> Edit and Unpush.  On the right hand side, I see:
> 
> Test Gating Status
> Tests Failed
> 1 of 2 required tests failed
> 
> The "1 of 2 required tests failed" text is linked to a page that has
> this text at the top:
> 
> Automated Test Results
> The update can not be pushed: 1 of 2 required tests failed
> 
> 
> If the gate is supposed to be advisory only at this time, then where
> is the button to push to batched?  I do not see it anywhere.

Yep, bodhi is definitely blocking things now without any way to override that I 
can see.  :-(
I've got a similar situation, I was able to push to batched 5 days ago but just 
now bodhi sent me an email saying "Bodhi is unable to request this update for 
stabilization: This update has not yet met the minimum testing requirements 
defined in the Package Update Acceptance Criteria."

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

Re: ABI gate: internal-only shared object

[Orcan Ogetbil]

On 22 January 2018 at 22:12, Scott Talbert  wrote:
> Yep, bodhi is definitely blocking things now without any way to override that 
> I can see.  :-(
> I've got a similar situation, I was able to push to batched 5 days ago but 
> just now bodhi sent me an email saying "Bodhi is unable to request this 
> update for stabilization: This update has not yet met the minimum testing 
> requirements defined in the Package Update Acceptance Criteria."

Interesting. In my case it doesn't allow me pushing with:
"The update can not be pushed: 1 of 2 required tests not found"
Unfortunately it doesn't tell me what is required, what is not found.

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

Re: F28 Self Contained Change: Enabling Python Generators

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-22 at 21:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 22, 2018 at 08:51:43PM +0100, Jan Kurik wrote:
> > = Proposed Self Contained Change: Enabling Python Generators =
> > https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators
> 
> It's great that this is finally happening.
> 
> > == Detailed Description ==
> > There is RPM dependency generator which is able to automatically add
> > Requires/Provides and other types of dependencies based on egg/wheel
> > metadata. The part which is generating Provides has been used in
> > Fedora since Jun 2016 which means by now all packages which provide
> > egg/wheel metadata have Provides: pythonX.Ydist(xyz) added
> > automatically. With this change proposal we allow people to opt-in for
> > using automatic generation of Requires.
> 
> What about BuildRequires? Quite often that list even more work
> to generate, and your proposal does not address it in any way.
> Do you foresee a separate generator that would be run manually
> or some other solution?

Right now, RPM doesn't support generation of BuildRequires. I've fileld ticket
about this long time ago[0]. I really hope this could be done somewhere in 4.15
timeline. But then it will take another decade to get it supported in Fedora ☹


[0] https://github.com/rpm-software-management/rpm/issues/104
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpm1ysACgkQaVcUvRu8
X0wDeA/+LBGEZIPMMq5YS6xCzkJ3/5Po//8GsL3oInpITd1PWkOhpdMAZtXr07Kw
++7bAsHxeZPYbAIRl7q2S120dDKMqKRjbn/zq/8dT33KTXrlTl/cmWSkFaZI1/RV
Xib8trQSU2HPMSGS49mgW5pv1iAoIr3Ezg0MKObRlX8Ggp0Zx1vewXKiOuy8F3t6
qTriRqvDB7YDyfVMctvlT7I6ItlqM8y3ymFvsKSkjreWEC18+aq4HktiMMbU0CVr
xCK/0QnTbzh1dBG716SbBOFNt29XuNLN6fln6OCN40a+ic8pU2s/DtmASttguZ5l
aIFpLZS350FaQNtvExKdKp4iYMdT9LLzK7uKh76MjmPfqK0F8IrUF6vtsH4Syjoq
nNS52rWbwAOYKx6IEPdt0Mw/R5eWGRwBXTKgGPRxRmm52/itvwXp9P+upf95SEtO
fBGpD4T37S6m2jQ0jh+kapFzMBhuwm3gHPSJfG4EdELB6d3LNHoNFOy+CJxQIhZG
u3UJpVVJmp+SeX8W3u9jwemmiMeA7XxcI8AjzWumIFPRFfY3GYqTj60T5207XtGf
aNjhYDZ3FiT57W7kAjqV4xBc6o8RmyoWy6qKbSBTvTLcRIWe9o6LUJTM9S1NbAQS
rfLCYD6NfPtkVL15c41bxrN3hhxtkx95kDlJw72caRGnj8d2Dyw=
=3M63
-END PGP SIGNATURE-
___
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)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-22 at 14:33 -0500, Matthew Miller wrote:
> On Sat, Jan 20, 2018 at 02:23:16PM +0100, Igor Gnatenko wrote:
> > What I'm trying to say here is that each time we want to implement
> > some feature in Fedora, we either need to have some replacement in
> > EPEL or diverge Fedora branches from EPEL branches. Having
> > replacement is not always possible, especially if we start utilizing
> > new (actually 8 years old) features of RPM.
> 
> I'd really like to see us tend towards coming up with macros that
> provide elegant fallbacks on EPEL. (The %license macro is a good
> example.)

There is no fallback for rich dependencies. There is no fallback for
filetriggers.

> I get the frustration with older stuff holding us back, but we really
> have a _lot_ of users who get value from doing so.
> https://twitter.com/mattdm/status/936243506355621888

I'm definitely not against supporting EPEL, but right now it is hurting me that
much that I don't do that.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpm19gACgkQaVcUvRu8
X0wXzg//ZJsgRXLmkEaSyLpVqpEWq0cZ676rjN6TVkwzQEeCVjVDjnlbPZ33A0Sc
R+rFOUIymJ7dDz/jToTvMBuHBzsAHn594a+9UBs36TqAV71OruxCAM1n8N1cAkWW
h9s0cHF0JdBJiukDBhs96vXS8Dnvv7FRlFHMvl/rfhxAIGSn8M+cxk4M+ils59EL
nwKqrO08SQdnU93jHU86LCG9vSQlR0k2c2KsCUtVNjhkdv2RAj02Na6idxvn7OzD
4OqE6WkX8npUC+5vcdid3bfzAyxRCbxUPZ5+HctHCXVkRCd/o/3rVPr7ei+BAYkw
VV8MBn56OTYckHm0Bhd6eZjqA1SqhVHnGulH5NzHiHiXhCWOdbDJUjNTqPkQWfYQ
A6YqL7N/gB6rOkylm4sq/sbkQXvbXdnr1s0mgrWvCLmE+DA7NGYTbm5mZye5/LZL
E3tZeev4YIxOnuqK1w/D54j0Y+N0oj4bSG4LQHtqW3FAOrsbg7dOIT0YKAs6KGfu
VuYzVMqkACW9iKVScfsQzNMagND0VoLNrNymf5uI8PwXLNPeRsqZfOhu5tNFLvA8
5yQ1+qunHF4990/licBTiFeBtNRSQ9oWKHmn30+7IlTe43OvEbatwyzj4UaZ3Wtt
eH395saHfPiJVO+8G4smSZ5MZVl9LhAa+sg7dY7d9fxSFtBr1XU=
=TP1T
-END PGP SIGNATURE-
___
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)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-22 at 15:58 -0500, Matthew Miller wrote:
> On Mon, Jan 22, 2018 at 08:21:19PM +, Tomasz Kłoczko wrote:
> > Yet anther thought ..
> > As long as between major EL releases is huge "distance" in differences
> > using %{rhel} within %ifings operators like <, <=, >, >= does not make to
> > much sense.
> 
> That's likely true. But I think it'd be even better to avoid
> base-os-name conditionals and use something like %{have_soft_deps} or
> something like that.

But how does this help? Without certain features, you simply can't build
package (in my case, I can't build any rust packages on EL7).
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpm2DQACgkQaVcUvRu8
X0yGTw//cKr/TRSk7JbCTaGS+eONPVWT1ssRltNMw8a8+KiAinXcSpgyEzSJ5RtP
lppwRGbWoUF3/VoLTMtdP2JMrzvDCcWyi52o5iORNaeMOCmB5TU6uub1PtrECdwv
oxwCb0YbMwAtTmRw/3o8p01zCMZqa4g8Tlw6nkv5ibTztePMoPKa0TBRUYR4x/Pk
z7Erb6dy9YVFUz83tB3gzQm0Vv1ezKlJewYXvkhTSQf2fIvtHPVOu37BL3/95AEf
szdWX5b30bAbGGXeF7G/OtXGErYLwvsPjXDuo9OPEiRMPLok83abaGt92SdIUJgq
x8SnjU7jg2USB5um1dBh6acI66qPMjK5/Tw5ZC/jJeNnoTVfcf+t4jjjwRsFxXa7
BJkoPpxsmuAtP2I7mKnOwR70Hd0dgQypU/+fPkqgs87pstxFhQ4FL4mozt/k7z3s
IbXjPaPWVXr1oJgKTIrBkp4/HAuiTrC07/0ZVn828hQjJ55fJeTUM38yKFwIWkYf
940PpkTxLK23J4hKEqjIqXag5UyMLj4/rpxZCr9WjSfMW9Lr1oBdhrfFinZxfl/d
csiez6xpilXiI93b73Z3uuna+/wKxWumMUddRlYuGCVgYu6g2DxVRlY5HeHVXIgK
ZuKwQtbPeGCWLp+XelatACh4uFsgAH4B+HG99YxMpvIUjJYR0oo=
=QTYR
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Florian Weimer]

On 01/22/2018 10:15 PM, Adam Jackson wrote:

On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote:

On 01/22/2018 06:26 PM, Adam Jackson wrote:


I'm trying to prepare xserver for this change, and it seems to provoke
an awkward warning when building on F27:

In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
   extern int bindresvport(int, struct sockaddr_in *);
  ^~~~
In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
   from ../os/rpcauth.c:47:
/usr/include/netinet/in.h:502:12: note: previous declaration of ‘bindresvport’ 
was here
   extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) 
__THROW;
  ^~~~

Is there any reasonable fix for this?


Redeclarations in system headers are expected.  Do you compile with
-Wsystem-headers?  Or do you something else which is unusual, such as
running the preprocessor separately?


Not that I'm aware of. The generated cc line is:

ninja: Entering directory `build'
[1/17] ccache cc  -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes


ccache runs the preprocessor separately. 8-)


Is -Wredundant-decls just not a thing one should try to use?


Certainly with ccache, yes.

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

Re: F28 Self Contained Change: Enabling Python Generators

[Mikolaj Izdebski]

On 01/23/2018 02:16 AM, Jason L Tibbitts III wrote:
>> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> What about BuildRequires? Quite often that list even more work to
> ZJ> generate, and your proposal does not address it in any way.
> 
> Does any dependency generation we use currently (i.e. Perl or even just
> the plain C/C++ stuff) do anything for build dependencies?  I'm pretty
> sure they don't.

Java dependency generator [1] does generate build-requires during build.
(Yes, this means that you need to run a successful build to get them
generated, but thanks to mock pm_request plugin [2] you can run initial
local build without specifying BuildRequires.)

[1] https://github.com/fedora-java/javapackages
[2] https://fedoraproject.org/wiki/Projects/Mock/Plugin/PMRequest

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Binutils version 2.29.1

[Tom Hughes]

On 17/01/18 11:35, Florian Weimer wrote:

On 01/09/2018 04:16 PM, Tomasz Torcz 👁️ wrote:

   I'm a bit perplexed by this change.  It looks like minor version
  update, in such case it need no to be announced so widely.
   On the other hand, you are changing the source.  According to the
  guidelines, changing source requires re-review.
   So why this is a system-wide change?


We've since realized that we should build software with -z defs to 
enable proper symbol versioning (you can't version undefined symbols), 
so that might be a justification for a system-wide change.


(rawhide binutils supports -z undefs to undo the effect.)


This seems to be breaking things. I have so's failing to link due to 
this even though the man page says -zdefs doesn't affect shared libraries.


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: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Jakub Jelinek]

On Tue, Jan 23, 2018 at 08:00:08AM +0100, Florian Weimer wrote:
> On 01/22/2018 10:15 PM, Adam Jackson wrote:
> > On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote:
> > > On 01/22/2018 06:26 PM, Adam Jackson wrote:
> > > > 
> > > > I'm trying to prepare xserver for this change, and it seems to provoke
> > > > an awkward warning when building on F27:
> > > > 
> > > > In file included from ../os/rpcauth.c:47:0:
> > > > /usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
> > > > ‘bindresvport’ [-Wredundant-decls]
> > > >extern int bindresvport(int, struct sockaddr_in *);
> > > >   ^~~~
> > > > In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
> > > >from ../os/rpcauth.c:47:
> > > > /usr/include/netinet/in.h:502:12: note: previous declaration of 
> > > > ‘bindresvport’ was here
> > > >extern int bindresvport (int __sockfd, struct sockaddr_in 
> > > > *__sock_in) __THROW;
> > > >   ^~~~
> > > > 
> > > > Is there any reasonable fix for this?
> > > 
> > > Redeclarations in system headers are expected.  Do you compile with
> > > -Wsystem-headers?  Or do you something else which is unusual, such as
> > > running the preprocessor separately?
> > 
> > Not that I'm aware of. The generated cc line is:
> > 
> > ninja: Entering directory `build'
> > [1/17] ccache cc  -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes
> 
> ccache runs the preprocessor separately. 8-)
> 
> > Is -Wredundant-decls just not a thing one should try to use?
> 
> Certainly with ccache, yes.

The command uses -I /usr/include/tirpc/ rather than -isystem /usr/include/tirpc,
so while /usr/include/netinet/in.h is treated like a system header,
/usr/include/tirpc/rpc/rpc.h is not.

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

Re: F28 System Wide Change: Binutils version 2.29.1

[Florian Weimer]

On 01/23/2018 08:16 AM, Tom Hughes wrote:
This seems to be breaking things. I have so's failing to link due to 
this even though the man page says -zdefs doesn't affect shared libraries.


Examples?

It will cause link failures because binutils now reports that it does 
not have enough information to produce correct binaries.


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