date:20190516

This is your reminder that elections nominations are open through
Wednesday 2019-05-22 at 23:59:59 UTC.

On Wed, May 8, 2019 at 9:08 AM Ben Cotton  wrote:
>
> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (4 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2019-05-22 at 23:59:59 UTC.
>
> Candidates may self-nominate. If you nominate someone else, please
> check with them to ensure that they are willing to be nominated before
> submitting their name.
>
> The steering bodies are currently selecting interview questions for
> the candidates.
>
> Nominees submit their questionnaire answers via a private Pagure
> issue.  The Election Wrangler or their backup will publish the
> interviews to the Community Blog  before the start of the voting
> period. Fedora Podcast episodes will be recorded and published as
> well.
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2019-05-29) will be disqualified and removed from the election.
>
> As part of the campaign people may also ask questions to specific
> candidates on the appropriate mailing list.
>
> The full schedule of the elections is available on the Elections
> schedule[4]. For more information about the elections process, see the
> wiki[5].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://fedorapeople.org/groups/schedule/f-30/f-30-elections.html
> [5] https://fedoraproject.org/wiki/Elections
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora 31 System-Wide Change proposal: perl 5.30

https://fedoraproject.org/wiki/Changes/perl5.30

== Summary ==
A new ''perl 5.30'' version brings a lot of changes done over a year
of development. Perl 5.30 should be released at the end of May 2019.
See [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta] for more details about preparing release.

== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]]
* Email: 
* Name: [[User:Ppisar| Petr Písař]]
* Email: 

=== Completed Items ===

=== Items in Progress ===

=== Items to Be Done ===

* Upstream to release Perl 5.30
* Get dedicated  build-root from rel-engs (''f31-perl'')
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.30.0
* Build new perl 5.30 keeping old COMPAT Provides
* Rebuild dual-lived packages (otherwise dnf recommends --skip-broken and fails)
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Remove old perl(:MODULE_COMPAT_5.28.*) from perl
* Undefine perl_bootstrap
* Rebuild other packages: Use Fedora::Rebuild dependency solver
* Rebuild packages having perl_bootstrap condition in spec file
* Rebuild all updated packages
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f31'' build root
* Rebuilt Perl packages: 0 of 3186 done (0.00 %)
* Failed builds (0):
* Unsatisfied dependencies (0):

== Detailed Description ==

New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.30.0 version is stable release
this year.

In addition, Perl ''site'' paths will be made ABI-specific. CPAN
modules intended for an installation under /usr/local/ will be
installed to /usr/local/{share,lib*}/perl5/5.30 paths. This will
prevent from breaking Perl with old locally installed modules after a
Fedora upgrade.

== Benefit to Fedora ==

Up-to-date and latest perl release will be delivered to Fedora users.

== Scope ==

Every Perl package will be rebuilt in a dedicated ''f31-perl''
build-root against perl 5.30.0 and then if no major problem emerges
the packages will be merged back to ''f31'' build-root.

* Proposal owners:
New perl and all packages requiring perl or a Perl module will be
rebuilt into ''f31-perl'' build-root.

* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.

* Release engineering: [https://pagure.io/releng/issue/8368 #8368] (a
check of an impact with Release Engineering is needed)
Release engineers will be asked for new ''f31-perl'' build-root
inheriting from ''f31'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f31-perl'' packages back to
''f31'' build-root.

* Policies and guidelines:
No policies have to be modified to complete this change.

== Upgrade/Compatibility Impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.30 will be removed from the
distribution. That will require to remove those packages from existing
systems otherwise package manager will encounter unsatisfied
dependencies. Modules installed locally into /usr/local will become
unavailable and users will need to reinstall them.

== How to Test ==
Try upgrading from Fedora 30 to 31. Try some Perl application to
verify they work as expected. Try embedded perl in slapd or snmpd.

== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstalation.

== Dependencies ==
There is more than 3100 packages depending on perl. Most of them are
expected not to break. Finishing this change can be endangered only by
critical changes in a toolchain.

== Contingency Plan ==
If we find perl 5.30 is not suitable for Fedora 31, we will revert
back to perl 5.28 and we drop the temporary build-root with already
rebuilt packages.

* Contingency deadline: branching Fedora 31 from Rawhide.
* Blocks release? No.

== Documentation ==
* [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta]
* An announcement on the perl-devel mailing list
* 
[https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/thread/YLWW33T7C4LTQY5XQ6E6PXOZUGYTP27M/
Making Perl site paths ABI-specific] discussion on perl-devel mailing
list

== Release Notes ==
=== Important Changes ===
* Unicode 11, 12 and draft 12.1 is supported
* The upper limit "n" specifiable in a regular expression quantifier
of the form "{m,n}" has been doubled to 65534
* Wildcards in Unicode property value specifications are now partially supported
* qr'\N{name}' is now supported
* It is now possible to compile perl to always use thread-safe locale
operations.
* Limited variable length lookbehind in regular expression pattern
matching is now experimentally supported
* Use faster

Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

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

== Summary ==
The upstream OpenSSH disabled password logins for root back in 2015.
The Fedora should follow to keep security expectation and avoid users
surprises with this configuration.

== Owner ==
* Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
* Email: jje...@redhat.com

== Detailed Description ==

The OpenSSH server configuration contains a configuration option
`PermitRootLogin`, which controls whether the root user is allowed to
login using passwords or using public key authentication. The root
login is target of most of the random or targeted attack on Linux
systems and password is usually the weakest part. For that reason, the
upstream OpenSSH changed this option in 2015 to `prohibit-password`,
which still allows public-key authentication, but prevents the
password logins. Fedora was for many practical reasons keeping the old
configuration since then, but the difference is no longer bearable and
might confuse users expecting the root logins will not be enabled out
of the box.

On the other hand, there is still a lot of infrastructure, installers
and test instances that simply might depend on this configuration and
therefore this change needs to go through the system-wide change so
everyone is onboard.

== Benefit to Fedora ==

This will provide more secure Fedora installations out of the box and
prevent inadvertently accessible root logins in the wild.

== Scope ==
* Proposal owners: Modify the default shipped sshd configuration in
`sshd_config` to no longer include the `PermitRootLogin yes` option
and advertise this change throughout Fedora.
* Other developers: Make sure their workflow does not include logging
in as a root to ssh, otherwise modify that workflow
* Release engineering: [https://pagure.io/releng/issues/8342]

* Policies and guidelines: none
* Trademark approval: none

== Upgrade/compatibility impact ==
The updates of previously-modified `sshd_config` will not be affected
and create a `.rpmnew` configuration file.

The updates of default `sshd_config` will be updated and the
modification needs to be listed in release notes to prevent surprises.

== How To Test ==

* Make sure you have root user with password and you can login to this
user using `su`
* Make sure the sshd_config does not contain `PermitRootLogin yes` option
* Restart sshd service: `systemctl restart sshd`
* Try to connect to root user: `ssh
-oPreferredAuthentications=password root@localhost`
* Should fail

Other authentication methods (publickey, gssapi should not be affected)

== User Experience ==
Nothing in production should really depend on root password logins in
2019. If it does, it is the time to change that (or explicitly allow
it on the affected systems).

== Dependencies ==
Installer and kickstarts depending on this functionality.

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?) Maintainer
will revert the change to sshd_config if needed.
* Contingency deadline: Beta freeze
* Blocks release? no
* Blocks product? no

== Documentation ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.

Upstream release notes: http://www.openssh.com/txt/release-7.0

== Release Notes ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora and the MDS CVEs

2019-05-16 Thread Justin Forbes

For those of you wondering the Fedora status of the MDS CVEs that went
public on Tuesday. Here is where we stand:
kernel-5.0.16 and microcode_ctl-2.1-29 contain the initial mitigations
for kernel/microcode, and are in stable updates for F29 and F30, The
kernel is still in updates-testing for F28 as it needs karma, but
should make it to regular updates soon.

libvirt and qemu have updates in updates-testing across all releases.
F29 and F30 updates will push to stable today, and F28 still needs
karma.

All updates, once they hit stable, may take a day or two to reach all
mirrors, so if you do not see it available, you can keep trying, or go
directly to the main mirror.


If you do not know what the MDS CVEs are, or would like more
infomation on them, there is a good write up at
https://access.redhat.com/security/vulnerabilities/mds

Thanks,
Justin
___
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: Packages retirement as part of OpenStack clients updates in Rawhide

2019-05-16 Thread Alfredo Moralejo Alonso

On Thu, May 16, 2019 at 12:10 PM Alfredo Moralejo Alonso <
amora...@redhat.com> wrote:

>
>
> On Thu, May 16, 2019 at 11:49 AM Miro Hrončok  wrote:
>
>> On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:
>> > Hi,
>> >
>> > OpenStack client packages have been updated in Fedora Rawhide to the
>> latest
>> > releases included in recently published Stein version.
>> >
>> > As part of this update some packages which were required in the past
>> are not
>> > longer needed, so i plan to retire them from Fedora:
>> >
>> > ...
>> > python-oslo-sphinx
>>
>>
>> I might have outdated data, but:
>>
>> $ dnf repoquery --repo=compose{,-source} --whatrequires
>> python3-oslo-sphinx
>> diskimage-builder-0:1.26.1-8.fc31.noarch
>> dlrn-0:0.9.1-1.fc31.src
>> python-automaton-0:1.14.0-5.fc30.src
>> python-bash8-0:0.1.1-18.fc30.src
>> python-bashate-0:0.5.1-11.fc30.src
>> python-castellan-0:0.5.0-7.fc30.src
>> python-congressclient-0:1.5.0-10.fc30.src
>> python-cursive-0:0.1.2-8.fc30.src
>> python-grafyaml-0:0.0.5-12.fc30.src
>> python-hacking-0:1.1.0-6.fc31.src
>> python-k8sclient-0:0.3.0-10.fc30.src
>> python-keystonemiddleware-0:4.21.0-2.fc30.src
>> python-microversion-parse-0:0.1.3-11.fc30.src
>> python-murano-pkg-check-0:0.3.0-11.fc30.src
>> python-os-testr-0:0.8.0-10.fc31.src
>> python-os-win-0:2.2.0-9.fc30.src
>> python-oslo-messaging-0:8.1.2-1.fc31.src
>> python-oslo-privsep-0:1.13.0-9.fc30.src
>> python-renderspec-0:1.7.0-8.fc31.src
>> python-rsd-lib-0:0.5.1-1.fc31.src
>> python-rsdclient-0:0.2.0-1.fc31.src
>> python-subunit2sql-0:1.9.0-3.fc30.src
>> python-taskflow-0:3.4.0-1.fc31.src
>> python-yaql-0:1.1.3-6.fc30.src
>> python3-congressclient-tests-0:1.5.0-10.fc30.noarch
>>
>>
>> I see quite a lot packages that are not listed as being retired.
>> And this is just one package I picked, I haven't checked all.
>>
>> Were all those recently updated to remove the depndency?
>>
>>
> Thanks for re-checking, i'll double check it as i see some packages there
> which are not being retired.
>


