[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-03-26 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2019-03-26 - 87% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/03/26/report-389-ds-base-1.4.1.1-20190326git395a4a2.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 25. 03. 19 18:56, Kevin Fenzi wrote:

Just make python36 obsolete the old version of python34 that had
/usr/bin/python3. This causes yum to install the new python34 and pull
in python36 for /usr/bin/python3.


If that works, we are good. Does it really behave like that with plain upgrade? 
E.g. without specifying what to upgrade?


I thought that obsoleting old py34 can do one of the following:

A) python34 gets queued for upgrading first, there is no more old python34 to be 
obsoleted by python36, python36 isn't installed.


B) python36 gets queued for obsoleting old python34 first, python34 gets queued 
for removing instead of updating, there is more pytho34 to be updated.


C) what you said.

If C) is the guaranteed behavior, I guess we are good to do this.


It does mean people with 3rd party software are now using python36
instead of 34, but if they only speficied /usr/bin/python3, it should
just run with any python3 version right?


As long as they are only using standard library, yes. Otherwise there might be 
problems. However that was anticipated.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1692229] perl-ExtUtils-CppGuess-0.14 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-ExtUtils-CppGuess-0.13 |perl-ExtUtils-CppGuess-0.14
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.14
Current version/release in rawhide: 0.12-6.fc30
URL: http://search.cpan.org/dist/ExtUtils-CppGuess/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2864/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

On Mon, 25 Mar 2019 at 21:57, Japheth Cleaver 
wrote:
[..]

> It feels like there's been this vast movement to try to remove every last
> bit of shell from Fedora whenever possible, and I really don't understand
> the aversion.
>

In most of the cases it is nothing more than some form of NIH syndrome (
https://en.wikipedia.org/wiki/Not_invented_here)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

On Mon, 25 Mar 2019 at 21:17, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Mar 25, 2019 at 08:18:34PM +, Tomasz Kłoczko wrote:
> > Switching to other than bash sh interpreter allow reduce total gcc
> package
> > build time by ~5%.
>
> OK. But that just shows that it is — possibly — worth to switch the gcc
> build
> to a different shell, by working with gcc upstream. Nothing should be
> extrapolated from this to other packages and in particular to their
> spec files.
>

Zbyszek .. please .. you are wrong about that I'm using here extrapolation.
I've posted only small fragment of what kind of data I'm collecting in my
infrastructure.

gcc has own set of issues which I've exposed here partially in last 2-3
weeks.
All those issues are way more important than what is used as /bin/sh.
Really.

Speaking about gcc build improvements. Just one number:

[tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac | wc -l
42

Funny. Looks like current Fedora gcc poses "The answer to the ultimate
question of life, the universe and everything" 

What does this 42 means in this case? It means that during whole gcc build
are repeated 42 times some subset of *autoconf tests*. How it was possible
to loose that?!? 樂
gcc is quite monolithic and it should have only one configure.ac. Yes,
am/ac can handle multiple gettext domains in single build tree so even this
is not the obstacle. How to do this? Just peak on gimp, gtk3 and many other
(however those two are kind of out of book examples).
IMO by such transition to single ac it should be possible to shorten gcc
build time (guessing a bit) by another 10% (optimistically).
However IMO it would be better move gcc build framework to meson (because
as I wrote few days ago ac/am/lt is effectively dead by now by how it is
maintained by GNU people and moving those tools maintenance outside GNU
project domain will be not easy task).
Just in case: cmake as ac/am/lt replacement is not IMO good because it is
yet another project in which coding process maintainers are trying to solve
famine problems on Earth.
cmake is written in C++ and additionally its C++ code uses exceptions and
RTT (only this says that says something .. not so good).
Speaking about cmake. Recently trying to fix some cmake issues I found that
cmake build using boostrap and cmake themselves does not produce the same
results because looks like cmake developers are not using cmake to develop
cmake which is really hilarious

Moving to meson (with all necessary tests in one place fired one time only)
probably should shorten gcc build time by another few percents (maybe even
more). I'm almost sure that with not so big effort in 2-3 man/weeks it
would be possible to reduce gcc build time by at least 1/3 (totally).
Is it worth to divert some people resources to do that? IMO definitely yes
as sooner or later gcc build should allow speedup whole gcc development
process (during last New Year I've started gcc build on my old laptop and
it took on it almost 25h).
However I'm fully aware that on top of moving to meson it will be another
chunk of man/hours resources and this could be painful for Jakub as it will
be necessary to sort out all those SIGSEGVs in gcc test suite and stop
doing his gcc magic
(Jakub don't take this personally please .. I'm really joking)

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 2:10 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Mar 25, 2019 at 08:18:34PM +, Tomasz Kłoczko wrote:

Switching to other than bash sh interpreter allow reduce total gcc package
build time by ~5%.

OK. But that just shows that it is — possibly — worth to switch the gcc build
to a different shell, by working with gcc upstream. Nothing should be
extrapolated from this to other packages and in particular to their
spec files.


But why not? It's obvious that anything with a lot of forking and 
subshelling in it will be improved. Back when ash was part of the 
distribution I regularly got 30-35% concurrency improvements on 
resource-strained machines when my service had an unavoidable fork or 
three in it. (Looking at you, qmail.) I mean, nothing about 
https://wiki.ubuntu.com/DashAsBinSh has actually /changed/ in all these 
years, really.


It feels like there's been this vast movement to try to remove every 
last bit of shell from Fedora whenever possible, and I really don't 
understand the aversion. True, sometimes the the best answer to a 
dilemma about how to improve XYZ is "mu - let's remove XYZ", but a 
slavish devotion to that has some significant drawbacks. (It was 
mentioned above that Fedora found a much better way to deal with boot 
times, and I'd have to disagree. If you can take a one-time hit to 
remove bashisms and get a 25-40% improvement, that seems a far better 
deal than the years of misery and Linux civil wars the alternative 
precipitated.)


Transactions are nice, but they're not everywhere, and won't solve every 
issue a .spec might have. And that's certainly not necessarily the case 
for non-Fedora code. Given that shell won't ever really completely go 
away, there's nothing wrong with evaluating ways to increase 
compatibility, quality, and efficiency in our execution choices.


Part of that begins with ensuring mechanisms are in there for local SAs 
to hook useful decisions into. And making this more explicit allows both 
the RPM format and Fedora's relation to it to be better defined.


-jc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2019 at 08:18:34PM +, Tomasz Kłoczko wrote:
> Switching to other than bash sh interpreter allow reduce total gcc package
> build time by ~5%.

OK. But that just shows that it is — possibly — worth to switch the gcc build
to a different shell, by working with gcc upstream. Nothing should be
extrapolated from this to other packages and in particular to their
spec files.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

On Mon, 25 Mar 2019 at 20:47, Stephen John Smoogen  wrote:
[..]

> [Also when giving one graph for one type of build, could you also give a
> similar graph showing how it looks with dash or ksh or whatever you used?]
>

Graph for the gcc will be exactly the same. Only overall time will be
shorter.
ksh93 is not the good replacement candidate. I've tested it with gcc and
using it causes that whole build freezes at some point. I've started my
testy from ksh and this is why I've took next on the alphabetic list which
was mksh.
Maybe it is only some issue with Fedora version and latest ksh93 is fixed
.. really I don't care about that as better POSIX sh alternatives are
around.

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692558] New: perl-libwww-perl-6.38 is available

[bugzilla]

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

Bug ID: 1692558
   Summary: perl-libwww-perl-6.38 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-libwww-perl
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.38
Current version/release in rawhide: 6.37-1.fc31
URL: http://search.cpan.org/dist/libwww-perl/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3024/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Jason L Tibbitts III]

> "JC" == Jeremy Cline  writes:

JC> The effort would be a 1-2 line change in the-new-hotness, and
JC> distributing the config to each package repository (some proven
JC> packager could do this easily).

Well that seems easy enough.  We still need the repo for the bugzilla
assignee override thing, but that's fine.  One thing at a time.

I can certainly drop commits into the repositories if that's what's
needed.  We would need to define the name and contents of the file, and
the default state for when the file is not present (to perhaps avoid
touching every repository).

It might also be nice to know what on earth monitoring means for a
module or a container, since the fedora-scm-requests has data for them
but I don't understand what point it has.

We would also need to change the admin tool which is generating these
files.  I think it would speed up its operation a good bit to not have
to mess with this ever-growing repository, so that is a positive.
(Especially since the tool does no local caching and so does a full
clone each time it processes an SCM request).  And fedpkg request-repo
would need to drop the --monitor option as it would have no effect.

So I guess it's more than just a couple of lines that need to change,
but everything outside of the initial new-hotness change and the
monitoring file commits could come later.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1691101] perl-Config-Grammar-1.13 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Config-Grammar-1.13-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-96808ad205

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1691101] perl-Config-Grammar-1.13 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Config-Grammar-1.13-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1b70f58119

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1691101] perl-Config-Grammar-1.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-Config-Grammar-1.13-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-21e90a106c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 16:20, Tomasz Kłoczko 
wrote:

> [.all the comments.]
>
> All replies are between "who cares?", "it is holy war/waste of time" to
> something like "be standards compliant is important" .. this thread is
> hilarious 
> I'm observing all the comments under my post and (with full respect to all
> of you guys) looks like all of you guys are *wrong* why sticking to POSIX
> sh is important 
>
> *Literally all of you lost one very important fact that bash is not
> fastest sh interpreter which is possible to use and only kind of
> coincidence is that all those fastest are almost puritanically POSIX sh
> compliant!!! *
>
>
For future threads, could you actually put this information in your first
post? You did not put in enough info and so everyone is going to bring up a
dozen different reasons for what you are aiming at. I am saying this
because this information would have made it clearer where you wanted it and
why you wanted it... which I think are:

1. Performance. Groups which do regular mass rebuilds of software find the
CPU usage of bash during builds to be making things slower. While 5% over
one build is not a lot, over 10,000 builds or similar it does. [You are the
3rd person or group I have run into the last month which are doing regular
mass rebuilds of parts of Fedora for their customers or own needs.]
2. Security. Why is bash using an old copy of readline and how does it keep
up with CVE's that affect it
3. Spec file conformity. If bash needs to use its readline, then it should
1) list it as bundled and 2) please have some note for the various groups
who have to do these rebuilds and audits to know why.

Does that cover the points you would like to be covered?

[Also when giving one graph for one type of build, could you also give a
similar graph showing how it looks with dash or ksh or whatever you used?]


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Jeremy Cline]

On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:

"KF" == Kevin Fenzi  writes:


KF> Well, I find it unfortunate, does that count? :)

It is unfortunate, but note that it's unfortunate simply because of our
procedures.  Certainly it would be nice if the functionality for making
new branches and changing monitoring and some bugzilla settings were
integrated directly into src.fp.o; I won't argue against that.  However,
that doesn't mean that changing those settings couldn't be accomplished
via some means other than a PR.

Possibilities I can think of include:

* Doing this via tickets in a manner similar to how branches are
   requested.  This would require teaching the ticket processing tools
   how to perform the operation, and writing some tool to submit the
   request.  Kind of a lot of overhead for a rare operation.

* Just storing this information in the package repository.  I've never
   understood why the system can't just extract this information from
   git.  I suspect there must be some reason related to security or
   resources consumption which prevents services from having a shallow
   git clone around from which to grab information like this, but I'm not
   sure.



This is how it _should_ work. I just looked at the actual implementation
and hotness is doing an HTTP GET to the scm-requests repository. It
makes no sense, each repo should have a "monitoring" file or something.
From the perspective of hotness, nothing changes. I have no idea why it
was put in a central repository.


* Letting people just file a ticket and ask for what they want and
   having the admins would take care of it by editing the repo.  This
   would require a separate ticket instance or more programming because
   the tools currently auto-close any ticket they don't understand.

Anyway, everything is just a simple matter of programming.  Does the
effort required outweigh the annoyance of users having to occasionally
(rarely) submit PRs against a repo that's of nontrivial size?  I don't
know.  Are there any other benefits besides making things a little
easier?  Would having this somehow increase the uptake of monitoring?


The effort would be a 1-2 line change in the-new-hotness, and
distributing the config to each package repository (some proven packager
could do this easily). Given how awful the current approach is from a
user perspective, I think this is worth doing. I've Cc'd the hotness
maintainer.

- Jeremy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

[.all the comments.]

All replies are between "who cares?", "it is holy war/waste of time" to
something like "be standards compliant is important" .. this thread is
hilarious 
I'm observing all the comments under my post and (with full respect to all
of you guys) looks like all of you guys are *wrong* why sticking to POSIX
sh is important 

*Literally all of you lost one very important fact that bash is not fastest
sh interpreter which is possible to use and only kind of coincidence is
that all those fastest are almost puritanically POSIX sh compliant!!! *

OK, so about what kind of performance difference in context of exact
numbers we are talking about?
I've tested building gcc using mksh as /bin/sh.
Only one detail: on doing that test you will find small obstacle that you
will be not able to measure whole build time because in the %install of the
gcc.spec is used pushd/popd.
*Warning*: on looking on whole gcc %install *please* remember wearing
welder mask because without it may hurt your brain (Yes, it is yet another
my small pebble with name "badly maintained" thrown in direction of the gcc
because it forces to do so many things outside pure "make install").

Checked my zabbix and here is the graph with CPU usage made during building
gcc on 24 core box (48 CPUs with MT) when bash is used as /bin/sh:
[image: image.png]
As you can see on the graph ~+60% of whole gcc build time hangs on single
thread/core serialised processes. Quite significant part of that time is
spend in *running sh scripts*. Only in second half of the build is possible
fully saturate potential of that particular HW (on running test suite).
Switching to other than bash sh interpreter allow reduce total gcc package
build time by ~5%.
On my 24 physical CPU core HW it is about 10 minutes.

Guys just try to have look around and try to estimate how many Fedora
packages are using autoconf/libtool and other POSIX sh based build
frameworks or using /bin/sh.
As all those frameworks are using sh mostly they are running without
parallelism how fast is /bin/sh is crucial.

No .. be POSIX sh compliant it is not about any kind of holly war!!! It is
pure about performance and for people like me quite often *time spend
waiting until package X build will be finished*. Some people cursing that
waiting and calling it "PCtology" (waiting on the front of the PC until
something will be finished).

BTW readline and bash: is there any particular reason why Fedora bash still
is statically linked with readline generated out of the  own copy of
readline code? That not changed from more than decade (if not +13y) so it
must be some reason 樂
IIRC readline is relatively high on the list of most frequently affected
packages by various CVEs so in case of any new issue with readline someone
must remember about that because ..

[tkloczko@domek SPECS.fedora]$ grep bundled bash.spec
[tkloczko@domek SPECS.fedora]$

Someone must remember about that (somehow) because bash is used as /bin/sh
which and is used almost everywhere(tm),  and by this attacking bash still
is quite popular vector of many security related attacks.
Simpler /bin/sh -> lower probability of many security related issues from
that angle.

Do you see now the subject in proper light?

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2

== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.

== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjo...@redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmart...@redhat.com

== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.

The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
grub2-mkconfig.

For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.

== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.

== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.

== How To Test ==
For "verify":

1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition

2. Add "trust " (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom

3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
/tmp/pass

5. Reboot. If system starts, change is successful


For cryptography modules:

1. Backup boot partition

2. Run cryptsetup luksFormat  --type luks1

3. Open luks container and restore backup

4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub

5. Confirm that /etc/fstab has the correct UUID for /boot

6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful

(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)

== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
partition.

== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Revert the
shipped configuration
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No

== Documentation ==
https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-signatures.html

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)

== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2

== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.

== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjo...@redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmart...@redhat.com

== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.

The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
grub2-mkconfig.

For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.

== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.

== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.

== How To Test ==
For "verify":

1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition

2. Add "trust " (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom

3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
/tmp/pass

5. Reboot. If system starts, change is successful


For cryptography modules:

1. Backup boot partition

2. Run cryptsetup luksFormat  --type luks1

3. Open luks container and restore backup

4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub

5. Confirm that /etc/fstab has the correct UUID for /boot

6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful

(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)

== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
partition.

== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Revert the
shipped configuration
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No

== Documentation ==
https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-signatures.html

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)

== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Fabio Valentini]

On Mon, Mar 25, 2019 at 8:56 PM Richard Shaw  wrote:
>
> Other than having it as a direct option in src.fp.org I think being part of a 
> special file in git would be next best.

Accessing such a simple file (probably YAML? it seems to be en vogue
right now ...) should be straightforward too, since pagure can serve
raw files from git over plain http, with links like this:
https://src.fedoraproject.org/rpms/rpm/raw/master/f/rpm.spec

Fabio

> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Richard Shaw]

On Mon, Mar 25, 2019 at 12:27 PM Kevin Fenzi  wrote:

>
> Can you file an issue or PR?
> https://github.com/fedora-infra/the-new-hotness/issues


Filed an issue but there were quite a few some going back to 2015... Is it
being actively maintained?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Richard Shaw]

Other than having it as a direct option in src.fp.org I think being part of
a special file in git would be next best.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692521] New: perl-HTML-Form-6.04 is available

[bugzilla]

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

Bug ID: 1692521
   Summary: perl-HTML-Form-6.04 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTML-Form
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.04
Current version/release in rawhide: 6.03-20.fc30
URL: http://search.cpan.org/dist/HTML-Form/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/14114/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

KF> Well, I find it unfortunate, does that count? :)

It is unfortunate, but note that it's unfortunate simply because of our
procedures.  Certainly it would be nice if the functionality for making
new branches and changing monitoring and some bugzilla settings were
integrated directly into src.fp.o; I won't argue against that.  However,
that doesn't mean that changing those settings couldn't be accomplished
via some means other than a PR.

Possibilities I can think of include:

* Doing this via tickets in a manner similar to how branches are
  requested.  This would require teaching the ticket processing tools
  how to perform the operation, and writing some tool to submit the
  request.  Kind of a lot of overhead for a rare operation.

* Just storing this information in the package repository.  I've never
  understood why the system can't just extract this information from
  git.  I suspect there must be some reason related to security or
  resources consumption which prevents services from having a shallow
  git clone around from which to grab information like this, but I'm not
  sure.

* Letting people just file a ticket and ask for what they want and
  having the admins would take care of it by editing the repo.  This
  would require a separate ticket instance or more programming because
  the tools currently auto-close any ticket they don't understand.

Anyway, everything is just a simple matter of programming.  Does the
effort required outweigh the annoyance of users having to occasionally
(rarely) submit PRs against a repo that's of nontrivial size?  I don't
know.  Are there any other benefits besides making things a little
easier?  Would having this somehow increase the uptake of monitoring?

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bugzilla (?) component for Fedora cloud images

[Florian Weimer]

* Kevin Fenzi:

> On 3/25/19 12:32 AM, Florian Weimer wrote:
>> This bug
>> 
>>   
>> 
>> is actually a documentation/configuration issue in the Fedora Cloud
>> images.  However, I can't find a Bugzilla component for these images or
>> their documentation.  Where should I reassign/report this?
>
> This is done in the fedora-kickstarts files.
>
> https://pagure.io/fedora-kickstarts/
>
> You can move that bug to spins-kickstarts bugzilla component.
> (or better yet, send a PR! :)

Thanks.  Joe Doss suggested to file an issue for the Cloud SIG, which
appears to be more specific, so I did that:

  

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/25/19 10:18 AM, Stephen John Smoogen wrote:
> On Mon, 25 Mar 2019 at 13:07, Miro Hrončok  wrote:
>>
>> On 13. 03. 19 15:30, Stephen John Smoogen wrote:
>>> Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
>>> and several helpers have gotten nearly all of the python34 packages
>>> moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>>> pushes because of a limitation in Bodhi for the text size of packages
>>> in an include.
>>>
>>> The current day for these package groups to move into EPEL regular is
>>> April 2nd. We would like to have all tests we find in the next week or
>>> so also added so that the updates can occur in a large group without
>>> too much breakage.
>>
>> A problem was pointed out in
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comment-914787
>>
>> If you have 3rd party software using /usr/bin/python3 and you have python34
>> installed, updating your system will remove that symlink and your software 
>> breaks.
>>
>> However we cannot obsolete python34 form python36, because that breaks 
>> software
>> that actually wants and uses /usr/bin/python3.4 and possibly make python34
>> uninstallable (not sure).
>>
>> So arguably, the update should update both python34 and install python36,
>> keeping both Pythons available, the user/admin could than remove the one 
>> that is
>> not needed.
>>
>> AFAIK The only thing that would make this happen is to require python36 from
>> python34. And that seems like a huge ugly workaround with unwanted side 
>> affects.
>>
> 
> Here is a hair-brained idea. have them both require
> python3-versioned-command which puts in the alternatives logic and
> sets it to 1 of 3 options?
> 1. python34
> 2. python36
> 3. you didn't install a python silly

I think that could be confusing (not that the alternatives are much
else. ;)

But we talked about this a lot on IRC.

Just make python36 obsolete the old version of python34 that had
/usr/bin/python3. This causes yum to install the new python34 and pull
in python36 for /usr/bin/python3.

It does mean people with 3rd party software are now using python36
instead of 34, but if they only speficied /usr/bin/python3, it should
just run with any python3 version right?

kevin




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Bugzilla (?) component for Fedora cloud images

[Kevin Fenzi]

On 3/25/19 12:32 AM, Florian Weimer wrote:
> This bug
> 
>   
> 
> is actually a documentation/configuration issue in the Fedora Cloud
> images.  However, I can't find a Bugzilla component for these images or
> their documentation.  Where should I reassign/report this?

This is done in the fedora-kickstarts files.

https://pagure.io/fedora-kickstarts/

You can move that bug to spins-kickstarts bugzilla component.
(or better yet, send a PR! :)

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Kevin Fenzi]

On 3/20/19 7:27 AM, Richard Shaw wrote:
> Am I the only person that finds this silly?

Well, I find it unfortunate, does that count? :)

> Infra things aside, is it planned to have this functionality in
> src.fedoraproject.org?

Not that I know of. The problem is that src.fedoraproject.org is a
pagure instance. pagure upstream wants to not carry a bunch of fedora
specific stuff in it if it can avoid it. So, I don't know that anyone
has convinced them to carry something like this.

Another option might be to put it in FPDC, but that is somewhat up in
the air too.

I agree we should "fix" this, but it's unclear what the best fix is.

> On a side note, the messages from the-new-hotness still reference pkgdb...
> Perhaps it should provide a link to:
> 
> https://pagure.io/releng/fedora-scm-requests/blob/master/f/README.md
>
> or
> 
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_change_the_upstream-monitoring.2Fanitya_flag_for_my_packages.3F

Can you file an issue or PR?
https://github.com/fedora-infra/the-new-hotness/issues

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 13:07, Miro Hrončok  wrote:
>
> On 13. 03. 19 15:30, Stephen John Smoogen wrote:
> > Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
> > and several helpers have gotten nearly all of the python34 packages
> > moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
> > pushes because of a limitation in Bodhi for the text size of packages
> > in an include.
> >
> > The current day for these package groups to move into EPEL regular is
> > April 2nd. We would like to have all tests we find in the next week or
> > so also added so that the updates can occur in a large group without
> > too much breakage.
>
> A problem was pointed out in
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comment-914787
>
> If you have 3rd party software using /usr/bin/python3 and you have python34
> installed, updating your system will remove that symlink and your software 
> breaks.
>
> However we cannot obsolete python34 form python36, because that breaks 
> software
> that actually wants and uses /usr/bin/python3.4 and possibly make python34
> uninstallable (not sure).
>
> So arguably, the update should update both python34 and install python36,
> keeping both Pythons available, the user/admin could than remove the one that 
> is
> not needed.
>
> AFAIK The only thing that would make this happen is to require python36 from
> python34. And that seems like a huge ugly workaround with unwanted side 
> affects.
>

Here is a hair-brained idea. have them both require
python3-versioned-command which puts in the alternatives logic and
sets it to 1 of 3 options?
1. python34
2. python36
3. you didn't install a python silly


> Any ideas?
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2019-03-25)

[Justin Forbes]

=
#fedora-meeting-1: FESCO (2019-03-25)
=


Meeting started by zbyszek at 15:00:10 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-25/fesco.2019-03-25-15.00.log.html
.



Meeting summary
---
* init process  (zbyszek, 15:00:13)

* #2105 F31 Change: Mono 5  (zbyszek, 15:01:36)
  * LINK: https://pagure.io/fesco/issue/2105   (zbyszek, 15:01:37)
  * LINK: https://koji.fedoraproject.org/koji/packageinfo?packageID=30
shows no 5.0 builds even in rawhide...  (zbyszek, 15:05:10)
  * LINK: https://pagure.io/fesco/issue/2105#comment-561929
(bowlofeggs, 15:08:46)
  * AGREED: The Change is approved for F31. It is also approved for F30,
as long as the builds can be done and submitted as an update no
later than March 31. If this isn't possible, F30 should keep the
previous version. (+7, 0, 0)  (zbyszek, 15:15:33)

* #2104 Delay retiring of java-packages moved to module until a solution
  for the (Build)Requires has been found  (zbyszek, 15:15:44)
  * LINK: https://pagure.io/fesco/issue/2104   (zbyszek, 15:15:50)
  * LINK: https://pagure.io/fesco/issue/2104#comment-560255   (mhroncok,
15:24:08)
  * AGREED: FESCo asks the Stewardship SIG and other maintainers to take
as many packages as possible. Packages which haven't found new
owners will be retired according to schedule, but not earlier than
April 1st. (+7, 0, 0)  (zbyszek, 15:42:51)

* #2102 F31 System-Wide Change: Gating Rawhide — Single package updates
  (zbyszek, 15:43:03)
  * LINK: https://pagure.io/fesco/issue/2102   (zbyszek, 15:43:09)
  * ACTION: bookwar to write an e-mail to the Stewardship SIG and other
maintainers  (zbyszek, 15:45:35)

* #2027 RFC: Module lifecycles  (zbyszek, 15:47:15)
  * LINK: https://pagure.io/fesco/issue/2027   (zbyszek, 15:47:15)

* #2109 Policy revamp: Package Removal for Long-standing FTBFS and FTI
  bugs  (zbyszek, 15:50:24)
  * LINK: https://pagure.io/fesco/issue/2109   (zbyszek, 15:50:30)
  * ACTION: mhroncok to update the proposal  (zbyszek, 16:00:13)

* #2110 F31 System-Wide Change: Enable Compiler Security hardening flags
  by default in GCC  (zbyszek, 16:00:15)
  * LINK: https://pagure.io/fesco/issue/2110   (zbyszek, 16:00:24)
  * AGREED: : proposal is rejected (0, 0, -7)  (zbyszek, 16:02:27)

* #2108 Change release blocking deliverables process  (zbyszek,
  16:03:10)
  * LINK: https://pagure.io/fesco/issue/2108   (zbyszek, 16:03:10)
  * AGREED: Proposed change to the process is approved (+6, 0, 0)
(zbyszek, 16:06:10)

* Next week's chair  (zbyszek, 16:06:21)
  * ACTION: NAME will chair next meeting  (zbyszek, 16:06:21)
  * ACTION: sgallagh to chair next meeting  (zbyszek, 16:08:35)

* #2027 RFC: Module lifecycles  (zbyszek, 16:09:28)
  * LINK: https://pagure.io/fesco/issue/2027   (zbyszek, 16:09:28)
  * AGREED: The proposal is approved with the additional requirement
that the maintainer can update the information at any time,
automatically, without releng or any other human involvement,
assuming the update is valid based on policy (+6, 0, 0)  (zbyszek,
16:21:18)

* Open floor  (zbyszek, 16:21:44)
  * AGREED: Two-phase approach for #2048 is approved (+5, 0, 0)