After checking again, following packages from the proposed list are still
needed by others:

- python-oslo-sphinx
- python-oslo-concurrency (needed by copr-backend).

I'll update both to latest releases.


>
>
>> > According to repoqueries to rawhide, these packages are not longer
>> needed for
>> > any other package so it should be safe to get them out but let me know
>> if
>> > anything else is needing them in.
>>
>> Let's wait for the new compose, so we can double check?
>>
>>
> Sure.
>
>

BTW, to move on I need to get a couple of PRs merged:

https://src.fedoraproject.org/rpms/python-congressclient/pull-request/1
https://src.fedoraproject.org/rpms/python-mistralclient/pull-request/3

I'm trying to contact the maintainer to get them merged.



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

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

2019-05-16 Thread Jun Aruga

> > ```
> > $ docker run --rm -t arm64v8/fedora:30 uname -m
> > standard_init_linux.go:207: exec user process caused "no such file or 
> > directory"
> > ```
>
> you should just run
> $ docker run --rm -t fedora:30 uname -m
> on all arches, we push manifest listed containers to dockerhub so that
> command will work everywhere.

Alright, I did not know the kind of alias feature. Thanks for the info.

-- 
Jun Aruga / He - His - 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: how to create Makefile

2019-05-16 Thread Martin Gansser

Thanks for your feedback, i switched from qmake to cmake.
A review [1] in rpmfusion already exists.

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=5163
___
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: xindy, texlive, and concurrency

On Thu, 16 May 2019 at 01:51, Vít Ondruch  wrote:

> Dear Jerry,
>
> Although I have no idea what xindy is, I enjoyed reading your analysis.
> Thx for your insightful post.
>
>
>
I want to say ++ to this. I have found every one of Mr James articles
explaining all the things he has done to work on, debug, dead-ends, etc to
be insightful and incredibly useful to track down in other software. If you
have a chance, please look up some previous ones.

Thank you again Jerry James. Your work and analysis is deeply appreciated.



> Vít
>
>
> Dne 16. 05. 19 v 3:45 Jerry James napsal(a):
> > I finally found some time to look at the xindy failure to build.
> > First, let me say that I've got a workaround for the problem, which
> > resulted in the beautiful green colors in this xindy-enabled scratch
> > build of texlive-base:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
> >
> > When the build process reached the xindy part of the build, it would
> > successfully build xindy itself, then go to work on some
> > documentation.  This involved invoking latex on several input files.
> > This marked the first (and possibly only) point in the build where
> > latex was invoked, so latex.fmt had not yet been generated.  Since we
> > build with %{?_smp_mflags}, several independent threads invoked latex
> > at approximately the same time.  Every one of those invocations
> > detected that latex.fmt was missing and tried to generate it.
> >
> > If you got lucky, each one of those threads would generate latex.fmt,
> > then quickly consume it as it ran on its appointed input file.  If you
> > didn't get lucky, one or more threads would start reading latex.fmt
> > after some other thread started writing it, but before it finished
> > writing it all the way.  That's why xindy would sometimes build and
> > sometimes fail to build: the build process had a race condition.
> >
> > It is unfortunate that texlive is smart enough to detect missing
> > format files and generate them, but not smart enough to stop that from
> > happening multiple times concurrently.  Anyway, poor xindy has been
> > maligned: none of this was xindy's fault, nor clisp's.  We, the Fedora
> > packagers, threw concurrency at a job that lacked concurrency control.
> > And the whole xindy_arches thing is useless: this is not an
> > arch-specific problem, so removing random arches from the build
> > accomplishes nothing.
> >
> > The workaround is to invoke latex on a dummy input file early in
> > %build.  This causes latex.fmt to be generated, and then everything is
> > hunky-dory when xindy is built later.
> >
> > My recommendation is to remove the xindy_arches conditional from the
> > texlive-base and texlive spec files.  Make it unconditionallly on
> > again.  Then insert something like this at the top of %build:
> >
> > # Make texlive generate latex.fmt, so that multiple threads do not race
> to
> > # make it during the xindy build.
> > cat > dummy.tex << EOF
> > \documentclass{article}
> > \begin{document}
> > This is a document.
> > \end{document}
> > EOF
> > latex dummy.tex
> > rm -f dummy.*
> >
> > That is the substance of this pull request:
> >
> > https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
> >
> > Also, I should be able to push a clisp build with s390x support to F30
> > stable tomorrow.  I, personally, would really appreciate having xindy
> > reappear in F30, due to Sphinx assuming it is available.
> >
> > Regards,
> ___
> 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: Packages retirement as part of OpenStack clients updates in Rawhide

2019-05-16 Thread Alfredo Moralejo Alonso

On Thu, May 16, 2019 at 11:49 AM Miro Hrončok  wrote:

> On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:
> > Hi,
> >
> > OpenStack client packages have been updated in Fedora Rawhide to the
> latest
> > releases included in recently published Stein version.
> >
> > As part of this update some packages which were required in the past are
> not
> > longer needed, so i plan to retire them from Fedora:
> >
> > ...
> > python-oslo-sphinx
>
>
> I might have outdated data, but:
>
> $ dnf repoquery --repo=compose{,-source} --whatrequires python3-oslo-sphinx
> diskimage-builder-0:1.26.1-8.fc31.noarch
> dlrn-0:0.9.1-1.fc31.src
> python-automaton-0:1.14.0-5.fc30.src
> python-bash8-0:0.1.1-18.fc30.src
> python-bashate-0:0.5.1-11.fc30.src
> python-castellan-0:0.5.0-7.fc30.src
> python-congressclient-0:1.5.0-10.fc30.src
> python-cursive-0:0.1.2-8.fc30.src
> python-grafyaml-0:0.0.5-12.fc30.src
> python-hacking-0:1.1.0-6.fc31.src
> python-k8sclient-0:0.3.0-10.fc30.src
> python-keystonemiddleware-0:4.21.0-2.fc30.src
> python-microversion-parse-0:0.1.3-11.fc30.src
> python-murano-pkg-check-0:0.3.0-11.fc30.src
> python-os-testr-0:0.8.0-10.fc31.src
> python-os-win-0:2.2.0-9.fc30.src
> python-oslo-messaging-0:8.1.2-1.fc31.src
> python-oslo-privsep-0:1.13.0-9.fc30.src
> python-renderspec-0:1.7.0-8.fc31.src
> python-rsd-lib-0:0.5.1-1.fc31.src
> python-rsdclient-0:0.2.0-1.fc31.src
> python-subunit2sql-0:1.9.0-3.fc30.src
> python-taskflow-0:3.4.0-1.fc31.src
> python-yaql-0:1.1.3-6.fc30.src
> python3-congressclient-tests-0:1.5.0-10.fc30.noarch
>
>
> I see quite a lot packages that are not listed as being retired.
> And this is just one package I picked, I haven't checked all.
>
> Were all those recently updated to remove the depndency?
>
>
Thanks for re-checking, i'll double check it as i see some packages there
which are not being retired.


> > According to repoqueries to rawhide, these packages are not longer
> needed for
> > any other package so it should be safe to get them out but let me know
> if
> > anything else is needing them in.
>
> Let's wait for the new compose, so we can double check?
>
>
Sure.


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

Re: xindy, texlive, and concurrency

On Thu, May 16, 2019 at 9:41 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote:

> Let me also add my +1 to the write-up itself, a very nice story.
>
> Zbyszek

I may have accidentally skipped the +1 step and jumped straight to
suggestions on how to improve the situation, shifting the blame away
from _smp_mflags. But I agree this is a very relatable investigation!

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: Removal of krb5-devel from "stable" F29 buidroot broke my package

2019-05-16 Thread Vít Ondruch


Dne 16. 05. 19 v 9:20 Dominique Martinet napsal(a):
> Vít Ondruch wrote on Thu, May 16, 2019 at 08:28:45AM +0200:
 This was removed on my request, triggered by this PR [1]. Nevertheless I
 concur that this should happen just in Rawhide and never be backported
 into stable releases.
>>> I don't see why this is a problem.  Removing an unneeded build
>>> dependency from a package shouldn't affect anything else.  That it did
>>> merely pointed out a bug in the other package where the build deps
>>> were incomplete.
> The problem is not the build dependency, you can get rid of it
> everywhere without any impact except for openssl itself.
>
> What is less transparent is the removal of an actual Require (two
> actually, zlib-devel is no longer pulled either) ; that can impact other
> packages and workflows.


Ah, right, I meant Require of course. I stand corrected. Thx.


Vít


> Someone installing openssl-devel could have expected it to pull
> krb5-devel and zlib-devel, now they need to install it explicitely
> separately for their own use as well, it's a change in user interface.
>
>> We lived with this "bug" for years. There is no reason to fix this bug
>> in stable release just to cause other bugs. And it was obvious it would
>> broke at least build of Ruby and now it is obvious it did broke not just
>> Ruby. It would be enough to have to solve this issues in Rawhide.
>>
>> Also, (not) pulling -devel package into build root might result in some
>> subtle bugs such as some part of package functionality disabled based on
>> build configuration, which might went unnoticed, until the package is
>> released. This is irresponsible.
> configure with feature autodetection is a PITA :/
>
___
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] soname version bump for evolution-data-server in rawhide

2019-05-16 Thread Milan Crha

Hello,
next week's 3.33.2 release of evolution-data-server, on 2019-05-20,
will contain soname version bumps in libecal, libedata-cal, libebook
and libedata-book. At least unless anything bad happens.

The main change on the calendar part is that there will be used
libical-glib instead of libical, which allows automatic gobject
introspection generation. That turned to be as significant change as it
worth the calendar API change from version 1.2 to 2.0.

The other change on the address book and the calendar parts was about
adding a new argument into some methods, which touches both the C API
and the D-Bus API, thus there is a version bump on the D-Bus service
names as well. [1]

Below is the list of affected packages in Fedora, divided into four
sections:

* Those, which require patching:
almanah
bijiben (aka gnome-notes)
evolution
evolution-ews
evolution-mapi
folks
gnome-calendar
gnome-shell
gnome-todo
libopensync
libreoffice
pidgin-chime
syncevolution

* Those, which require only rebuild:
ekiga
evolution-rspam
evolution-rss
glabels
gnome-contacts
gnome-phone-manager
sflphone

* Those, which require patching, but are already retired:
california
ffgtk

* Those, which require work:
elementary-calendar
wingpanel-indicator-datetime

Any existing patches can be found through [3], which contains also
links to respective merge requests and bugs, filled to let know the
maintainers beforehand.

I will rebuild/apply patches to the packages I've commit rights for.
I'd need help with others. Especially those two elementary-related
packages won't work easily, because they use vala bindings, which they
bundle in the sources, thus there is needed a lot of work. One of the
elementary developers promised me to look on it once the eds is
released.

If you find more packages to be ported and you'd like to help with it,
just let me know.
Bye,
Milan