(zbyszek, 16:30:25)

Meeting ended at 17:05:59 UTC.




Action Items

* bookwar to write an e-mail to the Stewardship SIG and other
  maintainers
* mhroncok to update the proposal
* NAME will chair next meeting
* sgallagh to chair next meeting




Action Items, by person
---
* bookwar
  * bookwar to write an e-mail to the Stewardship SIG and other
maintainers
* mhroncok
  * mhroncok to update the proposal
* sgallagh
  * sgallagh to chair next meeting
* **UNASSIGNED**
  * NAME will chair next meeting




People Present (lines said)
---
* mhroncok (130)
* zbyszek (117)
* bowlofeggs (86)
* jforbes (54)
* nirik (46)
* bookwar (31)
* contyk (23)
* zodbot (22)
* asamalik (16)
* cverna (15)
* otaylor (11)
* bcotton (4)
* sgallagh (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 13. 03. 19 15:30, Stephen John Smoogen wrote:

Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.

The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.


A problem was pointed out in 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comment-914787


If you have 3rd party software using /usr/bin/python3 and you have python34 
installed, updating your system will remove that symlink and your software breaks.


However we cannot obsolete python34 form python36, because that breaks software 
that actually wants and uses /usr/bin/python3.4 and possibly make python34 
uninstallable (not sure).


So arguably, the update should update both python34 and install python36, 
keeping both Pythons available, the user/admin could than remove the one that is 
not needed.


AFAIK The only thing that would make this happen is to require python36 from 
python34. And that seems like a huge ugly workaround with unwanted side affects.


Any ideas?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

On Mon, Mar 25, 2019 at 4:57 PM Japheth Cleaver  wrote:
>
> On 3/25/2019 8:02 AM, Adam Williamson wrote:
>
> On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
>
> And since RPM appears to be configurable for the
> default interpreter, have it use /usr/bin/bash by default.
>
> TBH, it seems to me reasonable that we just do this.
>
> If our position is that we actually expect Fedora package scriptlets to
> be executed by bash and don't think it's a problem if they don't work
> when executed by some other shell, why not this make this clear and
> explicit in this way instead of having the default be sh, but then tell
> people sh must be bash?
>
> One caveat: I'm not sure current RPM allows this to be configured separately 
> for builds versus installs.
>
> There's a %_buildshell macro as of 2.4.101, but this only references 
> %prep/%build/%install/%check/etc...
> https://github.com/rpm-software-management/rpm/blob/ba85c95963f9b62f237c0442f6b5aca3e355fa83/macros.in#L801
>
> https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmscript.c#L408
> ...seems like the default for unspecified %pre/%post/etc scriptlets might 
> fall to the compiled-in /bin/sh. And the configuration of *that* might be the 
> rejected proposal at 
> http://web.archive.org/web/20150821020837/http://rpm.org/ticket/877

Interesting in a sad way, thanks for looking that up!

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

On Mon, Mar 25, 2019 at 4:27 PM Stephen John Smoogen  wrote:
>
> On Mon, 25 Mar 2019 at 11:18, Kevin Fenzi  wrote:
> >
> > On 3/25/19 8:02 AM, Adam Williamson wrote:
> > > On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
> > >> And since RPM appears to be configurable for the
> > >> default interpreter, have it use /usr/bin/bash by default.
> > >
> > > TBH, it seems to me reasonable that we just do this.
> > >
> > > If our position is that we actually expect Fedora package scriptlets to
> > > be executed by bash and don't think it's a problem if they don't work
> > > when executed by some other shell, why not this make this clear and
> > > explicit in this way instead of having the default be sh, but then tell
> > > people sh must be bash?
> >
> > Doesn't bash behave slightly differently when invoked as 'sh' ?
> >
> > Long ago it used to, but I don't know if thats still the case...
> >
>
> It will interpret some things differently but does not shut off things
> like pushd/popd and $() and various other things that are either
> considered non-POSIX

But but... $() is in POSIX sh! Don't refrain from using that one! :D

It's rather things like custom `set -...` options, custom builtins,
associative arrays... Bash in POSIX mode doesn't enforce a strict
POSIX sh syntax:

$ cat test.sh
a=(a b c)
echo ${#a[@]}
$ bash test.sh
3
$ bash --posix test.sh
3
$ dash test.sh
test.sh: 1: test.sh: Syntax error: "(" unexpected

> Man page:
>
>   If  bash  is  invoked  with  the name sh, it tries to mimic the startup
>behavior of historical versions of sh as  closely  as  possible,  while
>conforming  to the POSIX standard as well.  When invoked as an interac‐
>tive login shell, or a non-interactive shell with the  --login  option,
>it  first  attempts  to read and execute commands from /etc/profile and
>~/.profile, in that order.  The  --noprofile  option  may  be  used  to
>inhibit  this  behavior.  When invoked as an interactive shell with the
>name sh, bash looks for the variable ENV, expands its value  if  it  is
>defined,  and uses the expanded value as the name of a file to read and
>execute.  Since a shell invoked as sh does not attempt to read and exe‐
>cute  commands from any other startup files, the --rcfile option has no
>effect.  A non-interactive shell invoked with  the  name  sh  does  not
>attempt  to  read  any  other  startup files.  When invoked as sh, bash
>enters posix mode after the startup files are read.
>
>When bash is started in posix mode, as with the  --posix  command  line
>option, it follows the POSIX standard for startup files.  In this mode,
>interactive shells expand the ENV variable and commands  are  read  and
>executed  from  the  file  whose  name is the expanded value.  No other
>startup files are read.
>
> 
> The argument of where posix conformity ends and where adding features begins.
>
>
> > kevin
> >
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Steven Bonneville]

On Mon, Mar 25, 2019 at 10:27 AM 
wrote:

 On Mon, 25 Mar 2019 08:16:43 -0700 Kevin Fenzi  wrote:

> On 3/25/19 8:02 AM, Adam Williamson wrote:
> > On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
> >> And since RPM appears to be configurable for the
> >> default interpreter, have it use /usr/bin/bash by default.
> >=20
> > TBH, it seems to me reasonable that we just do this.
> >=20
> > If our position is that we actually expect Fedora package scriptlets to=
>
> > be executed by bash and don't think it's a problem if they don't work
> > when executed by some other shell, why not this make this clear and
> > explicit in this way instead of having the default be sh, but then tell=
>
> > people sh must be bash?
>
> Doesn't bash behave slightly differently when invoked as 'sh' ?
>
> Long ago it used to, but I don't know if thats still the case...
>

Yes, it enters POSIX mode after startup.  From 'info bash':

6.11 Bash POSIX Mode
> 
>
> Starting Bash with the '--posix' command-line option or executing 'set
> -o posix' while Bash is running will cause Bash to conform more closely
> to the POSIX standard by changing the behavior to match that specified
> by POSIX in areas where the Bash default differs.
>
>When invoked as 'sh', Bash enters POSIX mode after reading the
> startup files.
>

Details of the differences follow in that section.

  -- Steve

-- 
Steven Bonneville 
Principal Technical Curriculum Architect
Red Hat | Red Hat Training   Phone: +1-612-638-0507
gpg: 1024D/221D06FF  68B1 3E66 A351 6485 B9AF  24D8 3DF5 B50B 221D 06FF
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692445] New: perl-WebService-Rajce-1.190840 is available

[bugzilla]

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

Bug ID: 1692445
   Summary: perl-WebService-Rajce-1.190840 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-WebService-Rajce
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.190840
Current version/release in rawhide: 1.180.380-4.fc30
URL: http://search.cpan.org/dist/WebService-Rajce/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3497/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 8:02 AM, Adam Williamson wrote:

On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:

And since RPM appears to be configurable for the
default interpreter, have it use /usr/bin/bash by default.

TBH, it seems to me reasonable that we just do this.

If our position is that we actually expect Fedora package scriptlets to
be executed by bash and don't think it's a problem if they don't work
when executed by some other shell, why not this make this clear and
explicit in this way instead of having the default be sh, but then tell
people sh must be bash?


One caveat: I'm not sure current RPM allows this to be configured 
separately for builds versus installs.


There's a %_buildshell macro as of 2.4.101, but this only references 
%prep/%build/%install/%check/etc...
https://github.com/rpm-software-management/rpm/blob/ba85c95963f9b62f237c0442f6b5aca3e355fa83/macros.in#L801 



https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmscript.c#L408 

...seems like the default for unspecified %pre/%post/etc scriptlets 
might fall to the compiled-in /bin/sh. And the configuration of *that* 
might be the rejected proposal at 
http://web.archive.org/web/20150821020837/http://rpm.org/ticket/877


-jc

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[R P Herrold]

On Mon, 25 Mar 2019, Kevin Fenzi wrote:

> > explicit in this way instead of having the default be sh, but then tell
> > people sh must be bash?
> 
> Doesn't bash behave slightly differently when invoked as 'sh' ?

bash behaviour has changed [1] over time --- /bin/sh is fixed 
in behaviour

It is pretty clear that feaping creaturitis is in play with 
the bash developer -- an addition (recently) of an inbuilt 
'seq' primitive was a surprise to me; lots of 'undocumented' 
behaviours discussed, and some 'promoted' to being documented.  
May one rely on undocumented behaviours?

-- Russ herrold