[1] This may cause trouble to Flatpak applications, which compile
against some version of the evolution-data-server (eds) and then
rely on the host system eds D-Bus services (that applies both
ways, it won't help to compile against older eds, because the
Flatpak application won't work on systems with the new eds). Such
applications can run their own eds services, as shown here [2].
The advantage of it is to receive also backend-specific fixes in
their Flatpak application, not only client-side fixes. The
disadvantage is that the data won't be shared between the
applications.

[2]
https://gitlab.gnome.org/GNOME/evolution/blob/master/flatpak/org.gnome.Evolution-stable.json#L258

[3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33

___
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: Packages retirement as part of OpenStack clients updates in Rawhide

2019-05-16 Thread Miro Hrončok


On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:

Hi,

OpenStack client packages have been updated in Fedora Rawhide to the latest 
releases included in recently published Stein version.


As part of this update some packages which were required in the past are not 
longer needed, so i plan to retire them from Fedora:


...
python-oslo-sphinx



I might have outdated data, but:

$ dnf repoquery --repo=compose{,-source} --whatrequires python3-oslo-sphinx
diskimage-builder-0:1.26.1-8.fc31.noarch
dlrn-0:0.9.1-1.fc31.src
python-automaton-0:1.14.0-5.fc30.src
python-bash8-0:0.1.1-18.fc30.src
python-bashate-0:0.5.1-11.fc30.src
python-castellan-0:0.5.0-7.fc30.src
python-congressclient-0:1.5.0-10.fc30.src
python-cursive-0:0.1.2-8.fc30.src
python-grafyaml-0:0.0.5-12.fc30.src
python-hacking-0:1.1.0-6.fc31.src
python-k8sclient-0:0.3.0-10.fc30.src
python-keystonemiddleware-0:4.21.0-2.fc30.src
python-microversion-parse-0:0.1.3-11.fc30.src
python-murano-pkg-check-0:0.3.0-11.fc30.src
python-os-testr-0:0.8.0-10.fc31.src
python-os-win-0:2.2.0-9.fc30.src
python-oslo-messaging-0:8.1.2-1.fc31.src
python-oslo-privsep-0:1.13.0-9.fc30.src
python-renderspec-0:1.7.0-8.fc31.src
python-rsd-lib-0:0.5.1-1.fc31.src
python-rsdclient-0:0.2.0-1.fc31.src
python-subunit2sql-0:1.9.0-3.fc30.src
python-taskflow-0:3.4.0-1.fc31.src
python-yaql-0:1.1.3-6.fc30.src
python3-congressclient-tests-0:1.5.0-10.fc30.noarch


I see quite a lot packages that are not listed as being retired.
And this is just one package I picked, I haven't checked all.

Were all those recently updated to remove the depndency?

According to repoqueries to rawhide, these packages are not longer needed for 
any other package so it should be safe to get them out but let me know if 
anything else is needing them in.


Let's wait for the new compose, so we can double check?

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

Fedora Rawhide-20190515.n.1 compose check report

2019-05-16 Thread Fedora compose checker

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose FAILS proposed Rawhide gating check!
5 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 10/146 (x86_64), 1/24 (i386), 1/2 (arm)

ID: 401631  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/401631
ID: 401659  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/401659
ID: 401660  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/401660
ID: 401661  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/401661
ID: 401670  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/401670
ID: 401673  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/401673
ID: 401674  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/401674
ID: 401684  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/401684
ID: 401686  Test: x86_64 universal install_anaconda_text **GATING**
URL: https://openqa.fedoraproject.org/tests/401686
ID: 401697  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/401697
ID: 401706  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/401706
ID: 401753  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/401753

Soft failed openQA tests: 3/24 (i386), 6/146 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 401634  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/401634
ID: 401635  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/401635
ID: 401652  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/401652
ID: 401653  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/401653
ID: 401654  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/401654
ID: 401658  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/401658
ID: 401732  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/401732
ID: 401742  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/401742
ID: 401744  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/401744

Passed openQA tests: 120/146 (x86_64), 20/24 (i386)

Skipped gating openQA tests: 4/146 (x86_64)

ID: 401665  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/401665
ID: 401666  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/401666
ID: 401668  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/401668
ID: 401669  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/401669

Skipped non-gating openQA tests: 7 of 172
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Removal of krb5-devel from "stable" F29 buidroot broke my package

2019-05-16 Thread Dominique Martinet

Vít Ondruch wrote on Thu, May 16, 2019 at 08:28:45AM +0200:
> >> This was removed on my request, triggered by this PR [1]. Nevertheless I
> >> concur that this should happen just in Rawhide and never be backported
> >> into stable releases.
> >
> > I don't see why this is a problem.  Removing an unneeded build
> > dependency from a package shouldn't affect anything else.  That it did
> > merely pointed out a bug in the other package where the build deps
> > were incomplete.

The problem is not the build dependency, you can get rid of it
everywhere without any impact except for openssl itself.

What is less transparent is the removal of an actual Require (two
actually, zlib-devel is no longer pulled either) ; that can impact other
packages and workflows.
Someone installing openssl-devel could have expected it to pull
krb5-devel and zlib-devel, now they need to install it explicitely
separately for their own use as well, it's a change in user interface.

> We lived with this "bug" for years. There is no reason to fix this bug
> in stable release just to cause other bugs. And it was obvious it would
> broke at least build of Ruby and now it is obvious it did broke not just
> Ruby. It would be enough to have to solve this issues in Rawhide.
> 
> Also, (not) pulling -devel package into build root might result in some
> subtle bugs such as some part of package functionality disabled based on
> build configuration, which might went unnoticed, until the package is
> released. This is irresponsible.

configure with feature autodetection is a PITA :/

-- 
Dominique
___
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: xindy, texlive, and concurrency

2019-05-16 Thread Zbigniew Jędrzejewski-Szmek

On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote:
> On Thu, May 16, 2019 at 3:46 AM Jerry James  wrote:
> >
> > I finally found some time to look at the xindy failure to build.
> > First, let me say that I've got a workaround for the problem, which
> > resulted in the beautiful green colors in this xindy-enabled scratch
> > build of texlive-base:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
> >
> > When the build process reached the xindy part of the build, it would
> > successfully build xindy itself, then go to work on some
> > documentation.  This involved invoking latex on several input files.
> > This marked the first (and possibly only) point in the build where
> > latex was invoked, so latex.fmt had not yet been generated.  Since we
> > build with %{?_smp_mflags}, several independent threads invoked latex
> > at approximately the same time.  Every one of those invocations
> > detected that latex.fmt was missing and tried to generate it.
> >
> > If you got lucky, each one of those threads would generate latex.fmt,
> > then quickly consume it as it ran on its appointed input file.  If you
> > didn't get lucky, one or more threads would start reading latex.fmt
> > after some other thread started writing it, but before it finished
> > writing it all the way.  That's why xindy would sometimes build and
> > sometimes fail to build: the build process had a race condition.
> 
> So this is a build system bug from upstream. If concurrency introduces
> a race condition then source-target dependencies are lacking in the
> build system. Depending on the build system it may not be upstream's
> fault, but the tooling itself.
> 
> A workaround for the concurrency problem would be an atomic write of
> the generated file. This way even when it is generated multiple times
> while others try to read it they either see a complete or missing file.
> 
> The only way I'm aware of for this workaround would be to write to a
> temp file on the same filesystem, and then use mv to rename it
> atomically.

Yes! Check-if-exists, write-to-tmpfile, atomic-rename. If the rename
fails, someone else won the race, so discard the tmpfile, continue
as usual.

So this isn't really a bug in the build system, but a bug in latex
which bungles creation of what is essentially a cache file.
(One expects that a tool like latex may be invoked more than once
at the same time and anything it does internally is its own business).

Let me also add my +1 to the write-up itself, a very nice story.

Zbyszek

> > It is unfortunate that texlive is smart enough to detect missing
> > format files and generate them, but not smart enough to stop that from
> > happening multiple times concurrently.  Anyway, poor xindy has been
> > maligned: none of this was xindy's fault, nor clisp's.  We, the Fedora
> > packagers, threw concurrency at a job that lacked concurrency control.
> > And the whole xindy_arches thing is useless: this is not an
> > arch-specific problem, so removing random arches from the build
> > accomplishes nothing.
> >
> > The workaround is to invoke latex on a dummy input file early in
> > %build.  This causes latex.fmt to be generated, and then everything is
> > hunky-dory when xindy is built later.
> >
> > My recommendation is to remove the xindy_arches conditional from the
> > texlive-base and texlive spec files.  Make it unconditionallly on
> > again.  Then insert something like this at the top of %build:
> >
> > # Make texlive generate latex.fmt, so that multiple threads do not race to
> > # make it during the xindy build.
> > cat > dummy.tex << EOF
> > \documentclass{article}
> > \begin{document}
> > This is a document.
> > \end{document}
> > EOF
> > latex dummy.tex
> > rm -f dummy.*
> >
> > That is the substance of this pull request:
> >
> > https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
> >
> > Also, I should be able to push a clisp build with s390x support to F30
> > stable tomorrow.  I, personally, would really appreciate having xindy
> > reappear in F30, due to Sphinx assuming it is available.
> >
> > Regards,
> > --
> > Jerry James
> > http://www.jamezone.org/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 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: 
>

how to create Makefile

2019-05-16 Thread Martin Gansser

Hi,

I'm trying to compile the program olive with the help of a spec file [1], which 
unfortunately fails when creating the Makefile.
Have somebody a idea or solution ?

[1] https://martinkg.fedorapeople.org/Packages/olive/olive.spec

Regars
Martin
___
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: Removal of krb5-devel from "stable" F29 buidroot broke my package

2019-05-16 Thread Igor Gnatenko

In meson we automatically set all "auto" features to be "enabled". So
people have to disable things they don't want manually.

On Thu, May 16, 2019, 10:00 Dridi Boukelmoune 
wrote:

> > configure with feature autodetection is a PITA :/
>
> The PITA doesn't come from auto-detection, rather auto-selection of
> (optional) dependencies. I tend to prefer explicit --with-* or --enable-*
> flags for anything optional and fixed defaults.
>
> It would be worse if we had to tell a configure script where each
> individual build dependency can be found! There tend to be more
> than what meets the eye, much more. Take your average project
> building with autotools and try this:
>
> ./configure --help | less
>
> 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
>
___
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

Packages retirement as part of OpenStack clients updates in Rawhide

2019-05-16 Thread Alfredo Moralejo Alonso

Hi,

OpenStack client packages have been updated in Fedora Rawhide to the latest
releases included in recently published Stein version.

As part of this update some packages which were required in the past are
not longer needed, so i plan to retire them from Fedora:

python-automaton
python-castellan
python-ceilometermiddleware
python-cursive
python-keystonemiddleware
python-microversion-parse
python-oslo-cache
python-oslo-concurrency
python-oslo-messaging
python-oslo-middleware
python-oslo-policy
python-oslo-privsep
python-oslo-reports
python-oslo-rootwrap
python-oslo-service
python-oslo-sphinx
python-oslo-vmware
python-osprofiler
python-os-win
python-pycadf
python-reno
python-taskflow

According to repoqueries to rawhide, these packages are not longer needed
for any other package so it should be safe to get them out but let me know
if anything else is needing them in.

Best regards,

Alfredo
___
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: Fedora GPG keys

2019-05-16 Thread Samuel Sieb


On 5/15/19 11:33 PM, Miroslav Suchý wrote:

Can someone enlighten me what happened to:
   https://getfedora.org/keys/
? There used to be GPG keys of Fedora, but now it just return 404.


This was just brought up on the users list as well.  It's being corrected.
___
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: Removal of krb5-devel from "stable" F29 buidroot broke my package

> configure with feature autodetection is a PITA :/

The PITA doesn't come from auto-detection, rather auto-selection of
(optional) dependencies. I tend to prefer explicit --with-* or --enable-*
flags for anything optional and fixed defaults.

It would be worse if we had to tell a configure script where each
individual build dependency can be found! There tend to be more
than what meets the eye, much more. Take your average project
building with autotools and try this:

./configure --help | less

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: Schedule for Thursday's FPC Meeting (2019-05-16 16:00 UTC)

2019-05-16 Thread Zbigniew Jędrzejewski-Szmek

On Wed, May 15, 2019 at 05:52:15PM -0400, James Antill wrote:
> Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2019-05-16 16:00 UTC in #fedora-meeting-1 on 
> irc.freenode.net.
> 
>  Local time information (via. uitime):
> 
> = Day: Thursday ==
> 2019-05-16 09:00 PDT  US/Pacific
> 2019-05-16 12:00 EDT  --> US/Eastern <--
> 2019-05-16 16:00 UTC  UTC   
> 2019-05-16 17:00 BST  Europe/London 
> 2019-05-16 18:00 CEST Europe/Berlin 
> 2019-05-16 18:00 CEST Europe/Paris  
> 2019-05-16 21:30 IST  Asia/Calcutta 
>  New Day: Friday -
> 2019-05-17 00:00 HKT  Asia/Hong_Kong
> 2019-05-17 00:00 +08  Asia/Singapore
> 2019-05-17 01:00 JST  Asia/Tokyo
> 2019-05-17 02:00 AEST Australia/Brisbane
> 
> 
>  Links to all tickets below can be found at: 
> 
> https://pagure.io/packaging-committee/issues?status=Open=meeting
> 
> = Followups =
> 
> #topic #845 Wiki deprecation status
> .fpc 845
> https://pagure.io/packaging-committee/issue/845
> 
> #topic #859 Scriptlet to replace a directory: try delete first? 
> .fpc 859
> https://pagure.io/packaging-committee/issue/859
> 
> = New business =
> 
> #topic #886 Enable BRP for detecting RPATH 
> .fpc 886
> https://pagure.io/packaging-committee/issue/886
> 
> #topic #887 Review Process Exemption: colcon - collective construction 
> .fpc 887
> https://pagure.io/packaging-committee/issue/887
> 
> #topic #889 (RE-)Bootstrap Exception for erlang-rebar3 
> .fpc 889
> https://pagure.io/packaging-committee/issue/889
> 
> = Open Floor = 

Can you please also add
https://pagure.io/packaging-committee/pull-request/890?
I can be there to answer questions if that helps.

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: how to create Makefile

On Thu, May 16, 2019 at 9:49 AM Martin Gansser  wrote:
>
> Hi,
>
> I'm trying to compile the program olive with the help of a spec file [1], 
> which unfortunately fails when creating the Makefile.
> Have somebody a idea or solution ?
>
> [1] https://martinkg.fedorapeople.org/Packages/olive/olive.spec

Follow the cmake guidelines, you are missing a "%cmake ." statement
before building.

https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/

Just in case, to my knowledge this is not an acceptable package for Fedora.

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: how to create Makefile

2019-05-16 Thread J. Scheurich




I'm trying to compile the program olive with the help of a spec file [1], which 
unfortunately fails when creating the Makefile.
Have somebody a idea or solution ?


qt projects usally uses "qmake" if you have a .pro project file.

https://doc.qt.io/archives/3.3/qmake-manual-3.html

so long
MUFTI
___
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

planning on taking python-urwid

2019-05-16 Thread Tomas Tomecek

Hey, this is just a heads-up that I'm planning on taking python-urwid
since it's a dep of 2 of my packages.

It's orphaned and I want it to find a new home.

Rel-eng ticket will follow.
___
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: sign_and_send_pubkey: signing failed: agent refused operation

2019-05-16 Thread Jakub Jelen

On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote:
> Hello,
> 
> I'm getting the following error when I'm access the fedora git trees.
> 
> sign_and_send_pubkey: signing failed: agent refused operation
> ste...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> Now I know I have the correct publickey (id_rsa/id_rsa.pub)
> because they work on a different host. and generally 
> when I have the wrong keys, I get the above error minus
> 
> sign_and_send_pubkey: signing failed: agent refused operation
> 
> Any idea what is happening? 

What Fedora and OpenSSH version are you using? Does it work if you
downgrade openssh? Are you using gnome-keyring? What is the output of
"echo $SSH_AUTH_SOCK"?

This error means that the agent fails to provide the signature using
your private key for some reason. Running the ssh-agent separately in
debug mode (ssh-agent -d) might show a bit more information.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
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: sign_and_send_pubkey: signing failed: agent refused operation

2019-05-16 Thread Dan Horák

On Thu, 16 May 2019 11:11:52 +0200
Jakub Jelen  wrote:

> On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote:
> > Hello,
> > 
> > I'm getting the following error when I'm access the fedora git
> > trees.
> > 
> > sign_and_send_pubkey: signing failed: agent refused operation
> > ste...@pkgs.fedoraproject.org: Permission denied (publickey).
> > fatal: Could not read from remote repository.
> > 
> > Please make sure you have the correct access rights
> > and the repository exists.
> > 
> > Now I know I have the correct publickey (id_rsa/id_rsa.pub)
> > because they work on a different host. and generally 
> > when I have the wrong keys, I get the above error minus
> > 
> > sign_and_send_pubkey: signing failed: agent refused operation
> > 
> > Any idea what is happening? 
> 
> What Fedora and OpenSSH version are you using? Does it work if you
> downgrade openssh? Are you using gnome-keyring? What is the output of
> "echo $SSH_AUTH_SOCK"?

probably only for the record as I don't expect many Fedora/ppc64le
desktop users here and the problem seems to be ppc64le specific :-)

You get the "agent refused operation" there, because the gcr-prompter
process (dbus service) crashes when unlocking the ssh key, for more
details see https://bugzilla.redhat.com/show_bug.cgi?id=1631759


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

Fedora rawhide compose report: 20190515.n.1 changes

2019-05-16 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20190514.n.0
NEW: Fedora-Rawhide-20190515.n.1

= SUMMARY =
Added images:0
Dropped images:  6
Added packages:  7
Dropped packages:1
Upgraded packages:   162
Downgraded packages: 0

Size of added packages:  10.00 MiB
Size of dropped packages:277.00 KiB
Size of upgraded packages:   9.12 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   171.86 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190514.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190514.n.0.iso
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190514.n.0.aarch64.raw.xz
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20190514.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190514.n.0-sda.raw.xz
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190514.n.0.iso

= ADDED PACKAGES =
Package: nodejs-generate-function-2.3.1-1.fc31
Summary: Module that helps you write generated functions in Node
RPMs:nodejs-generate-function
Size:11.73 KiB

Package: nodejs-generate-object-property-1.2.0-8.fc31
Summary: Generate safe JS code that can used to reference a object property
RPMs:nodejs-generate-object-property
Size:10.12 KiB

Package: nodejs-har-validator-2.0.6-1.fc31
Summary: Extremely fast HTTP Archive (HAR) validator using JSON Schema
RPMs:nodejs-har-validator
Size:17.64 KiB

Package: nodejs-is-my-json-valid-2.12.4-8.fc31
Summary: A JSONSchema validator that uses code generation to be extremely fast
RPMs:nodejs-is-my-json-valid
Size:16.69 KiB

Package: nodejs-is-property-1.0.2-8.fc31
Summary: Tests if a json property can be safely accessed using the .syntax
RPMs:nodejs-is-property
Size:11.80 KiB

Package: policycoreutils-2.9-1.module_f31+4252+e9820e36
Summary: SELinux policy core utilities
RPMs:policycoreutils policycoreutils-dbus policycoreutils-devel 
policycoreutils-gui policycoreutils-newrole policycoreutils-python-utils 
policycoreutils-restorecond policycoreutils-sandbox python2-policycoreutils 
python3-policycoreutils
Size:5.46 MiB

Package: setools-4.2.1-3.module_f31+4252+e9820e36
Summary: Policy analysis tools for SELinux
RPMs:python3-setools setools setools-console setools-console-analyses 
setools-gui
Size:4.47 MiB


= DROPPED PACKAGES =
Package: dwm-6.1-8.module_f31+3254+1bcded0b
Summary: Dynamic window manager for X
RPMs:dwm dwm-user
Size:277.00 KiB


= UPGRADED PACKAGES =
Package:  Carla-2.0.0-0.10.20190501git41f81a8.fc31
Old package:  Carla-2.0.0-0.9.20181225git2f3a442.fc30
Summary:  Audio plugin host
RPMs: Carla Carla-devel Carla-vst lv2-carla
Size: 65.43 MiB
Size change:  11.59 MiB
Changelog:
  * Wed May 15 2019 Martin Gansser  - 
2.0.0-0.10.20190501git41f81a8
  - Update to 2.0.0-0.10.20190501git41f81a8


Package:  R-hexbin-1.27.3-1.fc31
Old package:  R-hexbin-1.27.2-4.fc30
Summary:  Hexagonal Binning Routines
RPMs: R-hexbin
Size: 5.44 MiB
Size change:  547.29 KiB
Changelog:
  * Tue May 14 2019 Elliott Sales de Andrade  - 
1.27.3-1
  - Update to latest version


Package:  R-tinytex-0.13-1.fc31
Old package:  R-tinytex-0.12-1.fc31
Summary:  Helper Functions to Install and Maintain 'TeX Live', and Compile 
'LaTeX' Documents
RPMs: R-tinytex
Size: 107.29 KiB
Size change:  1.54 KiB
Changelog:
  * Tue May 14 2019 Elliott Sales de Andrade  - 
0.13-1
  - Update to latest version


Package:  R-xfun-0.7-1.fc31
Old package:  R-xfun-0.6-1.fc31
Summary:  Miscellaneous Functions by 'Yihui Xie'
RPMs: R-xfun
Size: 182.56 KiB
Size change:  500 B
Changelog:
  * Tue May 14 2019 Elliott Sales de Andrade  - 0.7-1
  - Update to latest version


Package:  anaconda-31.12-1.fc31
Old package:  anaconda-31.11-1.fc31
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel
Size: 20.75 MiB
Size change:  23.84 KiB
Changelog:
  * Wed May 15 2019 Martin Kolman  - 31.12-1
  - Fix condition for running GUI User spoke in Initial Setup (mkolman)
  - Expose individual user group, user and root password DBus tasks (mkolman)
  - Use a DBus task for Initial Setup configuration (mkolman)
  - Add ConfigureInitialSetupTask (mkolman)
  - Sysroot support for enable_service() and disable_service() (mkolman)
  - Fix documentation for nosslverify (jkonecny)
  - Replace noverifyssl flag in anaconda (jkonecny)
  - Adjust verify_ssl config from cmdline (jkonecny)
  - Move payload nosslverify to the config files (jkonecny)
  - Skip some of the driver disk tests

Re: xindy, texlive, and concurrency

On Thu, May 16, 2019 at 3:46 AM Jerry James  wrote:
>
> I finally found some time to look at the xindy failure to build.
> First, let me say that I've got a workaround for the problem, which
> resulted in the beautiful green colors in this xindy-enabled scratch
> build of texlive-base:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
>
> When the build process reached the xindy part of the build, it would
> successfully build xindy itself, then go to work on some
> documentation.  This involved invoking latex on several input files.
> This marked the first (and possibly only) point in the build where
> latex was invoked, so latex.fmt had not yet been generated.  Since we
> build with %{?_smp_mflags}, several independent threads invoked latex
> at approximately the same time.  Every one of those invocations
> detected that latex.fmt was missing and tried to generate it.
>
> If you got lucky, each one of those threads would generate latex.fmt,
> then quickly consume it as it ran on its appointed input file.  If you
> didn't get lucky, one or more threads would start reading latex.fmt
> after some other thread started writing it, but before it finished
> writing it all the way.  That's why xindy would sometimes build and
> sometimes fail to build: the build process had a race condition.

So this is a build system bug from upstream. If concurrency introduces
a race condition then source-target dependencies are lacking in the
build system. Depending on the build system it may not be upstream's
fault, but the tooling itself.

A workaround for the concurrency problem would be an atomic write of
the generated file. This way even when it is generated multiple times
while others try to read it they either see a complete or missing file.

The only way I'm aware of for this workaround would be to write to a
temp file on the same filesystem, and then use mv to rename it
atomically.



> It is unfortunate that texlive is smart enough to detect missing
> format files and generate them, but not smart enough to stop that from
> happening multiple times concurrently.  Anyway, poor xindy has been
> maligned: none of this was xindy's fault, nor clisp's.  We, the Fedora
> packagers, threw concurrency at a job that lacked concurrency control.
> And the whole xindy_arches thing is useless: this is not an
> arch-specific problem, so removing random arches from the build
> accomplishes nothing.
>
> The workaround is to invoke latex on a dummy input file early in
> %build.  This causes latex.fmt to be generated, and then everything is
> hunky-dory when xindy is built later.
>
> My recommendation is to remove the xindy_arches conditional from the
> texlive-base and texlive spec files.  Make it unconditionallly on
> again.  Then insert something like this at the top of %build:
>
> # Make texlive generate latex.fmt, so that multiple threads do not race to
> # make it during the xindy build.
> cat > dummy.tex << EOF
> \documentclass{article}
> \begin{document}
> This is a document.
> \end{document}
> EOF
> latex dummy.tex
> rm -f dummy.*
>
> That is the substance of this pull request:
>
> https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
>
> Also, I should be able to push a clisp build with s390x support to F30
> stable tomorrow.  I, personally, would really appreciate having xindy
> reappear in F30, due to Sphinx assuming it is available.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?

2019-05-16 Thread Jun Aruga

> > you should just run
> > $ docker run --rm -t fedora:30 uname -m
> > on all arches, we push manifest listed containers to dockerhub so that
> > command will work everywhere.
>
> Alright, I did not know the kind of alias feature. Thanks for the info.

But my motivation is not like
* Running x86_64 container on x86_64 machine
* Running aarch64 container on aarch64 machine
...

but
* Running aarch64, s390x, ppc64le and etc containers on x86_64 machine.

The reason is that makes multi arch's tests enable on x86_64
environment or x86_64 base CI service.

-- 
Jun Aruga / He - His - 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

is anyone using /usr/sbin/halt.local?

2019-05-16 Thread Zbigniew Jędrzejewski-Szmek

There's a proposal to drop the support for this pre-systemd compat feature,
but if it's actually used, we'll keep it.
C.f. https://github.com/systemd/systemd/pull/12571.

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: sign_and_send_pubkey: signing failed: agent refused operation

2019-05-16 Thread Brian C. Lane

On Wed, May 15, 2019 at 05:09:41PM -0400, Steve Dickson wrote:
> Hello,
> 
> I'm getting the following error when I'm access the fedora git trees.
> 
> sign_and_send_pubkey: signing failed: agent refused operation
> ste...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> Now I know I have the correct publickey (id_rsa/id_rsa.pub)
> because they work on a different host. and generally 
> when I have the wrong keys, I get the above error minus
> 
> sign_and_send_pubkey: signing failed: agent refused operation
> 
> Any idea what is happening? 

Do you have multiple keys loaded? ISTR hitting this when I had a large
number of different keys and it would hit a limit trying them. In my
~/.ssh/config I have this:

HOST *.fedoraproject.org fedorapeople.org *.fedorahosted.org fedorahosted.org
IdentityFile ~/.ssh/fedora

to force it to use the right key on the 1st try.

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted
___
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 1711066] New: perl-Net-HTTP-6.19 is available

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

Bug ID: 1711066
   Summary: perl-Net-HTTP-6.19 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-HTTP
  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: 6.19
Current version/release in rawhide: 6.18-4.fc30
URL: http://search.cpan.org/dist/Net-HTTP/

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

-- 
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 1710529] perl-re-engine-PCRE2-0.16 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-re-engine-PCRE2-0.16-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-633578dacc

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

[389-devel] Re: Logging future direction and ideas.

2019-05-16 Thread William Brown



> On 17 May 2019, at 00:16, Ludwig Krispenz  wrote:
> 
> 
> On 05/16/2019 02:56 AM, William Brown wrote:
>> Replying to both Simon and Ludwig in the one mail ...
>> 
>> To just comment to one point from Ludwig:
>> 
>>> This may sound too negative, I agree that logging deserves attention and 
>>> improvement, but we need to agree on what we want to achieve.
>> I don't think this is negative, at all and I think it's exactly the kind of 
>> feedback I wanted. :) So thank you!
>> 
>> 
>>> Hi William,
>>> I am more than interested!
>>> 
>>> I'd like to learn it one day anyway.
>>> So if there will be no objections and we'll go forward now,
>>> I think, it is important to agree on some points of decreasing a bus factor:
>>> 
>>> - As you said, it should have very detailed comments on all of the
>>>  language features and technics you'll use.
>>> - I think it will be nice to have an additional documentation which will
>>>  describe the basic setup for the development you use. All the toold you
>>>  need to develop, compile, test and debug.
>>> - Also, some nice links for the basic tutorials on Rust types, concepts, 
>>> etc.
>>> - I think, we should have detailed unit tests. It will help to
>>>  understand the code better and we will have less bugs (hopefully).
>> So I'm writing a document for the wiki to cover this *and* rust supports 
>> tests as part of the system - that will be all be included. Is that 
>> acceptable?
>> 
>>> And the final and big point I wanted to mention:
>>> 
>>> - We should be prepared for a slow review process because we have quite 
>>> limited
>>>  recources in the team and a lot of work should be done (WebUI still has to 
>>> be refactored to React,
>>>  and it is only a small piece of the workload).
>>>  Also, I think, it makes sense to have the smallest Rust PRs that can be 
>>> put together as an independent unit.
>> That's totally reasonable. I'll try to keep it to small parts and will build 
>> up as we go. See below for ideas on how I'll work toward this.
>> 
>>> But everything is just my opinion and I don't know what others think and
>>> if everyone is prepared to join it. I am feeling excited though :)
>>> 
>>> Thanks,
>>> Simon
>>> 
>>> P.S. check the contribution guide please. Espesially a part about
>>> 'rebase-force-push'. I think it is nice not to force push during
>>> the review process (and rebase-squash only after you got an ACK).
>> Yep, I saw this change. I'll keep it in mind :)
>> 
>> 
>>> On 15 May 2019, at 19:37, Ludwig  wrote:
>>> 
>>> Hi William,
>>> 
>>> this is a good starting point to discuss and decide how to move forward 
>>> with logging (although it looks like you are already some steps ahead).
>>> 
>>> I have no strong ties to existing logging format and if we do it in rust or 
>>> not I don't care, but I do not want to use existing functionality for the 
>>> sake af a new unified approach.
>>> 
>>> First we need to define what is the purpose and usage of our logs, what do 
>>> we want to keep or extend. I see these main area:
>>> 
>>> - statistics
>>> 
>>> - auditing (authentications, modifications)
>>> 
>>> . debugging (for my usage the most important aspect)
>>> 
>>> Next: what are the real problems
>>> 
>>> - performance: yes, it would be nice to have less logging impact on 
>>> performance, but I haven't seen real complaints and doing it differently 
>>> does not guarantee better performance, we have debug levels (like tracing) 
>>> which are not usable because they slow down everything, I do not think this 
>>> will be resolved by just replacing the library
>>> 
>>> - information:  we continue to add information to the logs, and there are 
>>> still open requests
>>> 
>>> 
>>> So: If I look at your suggestions I do like some and have concerns with 
>>> others, and I am not sure if the priorities are right.
>>> 
>>> You list a couple of tickets related to logging, but forgot others, eg:
>>> 
>>> https://pagure.io/389-ds-base/issue/47822 - improve logging of ACL decisions
>>> 
>>> https://pagure.io/389-ds-base/issue/48680 - enable logging for 3rd party 
>>> libs
>>> 
>>> https://pagure.io/389-ds-base/issue/50002 - improve password policy logging
>>> 
>>> https://pagure.io/389-ds-base/issue/50187 - improve replication logging
>> These are all things that you you are correct, that I missed.
>> 
>> So I want to focus on your point about what we want from logs, IE stats, 
>> auditing, debugging. I think this is a great summary of what we want, but to 
>> make it more detailed:
>> 
>> * Stats about operations from start to finish
>> * Auditing of client operations
>> * Debugging of client operations
>> * Debugging of internal server machinery and state
>> * Reporting of errors outside of the normal operation system.
>> 
>> Today we current have:
>> 
>> access - auditing of operations at a highlevel
>> audit - auditing of modifications and writes
>> error - debugging of internal server machinery (we tend not to enable the 
>> levels of debugging

[389-devel] Re: Advice on a memory issue

2019-05-16 Thread William Brown



> On 16 May 2019, at 17:18, thierry bordaz  wrote:
> 
> Hi William,
> 
> It looks to me that attr_syntax_create overwrite the allocated asi with one 
> it allocates itself based on provided params.
> In short I think attr_syntax_creates allocates for you the syntaxinfo, you do 
> not need to provide one.
> 

Ah how did I miss this!!! I was staring attr_syntax_create for most of the 
morning yesterday! 

Anyway, thank you, I have fixed that up - back to writing tests now ... 

> best regards
> thierry
> On 5/16/19 8:17 AM, William Brown wrote:
>> https://pagure.io/389-ds-base/pull-request/50379
>> 
>> 
>> This code is not yet ready to be merged. I'm currently having a problem with 
>> freeing the attrsyntaxinfo struct as part of the test.
>> 
>> If the code is as is I get:
>> 
>> 
>> =
>> ==98363==ERROR: LeakSanitizer: detected memory leaks
>> 
>> Direct leak of 160 byte(s) in 1 object(s) allocated from:
>> #0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
>> #1 0x7fbc40a34be6 in slapi_ch_calloc 
>> /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
>> #2 0x40499c in attr_syntax_add_from_name 
>> /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
>> #3 0x404b22 in test_libslapd_schema_filter_validate_simple 
>> /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:56
>> #4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)
>> 
>> Objects leaked above:
>> 0x60e00d60 (160 bytes)
>> 
>> Direct leak of 160 byte(s) in 1 object(s) allocated from:
>> #0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
>> #1 0x7fbc40a34be6 in slapi_ch_calloc 
>> /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
>> #2 0x40499c in attr_syntax_add_from_name 
>> /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
>> #3 0x404b0f in test_libslapd_schema_filter_validate_simple 
>> /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:55
>> #4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)
>> 
>> Objects leaked above:
>> 0x60e00ba0 (160 bytes)
>> 
>> SUMMARY: AddressSanitizer: 320 byte(s) leaked in 2 allocation(s).
>> 
>> However, if I free *a and *b, with attr_syntax_free, or slapi_ch_free, I get 
>> a double free error. The size of 160 bytes correlates to the sizeof(struct 
>> attrsyntaxinfo) but looking in gdb during attr_syntax_delete, the 
>> attr_syntax_free is called on asi as provided.
>> 
>> So I'm not 100% sure what's going wrong here, but I'm not thoroughly 
>> experienced in this part of the code, so feedback would be really helpful 
>> about this resource issue.
>> 
>> Thanks! 
>> 
>> —
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 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
> 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
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

[Bug 1711098] New: Segmentation Fault in UUlib.so (ScanData) used in perl-Convert-UUlib

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

Bug ID: 1711098
   Summary: Segmentation Fault in UUlib.so (ScanData) used in
perl-Convert-UUlib
   Product: Fedora EPEL
   Version: epel7
  Hardware: x86_64
OS: Linux
Status: NEW
 Component: perl-Convert-UUlib
  Severity: medium
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: ndu...@jadeworld.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
  Target Milestone: ---
Classification: Fedora



Description of problem:

When processing certain text, a segmentation fault is generated in the ScanData
method in UUlib.so.

Version-Release number of selected component (if applicable):

perl-Convert-UUlib-1.5-1.el7.x86_64

How reproducible:

Always

Steps to Reproduce:
1. The following Perl script uses UUlib to read files and process them.

-- >8 cut here --
use Convert::UUlib ':all';

LoadFile 'badfile'; 
-- >8 cut here --

2. The following input file, when passed to the above Perl, causes the
Segmentation Fault. Save this text to a file named "badfile".

-- >8 cut here --
a

a

Content-Type: text/plain
-- >8 cut here --

This is a hexdump of badfile to show the bytes.

$ hexdump -C badfile
  61 0a 0a 61 0a 0a 43 6f  6e 74 65 6e 74 2d 54 79  |a..a..Content-Ty|
0010  70 65 3a 20 74 65 78 74  2f 70 6c 61 69 6e 0a |pe: text/plain.|
001f

$ wc badfile
 5  4 31 badfile

3. With the Perl code saved in foo.pl and the text from step 2 saved in a file
named badfile, run:

$ perl foo.pl
Segmentation fault

Actual results:
Segmentation fault.

Expected results:
Library should read text and either produce an error if badly formed, otherwise
it should decode it.

Additional info:

This is what I see in gdb.

$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.6 (Maipo)

$ gdb perl
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/perl...Reading symbols from
/usr/lib/debug/usr/bin/perl.debug...done.
done.
(gdb) run foo.pl
Starting program: /usr/bin/perl foo.pl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7fffefdb6972 in ScanData (datei=datei@entry=0x62a3c0,
errcode=errcode@entry=0x7fffdf78, 
boundary=boundary@entry=0x0, ismime=,
checkheaders=checkheaders@entry=1, 
result=result@entry=0x626c50, fname=0x6284e0 "badfile") at uuscan.c:821
821   while (!isspace (*p2) && *p2 != ';') p2++;

(gdb) print p2
$1 = 0x77f41c0d "text/plain"

(gdb) list
816   break;
817 }
818 if ((ptr = strchr (line, ':')) != NULL) {
819   ptr++;
820   while (isspace (*ptr)) ptr++; p2 = ptr;
821   while (!isspace (*p2) && *p2 != ';') p2++;
822   c = *p2; *p2 = '\0';
823   if (p2 != ptr) {
824 _FP_free (result->mimetype);
825 result->mimetype = _FP_strdup (ptr);

(gdb) bt
#0  0x7fffefdb6972 in ScanData (datei=datei@entry=0x62a3c0,
errcode=errcode@entry=0x7fffdf78, 
boundary=boundary@entry=0x0, ismime=,
checkheaders=checkheaders@entry=1, 
result=result@entry=0x626c50, fname=0x6284e0 "badfile") at uuscan.c:821
#1  0x7fffefdb878c in ScanPart (datei=datei@entry=0x62a3c0,
fname=fname@entry=0x6284e0 "badfile", 
errcode=errcode@entry=0x7fffdf78) at uuscan.c:3141
#2  0x7fffefda848a in UULoadFileWithPartNo
(filename=filename@entry=0x6284e0 "badfile", 
fileid=0x6284e0 "badfile", fileid@entry=0x0, delflag=delflag@entry=0,
partno=partno@entry=-1, 
partcount=partcount@entry=0x7fffe074) at uulib.c:790
#3  0x7fffefda5181 in XS_Convert__UUlib_LoadFile (my_perl=,
cv=)
at UUlib.xs:382
#4  0x77b0941f in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2778
#5  0x77b01b96 in Perl_runops_standard (my_perl=0x603010) at run.c:41
#6  0x77a9e985 in S_run_body (oldscope=,
my_perl=) at perl.c:2402
#7  perl_run (my_perl=0x603010) at perl.c:2320
#8  0x00400ce9 in main (argc=3, argv=0x7fffe398,
env=0x7fffe3b8) at perlmain.c:120