1. https://tiswww.case.edu/php/chet/bash/CHANGES

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 11:18, Kevin Fenzi  wrote:
>
> On 3/25/19 8:02 AM, Adam Williamson wrote:
> > On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
> >> And since RPM appears to be configurable for the
> >> default interpreter, have it use /usr/bin/bash by default.
> >
> > TBH, it seems to me reasonable that we just do this.
> >
> > If our position is that we actually expect Fedora package scriptlets to
> > be executed by bash and don't think it's a problem if they don't work
> > when executed by some other shell, why not this make this clear and
> > explicit in this way instead of having the default be sh, but then tell
> > people sh must be bash?
>
> Doesn't bash behave slightly differently when invoked as 'sh' ?
>
> Long ago it used to, but I don't know if thats still the case...
>

It will interpret some things differently but does not shut off things
like pushd/popd and $() and various other things that are either
considered non-POSIX

Man page:

  If  bash  is  invoked  with  the name sh, it tries to mimic the startup
   behavior of historical versions of sh as  closely  as  possible,  while
   conforming  to the POSIX standard as well.  When invoked as an interac‐
   tive login shell, or a non-interactive shell with the  --login  option,
   it  first  attempts  to read and execute commands from /etc/profile and
   ~/.profile, in that order.  The  --noprofile  option  may  be  used  to
   inhibit  this  behavior.  When invoked as an interactive shell with the
   name sh, bash looks for the variable ENV, expands its value  if  it  is
   defined,  and uses the expanded value as the name of a file to read and
   execute.  Since a shell invoked as sh does not attempt to read and exe‐
   cute  commands from any other startup files, the --rcfile option has no
   effect.  A non-interactive shell invoked with  the  name  sh  does  not
   attempt  to  read  any  other  startup files.  When invoked as sh, bash
   enters posix mode after the startup files are read.

   When bash is started in posix mode, as with the  --posix  command  line
   option, it follows the POSIX standard for startup files.  In this mode,
   interactive shells expand the ENV variable and commands  are  read  and
   executed  from  the  file  whose  name is the expanded value.  No other
   startup files are read.


The argument of where posix conformity ends and where adding features begins.


> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New member on the block; Introducing Apprise

[Chris]

Ankur,

Thank you for your email! I look forward to helping out where I can :)

Chris

On Mon, Mar 25, 2019 at 10:47 AM Ankur Sinha  wrote:

> On Sun, Mar 10, 2019 21:39:22 -0400, Chris wrote:
> > Hi everyone,
>
> Hi Chris!
>
> I didn't see anyone reply to your e-mail, so I thought I'd drop a word :)
>
> >
> >
> > I believe i may need a sponsor too; not sure.
>
>
> From https://bugzilla.redhat.com/show_bug.cgi?id=1687178, I see that you
> have now been sponsored now. Welcome to the packagers group!
>
> --
> Thanks,
> Regards,
>
> Ankur Sinha "FranciscoD"
> https://fedoraproject.org/wiki/User:Ankursinha
>
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Kevin Fenzi]

On 3/25/19 8:02 AM, Adam Williamson wrote:
> On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
>> And since RPM appears to be configurable for the
>> default interpreter, have it use /usr/bin/bash by default.
> 
> TBH, it seems to me reasonable that we just do this.
> 
> If our position is that we actually expect Fedora package scriptlets to
> be executed by bash and don't think it's a problem if they don't work
> when executed by some other shell, why not this make this clear and
> explicit in this way instead of having the default be sh, but then tell
> people sh must be bash?

Doesn't bash behave slightly differently when invoked as 'sh' ?

Long ago it used to, but I don't know if thats still the case...

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692017] perl-XML-LibXML-2.0200 is available

[bugzilla]

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

Bug 1692343 Summary: Review Request: perl-Alien-Libxml2 - Install the C libxml2 
library on your system
https://bugzilla.redhat.com/show_bug.cgi?id=1692343

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Adam Williamson]

On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
> And since RPM appears to be configurable for the
> default interpreter, have it use /usr/bin/bash by default.

TBH, it seems to me reasonable that we just do this.

If our position is that we actually expect Fedora package scriptlets to
be executed by bash and don't think it's a problem if they don't work
when executed by some other shell, why not this make this clear and
explicit in this way instead of having the default be sh, but then tell
people sh must be bash?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

HEADS UP: PyYAML 5.1 in all Fedoras

[Miro Hrončok]

PyYAML was updated to 5.1 in all Fedoras (rawhide, branched and stable).

Most significant change is a new warning that can bit you is you treat warnings 
as errors.


Please read https://msg.pyyaml.org/load for full details about this.

tl;dr:  Use of yaml.load() without specifying the Loader parameter has been 
deprecated. It raises a custom warning that is not a subclass of DeprecationWarning.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692017] perl-XML-LibXML-2.0200 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-XML-LibXML-2.0200-1.fc
   ||31
 Resolution|--- |RAWHIDE
Last Closed||2019-03-25 14:50:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1692396] perl-Prima-1.55 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This release adds WebP support, changes image decoder interface, adds blending
with a background and renames Prima::Image::AnimateGIF to
Prima::Image::Animate::GIF. Suitable for Rawhide only.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1692396] perl-Prima-1.55 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.55-1.fc31



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: New member on the block; Introducing Apprise

[Ankur Sinha]

On Sun, Mar 10, 2019 21:39:22 -0400, Chris wrote:
> Hi everyone,

Hi Chris!

I didn't see anyone reply to your e-mail, so I thought I'd drop a word :)

>
> 
> I believe i may need a sponsor too; not sure.


From https://bugzilla.redhat.com/show_bug.cgi?id=1687178, I see that you
have now been sponsored now. Welcome to the packagers group!

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha

Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692396] New: perl-Prima-1.55 is available

[bugzilla]

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

Bug ID: 1692396
   Summary: perl-Prima-1.55 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Prima
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.55
Current version/release in rawhide: 1.54-1.fc30
URL: http://search.cpan.org/dist/Prima/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3289/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Florian Weimer]

* Stephen John Smoogen:

> My very hazy memory of UsrMove was that one of the arguments was that
> we were behind some other distros on this, and once again not "First".

Huh.  That surprises me.

> I think the issue is that many of us  look at the GNU/Linux ecosystem
> in different ways. There is what is in existence now with the majority
> of Linux being Android phones, and the majority of installed GNU/Linux
> being old Debian releases running on lightbulbs and other embedded
> hardware. However none of that is first, and being compliant with 10
> year old software is easy.. just never fix anything.  We are very much
> not compliant with those.

Debian has those multi-arch paths, though.  It really helps them with
qemu-user, and it also simplifies cross-toolchains because they can
use native libraries.  I assume this makes Debian a much more
attractive target as a developer workstation for targets where you
can't build natively—but I could be mistaken.

> There is the middle road, where you look and see a large number of
> Ubuntu being used in the cloud or in containers or whatever the hyped
> on technology of last month was. We are somewhat compliant with
> these.. but not really.

I don't think there's a significant difference between Ubuntu and
Debian in these matters at present, just the usual version skew
between packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 5:12 AM, Florian Weimer wrote:

Fedora is so different from other GNU/Linux systems these days, so I'm
not sure if *any* recommendation to encourage portability (at the cost
of convenience to Fedora developers or users) makes sense anymore.
___


If this is true (and I'm not saying I disagree), then it feels like it's 
high time that "Fedora" (as indicated) be spun towards something 
distinctly and clearly /downstream/ from a process that *does* encourage 
portability, so that Red Hat ecosystem users with those desires in mind 
have a place to attempt to manifest them.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2019 at 02:06:31PM +0100, Dridi Boukelmoune wrote:
> On Mon, Mar 25, 2019 at 1:12 PM Florian Weimer  wrote:
> >
> > * Dridi Boukelmoune:
> >
> > > This is the kind of spec that leads to spoiled upstreams putting
> > > /bin/sh in shebangs and scratching their heads when they get bug
> > > reports for stricter systems...
> > >
> > > I'd be happier if Fedora was not part of the problem and maintainers
> > > were encouraged to figure out the correct shebang (and when in doubt
> > > use /usr/bin/bash).
> >
> > If you want more compatibility, you definitely can't use /usr/bin/bash.
> 
> Or /bin/bash, it is good to be reminded that not everyone did the UsrMove...
> 
> > Fedora is so different from other GNU/Linux systems these days, so I'm
> > not sure if *any* recommendation to encourage portability (at the cost
> > of convenience to Fedora developers or users) makes sense anymore.
> 
> For me it's not so much about the defaults. When I take a script that
> says #!/bin/sh and it turns out to contain bashisms (not even talking
> about GNU extensions in  coreutils programs) it's a needless pain in
> the backside.
> 
> If were somehow able to switch /bin/sh to dash and see where things
> blow up, we could gradually switch those to bash, not necessarily
> rewrite them to be more portable.
We *could*, but what would be the point? We might just as well mandate
that all tabs should be converted to spaces (with some specific number
per tab), and fight the uphill battle of fixing every file. Fedora
scriptlets are only used in Fedora, and we only use bash, and we don't
plan to switch to anything else, and like with tabs vs. spaces, even
if we achieved the goal of posix spec-files, it would be *zero* benefit
to our users. Seriously, no one would even notice.

In the past, Debian had the idea of switching to dash because dash was
faster and they were using sysvinit and had lots of scripts executed
at startup. We have a *much* better solution to this — let's not run
scripts at all. Systemd did away with a lot of init files, and in the
rpm land, we're in the processing of removing a large chunk of our
scriptlets and replacing them with a few filetriggers. This effect of
this is actually noticable by users and has other benefits apart from
speed. Any effort put into this is much better spent than tweaking
syntax details of scriptlets.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 09:19, Florian Weimer  wrote:
>
> * Stephen John Smoogen:
>
> > On Mon, 25 Mar 2019 at 08:13, Florian Weimer  wrote:
> >>
> >> * Dridi Boukelmoune:
> >>
> >> > This is the kind of spec that leads to spoiled upstreams putting
> >> > /bin/sh in shebangs and scratching their heads when they get bug
> >> > reports for stricter systems...
> >> >
> >> > I'd be happier if Fedora was not part of the problem and maintainers
> >> > were encouraged to figure out the correct shebang (and when in doubt
> >> > use /usr/bin/bash).
> >>
> >> If you want more compatibility, you definitely can't use /usr/bin/bash.
> >>
> >> Fedora is so different from other GNU/Linux systems these days, so I'm
> >> not sure if *any* recommendation to encourage portability (at the cost
> >> of convenience to Fedora developers or users) makes sense anymore.
> >
> > This statement constantly confuses me. Every release we are told we
> > are too different from other GNU/Linux systems. That drives changes
> > which are supposed to make us more compatible, and yet at the next
> > release we are again where we started from.
>
> Hmm.  I haven't seen that, at least not for low-level matters.  (In
> the compiler flags discussion, it's about *not* changing defaults from
> GNU upstream.)
>
> We have implemented UsrMove and we don't use multi-arch paths for ELF
> objects, which makes use incompatible with a fairly large chunk of the
> rest of the GNU/Linux ecosystem.  Our Java packaging does not use the
> Class-Path: manifest attribute, and packages do not consistently use
> /usr/share/java for storing JAR files.
>
> So at the lower levels, there is not much we can do to improve
> compatibility.  Perhaps we can adopt multi-arch paths, and just hope
> that the rest of the world will eventually implement mandatory UsrMove
> as well.

My very hazy memory of UsrMove was that one of the arguments was that
we were behind some other distros on this, and once again not "First".

I think the issue is that many of us  look at the GNU/Linux ecosystem
in different ways. There is what is in existence now with the majority
of Linux being Android phones, and the majority of installed GNU/Linux
being old Debian releases running on lightbulbs and other embedded
hardware. However none of that is first, and being compliant with 10
year old software is easy.. just never fix anything.  We are very much
not compliant with those.

There is the middle road, where you look and see a large number of
Ubuntu being used in the cloud or in containers or whatever the hyped
on technology of last month was. We are somewhat compliant with
these.. but not really.

And finally there is the vast (possibly infinite) amount of GNU/Linux
which doesn't exist yet. And that is what people keep saying we aren't
compliant with as soon as it comes into existence. I would say that
the reason we don't use Java Class-Path is because Java is for old
people.. and not 'sexy' anymore for the next-gen people. Multi-arch is
for old people. UsrMove is what everyone 'should' have done.. but
didn't. When KlaFooBar Linux comes out with PDP-11-128 bit virtual
machines which make functional-object-shard-hyperledger-containers
possible.. we will be tacking as quickly to making the distro to
incorporate that. [It will probably not be something as sexy as that..
128 bit PDP-11 is just too much for this universe. The FOSHC paradigm
will probably be done in 80-128-86 instead.]




--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Florian Weimer]

* Stephen John Smoogen:

> On Mon, 25 Mar 2019 at 08:13, Florian Weimer  wrote:
>>
>> * Dridi Boukelmoune:
>>
>> > This is the kind of spec that leads to spoiled upstreams putting
>> > /bin/sh in shebangs and scratching their heads when they get bug
>> > reports for stricter systems...
>> >
>> > I'd be happier if Fedora was not part of the problem and maintainers
>> > were encouraged to figure out the correct shebang (and when in doubt
>> > use /usr/bin/bash).
>>
>> If you want more compatibility, you definitely can't use /usr/bin/bash.
>>
>> Fedora is so different from other GNU/Linux systems these days, so I'm
>> not sure if *any* recommendation to encourage portability (at the cost
>> of convenience to Fedora developers or users) makes sense anymore.
>
> This statement constantly confuses me. Every release we are told we
> are too different from other GNU/Linux systems. That drives changes
> which are supposed to make us more compatible, and yet at the next
> release we are again where we started from.

Hmm.  I haven't seen that, at least not for low-level matters.  (In
the compiler flags discussion, it's about *not* changing defaults from
GNU upstream.)

We have implemented UsrMove and we don't use multi-arch paths for ELF
objects, which makes use incompatible with a fairly large chunk of the
rest of the GNU/Linux ecosystem.  Our Java packaging does not use the
Class-Path: manifest attribute, and packages do not consistently use
/usr/share/java for storing JAR files.

So at the lower levels, there is not much we can do to improve
compatibility.  Perhaps we can adopt multi-arch paths, and just hope
that the rest of the world will eventually implement mandatory UsrMove
as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review swaps (Golang packages)

[Robert-André Mauchin]

Hello,

I'd like some help to review my packages, I'll review anything in exchange:

Review Request: golang-github-anacrolix-dms - A UPnP DLNA Digital Media Server 
that includes basic video transcoding
https://bugzilla.redhat.com/show_bug.cgi?id=1684956

Review Request: golang-github-mattn-pointer - Utility for cgo 
https://bugzilla.redhat.com/show_bug.cgi?id=1692344

Review Request: golang-github-mattn-gtk - Go binding for GTK
https://bugzilla.redhat.com/show_bug.cgi?id=1692376

Review Request: golang-github-grpc-ecosystem-middleware - Golang gRPC 
Middlewares: interceptor chaining, auth, logging, retries and more
https://bugzilla.redhat.com/show_bug.cgi?id=1689006

Review Request: golang-uber-zap - Blazing fast, structured, leveled logging in 
Go
https://bugzilla.redhat.com/show_bug.cgi?id=1688984

Review Request: golang-github-tmc-grpc-websocket-proxy - A proxy to 
transparently upgrade grpc-gateway streaming endpoints to use websockets
https://bugzilla.redhat.com/show_bug.cgi?id=1688944

Review Request: golang-github-armon-consul-api - Golang API client for Consul
https://bugzilla.redhat.com/show_bug.cgi?id=161

Review Request: golang-contrib-opencensus-exporter-ocagent - OpenCensus Go 
exporters for OpenCensus Agent
https://bugzilla.redhat.com/show_bug.cgi?id=1687159

Review Request: golang-github-gomodule-redigo - Go client for Redis
https://bugzilla.redhat.com/show_bug.cgi?id=1645286

Review Request: golang-github-snappy - Implementation of the Snappy 
compression format for Go
https://bugzilla.redhat.com/show_bug.cgi?id=1643993

Review Request: golang-github-eapache-xerial-snappy - Xerial-compatible Snappy 
framing support for golang 
https://bugzilla.redhat.com/show_bug.cgi?id=1643996

Thanks for the help!

Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

> > > Fedora is based on GNU tools versus strict POSIX compliant ones. As
> > > such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
> > > /bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
> > > specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not to
> > > be used, packagers may rely on tools to act as the upstream GNU tools
> > > in their spec files.

> So please write the spec you want to see.

Good point! Here is a variation on your proposal:

> Fedora is based on GNU tools versus strict POSIX compliant ones. As
> such, package maintainers can expect RPM build steps and scriptlets
> to be run with bash and that core programs come with GNU extensions.
> This means that unless specified elsewhere that a 'bashism', 'gawkism',
> 'gcc-ism' or other GNUism is not to be used, they may rely on tools to
> act as the upstream GNU tools in their spec files.
>
> When shipping scripts from upstream, care should be taken to check
> whether they rely on such GNUisms and report portability bugs upstream.

Funny enough, people often tell me not to use $(...) and switch to
`...` because the former "is" a bashism (spoiler alert, it isn't) and
as a result the only thing reported to me in this regard is always a
false positive :(

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

On Mon, Mar 25, 2019 at 1:12 PM Florian Weimer  wrote:
>
> * Dridi Boukelmoune:
>
> > This is the kind of spec that leads to spoiled upstreams putting
> > /bin/sh in shebangs and scratching their heads when they get bug
> > reports for stricter systems...
> >
> > I'd be happier if Fedora was not part of the problem and maintainers
> > were encouraged to figure out the correct shebang (and when in doubt
> > use /usr/bin/bash).
>
> If you want more compatibility, you definitely can't use /usr/bin/bash.

Or /bin/bash, it is good to be reminded that not everyone did the UsrMove...

> Fedora is so different from other GNU/Linux systems these days, so I'm
> not sure if *any* recommendation to encourage portability (at the cost
> of convenience to Fedora developers or users) makes sense anymore.

For me it's not so much about the defaults. When I take a script that
says #!/bin/sh and it turns out to contain bashisms (not even talking
about GNU extensions in  coreutils programs) it's a needless pain in
the backside.

If were somehow able to switch /bin/sh to dash and see where things
blow up, we could gradually switch those to bash, not necessarily
rewrite them to be more portable.

For example, our RPM configuration can definitely be Fedora-specific
and require /usr/bin/bash as the default interpreter. But when a
random script is started as an executable, via its shebang, the
shebang should be accurate and blow up when it isn't.

Bash will indeed run in POSIX mode when it is invoked as sh, but it
doesn't prevent bashisms.

Again, not beating up Fedora or bash, they are both my favorites in
their own categories, but since this topic came up it was a good
opportunity to complain :-/

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 08:13, Florian Weimer  wrote:
>
> * Dridi Boukelmoune:
>
> > This is the kind of spec that leads to spoiled upstreams putting
> > /bin/sh in shebangs and scratching their heads when they get bug
> > reports for stricter systems...
> >
> > I'd be happier if Fedora was not part of the problem and maintainers
> > were encouraged to figure out the correct shebang (and when in doubt
> > use /usr/bin/bash).
>
> If you want more compatibility, you definitely can't use /usr/bin/bash.
>
> Fedora is so different from other GNU/Linux systems these days, so I'm
> not sure if *any* recommendation to encourage portability (at the cost
> of convenience to Fedora developers or users) makes sense anymore.

This statement constantly confuses me. Every release we are told we
are too different from other GNU/Linux systems. That drives changes
which are supposed to make us more compatible, and yet at the next
release we are again where we started from. And yet every time people
try to find out what these differences are, the ones which seem to
cause the most 'this is a complete incompatibility!!!' are shed paint
colour differences versus anything substantial.

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1692017] perl-XML-LibXML-2.0200 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Depends On||1692343




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1692343
[Bug 1692343] Review Request: perl-Alien-Libxml2 - Install the C libxml2
library on your system
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Florian Weimer]