This bug is causing problems with Amavis for us because Amavis uses
perl-Convert-UUlib to decode some mime attachments, and one of them is now
causing

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

2019-05-16 Thread Chris Adams

Once upon a time, Stephen John Smoogen  said:
> RHEL-8 was built with various packages which are not shipped in
> BaseOS/AppStream/CRB. Some like screen are in the buildroot for the
> packages which depend on them but were decided not to be shipped.

Huh, that's... weird.  As someone that's been using screen for, hmm,
longer than Red Hat's been in business I think... that's annoying.

I guess the CentOS side would be the more appropriate place to ask, but
would it be practical to gather up these packages and make a CentOS
"module" of them?  Sorry if that doesn't make sense (like I said, still
trying to get my head around modularity).

-- 
Chris Adams 
___
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

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

2019-05-16 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c1577dae55   
singularity-3.1.1-1.1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2f5f6c5ba9   
libmediainfo-19.04-1.el6 mediainfo-19.04-1.el6


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

drupal7-7.67-1.el6
munin-2.0.49-1.el6
php-theseer-autoload-1.25.6-1.el6

Details about builds:



 drupal7-7.67-1.el6 (FEDORA-EPEL-2019-612bab5fc3)
 An open-source content-management platform

Update Information:

- https://www.drupal.org/project/drupal/releases/7.67 - [SA-
CORE-2019-007](https://www.drupal.org/SA-CORE-2019-007)
([CVE-2019-11831](https://nvd.nist.gov/vuln/detail/CVE-2019-11831))

ChangeLog:

* Wed May 15 2019 Shawn Iwinski  - 7.67-1
- Update to 7.67 (RHBZ #1707958, #1708649, #1708652, #1708653)
- https://www.drupal.org/SA-CORE-2019-007 (CVE-2019-11831)

References:

  [ 1 ] Bug #1707958 - drupal7-7.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1707958




 munin-2.0.49-1.el6 (FEDORA-EPEL-2019-2ea97da4a2)
 Network-wide resource monitoring tool

Update Information:

Upstream update for 2.0.49. Includes bugfixes for example for graph zoom urls
and TLS config.

ChangeLog:

* Thu May 16 2019 Kim B. Heino  - 2.0.49-1
- Upgrade to 2.0.49
* Mon Mar 18 2019 Kim B. Heino  - 2.0.45-2
- Drop munin-plugins-java subpackage

References:

  [ 1 ] Bug #1710596 - TLS config is not configurable per-node
https://bugzilla.redhat.com/show_bug.cgi?id=1710596




 php-theseer-autoload-1.25.6-1.el6 (FEDORA-EPEL-2019-953ff25e9c)
 A tool and library to generate autoload code

Update Information:

**Release 1.25.6**  * Fix: Add `lib-` prefixed dependencies in composer.json to
ignore list

ChangeLog:

* Thu May 16 2019 Remi Collet  - 1.25.6-1
- update to 1.25.6


___
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 1710529] perl-re-engine-PCRE2-0.16 is available

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



--- Comment #5 from Fedora Update System  ---
perl-re-engine-PCRE2-0.16-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-31203b5866

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

[389-devel] Advice on a memory issue

2019-05-16 Thread William Brown

https://pagure.io/389-ds-base/pull-request/50379

This code is not yet ready to be merged. I'm currently having a problem with 
freeing the attrsyntaxinfo struct as part of the test.

If the code is as is I get:


=
==98363==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
#1 0x7fbc40a34be6 in slapi_ch_calloc 
/home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
#2 0x40499c in attr_syntax_add_from_name 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
#3 0x404b22 in test_libslapd_schema_filter_validate_simple 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:56
#4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)

Objects leaked above:
0x60e00d60 (160 bytes)

Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
#1 0x7fbc40a34be6 in slapi_ch_calloc 
/home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
#2 0x40499c in attr_syntax_add_from_name 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
#3 0x404b0f in test_libslapd_schema_filter_validate_simple 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:55
#4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)

Objects leaked above:
0x60e00ba0 (160 bytes)

SUMMARY: AddressSanitizer: 320 byte(s) leaked in 2 allocation(s).

However, if I free *a and *b, with attr_syntax_free, or slapi_ch_free, I get a 
double free error. The size of 160 bytes correlates to the sizeof(struct 
attrsyntaxinfo) but looking in gdb during attr_syntax_delete, the 
attr_syntax_free is called on asi as provided.

So I'm not 100% sure what's going wrong here, but I'm not thoroughly 
experienced in this part of the code, so feedback would be really helpful about 
this resource issue.

Thanks! 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
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

[Bug 1710529] perl-re-engine-PCRE2-0.16 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-re-engine-PCRE2-0.16-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c2de15beff

-- 
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 1710529] perl-re-engine-PCRE2-0.16 is available

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



--- Comment #3 from Fedora Update System  ---
perl-re-engine-PCRE2-0.16-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-633578dacc

-- 
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 1710529] perl-re-engine-PCRE2-0.16 is available

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



--- Comment #2 from Fedora Update System  ---
perl-re-engine-PCRE2-0.16-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-31203b5866

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

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

2019-05-16 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 275  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  83  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2   
tor-0.3.5.8-1.el7
  51  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
  43  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd   
afflib-3.7.18-2.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04c7455f6a   
singularity-3.1.1-1.1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d44655ca3   
mediaconch-18.03.2-7.el7 libmediainfo-19.04-1.el7 mediainfo-19.04-1.el7


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

dist-git-1.11-1.el7
drupal7-7.67-1.el7
libuv-1.29.0-1.el7
munin-2.0.49-1.el7
php-theseer-autoload-1.25.6-1.el7
rust-1.34.2-1.el7

Details about builds:



 dist-git-1.11-1.el7 (FEDORA-EPEL-2019-48c9e4991f)
 Package source version control system

Update Information:

- remove python3-configparser require - move scripts to bindir    - python3
support - fix for empty webhook dir

ChangeLog:

* Tue Apr 30 2019 clime  1.11-1
- remove python3-configparser require
- move scripts to bindir
* Mon Mar 11 2019 clime  1.10-1
- python3 support
- fix post-receive hook in case post.receive.d is empty




 drupal7-7.67-1.el7 (FEDORA-EPEL-2019-1605b73a09)
 An open-source content-management platform

Update Information:

- https://www.drupal.org/project/drupal/releases/7.67 - [SA-
CORE-2019-007](https://www.drupal.org/SA-CORE-2019-007)
([CVE-2019-11831](https://nvd.nist.gov/vuln/detail/CVE-2019-11831))

ChangeLog:

* Wed May 15 2019 Shawn Iwinski  - 7.67-1
- Update to 7.67 (RHBZ #1707958, #1708649, #1708652, #1708653)
- https://www.drupal.org/SA-CORE-2019-007 (CVE-2019-11831)

References:

  [ 1 ] Bug #1707958 - drupal7-7.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1707958




 libuv-1.29.0-1.el7 (FEDORA-EPEL-2019-69f42e0b0d)
 Platform layer for node.js

Update Information:

Update to libuv 1.29.0    Fix regression causing segmentation faults

ChangeLog:

* Wed May 15 2019 Stephen Gallagher  - 1.29.0-1
- Update to 1.29.0
- Drop upstreamed patch
* Fri May  3 2019 Stephen Gallagher  - 1.28.0-2
- Fix regression in uv_fs_poll_stop() (BZ 1703935)
* Tue Apr 23 2019 Stephen Gallagher  - 1.28.0-1
- Update to libuv 1.28.0
- https://github.com/libuv/libuv/blob/v1.28.0/ChangeLog

References:

  [ 1 ] Bug #1700033 - libuv-1.29.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1700033
  [ 2 ] Bug #1703935 - assertion failure since 1.27.0
https://bugzilla.redhat.com/show_bug.cgi?id=1703935




 munin-2.0.49-1.el7 (FEDORA-EPEL-2019-4067ba7c92)
 Network-wide resource monitoring tool

Update Information:

Upstream update for 2.0.49. Includes bugfixes for example for graph zoom urls
and TLS config.

ChangeLog:

* Thu May 16 2019 Kim B. Heino  - 2.0.49-1
- Upgrade to 2.0.49
* Mon Mar 18 2019 Kim B. Heino  - 2.0.45-2
- Drop munin-plugins-java subpackage

References:

  [ 1 ] Bug #1710596 - TLS config is not configurable per-node
https://bugzilla.redhat.com/show_bug.cgi?id=1710596

Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

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

== Summary ==
The upstream OpenSSH disabled password logins for root back in 2015.
The Fedora should follow to keep security expectation and avoid users
surprises with this configuration.

== Owner ==
* Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
* Email: jje...@redhat.com

== Detailed Description ==

The OpenSSH server configuration contains a configuration option
`PermitRootLogin`, which controls whether the root user is allowed to
login using passwords or using public key authentication. The root
login is target of most of the random or targeted attack on Linux
systems and password is usually the weakest part. For that reason, the
upstream OpenSSH changed this option in 2015 to `prohibit-password`,
which still allows public-key authentication, but prevents the
password logins. Fedora was for many practical reasons keeping the old
configuration since then, but the difference is no longer bearable and
might confuse users expecting the root logins will not be enabled out
of the box.

On the other hand, there is still a lot of infrastructure, installers
and test instances that simply might depend on this configuration and
therefore this change needs to go through the system-wide change so
everyone is onboard.

== Benefit to Fedora ==

This will provide more secure Fedora installations out of the box and
prevent inadvertently accessible root logins in the wild.

== Scope ==
* Proposal owners: Modify the default shipped sshd configuration in
`sshd_config` to no longer include the `PermitRootLogin yes` option
and advertise this change throughout Fedora.
* Other developers: Make sure their workflow does not include logging
in as a root to ssh, otherwise modify that workflow
* Release engineering: [https://pagure.io/releng/issues/8342]

* Policies and guidelines: none
* Trademark approval: none

== Upgrade/compatibility impact ==
The updates of previously-modified `sshd_config` will not be affected
and create a `.rpmnew` configuration file.

The updates of default `sshd_config` will be updated and the
modification needs to be listed in release notes to prevent surprises.

== How To Test ==

* Make sure you have root user with password and you can login to this
user using `su`
* Make sure the sshd_config does not contain `PermitRootLogin yes` option
* Restart sshd service: `systemctl restart sshd`
* Try to connect to root user: `ssh
-oPreferredAuthentications=password root@localhost`
* Should fail

Other authentication methods (publickey, gssapi should not be affected)

== User Experience ==
Nothing in production should really depend on root password logins in
2019. If it does, it is the time to change that (or explicitly allow
it on the affected systems).

== Dependencies ==
Installer and kickstarts depending on this functionality.

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?) Maintainer
will revert the change to sshd_config if needed.
* Contingency deadline: Beta freeze
* Blocks release? no
* Blocks product? no

== Documentation ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.

Upstream release notes: http://www.openssh.com/txt/release-7.0

== Release Notes ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora 31 System-Wide Change proposal: perl 5.30

https://fedoraproject.org/wiki/Changes/perl5.30

== Summary ==
A new ''perl 5.30'' version brings a lot of changes done over a year
of development. Perl 5.30 should be released at the end of May 2019.
See [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta] for more details about preparing release.

== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]]
* Email: 
* Name: [[User:Ppisar| Petr Písař]]
* Email: 

=== Completed Items ===

=== Items in Progress ===

=== Items to Be Done ===

* Upstream to release Perl 5.30
* Get dedicated  build-root from rel-engs (''f31-perl'')
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.30.0
* Build new perl 5.30 keeping old COMPAT Provides
* Rebuild dual-lived packages (otherwise dnf recommends --skip-broken and fails)
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Remove old perl(:MODULE_COMPAT_5.28.*) from perl
* Undefine perl_bootstrap
* Rebuild other packages: Use Fedora::Rebuild dependency solver
* Rebuild packages having perl_bootstrap condition in spec file
* Rebuild all updated packages
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f31'' build root
* Rebuilt Perl packages: 0 of 3186 done (0.00 %)
* Failed builds (0):
* Unsatisfied dependencies (0):

== Detailed Description ==

New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.30.0 version is stable release
this year.

In addition, Perl ''site'' paths will be made ABI-specific. CPAN
modules intended for an installation under /usr/local/ will be
installed to /usr/local/{share,lib*}/perl5/5.30 paths. This will
prevent from breaking Perl with old locally installed modules after a
Fedora upgrade.

== Benefit to Fedora ==

Up-to-date and latest perl release will be delivered to Fedora users.

== Scope ==

Every Perl package will be rebuilt in a dedicated ''f31-perl''
build-root against perl 5.30.0 and then if no major problem emerges
the packages will be merged back to ''f31'' build-root.

* Proposal owners:
New perl and all packages requiring perl or a Perl module will be
rebuilt into ''f31-perl'' build-root.

* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.

* Release engineering: [https://pagure.io/releng/issue/8368 #8368] (a
check of an impact with Release Engineering is needed)
Release engineers will be asked for new ''f31-perl'' build-root
inheriting from ''f31'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f31-perl'' packages back to
''f31'' build-root.

* Policies and guidelines:
No policies have to be modified to complete this change.

== Upgrade/Compatibility Impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.30 will be removed from the
distribution. That will require to remove those packages from existing
systems otherwise package manager will encounter unsatisfied
dependencies. Modules installed locally into /usr/local will become
unavailable and users will need to reinstall them.

== How to Test ==
Try upgrading from Fedora 30 to 31. Try some Perl application to
verify they work as expected. Try embedded perl in slapd or snmpd.

== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstalation.

== Dependencies ==
There is more than 3100 packages depending on perl. Most of them are
expected not to break. Finishing this change can be endangered only by
critical changes in a toolchain.

== Contingency Plan ==
If we find perl 5.30 is not suitable for Fedora 31, we will revert
back to perl 5.28 and we drop the temporary build-root with already
rebuilt packages.

* Contingency deadline: branching Fedora 31 from Rawhide.
* Blocks release? No.

== Documentation ==
* [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta]
* An announcement on the perl-devel mailing list
* 
[https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/thread/YLWW33T7C4LTQY5XQ6E6PXOZUGYTP27M/
Making Perl site paths ABI-specific] discussion on perl-devel mailing
list

== Release Notes ==
=== Important Changes ===
* Unicode 11, 12 and draft 12.1 is supported
* The upper limit "n" specifiable in a regular expression quantifier
of the form "{m,n}" has been doubled to 65534
* Wildcards in Unicode property value specifications are now partially supported
* qr'\N{name}' is now supported
* It is now possible to compile perl to always use thread-safe locale
operations.
* Limited variable length lookbehind in regular expression pattern
matching is now experimentally supported
* Use faster

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

NOTICE: I have been informed that various parts of the document have major
errors. I will be updating and fixing today. Problems include the
mentioning various javapackages which were shipped and not spelling out
that one of the differences between internal and external is usra-major

On Wed, 15 May 2019 at 18:06, Stephen John Smoogen  wrote:

>
> In trying to get resources allocated, I have been working on the project
> plans for 8. The original one was at
> https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
>
> As of today an updated one is at
>
> https://smooge.fedorapeople.org/EPEL-8/
>
> which I will translate to wiki for better editing this weekend. However
> the core items I am currently working on
>
> 1. https://smooge.fedorapeople.org/EPEL-8/EPEL-8-known-package-list.txt 
> contains
> a list of packages I know we can't rebuild  (because they will be in
> CentOS/RHEL-8 and a list of packages I know will build with our first
> attempt at EPEL-8
>
> 2. I am currently working on patches for
> https://github.com/puiterwijk/grobisplitter so that I can get it to work
> with how Red Hat publishes its packages. I am also working on it just
> breaking out default modules.
>
> 3. I have discovered that modules which have no default channel should not
> be used to build non-modular packages against. There are 6 modules set up
> this way
> ( 389-ds, libselinux-python, mod_auth_openidc, parfait, pki-core, pki-deps
> ) and so the packages in them will not be available to build against. Even
> after we have some ursa-* solution in place, packages requiring them must
> be part of a module.
>
>
>
>
>
> --
> Stephen J Smoogen.
>
>

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

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

2019-05-16 Thread Chris Adams

So, I don't have a handle on the whole modularity thing... still trying
to understand what's what with that.  But this caught my eye in your
"Open Questions":

- Some normally leaf packages like screen are inside of the Red Hat
  hidden buildroot package set. Having them built in EPEL is likely to
  cause conflicts on user systems and divergence with RHEL. EPEL
  maintains agreed upon policies for these cases so using the repo
  doesn’t cause pain for RHEL customers or users.

What does that actually mean?  I'm a consumer of CentOS rather than RHEL
these days, so I haven't really dug into version 8 yet.  I do use screen
a lot, so what does "inside of the Red Hat hidden buildroot package set"
mean for me?

-- 
Chris Adams 
___
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

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

2019-05-16 Thread Dan Horák

On Wed, 15 May 2019 18:06:21 -0400
Stephen John Smoogen  wrote:

> In trying to get resources allocated, I have been working on the
> project plans for 8. The original one was at
> https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
> 
> As of today an updated one is at
> 
> https://smooge.fedorapeople.org/EPEL-8/

is there a plan to start EPEL-8 with all arches supported by RHEL-8? So
s390x will be also included? We never bootstrapped EPEL-7 for s390x, but
it wasn't a blocker because there is a rebuild available from the ClefOS
people (they do a CentOS rebuild for s390x). We are registering
questions about availability of EPEL for s390x quite regularly.

Thanks

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

[389-devel] Re: Logging future direction and ideas.

2019-05-16 Thread Ludwig Krispenz

On 05/16/2019 02:56 AM, William Brown wrote:

Replying to both Simon and Ludwig in the one mail ...

To just comment to one point from Ludwig:

This may sound too negative, I agree that logging deserves attention and
improvement, but we need to agree on what we want to achieve.

I don't think this is negative, at all and I think it's exactly the kind of
feedback I wanted. :) So thank you!

Hi William,
I am more than interested!

I'd like to learn it one day anyway.
So if there will be no objections and we'll go forward now,
I think, it is important to agree on some points of decreasing a bus factor:

- As you said, it should have very detailed comments on all of the
language features and technics you'll use.
- I think it will be nice to have an additional documentation which will
describe the basic setup for the development you use. All the toold you
need to develop, compile, test and debug.
- Also, some nice links for the basic tutorials on Rust types, concepts, etc.
- I think, we should have detailed unit tests. It will help to
understand the code better and we will have less bugs (hopefully).

So I'm writing a document for the wiki to cover this *and* rust supports tests
as part of the system - that will be all be included. Is that acceptable?

And the final and big point I wanted to mention:

- We should be prepared for a slow review process because we have quite limited
recources in the team and a lot of work should be done (WebUI still has to be
refactored to React,
and it is only a small piece of the workload).
Also, I think, it makes sense to have the smallest Rust PRs that can be put
together as an independent unit.

That's totally reasonable. I'll try to keep it to small parts and will build up
as we go. See below for ideas on how I'll work toward this.

But everything is just my opinion and I don't know what others think and
if everyone is prepared to join it. I am feeling excited though :)