* Dridi Boukelmoune:

> This is the kind of spec that leads to spoiled upstreams putting
> /bin/sh in shebangs and scratching their heads when they get bug
> reports for stricter systems...
>
> I'd be happier if Fedora was not part of the problem and maintainers
> were encouraged to figure out the correct shebang (and when in doubt
> use /usr/bin/bash).

If you want more compatibility, you definitely can't use /usr/bin/bash.

Fedora is so different from other GNU/Linux systems these days, so I'm
not sure if *any* recommendation to encourage portability (at the cost
of convenience to Fedora developers or users) makes sense anymore.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 08:02, Dridi Boukelmoune
 wrote:
>
> > Try 1 at specification:
> >
> > Fedora is based on GNU tools versus strict POSIX compliant ones. As
> > such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
> > /bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
> > specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not to
> > be used, packagers may rely on tools to act as the upstream GNU tools
> > in their spec files.
>
> This is the kind of spec that leads to spoiled upstreams putting
> /bin/sh in shebangs and scratching their heads when they get bug
> reports for stricter systems...
>
> I'd be happier if Fedora was not part of the problem and maintainers
> were encouraged to figure out the correct shebang (and when in doubt
> use /usr/bin/bash). And since RPM appears to be configurable for the
> default interpreter, have it use /usr/bin/bash by default.
>
> Dridi

So please write the spec you want to see.


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

> Try 1 at specification:
>
> Fedora is based on GNU tools versus strict POSIX compliant ones. As
> such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
> /bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
> specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not to
> be used, packagers may rely on tools to act as the upstream GNU tools
> in their spec files.

This is the kind of spec that leads to spoiled upstreams putting
/bin/sh in shebangs and scratching their heads when they get bug
reports for stricter systems...

I'd be happier if Fedora was not part of the problem and maintainers
were encouraged to figure out the correct shebang (and when in doubt
use /usr/bin/bash). And since RPM appears to be configurable for the
default interpreter, have it use /usr/bin/bash by default.

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [modularity] Bringing order to the confusing module stream and profile names

[Adam Samalik]

Thanks all for the input. I've made a specific (quite short) proposal [1]
for the common streams and profiles including their names. We'll discuss
this tomorrow at the Modularity Team meeting (Tuesday 3 PM GMT
#fedora-meeting-3).

[1] https://pagure.io/modularity/issue/128



On Thu, Mar 14, 2019 at 4:39 PM Adam Samalik  wrote:

>
>
> On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy 
> wrote:
>
>> On to, 14 maalis 2019, Stephen Gallagher wrote:
>> >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy 
>> wrote:
>> >>
>> >> On to, 14 maalis 2019, Stephen Gallagher wrote:
>> >> >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <
>> aboko...@redhat.com> wrote:
>> >> >> This split is very artificial. In practice, at least for first four
>> use
>> >> >> cases you actually want first three to be available always because
>> they
>> >> >> are used by various parts of the code (especially by the fourth
>> one).
>> >> >>
>> >> >> It is probably better to show this with FreeIPA. In RHEL8 beta we
>> did
>> >> >> several profiles:
>> >> >>  - client, only providing a bare minimum of FreeIPA client packages
>> >> >>(freeipa-client, essentially)
>> >> >>  - server, only providing basic FreeIPA master without DNS and
>> trust to
>> >> >>AD support
>> >> >>  - dns, which is server profile + freeipa-server-dns package which
>> pulls
>> >> >>in bind and bind-dyndb-ldap
>> >> >>  - adtrust, which is server + freeipa-server-trust-ad package which
>> >> >>pulls in Samba and other packages needed to configure IPA master
>> to
>> >> >>trust Active Directory configuration, including FreeIPA plugins
>> to
>> >> >>allow management of FreeIPA by users from Active Directory
>> >> >>
>> >> >> If you are only interested in client-side operations, you'd install
>> >> >> client profile. If you need full support, you'd install dns+adtrust
>> >> >> which will bring in all individual packages you shouldn't worry
>> about.
>> >> >>
>> >> >> The difference between a profile and a normal package dependency is
>> that
>> >> >> in profile I can encode use-case specific knowledge for a set of
>> >> >> dependencies which span packages that could cater to multiple use
>> cases.
>> >> >>
>> >> >
>> >> >Sure, it was a contrived example. I was mostly trying to demonstrate
>> >> >that use-case based names for profiles must always be the preferred
>> >> >approach (which FreeIPA did perfectly). The open question in this
>> >> >thread has to do with "what do we call it when there's no obvious
>> >> >fit?". We've been using "default" up to this point, but that's a
>> >> >terribly confusing name. We've suggested "common" as an alternative
>> >> >that doesn't carry the implication that it must be (or automatically
>> >> >is) the default installed stream.
>> >> I'd say if there is no obvious fit, it is rather confusing to call that
>> >> profile 'default' or 'common'. ;)
>> >>
>> >> It is not common to have common profiles for non-obvious stuff. May be
>> >> it shouldn't even be having a profile at all? After all, package names
>> >> are accessible through existing querying interfaces (dnf search, etc.)
>> >> so there is no need to have a specific profile if it is
>> >> not-that-specific.
>> >
>> >Well, I may not have done a great job of explaining the Node.js case,
>> >but let me try to use a different example: Perl
>> >
>> >Perl defines a set of modules (not all of which are shipped with the
>> >interpreter package) that are expected to be present on any standard
>> >installation. What do we call that profile? To me, "common" seems
>> >pretty reasonable. We may also have an "interpreter" or "embedded"
>> >profile that ships a smaller set of content but that would not be the
>> >default profile.
>> In case of a programming language it could probably be called
>> 'standard-environment' or 'runtime' to underline the fact that it is
>> what is expected from a compliant environment for that programming
>> language runtime.
>>
>> However, for a client-server software there is little can be gained from
>> making a 'common' profile. What is common for a MariaDB client and a
>> MariaDB server? What set of modules is considered 'common' for Apache or
>> Nginx deployments? If there is a common agreement to what is reasonably
>> expected by the users of that software, then there is a good reason to
>> name that one 'common' but not in every case.
>>
>> >Yes, some of these same problems can and may be solved with standard
>> >dependencies and metapackages, but profiles will be a bit
>> >higher-visibility and offer an opportunity for describing things by
>> >their use-case.
>> I think that's an opportunity, indeed, but not a requirement to do it
>> for every single case. ;)
>>
>
> Ah, we're not proposing to force this profile to be used in every case.
> But when it is used, we just want the name to be consistent across all
> modules. The same goes for some common stream names.
>
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> 

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 06:34, Japheth Cleaver  wrote:
>
> On 3/25/2019 2:46 AM, Nicolas Mailhot wrote:
> > Le 2019-03-25 09:53, Jan Pokorný a écrit :
> >
> >> Good point, and that's something capable of making upstream
> >> maintenance cumbersome at times (sed is a common pet peeve),
> >> but that's an order of magnitude more demanding level when it
> >> comes to portability, and with Fedora settled firmly just around
> >> GNU approaches and extensions, there's hardly a pressing need for
> >> the spec files to come anywhere close (but if so, the restrictions
> >> should not be limited to shell interpreter alone as remarked,
> >> since POSIX compliance is a wider topic).
> >
> > More accurately, what is the point of wasting energy on making a Linux
> > system POSIX-only today? POSIX was a useful tool to make proprietary
> > unixes more or less compatible with one another. The situation has
> > changed since. Linux has taken over most of the marketplace. That
> > means the common compat layer you need to target to replace it with
> > something else, is whatever major Linux distributions agree on, and
> > that includes all the GNU tools with all their non-POSIX extensions.
>
> The original point was on the execution shell, not external commands
> being run through it. Those can always vary according to the needs of
> the .spec writer, which is why Requires(pre/post) exist. (Using perl's
> broader compatibility to get around sed oddities springs to mind.) It's
> true that it's always good to strive for maximal compatibility whenever
> possible, but that's slightly orthogonal here.
>
> It's clear that there are GNU/Linux systems that do simply use other
> Bourne shells by default, and users who would like to do so
> individually. Removing unnecessary bashisms would be very nice, but a
> sensible, coherent specification would at least be a good start.