Thanks,
Simon

P.S. check the contribution guide please. Espesially a part about
'rebase-force-push'. I think it is nice not to force push during
the review process (and rebase-squash only after you got an ACK).

Yep, I saw this change. I'll keep it in mind :)

On 15 May 2019, at 19:37, Ludwig wrote:

Hi William,

this is a good starting point to discuss and decide how to move forward with
logging (although it looks like you are already some steps ahead).

I have no strong ties to existing logging format and if we do it in rust or not
I don't care, but I do not want to use existing functionality for the sake af a
new unified approach.

First we need to define what is the purpose and usage of our logs, what do we
want to keep or extend. I see these main area:

- statistics

- auditing (authentications, modifications)

. debugging (for my usage the most important aspect)

Next: what are the real problems

- performance: yes, it would be nice to have less logging impact on
performance, but I haven't seen real complaints and doing it differently does
not guarantee better performance, we have debug levels (like tracing) which are
not usable because they slow down everything, I do not think this will be
resolved by just replacing the library

- information: we continue to add information to the logs, and there are still
open requests

So: If I look at your suggestions I do like some and have concerns with others,
and I am not sure if the priorities are right.

You list a couple of tickets related to logging, but forgot others, eg:

https://pagure.io/389-ds-base/issue/47822 - improve logging of ACL decisions

https://pagure.io/389-ds-base/issue/48680 - enable logging for 3rd party libs

https://pagure.io/389-ds-base/issue/50002 - improve password policy logging

https://pagure.io/389-ds-base/issue/50187 - improve replication logging

These are all things that you you are correct, that I missed.

So I want to focus on your point about what we want from logs, IE stats,
auditing, debugging. I think this is a great summary of what we want, but to
make it more detailed:

* Stats about operations from start to finish
* Auditing of client operations
* Debugging of client operations
* Debugging of internal server machinery and state
* Reporting of errors outside of the normal operation system.

Today we current have:

access - auditing of operations at a highlevel
audit - auditing of modifications and writes
error - debugging of internal server machinery (we tend not to enable the
levels of debugging operations ...)

So I think there is room to improve.

Now I think that performance so far is only a barrier in terms of preventing us from
adding more detail, because it slows down operations. This is why it's pretty high on the
list of "to fix".

these requests for improvements of logging exist for quite some time, they were accepted as useful
and good to have, but we didn't have the capacity to work on them. The work is tedious, going thru
ACL or replication code and

[389-devel] Re: Advice on a memory issue

2019-05-16 Thread thierry bordaz


Hi William,

|It looks to me that attr_syntax_create overwrite the allocated asi with 
one it allocates itself based on provided params.
In short I think attr_syntax_creates allocates for you the syntaxinfo, 
you do not need to provide one.