Try 1 at specification:

Fedora is based on GNU tools versus strict POSIX compliant ones. As
such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
/bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not to
be used, packagers may rely on tools to act as the upstream GNU tools
in their spec files.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Japheth Cleaver]

On 3/25/2019 2:46 AM, Nicolas Mailhot wrote:

Le 2019-03-25 09:53, Jan Pokorný a écrit :


Good point, and that's something capable of making upstream
maintenance cumbersome at times (sed is a common pet peeve),
but that's an order of magnitude more demanding level when it
comes to portability, and with Fedora settled firmly just around
GNU approaches and extensions, there's hardly a pressing need for
the spec files to come anywhere close (but if so, the restrictions
should not be limited to shell interpreter alone as remarked,
since POSIX compliance is a wider topic).


More accurately, what is the point of wasting energy on making a Linux 
system POSIX-only today? POSIX was a useful tool to make proprietary 
unixes more or less compatible with one another. The situation has 
changed since. Linux has taken over most of the marketplace. That 
means the common compat layer you need to target to replace it with 
something else, is whatever major Linux distributions agree on, and 
that includes all the GNU tools with all their non-POSIX extensions.


The original point was on the execution shell, not external commands 
being run through it. Those can always vary according to the needs of 
the .spec writer, which is why Requires(pre/post) exist. (Using perl's 
broader compatibility to get around sed oddities springs to mind.) It's 
true that it's always good to strive for maximal compatibility whenever 
possible, but that's slightly orthogonal here.


It's clear that there are GNU/Linux systems that do simply use other 
Bourne shells by default, and users who would like to do so 
individually. Removing unnecessary bashisms would be very nice, but a 
sensible, coherent specification would at least be a good start.


-jc

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Nicolas Mailhot]

Le 2019-03-25 09:53, Jan Pokorný a écrit :


Good point, and that's something capable of making upstream
maintenance cumbersome at times (sed is a common pet peeve),
but that's an order of magnitude more demanding level when it
comes to portability, and with Fedora settled firmly just around
GNU approaches and extensions, there's hardly a pressing need for
the spec files to come anywhere close (but if so, the restrictions
should not be limited to shell interpreter alone as remarked,
since POSIX compliance is a wider topic).


More accurately, what is the point of wasting energy on making a Linux 
system POSIX-only today? POSIX was a useful tool to make proprietary 
unixes more or less compatible with one another. The situation has 
changed since. Linux has taken over most of the marketplace. That means 
the common compat layer you need to target to replace it with something 
else, is whatever major Linux distributions agree on, and that includes 
all the GNU tools with all their non-POSIX extensions.


That's why Microsoft created WSL instead of just fixing its POSIX 
subsystem. POSIX is no longer sufficient to gain significant market 
traction. Users want their pushds/popds.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

gegl04 update in rawhide and f30

[Josef Ridky]

Hi,

new upstream release of gegl04 is now available in rawhide and I am going to 
push it to f30 as well.
In this update, libgegl-0.4.so.0 will point to libgegl-0.4.so.0.414.0, instead 
of libgegl-0.4.so.0.412.0

List of affected packages (based on dnf -C repoquery --alldeps --whatrequires 
gegl04) is:
GREYCstoration-gimp
gimp
gimp-dbp
gimp-dds-plugin
gimp-fourier-plugin
gimp-gap
gimp-lensfun
gimp-normalmap
gimp-resynthesizer
gimp-separate+
gimp-wavelet-denoise-plugin
gmic-gimp
gnome-photos
libmypaint
libmypaint2
ufraw-gimp

List of changes can be found at 
https://gitlab.gnome.org/GNOME/gegl/blob/e6e673408cea212b6bef3f5ad2fbd2b017eae4eb/docs/NEWS.txt
No rebuild should be needed, due all builds refers to man libgegl-0.4.so.0, but 
ABI changes has been introduced.

Please, check your package/spec file compatibility with this update.

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Monday's FESCo Meeting (2019-03-25)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-03-25 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda


= Discussed and Voted in the Ticket =

F31 Change: Remove 389 Console 
https://pagure.io/fesco/issue/2103
APPROVED (+6, 0, 0)

F30 Change: Firefox Wayland By Default On Gnome
https://pagure.io/fesco/issue/2071
Firefox Wayland by default on gnome is deferred to F31, but also
advertise some way to do a "preview" of the feature for F30
users. (+8,0,-0)

Problematic blocker for F29: dnf 'offline' module tracking
https://pagure.io/fesco/issue/1974
The modularity team has agreed to deliver the feature in F31.
[No FESCo decision, but I think it's important to note that this
issue will still be present in the soon-to-be-released F30.]


= Followups =

#topic #2105 F31 Change: Mono 5
.fesco 2105
https://pagure.io/fesco/issue/2105

#topic #2104 Delay retiring of java-packages moved to module until a solution 
for the (Build)Requires has been found 
.fesco 2104
https://pagure.io/fesco/issue/2104

#topic #2102 F31 System-Wide Change: Gating Rawhide — Single package updates 
.fesco 2102
https://pagure.io/fesco/issue/2102

#topic #2027 RFC: Module lifecycles 
.fesco 2027
https://pagure.io/fesco/issue/2027


= New business =

#topic #2109 Policy revamp: Package Removal for Long-standing FTBFS and FTI 
bugs 
.fesco 2109
https://pagure.io/fesco/issue/2109

#topic #2110 F31 System-Wide Change: Enable Compiler Security hardening flags 
by default in GCC 
.fesco 2110
https://pagure.io/fesco/issue/2110

#topic #2108 Change release blocking deliverables process
.fesco 2108
https://pagure.io/fesco/issue/2108


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Jan Pokorný]

On 22/03/19 19:17 +0100, Dridi Boukelmoune wrote:
> On Fri, Mar 22, 2019 at 6:04 PM Japheth Cleaver  
> wrote:
>> IMO the situation that we're in now ("Assume you're running in
>> bash, but called as -/bin/sh") is a worst-of-both-worlds middle
>> ground, somewhat akin to mandating webpages be written in IE Quirks
>> Mode for all time. It's neither pedantically correct, nor flexible
>> for users and downstreams. And the resolution from all of this last
>> time remains lacking in the guarantees that an independent spec
>> should have:
> 
> The result is what we call bashisms where people put /bin/sh in their
> shebangs but don't realize they are using GNU extensions, and that
> goes for "standard" programs like awk too where people are not aware
> of the differences regarding what's on their machine and what POSIX
> mandates.

Good point, and that's something capable of making upstream
maintenance cumbersome at times (sed is a common pet peeve),
but that's an order of magnitude more demanding level when it
comes to portability, and with Fedora settled firmly just around
GNU approaches and extensions, there's hardly a pressing need for
the spec files to come anywhere close (but if so, the restrictions
should not be limited to shell interpreter alone as remarked,
since POSIX compliance is a wider topic).

> So with both a default non-POSIX-compliant shell (by default, I'm
> aware) and non-POSIX-compliant options to the basic commands it takes
> more effort to write portable shell.
> 
> To be clear, bash is my favorite shell and the one I use, but I'd
> prefer that running it as sh or /bin/sh would be enough to enter
> POSIX mode.

-- 
Jan (Poki)


pgpvqAxMo6aKZ.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is SELinux enforcing on the koji builders?

[Miroslav Suchý]

Dne 25. 03. 19 v 4:26 John M. Harris, Jr. napsal(a):
> What is the reason for builders running permissive, rather than with a 
> tailored targeted policy?

Technical details from Mock POV:

When Mock install the chroot using:

  dnf --installroot=/var/lib/mock/fedora-29-x86_64-bootstrap/root/ 

the files there get the same SELinux context as 
/var/lib/mock/fedora-29-x86_64-bootstrap/root/ - which in my case is
unconfined_u:object_r:user_tmp_t because I use tmpfs plugin.

If you would relabel that chroot, e.g., etc_t for 
/var/lib/mock/fedora-29-x86_64-bootstrap/root/etc/ you would make big
hole in system allowing user to play with the system if they have access to 
host.

The propper solution would likely means giving the files something like 
mock_etc_t for CHROOT/root/etc, but that would
mean you cannot install selinux-policy-targeted in the chroot - so different 
package for runtime and different package
for buildtime...
S many issues, and no one had time, will and power to work on this. You can 
be the first one :)

BTW there is SELinux plugin which (with --old-chroot) pretends that SELinux is 
disabled.

   https://github.com/rpm-software-management/mock/wiki/Plugin-SELinux


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Miroslav Suchý]

Dne 22. 03. 19 v 18:03 Japheth Cleaver napsal(a):
> RPM should IMHO indicate scriptlets are to be written in Bourne shell, give a 
> 'SHOULD'-level recommendation for
> POSIX-correctness, and provide a mechanism for distros to override that 
> default.

BTW any maintainer can easily indicate that by:

%post -p /usr/bin/bash
BASH SCRIPTLET

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Bugzilla (?) component for Fedora cloud images

[Florian Weimer]

This bug

  

is actually a documentation/configuration issue in the Fedora Cloud
images.  However, I can't find a Bugzilla component for these images or
their documentation.  Where should I reassign/report this?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org