best regards
thierry
|
On 5/16/19 8:17 AM, William Brown wrote:

https://pagure.io/389-ds-base/pull-request/50379

This code is not yet ready to be merged. I'm currently having a problem with 
freeing the attrsyntaxinfo struct as part of the test.

If the code is as is I get:


=
==98363==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 160 byte(s) in 1 object(s) allocated from:
 #0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
 #1 0x7fbc40a34be6 in slapi_ch_calloc 
/home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
 #2 0x40499c in attr_syntax_add_from_name 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
 #3 0x404b22 in test_libslapd_schema_filter_validate_simple 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:56
 #4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)

Objects leaked above:
0x60e00d60 (160 bytes)

Direct leak of 160 byte(s) in 1 object(s) allocated from:
 #0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
 #1 0x7fbc40a34be6 in slapi_ch_calloc 
/home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
 #2 0x40499c in attr_syntax_add_from_name 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
 #3 0x404b0f in test_libslapd_schema_filter_validate_simple 
/home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:55
 #4 0x7fbc40d340d8  (/usr/lib64/libcmocka.so.0+0x50d8)

Objects leaked above:
0x60e00ba0 (160 bytes)

SUMMARY: AddressSanitizer: 320 byte(s) leaked in 2 allocation(s).

However, if I free *a and *b, with attr_syntax_free, or slapi_ch_free, I get a 
double free error. The size of 160 bytes correlates to the sizeof(struct 
attrsyntaxinfo) but looking in gdb during attr_syntax_delete, the 
attr_syntax_free is called on asi as provided.

So I'm not 100% sure what's going wrong here, but I'm not thoroughly 
experienced in this part of the code, so feedback would be really helpful about 
this resource issue.

Thanks!

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
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


___
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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

On Thu, 16 May 2019 at 09:59, Chris Adams  wrote:

> So, I don't have a handle on the whole modularity thing... still trying
> to understand what's what with that.  But this caught my eye in your
> "Open Questions":
>
> - Some normally leaf packages like screen are inside of the Red Hat
>   hidden buildroot package set. Having them built in EPEL is likely to
>   cause conflicts on user systems and divergence with RHEL. EPEL
>   maintains agreed upon policies for these cases so using the repo
>   doesn’t cause pain for RHEL customers or users.
>
> What does that actually mean?  I'm a consumer of CentOS rather than RHEL
> these days, so I haven't really dug into version 8 yet.  I do use screen
> a lot, so what does "inside of the Red Hat hidden buildroot package set"
> mean for me?
>
>
RHEL-8 was built with various packages which are not shipped in
BaseOS/AppStream/CRB. Some like screen are in the buildroot for the
packages which depend on them but were decided not to be shipped. Thus they
are hidden buildroot set. They were however branched to CentOS git
repository. While building a newer version of screen and putting it in EPEL
might not break anything, other packages might cause problems which we
don't have the resources to track down and debug. So I would like to not
have EPEL rebuild any package which was branched to CentOS EL-8.

I will clarify the document.



> --
> Chris Adams 
> ___
> 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

[Bug 1710933] New: Invalid DocumentLocator object passed to

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

Bug ID: 1710933
   Summary: Invalid DocumentLocator object passed to
   Product: Fedora
   Version: 30
  Hardware: x86_64
OS: Linux
Status: NEW
 Component: perl-XML-SAX
  Assignee: jples...@redhat.com
  Reporter: bug.report.trac...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com,
john.j5l...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Created attachment 1569596
  --> https://bugzilla.redhat.com/attachment.cgi?id=1569596=edit
perl XML::SAX::DocumentLocator test

Description of problem:
When parsing XLM data, set_document_locator is passed an empty hash instead of
DocumentLocator object.

Version-Release number of selected component (if applicable):
perl-XML-SAX-Base-1.09-7.fc30.noarch
perl-XML-SAX-1.00-4.fc30.noarch

How reproducible:
Always


Steps to Reproduce:
1. Run the attached test.


Actual results:
Test prints: $VAR2 = {};

Expected results:
A valid DocumentLocator object printed:
$VAR2 = bless( {
 'ColumnNumber' => 0,
 'Encoding' => undef,
 'XMLVersion' => undef,
 'LineNumber' => 1,
 'SystemId' => undef,
 'PublicId' => undef
   }, 'XML::SAX::DocumentLocator' );

Additional info:
Test works on https://f.perl.bot/

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

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)