date:20190408

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-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-1a060feb93

-- 
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 1696928] perl-Locale-SubCountry-2.05 is available

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



--- Comment #7 from Fedora Update System  ---
perl-Locale-SubCountry-2.05-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-6960dff6b1

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

2019-04-08 Thread nils

Dear all,

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

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

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

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



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

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

[Bug 1696928] perl-Locale-SubCountry-2.05 is available

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



--- Comment #6 from Fedora Update System  ---
perl-Locale-SubCountry-2.05-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-23c6655da7

-- 
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 1696882] perl-CPAN-Perl-Releases-3.94 is available

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-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-4e6d9989e7

-- 
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] 389 DS nightly 2019-04-09 - 92% PASS

2019-04-08 Thread vashirov

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

[Bug 1679590] perl-File-Edit-Portable-1.24-9.fc30 FTBFS: files are not named in the MANIFEST file: /builddir/build/BUILD/File-Edit-Portable-1.24/debugfiles.list

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-File-Edit-Portable-1.2 |perl-File-Edit-Portable-1.2
   |4-10.fc30   |4-10.fc30
   ||perl-File-Edit-Portable-1.2
   ||4-10.fc29



--- Comment #8 from Fedora Update System  ---
perl-File-Edit-Portable-1.24-10.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1688648] Upgrade perl-DBIx-RunSQL to 0.21

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBIx-RunSQL-0.21-1.fc3 |perl-DBIx-RunSQL-0.21-1.fc3
   |0   |0
   ||perl-DBIx-RunSQL-0.21-1.fc2
   ||9



--- Comment #6 from Fedora Update System  ---
perl-DBIx-RunSQL-0.21-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1679592] perl-Mock-Sub-1.09-5.fc30 FTBFS: files are not named in the MANIFEST file: /builddir/build/BUILD/Mock-Sub-1.09/debugfiles.list

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Mock-Sub-1.09-6.fc30   |perl-Mock-Sub-1.09-6.fc30
   ||perl-Mock-Sub-1.09-6.fc29



--- Comment #6 from Fedora Update System  ---
perl-Mock-Sub-1.09-6.fc29 has been pushed to the Fedora 29 stable repository.
If problems still persist, please make note of it in this bug report.

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

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

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Config-Grammar-1.13-1. |perl-Config-Grammar-1.13-1.
   |fc30|fc30
   |perl-Config-Grammar-1.13-1. |perl-Config-Grammar-1.13-1.
   |fc28|fc28
   ||perl-Config-Grammar-1.13-1.
   ||fc29



--- Comment #9 from Fedora Update System  ---
perl-Config-Grammar-1.13-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1697126] perl-Excel-Writer-XLSX-1.00 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Excel-Writer-XLSX-1.00-1.fc30 has been pushed to the Fedora 30 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-60ba8f0510

-- 
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 1696882] perl-CPAN-Perl-Releases-3.94 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-1.fc30 has been pushed to the Fedora 30 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-33db30f21d

-- 
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 1696928] perl-Locale-SubCountry-2.05 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Locale-SubCountry-2.05-1.fc30 has been pushed to the Fedora 30 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-55c521ac24

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

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

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Config-Grammar-1.13-1. |perl-Config-Grammar-1.13-1.
   |fc30|fc30
   ||perl-Config-Grammar-1.13-1.
   ||fc28



--- Comment #8 from Fedora Update System  ---
perl-Config-Grammar-1.13-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Basic graphics mode / 'nomodeset' testing request, round 2

2019-04-08 Thread Adam Williamson

Hi folks!

A few weeks back we asked for testing of 'basic graphics mode' /
nomodeset booting - the feedback from that was very helpful in
establishing that we had a generic issue which dated back to Fedora 29,
thanks a lot. We have now established more or less what that initial
issue is, and work is ongoing to get it fixed entirely. However, it's
already been fixed *partially*, and that revealed a subsequent bug.

The initial bug is fixed for the case of UEFI native boots (it is not
fixed for BIOS native boots yet). However, in testing, I and others
found that several UEFI test systems still do not boot successfully to
GDM, because they run into a *different* bug later:

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

This bug can be identified by the presence of the following string in
the journal:

"(EE) Cannot run in framebuffer mode. Please specify busIDsfor
all framebuffer devices"

(yes, with a bunch of spaces - but just the first part of the line is
sufficient to identify the problem, I think).

It would be great if folks with UEFI-capable systems could try booting
a recent Fedora 30 Workstation live image on them, e.g. this one:

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso

ensure you boot in UEFI mode. Please report back whether it works. If
it doesn't work, please check the logs - you should be able to log into
a console on tty3 (ctrl-alt-f3 to get there) as root with no password,
then run 'journalctl -b' to see the logs - and report if that line is
present or not. If it isn't, it'd be useful to know if some other error
message is present.

Thanks a lot, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction for gaming packaging/maintaining

2019-04-08 Thread Justin W. Flory

On 4/8/19 1:32 PM, Karsten Andreas Artz wrote:
> Hi guys,
> 
> my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2
> years (Fedora 26). My programming skills are on Python, Java/Java
> Script, and C/C++. But acutally I prefer mostly Python hacking. I
> studied B.A. of Arts History, Archaeology and Cath.Theology. Besides
> this, I can speak a lot of languages: German, English, French, a bit
> Italian and Spanish.
> 
> It would be glad starting contributing on Fedora as a maintainer.
> Therefore I hope to work on a small project soon.
> I'm interested in games packaging, but I don't know where to start.
> 

Hi Andi, welcome to the mailing lists. :)

The Games SIG is a good place to find more information about what help
is needed to improve the gaming experience on Fedora. In the past couple
months, there were a few discussions from people needing help on a few
small things. Hopefully someone more informed than me can offer some
pointers since I am not a games packager.

Happy to have you here in the community!

-- 
Cheers,
Justin W. Flory
jflo...@gmail.com



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

[Bug 1694428] perl-ExtUtils-CBuilder-0.280231 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-ExtUtils-CBuilder-0.28 |perl-ExtUtils-CBuilder-0.28
   |0231-1.fc31 |0231-1.fc31
   ||perl-ExtUtils-CBuilder-0.28
   ||0231-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-04-09 00:02:34



--- Comment #8 from Fedora Update System  ---
perl-ExtUtils-CBuilder-0.280231-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1694424] perl-Inline-Files-0.71 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Inline-Files-0.71-1.fc |perl-Inline-Files-0.71-1.fc
   |31  |31
   ||perl-Inline-Files-0.71-1.fc
   ||30
 Resolution|--- |ERRATA
Last Closed||2019-04-09 00:02:33



--- Comment #9 from Fedora Update System  ---
perl-Inline-Files-0.71-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1694465] perl-Inline-0.82 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Inline-0.82-1.fc31 |perl-Inline-0.82-1.fc31
   ||perl-Inline-0.82-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-04-09 00:02:35



--- Comment #8 from Fedora Update System  ---
perl-Inline-0.82-1.fc30 has been pushed to the Fedora 30 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
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 1694736] perl-PPIx-Regexp-0.064 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-PPIx-Regexp-0.064-1.fc |perl-PPIx-Regexp-0.064-1.fc
   |31  |31
   ||perl-PPIx-Regexp-0.064-1.fc
   ||30
 Resolution|--- |ERRATA
Last Closed||2019-04-09 00:02:30



--- Comment #4 from Fedora Update System  ---
perl-PPIx-Regexp-0.064-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: Orphaned packages to be retired

2019-04-08 Thread Fabio Valentini

On Mon, Apr 8, 2019, 19:20 Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Grep the list for your FAS name, follow the transitive deps:
> https://churchyard.fedorapeople.org/orphans-2019-04-08.txt


Hi Miro!

Grepping for our usernames and stewardship-sig, it looks like we got to the
bottom of things with the last round of unretired packages.

I've kicked off the generation of another Stewardship SIG report with the
latest package list and the 20190408.n.0 rawhide compose as sources - I
will let it run overnight.

Fabio


>
> Request package ownership via releng ticket:
> https://pagure.io/releng/issues
>
> Packages retired today are still listed in this report:
>
>  SimplyHTML
>  devilspie
>  iris
>  keybinder
>  libkexif
>  maven-toolchains-plugin
>  mingw-webkitgtk
>  mingw-webkitgtk3
>  python-urwid
>  qcodeedit
>  rubygem-fakeweb
>  sketch
>  superkaramba
>  wicd
>
>  Package  (co)maintainers   Status
> Change
>
> 
> PyMca orphan   1 weeks
> ago
> Ray   orphan   1 weeks
> ago
> SimplyHTMLmizdebsk, orphan 8 weeks
> ago
> ahkab orphan   0 weeks
> ago
> arc-theme besser82, dbenoit, orphan0 weeks
> ago
> cmusphinx3jjames, orphan   5 weeks
> ago
> cwiid orphan   1 weeks
> ago
> devilspie orphan   7 weeks
> ago
> gnue-common   orphan   1 weeks
> ago
> iris  kde-sig, orphan, rdieter,7 weeks
> ago
>slankes
> jam-control   orphan   1 weeks
> ago
> keybinder ohaessler, orphan7 weeks
> ago
> ktechlab  chitlesh, orphan 0 weeks
> ago
> libkexif  orphan, rdieter  7 weeks
> ago
> lightdm-gtk   cwickert, dbenoit, orphan,   0 weeks
> ago
>rdieter
> linsmith  chitlesh, orphan 0 weeks
> ago
> maven-toolchains-plugin   mizdebsk, orphan 8 weeks
> ago
> mingw-webkitgtk   epienbro, orphan, pfor   7 weeks
> ago
> mingw-webkitgtk3  epienbro, orphan, pfor   7 weeks
> ago
> nodejs-after  nodejs-sig, orphan   3 weeks
> ago
> nodejs-alter  nodejs-sig, orphan   3 weeks
> ago
> nodejs-ansi-font  nodejs-sig, orphan   3 weeks
> ago
> nodejs-ansidiff   nodejs-sig, orphan   3 weeks
> ago
> nodejs-archiver   nodejs-sig, orphan   3 weeks
> ago
> nodejs-archiver-utils nodejs-sig, orphan   3 weeks
> ago
> nodejs-ast-traverse   nodejs-sig, orphan   3 weeks
> ago
> nodejs-ast-types  nodejs-sig, orphan   3 weeks
> ago
> nodejs-astral nodejs-sig, orphan   3 weeks
> ago
> nodejs-astral-angular-annotatenodejs-sig, orphan   3 weeks
> ago
> nodejs-astral-passnodejs-sig, orphan   3 weeks
> ago
> nodejs-async-cachenodejs-sig, orphan   3 weeks
> ago
> nodejs-async-each nodejs-sig, orphan   3 weeks
> ago
> nodejs-aws-sign2  nodejs-sig, orphan   3 weeks
> ago
> nodejs-base64-js  nodejs-sig, orphan   3 weeks
> ago
> nodejs-basic-auth-parser  nodejs-si

Re: Orphaned packages to be retired


On 09. 04. 19 0:03, Raphael Groner wrote:

Hopefully, it's sufficient to rebuild in rawhide only.


It is.


No idea why the original try to unbundle failed and your script cares about 
other as just looking into really generated dependencies of binary rpm instead 
of analysis done in spec file.


Sorry, but I'm afraid I don't quite get this. Could you please rephrase?

The script uses source repos to fetch build-dependencies.

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

OpenVPN 3 Linux client - v5 beta release

2019-04-08 Thread David Sommerseth


Hi,

Just a shameless update again from the OpenVPN 3 Linux project.

We published the v5 beta release earlier yesterday (Monday).  This release is
taking a good step forward in regards to reach a release candidate quality 
level.

There are several changes since the last announcement we did in end of January
with the v3 beta release.  But most importantly, OpenVPN 3 Linux is now built
against OpenSSL by default.  Currently only OpenSSL 1.0 is supported (so we
depend on compat-openssl10 for now), but there are work in the pipes to enable
OpenSSL 1.1.1 as well.

For more details, please see our release announcements to the OpenVPN community:



We are trying to get a new release out approx. once per month.


Quick start
===

- Install openvpn3-client according to the Fedora Copr page:
  

- To start a VPN tunnel, run this command:

  $ openvpn2 --config my-config.conf --verb 6

  If this configuration contains the --daemon option, you will need to manage
  this session via the 'openvpn3' command line utility:

  It is also possible to do it like this:

  $ openvpn3 session-start --config my-config.conf

  In this case, the VPN session must be managed by 'openvpn3' commands.


- Managing VPN sessions:

  $ openvpn3 sessions-list
  $ openvpn3 session-stats --config my-config.conf
  $ openvpn3 session-manage --config my-config.conf \
{--pause,--resume,--disconnect}
  $ openvpn3 log --config my-config.conf --verb 6
(this will only provide a real-time view of log events, not a "historical"
 view)

Please see the man page for 'openvpn3', 'openvpn2' and 'openvpn3-linux' for
more details.

This project is now ready to get better integration within desktop
environments (GNOME, KDE, XFCE, etc), NetworkManager, Cockpit Project, etc.
This shouldn't be too daunting, as you can get a long way by using all the
various D-Bus interfaces being exposed by the OpenVPN 3 Linux services.
Please get in touch if you want to get involved and I can ensure you get
started in the right direction instantly.


-- 
kind regards,

David Sommerseth
OpenVPN 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: Orphaned packages to be retired

2019-04-08 Thread Raphael Groner

Hi Miro,

volumeicon should be fixed in rawhide.

It turns out that the BuildRequires line wasn't needed at all in 
volumeicon.spec because upstream bundles partly its own copy of the needed 
functions with code obviously copied from keybinder. Therefore I dropped this 
BR and added a new Provides line with a comment as well.

Hopefully, it's sufficient to rebuild in rawhide only. No idea why the original 
try to unbundle failed and your script cares about other as just looking into 
really generated dependencies of binary rpm instead of analysis done in spec 
file.

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

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

2019-04-08 Thread Robert-André Mauchin

On Monday, 25 March 2019 21:45:06 CEST Jason L Tibbitts III wrote:
> > "JC" == Jeremy Cline  writes:
> 
> 
> JC> The effort would be a 1-2 line change in the-new-hotness, and
> JC> distributing the config to each package repository (some proven
> JC> packager could do this easily).
> 
> Well that seems easy enough.  We still need the repo for the bugzilla
> assignee override thing, but that's fine.  One thing at a time.
> 
> I can certainly drop commits into the repositories if that's what's
> needed.  We would need to define the name and contents of the file, and
> the default state for when the file is not present (to perhaps avoid
> touching every repository).
> 
> It might also be nice to know what on earth monitoring means for a
> module or a container, since the fedora-scm-requests has data for them
> but I don't understand what point it has.
> 
> We would also need to change the admin tool which is generating these
> files.  I think it would speed up its operation a good bit to not have
> to mess with this ever-growing repository, so that is a positive.
> (Especially since the tool does no local caching and so does a full
> clone each time it processes an SCM request).  And fedpkg request-repo
> would need to drop the --monitor option as it would have no effect.
> 
> So I guess it's more than just a couple of lines that need to change,
> but everything outside of the initial new-hotness change and the
> monitoring file commits could come later.
> 
>  - J<

Any chance this might happen?

 - A YAML (or TOML maybe) file at the root of the dist-git repo
 - name to be determined
 - the-new-hotness can look directly at the file and acts accordingly
 - some "fedpkg set-monitoring [no-monitoring,monitoring,monitoring-with-
scratch]" does the creation and commit of the file
 - --monitor is retired from fedpkg  request-repo
 - Make monitoring an opt-out only (that is we force all maintainers to run 
the commands fedpkg set-monitoring no-monitoring after the change if they 
really want to)

No idea what is the admin tool or what does it do.

On Tuesday, 26 March 2019 14:53:10 CEST Pierre-Yves Chibon wrote:
> > > The original idea, I believe, was to allow for the file to different per
> > > branch without breaking the one branch for all releases that many
> > > packager like. With modularity and stream branching, the ability to
> > > say: "I want PR filled for this version to this branch and for that
> > > version to that branch" would be neat, but this means having per-branch
> > > information that the-new-hotness will then access and act upon.
> > > Having this outside of the dist-git repo was meant to make it easier to
> > > tweak this file and have it diverge without having the different
> > > dist-git branches diverge.
> > 
> > If this is the reason than I don't think it's good idea to move the
> > monitoring file
> > to package repository, because the-new-hotness doesn't know which branch
> > should be used.
> > Right now I'm working on creating PR against dist-git in the-new-hotness,
> > but this
> > is basic feature and will create PR only against master branch, it's
> > than on packager to check, if this is correct.
> 
> The alternative would be to change the format to include the mapping version
> -> git branch.
> If we could do this in a backward compatible way it'd be great but that's
> always kinda hard.
> 
> 
> Pierre

Could we start simple and add a layer of complexity later on?
Could we keep all the infos in a single file in the master branch? 

I guess everyone is ENOTIME, but it would be great to see that issue progress.

Best regards,

Robert-André



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

[Bug 1697633] New: perl-Sereal-4.006 is available

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

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



Latest upstream release: 4.006
Current version/release in rawhide: 4.005-5.fc30
URL: http://search.cpan.org/dist/Sereal/

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

-- 
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 1697634] New: perl-Sereal-Decoder-4.006 is available

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

Bug ID: 1697634
   Summary: perl-Sereal-Decoder-4.006 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Decoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.006
Current version/release in rawhide: 4.005-6.fc30
URL: http://search.cpan.org/dist/Sereal-Decoder/

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

-- 
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 1697635] New: perl-Sereal-Encoder-4.006 is available

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

Bug ID: 1697635
   Summary: perl-Sereal-Encoder-4.006 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Encoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.006
Current version/release in rawhide: 4.005-5.fc30
URL: http://search.cpan.org/dist/Sereal-Encoder/

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

-- 
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 1697630] New: perl-App-a2p-1.011 is available

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

Bug ID: 1697630
   Summary: perl-App-a2p-1.011 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-App-a2p
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.011
Current version/release in rawhide: 1.010-7.fc30
URL: http://search.cpan.org/dist/App-a2p/

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

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

Re: Introduction for gaming packaging/maintaining


Hi Benson,
thx for welcoming me on Fedora and thx for providing the links. 
I’ve read through them and skimmed them. 
Should I start reviewing packages or do you have another idea?
Regards
Andi 
Sent from Yahoo Mail for iPhone


On Monday, April 8, 2019, 9:35 PM, Benson Muite  
wrote:

 
Hi Andi,
 Welcome to Fedora. Some general information is at:
 https://docs.fedoraproject.org/en-US/project/
 The get involved page still needs an update:
 https://docs.fedoraproject.org/en-US/project/join/
 but packaging guidelines are here:
 https://docs.fedoraproject.org/en-US/packaging-guidelines/
 
most people start by reviewing packages - though there are other ways to 
contribute other than packaging.
 

 
 Regards,
 Benson 

 
 On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
  
 
   Hi guys, 
  my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
(Fedora 26). My programming skills are on Python, Java/Java Script, and  C/C++. 
But acutally I prefer mostly Python hacking. I studied B.A. of Arts History, 
Archaeology and Cath.Theology. Besides this, I can speak a lot of languages: 
German, English, French, a  bit Italian and Spanish. 
  
  It would be glad starting contributing on Fedora as a maintainer. Therefore I 
hope to work on a small  project soon.
  I'm interested in games packaging, but I don't know where to start.
  
  
  Regards 
  Andi
  
  
   
  ___
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



___
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: Please revert the python-impacket package removal


On 04. 04. 19 18:03, Miro Hrončok wrote:

On 04. 04. 19 17:46, Michal Ambroz wrote:
Package python-impacket was providing whole bunch of utilities with additional 
functionality like *wmiexec.py* and *psexec.py*, which currently do not have 
replacement (process automation from linux to windows hosts).


This was an automation failure. As much as I try for this not to happen, it 
sometimes does.


I've reopened https://bugzilla.redhat.com/show_bug.cgi?id=1672052


Here you go: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0762303419

--
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread mcatanzaro



On Mon, Apr 8, 2019 at 1:39 PM, Benjamin Tissoires 
 wrote:

That's not how I read it:
https://github.com/mesonbuild/meson/blob/master/docs/markdown/Builtin-options.md#base-options
-DB-ndebug defaults to false.


OK, then I was totally wrong, thanks.

Shame the docs are so hard to search through. :(


Again, this setting should be set per project, so reverting the change
was the right call IMO.


OK, I agree now. Since it's off by default in meson upstream, we 
shouldn't be turning it on in Fedora. Sounds like reverting is the 
right move.


With the above in mind, I consider mesa's meson build system to be 
broken for incorrectly assuming distros will use -Db_ndebug=if-release 
or -Db_ndebug=true, since we will not be doing that. So mesa should 
find another way to ensure its performance-sensitive asserts are not 
enabled in plain builds (or release builds). Right? We can of course 
work around the issue in the Fedora spec by using -Db_ndebug=true just 
for mesa.


Michael

___
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: Registering Python packages with Anitya and the "no-monitoring" option

2019-04-08 Thread Dominik 'Rathann' Mierzejewski

On Monday, 08 April 2019 at 20:13, Robert-André Mauchin wrote:
> On Monday, 8 April 2019 07:42:25 CEST Miro Hrončok wrote:
> > On 08. 04. 19 1:32, Robert-André Mauchin wrote:
> > > Hello,
> > > 
> > > I have worked on my script to register packages with Anitya this week-end:
> > > https://gist.github.com/eclipseo/fbc52aeebccb7f560221bd40ec28b6af
> > > 
> > > It now handles all backend that Anitya supports.
> > > 
> > > I have ran it on Python 2661 packages and this resulted in 637 new
> > > packages
> > > being registered. Michal Konecny still needs to do something for the new
> > > hotness to pick them up.
> > > 
> > > However I already noticed that a large number of packages have set "no-
> > > monitoring" in Pagure. A lot of that are old packages ported from pkgdb
> > > and it seems it defaulted to "no-monitoring" back then. As a results many
> > > bugs won't be filled even if the packages is outdated.
> > > 
> > > I wish we forbid the use of "no-monitoring" and force maintainers to track
> > > updates through Bugzilla, so updates are always linked to a bug number. So
> > > we would convert all existing packages from "no-monitoring" to
> > > "monitoring". Any input regarding this proposal? Would many of you be
> > > against such a change? Right now we have tons of packages left
> > > unmaintained as a result.
> > 
> > For some packages it makes sense to be able to opt-out.
> > Some of them release versions that are not OK for Fedora, some only go
> > released together with another packages, some release 3 times a day.
> > There might be other reasons.
> > 
> > I would suggest the following approach:
> > 
> >   1. Switch everything that was converted from Pagure. Keep anything
> > disabled by later commits.
> >   2. Mass e-mail the affected maintainers about this with specific
> > instructions to opt-out if needed.
> > 
> > For the repo maintainers, I suggest demanding reasons before merging a Pull
> > Request that sets a package to no-monitoring.
> 
> I've identified 12889 packages which were imported with "no-monitoring".
> I could mail all of the affected maintainers but the instructions to opt-out
> are quite tedious and I fear the wrath of affected maintainers.
> 
> Any affected people want to chime in?

A number of packages I (co-)maintain are affected and I find the
"opt-in" instructions quite tedious as well. I'd love to have an option
in fedpkg or at least a toggle button on src.fedoraproject.org or
apps.fedoraproject.org/packages similar to what was there in the old
PkgDB. So, if anyone wants to turn on automated version monitoring and
bug filling for the packages I maintain, you're welcome to do so.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

Planned Outage - Fedora Core Services 2019-04-10 21:00 UTC

2019-04-08 Thread Stephen John Smoogen

Planned Outage - Fedora Core Services 2019-04-10 21:00 UTC

There will be an outage starting at 2019-04-10 21:00 UTC ,
which will last approximately 5 hours.

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

date -d '2019-04-10 21:00UTC'

Reason for outage:

There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting
staging and non-PHX2 servers which do not require a full outage due to
redundancy or low service level expectations.

Affected Services:

koji.fedoraproject.org
src.fedoraproject.org
fedorapeople.org
pagure.io
*.phx2.fedoraproject.org
ibiblio01.fedoraproject.org download-ib01.fedoraproject.org
ibiblio01.fedoraproject.org noc02.fedoraproject.org
ibiblio01.fedoraproject.org pagure-proxy01.fedoraproject.org
ibiblio01.fedoraproject.org proxy04.fedoraproject.org
ibiblio05.fedoraproject.org ns02.fedoraproject.org
ibiblio05.fedoraproject.org people02.fedoraproject.org
ibiblio05.fedoraproject.org proxy12.fedoraproject.org
ibiblio05.fedoraproject.org smtp-mm-ib01.fedoraproject.org
ibiblio05.fedoraproject.org torrent02.fedoraproject.org
ibiblio05.fedoraproject.org unbound-ib01.fedoraproject.org
osuosl01.fedoraproject.org pagure01.fedoraproject.org
osuosl01.fedoraproject.org proxy06.fedoraproject.org
osuosl01.fedoraproject.org repospanner-osuosl01.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org infinote.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org proxy03.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org repospanner-cc-rdu01.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org unbound-cc-rdu01.fedoraproject.org

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 
Stephen J Smoogen.
___
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

Re: Introduction for gaming packaging/maintaining

2019-04-08 Thread Benson Muite


Hi Andi,

Welcome to Fedora. Some general information is at:
https://docs.fedoraproject.org/en-US/project/
The get involved page still needs an update:
https://docs.fedoraproject.org/en-US/project/join/
but packaging guidelines are here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/

most people start by reviewing packages - though there are other ways to 
contribute other than packaging.



Regards,
Benson


On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:

Hi guys,

my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 
years (Fedora 26). My programming skills are on Python, Java/Java 
Script, and C/C++. But acutally I prefer mostly Python hacking. I 
studied B.A. of Arts History, Archaeology and Cath.Theology. Besides 
this, I can speak a lot of languages: German, English, French, a bit 
Italian and Spanish.


It would be glad starting contributing on Fedora as a maintainer. 
Therefore I hope to work on a small project soon.

I'm interested in games packaging, but I don't know where to start.


Regards

Andi



___
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

Planned Outage - Fedora Core Services 2019-04-10 21:00 UTC

2019-04-08 Thread Stephen John Smoogen

Planned Outage - Fedora Core Services 2019-04-10 21:00 UTC

There will be an outage starting at 2019-04-10 21:00 UTC ,
which will last approximately 5 hours.

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

date -d '2019-04-10 21:00UTC'

Reason for outage:

There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting
staging and non-PHX2 servers which do not require a full outage due to
redundancy or low service level expectations.

Affected Services:

koji.fedoraproject.org
src.fedoraproject.org
fedorapeople.org
pagure.io
*.phx2.fedoraproject.org
ibiblio01.fedoraproject.org download-ib01.fedoraproject.org
ibiblio01.fedoraproject.org noc02.fedoraproject.org
ibiblio01.fedoraproject.org pagure-proxy01.fedoraproject.org
ibiblio01.fedoraproject.org proxy04.fedoraproject.org
ibiblio05.fedoraproject.org ns02.fedoraproject.org
ibiblio05.fedoraproject.org people02.fedoraproject.org
ibiblio05.fedoraproject.org proxy12.fedoraproject.org
ibiblio05.fedoraproject.org smtp-mm-ib01.fedoraproject.org
ibiblio05.fedoraproject.org torrent02.fedoraproject.org
ibiblio05.fedoraproject.org unbound-ib01.fedoraproject.org
osuosl01.fedoraproject.org pagure01.fedoraproject.org
osuosl01.fedoraproject.org proxy06.fedoraproject.org
osuosl01.fedoraproject.org repospanner-osuosl01.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org infinote.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org proxy03.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org repospanner-cc-rdu01.fedoraproject.org
virthost-cc-rdu02.fedoraproject.org unbound-cc-rdu01.fedoraproject.org

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

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

Planned Outage - Fedora Staging/Proxies Updates/Reboots - 2019-04-09 21:00 UTC

2019-04-08 Thread Stephen John Smoogen

Planned Outage - Fedora Staging/Proxies Updates/Reboots - 2019-04-09 21:00 UTC

There will be an outage starting at 2019-04-09 21:00 UTC,
which will last approximately 4 hours.

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

date -d '2019-04-09 21:00UTC'

Reason for outage:

We have come to chew gum and reboot servers, and we have all run out of gum.

There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting
staging and non-PHX2 servers which do not require a full outage due to
redundancy or low service level expectations.

Affected Services:

*.stg.fedoraproject.org
*.stg.phx2.fedoraproject.org
coloamer01.fedoraproject.org proxy08.fedoraproject.org
dedicatedsolutions01.fedoraproject.org proxy11.fedoraproject.org
internetx01.fedoraproject.org ns05.fedoraproject.org
internetx01.fedoraproject.org proxy02.fedoraproject.org
osuosl02.fedoraproject.org keys01.fedoraproject.org
osuosl02.fedoraproject.org pagure-stg01.fedoraproject.org
osuosl02.fedoraproject.org proxy09.fedoraproject.org
osuosl02.fedoraproject.org smtp-mm-osuosl01.fedoraproject.org
osuosl02.fedoraproject.org unbound-osuosl01.fedoraproject.org
virthost-cc-rdu01.fedoraproject.org ci-cc-rdu01.fedoraproject.org
virthost-cc-rdu01.fedoraproject.org proxy14.fedoraproject.org
virthost-cc-rdu01.fedoraproject.org smtp-mm-cc-rdu01.fedoraproject.org
virthost-rdu01.fedoraproject.org bastion13.fedoraproject.org
virthost-rdu01.fedoraproject.org batcave13.rdu2.fedoraproject.org
virthost-rdu01.fedoraproject.org ns13.rdu2.fedoraproject.org
virthost-rdu01.fedoraproject.org proxy13.fedoraproject.org
Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7699

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 
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: Registering Python packages with Anitya and the "no-monitoring" option

2019-04-08 Thread Jeremy Cline

On 4/7/19 9:27 PM, Charalampos Stratakis wrote:

- Original Message -

From: "Robert-André Mauchin" 
To: "Miro Hrončok" 
Cc: devel@lists.fedoraproject.org
Sent: Monday, April 8, 2019 1:32:58 AM
Subject: Registering Python packages with Anitya and the "no-monitoring" option

Hello,

I have worked on my script to register packages with Anitya this week-end:
https://gist.github.com/eclipseo/fbc52aeebccb7f560221bd40ec28b6af

It now handles all backend that Anitya supports.

I have ran it on Python 2661 packages and this resulted in 637 new packages
being registered. Michal Konecny still needs to do something for the new
hotness to pick them up.

However I already noticed that a large number of packages have set "no-
monitoring" in Pagure. A lot of that are old packages ported from pkgdb and
it
seems it defaulted to "no-monitoring" back then. As a results many bugs won't
be filled even if the packages is outdated.

I wish we forbid the use of "no-monitoring" and force maintainers to track
updates through Bugzilla, so updates are always linked to a bug number. So we
would convert all existing packages from "no-monitoring" to "monitoring".
Any input regarding this proposal? Would many of you be against such a
change?
Right now we have tons of packages left unmaintained as a result.

I'm all for enabling monitoring everywhere, as I have myself lost way too many
updates of my packages due to it being disabled after the migration from pkgdb.

However I'd also like some simple way to opt out as well. Some packages have
really aggressive release schedules (looking at you boto3) generating too much
noise, and having to file PR's here [0], skimming through all the fedora rpm's
to find my package in order to tweak release monitoring is really not the most
intuitive approach.

[0] https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms

Indeed, a more reasonable approach was discussed recently[0]. I think it
would be best if that (or something better) be implemented before
flipping on monitoring in any large-scale way.

[0] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RNUBMEG6GOY3V2LNXV7PX4P56CE4NSEN/#24A7EJZI4P6Q47XEUA52RWTOQVB2MU3Y

___
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

Orphaned packages to be retired


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Grep the list for your FAS name, follow the transitive deps:
   https://churchyard.fedorapeople.org/orphans-2019-04-08.txt

Request package ownership via releng ticket: https://pagure.io/releng/issues

Packages retired today are still listed in this report:

SimplyHTML
devilspie
iris
keybinder
libkexif
maven-toolchains-plugin
mingw-webkitgtk
mingw-webkitgtk3
python-urwid
qcodeedit
rubygem-fakeweb
sketch
superkaramba
wicd

Package  (co)maintainers   Status Change

PyMca orphan   1 weeks ago
Ray   orphan   1 weeks ago
SimplyHTMLmizdebsk, orphan 8 weeks ago
ahkab orphan   0 weeks ago
arc-theme besser82, dbenoit, orphan0 weeks ago
cmusphinx3jjames, orphan   5 weeks ago
cwiid orphan   1 weeks ago
devilspie orphan   7 weeks ago
gnue-common   orphan   1 weeks ago
iris  kde-sig, orphan, rdieter,7 weeks ago
  slankes
jam-control   orphan   1 weeks ago
keybinder ohaessler, orphan7 weeks ago
ktechlab  chitlesh, orphan 0 weeks ago
libkexif  orphan, rdieter  7 weeks ago
lightdm-gtk   cwickert, dbenoit, orphan,   0 weeks ago
  rdieter
linsmith  chitlesh, orphan 0 weeks ago
maven-toolchains-plugin   mizdebsk, orphan 8 weeks ago
mingw-webkitgtk   epienbro, orphan, pfor   7 weeks ago
mingw-webkitgtk3  epienbro, orphan, pfor   7 weeks ago
nodejs-after  nodejs-sig, orphan   3 weeks ago
nodejs-alter  nodejs-sig, orphan   3 weeks ago
nodejs-ansi-font  nodejs-sig, orphan   3 weeks ago
nodejs-ansidiff   nodejs-sig, orphan   3 weeks ago
nodejs-archiver   nodejs-sig, orphan   3 weeks ago
nodejs-archiver-utils nodejs-sig, orphan   3 weeks ago
nodejs-ast-traverse   nodejs-sig, orphan   3 weeks ago
nodejs-ast-types  nodejs-sig, orphan   3 weeks ago
nodejs-astral nodejs-sig, orphan   3 weeks ago
nodejs-astral-angular-annotatenodejs-sig, orphan   3 weeks ago
nodejs-astral-passnodejs-sig, orphan   3 weeks ago
nodejs-async-cachenodejs-sig, orphan   3 weeks ago
nodejs-async-each nodejs-sig, orphan   3 weeks ago
nodejs-aws-sign2  nodejs-sig, orphan   3 weeks ago
nodejs-base64-js  nodejs-sig, orphan   3 weeks ago
nodejs-basic-auth-parser  nodejs-sig, orphan   3 weeks ago
nodejs-bl nodejs-sig, orphan   3 weeks ago
nodejs-bluebird   nodejs-sig, orphan   3 weeks ago
nodejs-breakable  nodejs-sig, orphan   3 weeks ago
nodejs-camel-case nodejs-sig, orphan   3 weeks ago
nodejs-caniuse-db nodejs-sig, orphan   3 weeks ago
nodejs-change-casenodejs-sig, orphan   3 weeks ago
nodejs-clean-css  nodejs-sig, orphan   3 weeks ago
nodejs-clone  nodejs-sig, orphan   3 weeks ago
nodejs-clsnodejs-sig, orphan   3 weeks ago
nodejs-co nodejs-sig, orphan   3 weeks ago
nodejs-commoner   nodejs-sig, orphan   3 weeks ago
nodejs-compress-commons   nodejs-sig,

Re: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Benjamin Tissoires

On Mon, Apr 8, 2019 at 3:17 PM  wrote:
>
> On Mon, Apr 8, 2019 at 5:50 AM, Kalev Lember 
> wrote:
> > I agree as well. Please don't override -Db_ndebug in distro-wide
> > %meson
> > macro and instead move the override to mesa packaging if it's needed
> > there.
>
> Well hold up. -Db_ndebug defaults to if-release... right? We have only

That's not how I read it:
https://github.com/mesonbuild/meson/blob/master/docs/markdown/Builtin-options.md#base-options
-DB-ndebug defaults to false.

> changed the behavior for plain builds (distro builds) to match release
> builds? So any package that has ever tested a release build would
> already know to expect assertions to be disabled, and the only broken
> packages are those that have never tested a release build?

Packages built previously were tested against the default build system
and their test suite that catches the assert were passing. With the
-DB-ndebug changed to true, those same tests were failing.

>
> I see three options:
>
>  - Plain builds should match the behavior of release builds, and Fedora
> plain builds should match the behavior of upstream plain builds. This
> is what we briefly had but just reverted. (Option one)
>
>  - Upstream plain builds should be really completely plain. Fedora can
> either add on -Db_ndebug=true or not (options two and three). This
> makes less sense to me because -Db_ndebug is really special, not like
> other compiler flags.
>
> I don't think it's right to say "NDEBUG should be off by default
> because that's how it is with Autotools" since we're not Autotools
> anymore, we should decide something that makes sense for meson, based
> on meson semantics and meson expectations and in coordination with
> meson upstream. E.g. I see you (Igor) reverted the RPM macro change,
> but that was just the bandaid over the default behavior of if-release,
> which is actually still changed, right? It's unclear to me what the
> default value of -Db_ndebug is due to underdocumentation, but if it's
> if-release then this change is just going to reappear again in the next
> version of meson, right?

Again, this setting should be set per project, so reverting the change
was the right call IMO.

The default value is documented in the markdown file above and the
actual code is at
https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/compilers.py#L399-L400
So definitively, defaults is `false` and the next meson release will
not change this as of today.

Cheers,
Benjamin
___
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

Updating/rebuilding of coin-or packages

2019-04-08 Thread Antonio Trande

Hi all.

Updates of coin-or-Sample/CoinUtils/Ipopt packages are coming on
Rawhide; involved packages:

$ dnf repoquery --release rawhide --enablerepo=*-source
--disablerepo=rpmfusion* --disablerepo=*modular* --whatrequires
coin-or-CoinUtils-devel
Last metadata expiration check: 0:00:02 ago on lun 08 apr 2019 18:31:27
CEST.
coin-or-Alps-0:1.5.5-9.fc30.src
coin-or-Alps-devel-0:1.5.5-9.fc30.i686
coin-or-Alps-devel-0:1.5.5-9.fc30.x86_64
coin-or-Bcp-0:1.4.3-9.fc30.src
coin-or-Bcp-devel-0:1.4.3-9.fc30.i686
coin-or-Bcp-devel-0:1.4.3-9.fc30.x86_64
coin-or-Bcps-0:0.94.4-9.fc30.src
coin-or-Bcps-devel-0:0.94.4-9.fc30.i686
coin-or-Bcps-devel-0:0.94.4-9.fc30.x86_64
coin-or-Blis-0:0.94.4-9.fc30.src
coin-or-Blis-devel-0:0.94.4-9.fc30.i686
coin-or-Blis-devel-0:0.94.4-9.fc30.x86_64
coin-or-Bonmin-0:1.8.6-2.fc30.src
coin-or-Bonmin-devel-0:1.8.6-2.fc30.i686
coin-or-Bonmin-devel-0:1.8.6-2.fc30.x86_64
coin-or-Cbc-0:2.9.8-10.fc30.src
coin-or-Cbc-devel-0:2.9.8-10.fc30.i686
coin-or-Cbc-devel-0:2.9.8-10.fc30.x86_64
coin-or-Cgl-0:0.59.9-9.fc30.src
coin-or-Cgl-devel-0:0.59.9-9.fc30.i686
coin-or-Cgl-devel-0:0.59.9-9.fc30.x86_64
coin-or-Clp-0:1.16.10-8.fc30.src
coin-or-Clp-devel-0:1.16.10-8.fc30.i686
coin-or-Clp-devel-0:1.16.10-8.fc30.x86_64
coin-or-CoinMP-0:1.8.3-8.fc30.src
coin-or-CoinMP-devel-0:1.8.3-8.fc30.i686
coin-or-CoinMP-devel-0:1.8.3-8.fc30.x86_64
coin-or-Couenne-0:0.5.6-18.fc30.src
coin-or-Couenne-devel-0:0.5.6-18.fc30.i686
coin-or-Couenne-devel-0:0.5.6-18.fc30.x86_64
coin-or-Dip-0:0.92.2-9.fc30.src
coin-or-Dip-devel-0:0.92.2-9.fc30.i686
coin-or-Dip-devel-0:0.92.2-9.fc30.x86_64
coin-or-DyLP-0:1.10.3-8.fc30.src
coin-or-DyLP-devel-0:1.10.3-8.fc30.i686
coin-or-DyLP-devel-0:1.10.3-8.fc30.x86_64
coin-or-FlopC++-0:1.2.4-5.fc27.src
coin-or-FlopC++-devel-0:1.2.4-5.fc27.i686
coin-or-FlopC++-devel-0:1.2.4-5.fc27.x86_64
coin-or-Ipopt-devel-0:3.12.11-4.fc30.i686
coin-or-Ipopt-devel-0:3.12.11-4.fc30.x86_64
coin-or-OS-0:2.10.1-19.fc30.src
coin-or-OS-devel-0:2.10.1-19.fc30.i686
coin-or-OS-devel-0:2.10.1-19.fc30.x86_64
coin-or-Osi-0:0.107.8-9.fc30.src
coin-or-Osi-devel-0:0.107.8-9.fc30.i686
coin-or-Osi-devel-0:0.107.8-9.fc30.x86_64
coin-or-SYMPHONY-0:5.6.14-9.fc30.src
coin-or-SYMPHONY-devel-0:5.6.14-9.fc30.i686
coin-or-SYMPHONY-devel-0:5.6.14-9.fc30.x86_64
coin-or-Vol-0:1.5.3-9.fc30.src
coin-or-Vol-devel-0:1.5.3-9.fc30.i686
coin-or-Vol-devel-0:1.5.3-9.fc30.x86_64
openms-0:2.4.0-4.fc30.src

Builds tested on Copr:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/

Let me know if any problem comes out before commit these changes.

Best regards.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.fedoraproject.org/



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

Re: Registering Python packages with Anitya and the "no-monitoring" option

2019-04-08 Thread Robert-André Mauchin

On Monday, 8 April 2019 07:42:25 CEST Miro Hrončok wrote:
> On 08. 04. 19 1:32, Robert-André Mauchin wrote:
> > Hello,
> > 
> > I have worked on my script to register packages with Anitya this week-end:
> > https://gist.github.com/eclipseo/fbc52aeebccb7f560221bd40ec28b6af
> > 
> > It now handles all backend that Anitya supports.
> > 
> > I have ran it on Python 2661 packages and this resulted in 637 new
> > packages
> > being registered. Michal Konecny still needs to do something for the new
> > hotness to pick them up.
> > 
> > However I already noticed that a large number of packages have set "no-
> > monitoring" in Pagure. A lot of that are old packages ported from pkgdb
> > and it seems it defaulted to "no-monitoring" back then. As a results many
> > bugs won't be filled even if the packages is outdated.
> > 
> > I wish we forbid the use of "no-monitoring" and force maintainers to track
> > updates through Bugzilla, so updates are always linked to a bug number. So
> > we would convert all existing packages from "no-monitoring" to
> > "monitoring". Any input regarding this proposal? Would many of you be
> > against such a change? Right now we have tons of packages left
> > unmaintained as a result.
> 
> For some packages it makes sense to be able to opt-out.
> Some of them release versions that are not OK for Fedora, some only go
> released together with another packages, some release 3 times a day.
> There might be other reasons.
> 
> I would suggest the following approach:
> 
>   1. Switch everything that was converted from Pagure. Keep anything
> disabled by later commits.
>   2. Mass e-mail the affected maintainers about this with specific
> instructions to opt-out if needed.
> 
> For the repo maintainers, I suggest demanding reasons before merging a Pull
> Request that sets a package to no-monitoring.

I've identified 12889 packages which were imported with "no-monitoring".
I could mail all of the affected maintainers but the instructions to opt-out
are quite tedious and I fear the wrath of affected maintainers.

Any affected people want to chime in?

___
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: Introduction for gaming packaging/maintaining



Mit freundlichen Grüßen
Karsten Andreas ArtzSchaal 1335435 Wettenberg
 

Am Montag, 8. April 2019, 19:32:42 MESZ hat Karsten Andreas Artz 
 Folgendes geschrieben:  
 
 Hi guys,
my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
(Fedora 26). My programming skills are on Python, Java/Java Script, and C/C++. 
But acutally I prefer mostly Python hacking. I studied B.A. of Arts History, 
Archaeology and Cath.Theology. Besides this, I can speak a lot of languages: 
German, English, French, a bit Italian and Spanish. 

It would be glad starting contributing on Fedora as a maintainer. Therefore I 
hope to work on a small project soon.
I'm interested in games packaging, but I don't know where to start.


Regards
Andi


  ___
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: Could not execute import_srpm

2019-04-08 Thread Paulo César Pereira de Andrade

Em seg, 8 de abr de 2019 às 10:09, Antonio Trande
 escreveu:
>
> Hi all.

  Hi,

  Just a guess that it was the same issue as for me a few days ago. But it might
be something else, like an offline server for some reason.

  I did not do much work on Fedora for some time, then, when uploading
a new source I was getting all kinds of errors.
   Eventually fixing some .rpmsav andor .rpmorig files, plus using
rdns = false
in /etc/krb5.conf fixed the issue.
  For other possible issues check
https://fedoraproject.org/wiki/Infrastructure/Kerberos

> I can't upload source archive of new package 'smoldyn'
>
> $ fedpkg import ../../smoldyn-2.58-1.fc29.src.rpm
> Uploading: /home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz
> 
> 100.0%
> Could not execute import_srpm: Fail to upload files. Server returns
> status 408
>
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x6e0331dd1699e4d7
> GPG key server: https://keys.fedoraproject.org/

Thanks,
Paulo
___
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

Introduction for gaming packaging/maintaining

Hi guys,
my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
(Fedora 26). My programming skills are on Python, Java/Java Script, and C/C++. 
But acutally I prefer mostly Python hacking. I studied B.A. of Arts History, 
Archaeology and Cath.Theology. Besides this, I can speak a lot of languages: 
German, English, French, a bit Italian and Spanish. 

It would be glad starting contributing on Fedora as a maintainer. Therefore I 
hope to work on a small project soon.
I'm interested in games packaging, but I don't know where to start.


Regards
Andi


___
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: Orphaned some Java packages

2019-04-08 Thread Christopher

On Mon, Apr 8, 2019 at 12:21 PM Mikolaj Izdebski  wrote:
>
> On Sat, Mar 30, 2019 at 1:34 AM Christopher  
> wrote:
> >
> > On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski  
> > wrote:
> > >
> > > On Thu, Mar 28, 2019 at 7:46 PM Christopher  
> > > wrote:
> > > >
> > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski  
> > > > wrote:
> > > > > - javapackages-tools, stream 201801 (buildroot-only module, not
> > > > > intended to be delivered to users)
> > > >
> > > > How do I enable/install this module locally? It would be very helpful
> > > > for local builds/testing, but is not available in:
> > > > sudo dnf --releasever=30 module list
> > >
> > > The official, recommended way of building modules locally is "fedpkg
> > > module-build-local". This command should take care of fetching and
> > > installing all required dependencies specified in modulemd being
> > > built. Therefore in this case it is enough to add dependency on
> > > javapackages-tools and it should "just work", for both local and
> > > remote builds.
> >
> > Hmm. I don't know how to do modules yet. I don't know how to create a
> > modulemd, or where it lives, or which packages I need to put in which
> > module, or how to name modules, or anything. I just want to install
> > all the tools from javapackages-tools, so I can do a plain old `fedpkg
> > local` build of my regular RPMs. I know this isn't going to work in
> > Koji for Fedora... but it would help me, as a user of those tools,
> > have access to them for my own RPM building purposes.
>
> You don't have to use these packages. You can keep using traditional,
> "ursine" Java packages that are still available in non-modular repos.
> These packages new owners who signed up to maintain them.
>

I know I don't have to use them, but... I *want* to use them. My
understanding is that those new owners maintaining them is an interim
solution, *minimally* maintained to prevent catastrophe, not the
stable long-term solution. I'd prefer the go to where the  fully
maintained packages are going... not stay with the minimally
maintained ones. Besides, the catastrophe can still occur, if we don't
work to migrate while we have the chance.

> In addition to the above set of traditional, "ursine", packages, there
> is also javapackages-tools module, that contains Java packages
> intended for building certain other modules. Module maintainers can
> choose whether they want to build their modules using ursine Java
> packages, or using javapackages-tools module. Ursine package
> maintainers have no such choice and they are limited to depending on
> ursine Java packages only.
>

I'm trying to get on board the modular train, and convert my ursine
packages to modules. I want to learn how to do this correctly locally.
How can I get local builds of my modular packages, using the versions
I want them to use from the javapackages-tools module? I think the
lack of local availability of the packages in this module will make it
harder to transition to the modular versions, and will keep the
requirement for the ursine packages around longer.

> The original goal was to have a single set of modular packages that
> would be used for both building other modules and for building
> non-modular ("ursine") packages. However, in the end this set was
> split/forked and now we have two package sets, but with different
> maintainers. These packages are similar for now, but I expect them to
> diverge more over time. I don't like this situation either, but I've
> done everything I could to avoid it.
>

I understand, and appreciate what you've done to sound the alarm, and
the effort you've put into these packages to benefit the Java
ecosystem within Fedora. That's why I'm trying to follow the path
you're going, rather than stay on the ursine packages. I'm just
finding it extremely difficult to do so, because I do not understand
how to do modules, and the fact that some of them are less available
than others, makes it hard to "play" to learn on my own.

> >
> > >
> > > The module is not included in any compose, therefore dnf won't be able
> > > to find it in default repos. If you really want to install the module
> > > on your system for some reason then you can use ODCS [1] to generate a
> > > compose containing the module. Install ODCS client with "dnf install
> > > odcs-client" and then request compose with "odcs create module
> > > javapackages-tools:201801". ODCS will (usually) quickly create repo
> > > with the module and output repo URL, which you can put in a config
> > > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
> > > option. Note that contents of javapackages-tools module are not signed
> > > and therefore you need to skip GPG verification in order to be able to
> > > install it.
> >
> > It seems a bit crazy to me that we have packages built for Fedora that
> > aren't available for users to install. Why wouldn't we make everything
> > maximally available? I used to love Fedora, because I just

Re: Catch 22 in epel7 for %selinux_requires

2019-04-08 Thread Dridi Boukelmoune

> Breaking the line with back-slashes didn't work, the modules weren't
> considered arguments to the macro:
>
> > %selinux_modules_install \
> >%{_datadir}/selinux/%{selinuxtype}/mod1.cil \
> >%{_datadir}/selinux/%{selinuxtype}/mod2.pp
>
> I tried %{selinux_modules_install} and other shenanigans but no luck.

And of course the moment I send the email it occurs to me that I could try this:

> %{selinux_modules_install \
>%{_datadir}/selinux/%{selinuxtype}/mod1.cil \
>%{_datadir}/selinux/%{selinuxtype}/mod2.pp
> }

And it appears to work after inspecting the scriptlets from the RPM :)

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

Introduction for new maintainer

Hi guys,
my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
(Fedora 26). My programming skills are on Python, Java/Java Script, and C/C++. 
But acutally I prefer mostly Python hacking. I studied B.A. of Arts History, 
Archaeology and Cath.Theology. Besides this, I can speak a lot of languages: 
German, English, French, a bit Italian and Spanish. 

It would be glad starting contributing on Fedora as a maintainer. Therefore I 
hope to work on a small project soon.
I'm interested in games packaging, but I don't know where to start.


Regards
Andi
___
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

Orphaned packages to be retired


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Grep the list for your FAS name, follow the transitive deps:
   https://churchyard.fedorapeople.org/orphans-2019-04-08.txt

Request package ownership via releng ticket: https://pagure.io/releng/issues

Packages retired today are still listed in this report:

SimplyHTML
devilspie
iris
keybinder
libkexif
maven-toolchains-plugin
mingw-webkitgtk
mingw-webkitgtk3
python-urwid
qcodeedit
rubygem-fakeweb
sketch
superkaramba
wicd

Package  (co)maintainers   Status Change

PyMca orphan   1 weeks ago
Ray   orphan   1 weeks ago
SimplyHTMLmizdebsk, orphan 8 weeks ago
ahkab orphan   0 weeks ago
arc-theme besser82, dbenoit, orphan0 weeks ago
cmusphinx3jjames, orphan   5 weeks ago
cwiid orphan   1 weeks ago
devilspie orphan   7 weeks ago
gnue-common   orphan   1 weeks ago
iris  kde-sig, orphan, rdieter,7 weeks ago
  slankes
jam-control   orphan   1 weeks ago
keybinder ohaessler, orphan7 weeks ago
ktechlab  chitlesh, orphan 0 weeks ago
libkexif  orphan, rdieter  7 weeks ago
lightdm-gtk   cwickert, dbenoit, orphan,   0 weeks ago
  rdieter
linsmith  chitlesh, orphan 0 weeks ago
maven-toolchains-plugin   mizdebsk, orphan 8 weeks ago
mingw-webkitgtk   epienbro, orphan, pfor   7 weeks ago
mingw-webkitgtk3  epienbro, orphan, pfor   7 weeks ago
nodejs-after  nodejs-sig, orphan   3 weeks ago
nodejs-alter  nodejs-sig, orphan   3 weeks ago
nodejs-ansi-font  nodejs-sig, orphan   3 weeks ago
nodejs-ansidiff   nodejs-sig, orphan   3 weeks ago
nodejs-archiver   nodejs-sig, orphan   3 weeks ago
nodejs-archiver-utils nodejs-sig, orphan   3 weeks ago
nodejs-ast-traverse   nodejs-sig, orphan   3 weeks ago
nodejs-ast-types  nodejs-sig, orphan   3 weeks ago
nodejs-astral nodejs-sig, orphan   3 weeks ago
nodejs-astral-angular-annotatenodejs-sig, orphan   3 weeks ago
nodejs-astral-passnodejs-sig, orphan   3 weeks ago
nodejs-async-cachenodejs-sig, orphan   3 weeks ago
nodejs-async-each nodejs-sig, orphan   3 weeks ago
nodejs-aws-sign2  nodejs-sig, orphan   3 weeks ago
nodejs-base64-js  nodejs-sig, orphan   3 weeks ago
nodejs-basic-auth-parser  nodejs-sig, orphan   3 weeks ago
nodejs-bl nodejs-sig, orphan   3 weeks ago
nodejs-bluebird   nodejs-sig, orphan   3 weeks ago
nodejs-breakable  nodejs-sig, orphan   3 weeks ago
nodejs-camel-case nodejs-sig, orphan   3 weeks ago
nodejs-caniuse-db nodejs-sig, orphan   3 weeks ago
nodejs-change-casenodejs-sig, orphan   3 weeks ago
nodejs-clean-css  nodejs-sig, orphan   3 weeks ago
nodejs-clone  nodejs-sig, orphan   3 weeks ago
nodejs-clsnodejs-sig, orphan   3 weeks ago
nodejs-co nodejs-sig, orphan   3 weeks ago
nodejs-commoner   nodejs-sig, orphan   3 weeks ago
nodejs-compress-commons   nodejs-sig,

Re: Catch 22 in epel7 for %selinux_requires

2019-04-08 Thread Dridi Boukelmoune

> >  BuildRequires: selinux-policy
> >  BuildRequires: /usr/share/selinux/devel/Makefile
>
>
> Thank you for the feedback. You are correct that the BuildRequires in
> the macro are useless. At this point I have no idea how to get around
> the macro expansion. I will at least add selinux-policy-devel package
> BuildRequire to the Packaging guidelines.

I eventually did that, I folded both BuildRequires into a single one for
selinux-policy-devel and it worked just fine.

> If you have any more issues with shipping custom policy, feel free to CC
> me so that I get to you sooner.

I think I really don't want the BuildRequires from the macro, they
look superfluous since my build is passing and I certainly don't want
to drag git needlessly in my buildroot.

The Requires on the other hand are a must, so many thanks for the macro.

One thing that I love is the ability to manage multiple modules at
once. Unfortunately I didn't find how to break the line in the RPM
spec:

> %selinux_modules_install %{_datadir}/selinux/%{selinuxtype}/mod1.cil 
> %{_datadir}/selinux/%{selinuxtype}/mod2.pp

Breaking the line with back-slashes didn't work, the modules weren't
considered arguments to the macro:

> %selinux_modules_install \
>%{_datadir}/selinux/%{selinuxtype}/mod1.cil \
>%{_datadir}/selinux/%{selinuxtype}/mod2.pp

I tried %{selinux_modules_install} and other shenanigans but no luck.

I can live with a long line every now and then :)

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

Fedora 30-20190408.n.0 compose check report

2019-04-08 Thread Fedora compose checker

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Failed openQA tests: 14/144 (x86_64), 1/2 (arm), 2/24 (i386)

ID: 379607  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/379607
ID: 379608  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/379608
ID: 379615  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/379615
ID: 379619  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/379619
ID: 379621  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379621
ID: 379622  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/379622
ID: 379623  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/379623
ID: 379642  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/379642
ID: 379644  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/379644
ID: 379659  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/379659
ID: 379665  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/379665
ID: 379676  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/379676
ID: 379681  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/379681
ID: 379682  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/379682
ID: 379700  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/379700
ID: 379710  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/379710
ID: 379711  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/379711

Soft failed openQA tests: 13/144 (x86_64), 4/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 379550  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379550
ID: 379551  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379551
ID: 379552  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/379552
ID: 379554  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379554
ID: 379578  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/379578
ID: 379579  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379579
ID: 379580  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/379580
ID: 379596  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/379596
ID: 379599  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/379599
ID: 379600  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/379600
ID: 379602  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/379602
ID: 379649  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/379649
ID: 379655  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/379655
ID: 379679  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/379679
ID: 379680  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/379680
ID: 379684  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/379684
ID: 379717  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/379717

Passed openQA tests: 110/144 (x86_64), 18/24 (i386)

Skipped non-gating openQA tests: 8 of 170
-- 
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

Summary/Minutes from today's FESCo Meeting (2019-04-08)

2019-04-08 Thread Stephen Gallagher

=
#fedora-meeting-1: FESCO (2019-04-08)
=


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



Meeting summary
---
* init process  (sgallagh, 15:00:03)
  * ACTION: zbyszek to do whenisgood  (zbyszek, 15:03:37)

* #2102 F31 System-Wide Change: Gating Rawhide Packages  (sgallagh,
  15:04:10)
  * LINK: https://pagure.io/fedora-ci/general/issue/44   (mhroncok,
15:17:05)
  * LINK: https://pagure.io/fedora-ci/general/issue/43   (mhroncok,
15:17:09)
  * LINK:
https://pagure.io/fedora-ci/general/issues?status=Open=new+pipeline
(bookwar, 15:17:52)
  * AGREED: Opt-in gating may be enabled. (+6, 1, -2)  (sgallagh,
15:33:27)

* #2109 Policy revamp: Package Removal for Long-standing FTBFS and FTI
  bugs  (sgallagh, 15:34:20)
  * LINK: https://pagure.io/fesco/issue/2109#comment-563753   (mhroncok,
15:36:36)
  * AGREED: https://pagure.io/fesco/issue/2109#comment-563753 is
approved, with one amendmend that we add an email to pkg-owner@fp.o
at the NEEDINFO step (+8, 0, -0)  (sgallagh, 15:41:56)

* #2113 F31 System-Wide Change: F31 Mass Python 2 Package Removal
  (sgallagh, 15:42:06)
  * AGREED: "F31 Mass Python 2 Package Removal" Change is approved. (+7,
0, -0)  (sgallagh, 15:49:04)

* #2114 What is the scope of Modularity?  (sgallagh, 15:49:11)
  * Discussion is active in the ticket, let it bake there a bit longer.
(sgallagh, 15:51:56)

* #2115 Missing PkgDB features should be implemented  (sgallagh,
  15:52:58)
  * Discussion will continue in the ticket  (sgallagh, 16:11:27)

* #2116 Moving forward with zchunk metadata for F30?  (sgallagh,
  16:11:35)
  * AGREED: Turn zchunk metadata back on (+8, 0, -0)  (sgallagh,
16:15:57)

* #2117 Set skip_if_unavailable=false as default behavior for software
  management tools  (sgallagh, 16:16:37)
  * AGREED: please submit a regular change proposal. fesco recommends
targeting fedora 31 (+7, 0, -0)  (sgallagh, 16:30:23)

* Next week's chair  (sgallagh, 16:30:36)
  * ACTION: bowlofeggs will chair next meeting  (sgallagh, 16:32:39)
  * Available time-slots must be provided to the WhenIsGood (or equiv.)
by 2359 on Thursday. New meeting time will be announced Friday.
(sgallagh, 16:37:34)

* Open Floor  (sgallagh, 16:38:07)

Meeting ended at 16:40:11 UTC.




Action Items

* zbyszek to do whenisgood
* bowlofeggs will chair next meeting




Action Items, by person
---
* bowlofeggs
  * bowlofeggs will chair next meeting
* zbyszek
  * zbyszek to do whenisgood
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (142)
* mhroncok (118)
* bowlofeggs (53)
* nirik (43)
* bookwar (36)
* jforbes (35)
* zodbot (26)
* otaylor (19)
* zbyszek (15)
* pingou (11)
* contyk (11)
* bcotton (4)
* tflink (3)




Generated by `MeetBot`_ 0.1.4

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

Re: Orphaned some Java packages

2019-04-08 Thread Mikolaj Izdebski

On Sat, Mar 30, 2019 at 1:34 AM Christopher  wrote:
>
> On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski  wrote:
> >
> > On Thu, Mar 28, 2019 at 7:46 PM Christopher  
> > wrote:
> > >
> > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski  
> > > wrote:
> > > > - javapackages-tools, stream 201801 (buildroot-only module, not
> > > > intended to be delivered to users)
> > >
> > > How do I enable/install this module locally? It would be very helpful
> > > for local builds/testing, but is not available in:
> > > sudo dnf --releasever=30 module list
> >
> > The official, recommended way of building modules locally is "fedpkg
> > module-build-local". This command should take care of fetching and
> > installing all required dependencies specified in modulemd being
> > built. Therefore in this case it is enough to add dependency on
> > javapackages-tools and it should "just work", for both local and
> > remote builds.
>
> Hmm. I don't know how to do modules yet. I don't know how to create a
> modulemd, or where it lives, or which packages I need to put in which
> module, or how to name modules, or anything. I just want to install
> all the tools from javapackages-tools, so I can do a plain old `fedpkg
> local` build of my regular RPMs. I know this isn't going to work in
> Koji for Fedora... but it would help me, as a user of those tools,
> have access to them for my own RPM building purposes.

You don't have to use these packages. You can keep using traditional,
"ursine" Java packages that are still available in non-modular repos.
These packages new owners who signed up to maintain them.

In addition to the above set of traditional, "ursine", packages, there
is also javapackages-tools module, that contains Java packages
intended for building certain other modules. Module maintainers can
choose whether they want to build their modules using ursine Java
packages, or using javapackages-tools module. Ursine package
maintainers have no such choice and they are limited to depending on
ursine Java packages only.

The original goal was to have a single set of modular packages that
would be used for both building other modules and for building
non-modular ("ursine") packages. However, in the end this set was
split/forked and now we have two package sets, but with different
maintainers. These packages are similar for now, but I expect them to
diverge more over time. I don't like this situation either, but I've
done everything I could to avoid it.

>
> >
> > The module is not included in any compose, therefore dnf won't be able
> > to find it in default repos. If you really want to install the module
> > on your system for some reason then you can use ODCS [1] to generate a
> > compose containing the module. Install ODCS client with "dnf install
> > odcs-client" and then request compose with "odcs create module
> > javapackages-tools:201801". ODCS will (usually) quickly create repo
> > with the module and output repo URL, which you can put in a config
> > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
> > option. Note that contents of javapackages-tools module are not signed
> > and therefore you need to skip GPG verification in order to be able to
> > install it.
>
> It seems a bit crazy to me that we have packages built for Fedora that
> aren't available for users to install. Why wouldn't we make everything
> maximally available? I used to love Fedora, because I just play with
> all the bits. But now, a lot of those bits are going away... I have
> less to play with... and the focus seems more targeted towards
> Fedora's internal needs, and not Fedora's users needs. Contributing to
> Fedora is so much harder now. Do we have to make it harder by making
> certain packages unavailable to regular users (and casual
> packager-contributors like me)?

We already have packages that are built by Fedora and for Fedora, but
are not distributed to users for various reasons. These include
glibc32, some buildroot overrides and even non-distributable-rpms [1],
which are not only not included in Fedora repos, but also users are
also blocked from downloading them from Koji.

[1] https://fedoraproject.org/wiki/Non-distributable-rpms

--
Mikolaj Izdebski
___
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: Catch 22 in epel7 for %selinux_requires

2019-04-08 Thread Vit Mojzis



On 05. 04. 19 15:58, Dridi Boukelmoune wrote:

On Fri, Apr 5, 2019 at 3:36 PM Dridi Boukelmoune
 wrote:

I think I found the solution here:

https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy

 BuildRequires: selinux-policy
 %{?selinux_requires}

This way its expansion can be deferred at rebuild time, I suppose. But
don't we miss the other BuildRequires tags in this case?

We do:

 make: /usr/share/selinux/devel/Makefile: No such file or directory

A different catch 22 now :(

I ended up with this, and it seems to cover all my needs:

 BuildRequires: selinux-policy
 BuildRequires: /usr/share/selinux/devel/Makefile



Thank you for the feedback. You are correct that the BuildRequires in 
the macro are useless. At this point I have no idea how to get around 
the macro expansion. I will at least add selinux-policy-devel package 
BuildRequire to the Packaging guidelines.


If you have any more issues with shipping custom policy, feel free to CC 
me so that I get to you sooner.


Vit



 %{?selinux_requires}

I'm a bit curious on how things could improve on epel7, but having the
macros in the first place is already very helpful!

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

Re: Orphaned some Java packages

2019-04-08 Thread Mikolaj Izdebski

On Fri, Mar 29, 2019 at 11:25 AM Aleksandra Fedorova  wrote:
> if I understand correctly, you say that javapackages-tools module is not 
> included in any Fedora Modular repositories.

That is correct.

> But you want it to be included in Fedora buildroot through Ursa Major.

No, not any longer.

> Can you explain why you don't make it available through a Modular repo?

Because that requires too much effort from my side. More effort that I
can spend on Fedora package maintenance. Shipping content to users has
serious implications, coming from "Package maintainers responsibility"
and other policies and documents. By limiting "supported" use case of
the module to only building other Fedora package I can reduce the work
required to maintain the module by at least a factor of two.

--
Mikolaj Izdebski
___
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: python-zstd?

According to the discussion here:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-April/130061.html

I think maybe we may instead ask to bundle a statically linked zstd with 
mercurial 4.9.  

Thanks,
Neal

Neal Gompa wrote:

> On Mon, Apr 8, 2019 at 8:21 AM Neal Becker  wrote:
>>
>> Neal Gompa wrote:
>>
>> > On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok 
>> > wrote:
>> >>
>> >> On 08. 04. 19 13:28, Neal Becker wrote:
>> >> > mercurial 4.9 packages zstd and python wrapper.
>> >> >
>> >> > I think we need to use system zstd.  But I don't see python2-zstd.
>> >> >
>> >> > Is anyone working on packaging python2-zstd?  It would be needed to
>> >> > proceed
>> >> > with mercurial 4.9.  (I haven't yet checked on version number
>> >> > compatibility).
>> >>
>> >> To add new python2 package, an exception from FPC or FESCo is needed.
>> >>
>> >> Can we instead update to directly to hg 5.0 in May and switch to
>> >> Python 3?
>> >>
>> >
>> > If all the reverse dependencies of Mercurial in Fedora are made ready
>> > in time, we probably could. But that's still past the expected release
>> > date for Fedora 30.
>> >
>> > Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
>> > we can do is allow python-zstd in the distribution with an exception
>> > to allow including a python2-zstd subpackage in addition to the
>> > python3-zstd subpackage.
>> >
>>
>> I think mercurial 5.0 on python3 is not quite ready for production use. 
>> I prefer to plan on mercurial 4.9 and package python-zstd, including a
>> python2-zstd.
> 
> I'd like for us to ship Mercurial 5.0 on Python 3 in Fedora Rawhide
> for sure. I think the six(ish) months of baking in Rawhide should be
> sufficient for getting Mercurial ready to go for production use on
> Python 3 and getting the reverse dependencies ported.
> 
> 

___
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 30 compose report: 20190408.n.0 changes

2019-04-08 Thread Fedora Branched Report

OLD: Fedora-30-20190407.n.0
NEW: Fedora-30-20190408.n.0

= SUMMARY =
Added images:8
Dropped images:  7
Added packages:  6
Dropped packages:0
Upgraded packages:   31
Downgraded packages: 0

Size of added packages:  58.47 MiB
Size of dropped packages:0 B
Size of upgraded packages:   565.63 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190408.n.0.x86_64.vagrant-virtualbox.box
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-30-20190408.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190408.n.0.x86_64.vagrant-libvirt.box
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-30-20190408.n.0.iso
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-30-20190408.n.0-sda.raw.xz
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-30-20190408.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-30-20190408.n.0.s390x.tar.xz
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-30-20190408.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-30-20190407.n.0.aarch64.raw.xz
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-30-20190407.n.0.iso
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-30-20190407.n.0.iso
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-30-20190407.n.0-sda.raw.xz
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-30-20190407.n.0-sda.raw.xz
Image: Python_Classroom live i386
Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-30-20190407.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-30-20190407.n.0.iso

= ADDED PACKAGES =
Package: bifcl-1.1-1.fc30
Summary: A built-in-function (BIF) compiler/generator
RPMs:bifcl
Size:226.05 KiB

Package: ccls-0.20190314-1.fc30
Summary: C/C++/ObjC language server
RPMs:ccls
Size:3.13 MiB

Package: crossguid2-0.2.2-1.20190126gitb151b7d.fc30
Summary: Lightweight cross platform C++ GUID/UUID library
RPMs:crossguid2 crossguid2-devel
Size:172.47 KiB

Package: js8call-1.0.0-2.fc30
Summary: Amateur Radio message passing using FT8 modulation
RPMs:js8call
Size:54.38 MiB

Package: python-resumable-urlretrieve-0.1.6-1.fc30
Summary: Small library to fetch files over HTTP and resume their download
RPMs:python3-resumable-urlretrieve
Size:14.57 KiB

Package: python-zarr-2.3.1-2.fc30
Summary: An implementation of chunked, compressed, N-dimensional arrays for 
Python
RPMs:python-zarr-doc python3-zarr
Size:567.66 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  automoc-1.0-0.34.rc3.fc30
Old package:  automoc-1.0-0.33.rc3.fc30
Summary:  Automatic moc for Qt 4
RPMs: automoc
Size: 190.45 KiB
Size change:  1.43 KiB
Changelog:
  * Tue Apr 02 2019 Rex Dieter  - 1.0-0.34.rc4
  - rebuild, use %make_build


Package:  batctl-2019.1-1.fc30
Old package:  batctl-2019.0-1.fc30
Summary:  B.A.T.M.A.N. advanced control and management tool
RPMs: batctl
Size: 454.57 KiB
Size change:  34.44 KiB
Changelog:
  * Tue Apr 02 2019 Felix Kaechele  - 2019.1-1
  - update to 2019.1


Package:  capstats-0.26-3.fc30
Old package:  capstats-0.26-2.fc30
Summary:  A command-line tool collecting packet statistics
RPMs: capstats
Size: 119.80 KiB
Size change:  -736 B
Changelog:
  * Tue Mar 19 2019 Fabian Affolter  - 0.26-3
  - Update details as project was renamed


Package:  cockpit-191-1.fc30
Old package:  cockpit-190-1.fc30
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc 
cockpit-docker cockpit-kdump cockpit-machines cockpit-networkmanager 
cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport 
cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 16.23 MiB
Size change:  52.02 KiB
Changelog:
  * Wed Apr 03 2019 Marius Vollmer  - 191-1
  - Machines: iSCSI Storage pools
  - Machines: better notifications
  - System: CPU security mitigation
  - Network: Ports in the Firewall


Package:  crawl-0.23.2-1.fc30
Old package:  crawl-0.23.1-1.fc30
Summary:  Roguelike dungeon exploration game
RPMs: crawl crawl-common-data crawl-tiles crawl-tiles-data
Size: 54.56 MiB
Size change:  4.26 KiB
Changelog:
  * Tue Apr 02 2019 Antonio Trande  - 0.23.2-1
  - Upstream bugfix release 0.23.2


Package:  deepin-icon-theme-15.12.68-2.fc30

Re: Sphinx and xindy

2019-04-08 Thread Jerry James

On Mon, Apr 1, 2019 at 9:36 PM Jerry James  wrote:
> That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> Sadly, the clisp build is still failing in Rawhide, with failures in
> the socket tests:

The failing test attempts to bind to localhost:9090.  Apparently
something on the s390x koji builders binds that port.  The test is
arguably broken; it should iterate over successive port numbers until
if finds one that is available, rather than picking a single port
number and failing if that port is unavailable.  Anyway, I "fixed" it
for now by choosing a different port number.  I'll ask upstream to
really fix it.

So clisp has been built for all architectures in Rawhide now.  I
cannot build it for F30 yet, because the version of gcc with the s390x
fix has not yet been submitted as an update.  Regardless, can somebody
who knows how to build xindy try it in Rawhide and let me know if
there are problems doing so?  Or give me instructions on how to build
it myself?  Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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-20190408.n.0 compose check report

2019-04-08 Thread Fedora compose checker

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose FAILS proposed Rawhide gating check!
30 of 47 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 91/135 (x86_64), 23/24 (i386), 1/2 (arm)

ID: 379355  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/379355
ID: 379356  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/379356
ID: 379357  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/379357
ID: 379359  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/379359
ID: 379362  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/379362
ID: 379370  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/379370
ID: 379372  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/379372
ID: 379382  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/379382
ID: 379384  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379384
ID: 379385  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/379385
ID: 379386  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/379386
ID: 379387  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/379387
ID: 379388  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379388
ID: 379389  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/379389
ID: 379390  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/379390
ID: 379392  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/379392
ID: 379402  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/379402
ID: 379403  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/379403
ID: 379405  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/379405
ID: 379406  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/379406
ID: 379408  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379408
ID: 379409  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/379409
ID: 379410  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/379410
ID: 379411  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/379411
ID: 379412  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/379412
ID: 379423  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/379423
ID: 379424  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/379424
ID: 379426  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/379426
ID: 379427  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/379427
ID: 379428  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/379428
ID: 379429  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/379429
ID: 379430  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/379430
ID: 379431  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/379431
ID: 379432  Test: x86_64 universal install_scsi_updates_img **GATING**
URL: https://openqa.fedoraproject.org/tests/379432
ID: 379433  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/379433
ID: 379434  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/379434
ID: 379435  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/379435
ID: 379436  Test: x86_64 universal

[EPEL-devel] Re: RHEL/CentOS 8.x and KDE

2019-04-08 Thread Nicolas Kovacs

Le 08/04/2019 à 15:10, Troy Dawson a écrit :
> There are several of us that are KDE users (Well, I am, and I assume 
> there are others). It will probably be a case of figuring out who is
> the maintainer or if we do it as a group. There are a few of us who
> have rebuilt it already for RHEL8 Beta.  As far as I know, I am the
> only one who is sharing my repo publically.[1] So if you want to test
> it out while you test the RHEL8 Beta, you can.

Well, that's good news. I'm not in a particular hurry to test this. I
only wanted to be reassured that KDE has some kind of future on
RHEL/CentOS systems. It has been my favorite desktop since version 2.4
on Slackware 7.1, and my clients also enjoy working with it. Thanks for
working on this.

Cheers from the sunny South of France,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: HEADS UP: Pytest 4 in rawhide


On 08. 04. 19 8:00, Miro Hrončok wrote:

Pytest has been updated to 4.3.1 and most likely will get updated to 4.4 soon.

We had pytest 3.9 before. This is backward incompatible update. See removed 
things at:


https://docs.pytest.org/en/latest/deprecations.html#removed-features
https://docs.pytest.org/en/latest/changelog.html

If you get git by [pytest] section in setup.cfg files, this sed in %prep will 
do, but please communicate with your upstreams:


     sed -i 's/\[pytest\]/\[tool:pytest\]/' setup.cfg

Should you hit any trouble, please report bugs and block

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



If you get:

TypeError: object of type 'MarkDecorator' has no len()

It is 
https://docs.pytest.org/en/latest/deprecations.html#marks-in-pytest-mark-parametrize



--
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 compose report: 20190408.n.0 changes

2019-04-08 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20190407.n.1
NEW: Fedora-Rawhide-20190408.n.0

= SUMMARY =
Added images:4
Dropped images:  2
Added packages:  2
Dropped packages:0
Upgraded packages:   13
Downgraded packages: 0

Size of added packages:  1.05 MiB
Size of dropped packages:0 B
Size of upgraded packages:   52.84 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   439.42 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20190408.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190408.n.0.s390x.tar.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20190408.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20190408.n.0.iso

= DROPPED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20190407.n.1.iso
Image: Mate live i386
Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20190407.n.1.iso

= ADDED PACKAGES =
Package: butt-0.1.17-2.fc31
Summary: Broadcast using this tool
RPMs:butt
Size:960.95 KiB

Package: swayidle-1.2-5.fc31
Summary: An idle daemon for wayland compositors
RPMs:swayidle
Size:118.07 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-ggplot2-3.1.1-1.fc31
Old package:  R-ggplot2-3.1.0-1.fc31
Summary:  Create Elegant Data Visualisations Using the Grammar of Graphics
RPMs: R-ggplot2
Size: 3.49 MiB
Size change:  -11.93 KiB
Changelog:
  * Sun Apr 07 2019 Elliott Sales de Andrade  - 
3.1.1-1
  - Update to latest version


Package:  R-rlang-0.3.4-1.fc31
Old package:  R-rlang-0.3.3-1.fc31
Summary:  Functions for Base Types and Core R and 'Tidyverse' Features
RPMs: R-rlang
Size: 6.33 MiB
Size change:  -7.48 KiB
Changelog:
  * Sun Apr 07 2019 Elliott Sales de Andrade  - 
0.3.4-1
  - Update to latest version


Package:  getdns-1.5.2-2.fc31
Old package:  getdns-1.5.2-1.rc1.fc31
Summary:  Modern asynchronous API to the DNS
RPMs: getdns getdns-devel getdns-stubby
Size: 2.35 MiB
Size change:  5.68 KiB
Changelog:
  * Sun Apr 07 2019 Petr Menk  - 1.5.2-2
  - Update to 1.5.2 (#1689431)


Package:  parole-1.0.2-1.fc31
Old package:  parole-1.0.1-4.fc30
Summary:  Media player for the Xfce desktop
RPMs: parole parole-devel
Size: 2.79 MiB
Size change:  79.59 KiB
Changelog:
  * Sun Apr 07 2019 Kevin Fenzi  - 1.0.2-1
  - Upgrade to 1.0.2.


Package:  pytest-4.3.1-1.fc31
Old package:  pytest-3.9.3-2.fc30
Summary:  Simple powerful testing with Python
RPMs: python2-pytest python3-pytest
Size: 3.03 MiB
Size change:  86.44 KiB
Changelog:
  * Mon Feb 18 2019 Igor Gnatenko  - 3.9.3-3
  - Enable python dependency generator

  * Tue Mar 12 2019 Miro Hron??ok  - 4.3.0-1
  - Update to 4.3.0 and fix FTBFS (#1671167, #1687384)

  * Sat Mar 16 2019 Miro Hron??ok  - 4.3.1-1
  - Update to 4.3.1


Package:  python-PyMuPDF-1.14.13-1.fc31
Old package:  python-PyMuPDF-1.14.12-1.fc31
Summary:  Python binding for MuPDF - a lightweight PDF and XPS viewer
RPMs: python-PyMuPDF-doc python3-PyMuPDF
Size: 15.97 MiB
Size change:  10.86 KiB
Changelog:
  * Mon Apr 08 2019 Scott Talbert  - 1.14.13-1
  - New upstream release 1.14.13


Package:  python-apprise-0.7.5-1.fc31
Old package:  python-apprise-0.7.4-1.fc31
Summary:  A simple wrapper to many popular notification services used today
RPMs: apprise python3-apprise
Size: 639.15 KiB
Size change:  26.59 KiB
Changelog:
  * Sun Apr 07 2019 Chris Caron  - 0.7.5-1
  - Updated to v0.7.5


Package:  python-click-plugins-1.1.1-1.fc31
Old package:  python-click-plugins-1.0.4-3.fc30
Summary:  Click extension to register CLI commands via setuptools
RPMs: python3-click-plugins
Size: 16.69 KiB
Size change:  44 B
Changelog:
  * Mon Apr 08 2019 Elliott Sales de Andrade  - 
1.1.1-1
  - Update to latest version


Package:  python-empy-3.3.4-1.fc31
Old package:  python-empy-3.3.3-5.fc30
Summary:  A powerful and robust template system for Python
RPMs: python2-empy python3-empy
Size: 213.04 KiB
Size change:  -56 B
Changelog:
  * Sun Apr 07 2019 Filipe Rosset  - 3.3.4-1
  - Update to latest 3.3.4 upstream release, fixes rhbz #1697143


Package:  python-pygit2-0.27.4-1.module_f31+3865+3ca66503
Old package:  python-pygit2-0.27.4-1.module_f31+3326+1efaac5b
Summary:  Python bindings for libgit2
RPMs: python-pygit2-doc python2-pygit2 python3-pygit2
Size: 4.44 MiB
Size change:  -6.23 KiB

Package:  ristretto-0.8.4-1.fc31
Old package:  ristretto-0.8.3-21.fc30
Summary:  Image-viewer for the Xfce desktop environment
RPMs: ristretto
Size: 2.35 MiB
Size change

Re: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Kalev Lember



On 4/8/19 15:16, mcatanz...@gnome.org wrote:
- Plain builds should match the behavior of release builds, and Fedora 
plain builds should match the behavior of upstream plain builds. This is 
what we briefly had but just reverted. (Option one)


I believe this is the case already in upstream meson git master. Igor,
correct me if I'm wrong.

--
Kalev
___
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: Rawhide issue with python3-wxpython4

2019-04-08 Thread Steven A. Falco

On 4/7/19 8:35 PM, Scott Talbert wrote:
> On Sun, 7 Apr 2019, Steven A. Falco wrote:
> 
>> The KiCad package uses python3-wxpython4 - I'm one of the package 
>> maintainers.  KiCad is building correctly on Fedora 30, but my rawhide 
>> builds are failing with the following error:
>>
>> BUILDSTDERR:   - nothing provides python3-sip-api(12)(x86-64) = 12.5 needed 
>> by python3-wxpython4-4.0.4-2.fc30.x86_64
>>
>> It looks like the sip package was upgraded to 12.6 recently (March 21, 
>> 2019).  Here is part of the changelog from the sip.spec file:
>>
>> %changelog
>> * Thu Mar 21 2019 Rex Dieter  - 4.19.15-1
>> - 4.19.15, - sip-api(12)=12.6
>>
>> It seems like the python3-wxpython4 package should be rebuilt to pick up 
>> that change.
>>
>> I am new to this part of the process.  How might I request a rebuild of 
>> python3-wxpython4, and would that fix the problem or is something additional 
>> needed?
> 
> The python-wxpython4 package needs to be rebuilt every time that the SIP API 
> changes.  @Rex - can you please initiate a build when you bump the SIP API?
> 
> Currently, though, wxPython is FTBFS in Rawhide [1] due to changes in SIP 
> 4.19.14 and 4.19.15.  I've got the SIP 4.19.14 changes addressed in wxPython, 
> but 4.19.15 introduced some bugs in SIP which I'm addressing with SIP 
> upstream.  Hopefully, there should be a new SIP release soon.
> 
> Bottom line - the issues are being worked on.  :)
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1696302

Thanks Scott.  I tried building wxPython locally and ran into the same FTBFS.  
I'll stand by until the upstream issues get resolved.

Steve
___
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: Pytest 4 in rawhide


Pytest has been updated to 4.3.1 and most likely will get updated to 4.4 soon.

We had pytest 3.9 before. This is backward incompatible update. See removed 
things at:


https://docs.pytest.org/en/latest/deprecations.html#removed-features
https://docs.pytest.org/en/latest/changelog.html

If you get git by [pytest] section in setup.cfg files, this sed in %prep will 
do, but please communicate with your upstreams:


sed -i 's/\[pytest\]/\[tool:pytest\]/' setup.cfg

Should you hit any trouble, please report bugs and block

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

Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Schedule for Monday's FESCo Meeting (2019-04-08)

2019-04-08 Thread Stephen Gallagher

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

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

or run:
  date -d '2019-04-08 15:00 UTC'


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

= Discussed and Voted in the Ticket =


= Followups =

#topic #2102 F31 System-Wide Change: Gating Rawhide Packages
.fesco 2102
https://pagure.io/fesco/issue/2102

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

= New business =

#topic #2113 F31 System-Wide Change: F31 Mass Python 2 Package Removal
.fesco 2113
https://pagure.io/fesco/issue/2113

#topic #2114 What is the scope of Modularity?
.fesco 2114
https://pagure.io/fesco/issue/2114

#topic #2115 Missing PkgDB features should be implemented
.fesco 2115
https://pagure.io/fesco/issue/2115

#topic #2116 Moving forward with zchunk metadata for F30?
.fesco 2116
https://pagure.io/fesco/issue/2116

#topic #2117 Set skip_if_unavailable=false as default behavior for
software management tools
.fesco 2117
https://pagure.io/fesco/issue/2117

= Open Floor =

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

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

Re: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread mcatanzaro

On Mon, Apr 8, 2019 at 5:50 AM, Kalev Lember  
wrote:
I agree as well. Please don't override -Db_ndebug in distro-wide 
%meson
macro and instead move the override to mesa packaging if it's needed 
there.


Well hold up. -Db_ndebug defaults to if-release... right? We have only 
changed the behavior for plain builds (distro builds) to match release 
builds? So any package that has ever tested a release build would 
already know to expect assertions to be disabled, and the only broken 
packages are those that have never tested a release build?


I see three options:

- Plain builds should match the behavior of release builds, and Fedora 
plain builds should match the behavior of upstream plain builds. This 
is what we briefly had but just reverted. (Option one)


- Upstream plain builds should be really completely plain. Fedora can 
either add on -Db_ndebug=true or not (options two and three). This 
makes less sense to me because -Db_ndebug is really special, not like 
other compiler flags.


I don't think it's right to say "NDEBUG should be off by default 
because that's how it is with Autotools" since we're not Autotools 
anymore, we should decide something that makes sense for meson, based 
on meson semantics and meson expectations and in coordination with 
meson upstream. E.g. I see you (Igor) reverted the RPM macro change, 
but that was just the bandaid over the default behavior of if-release, 
which is actually still changed, right? It's unclear to me what the 
default value of -Db_ndebug is due to underdocumentation, but if it's 
if-release then this change is just going to reappear again in the next 
version of meson, right?


Michael

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

[EPEL-devel] Re: RHEL/CentOS 8.x and KDE

2019-04-08 Thread Troy Dawson

Yes.
There are several of us that are KDE users (Well, I am, and I assume
there are others).
It will probably be a case of figuring out who is the maintainer or if
we do it as a group.
There are a few of us who have rebuilt it already for RHEL8 Beta.  As
far as I know, I am the only one who is sharing my repo publically.[1]
 So if you want to test it out while you test the RHEL8 Beta, you can.
Notes about my repo.
1 - I removed all KDE4 references
2 - I removed most python2 references.
3 - Not all kde applications built.  Here is my list of packages that
are not in my repo.[2]

Troy

[1] - https://tdawson.fedorapeople.org/epel8/kde/
[2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built

On Sat, Apr 6, 2019 at 1:10 AM Nicolas Kovacs  wrote:
>
> Hi,
>
> I'm a CentOS user since version 4.x, not only on servers, but also on
> desktops. The EPEL repository is a precious addition for my desktop
> configurations.
>
> Currently I have CentOS 7 + KDE running on most of my client machines.
> Here's my setup, which relies heavily on EPEL:
>
>   * https://www.microlinux.fr/poste-de-travail-entreprise-centos-7-kde/
>
> Now that KDE is officially deprecated by Red Hat, I wonder if my
> favorite desktop environment will be made available for Red Hat 8.x by
> EPEL. So I thought I'd simply ask the EPEL maintainers. Are there any
> plans for doing so ?
>
> Thanks & Cheers from the rainy South of France,
>
> Niki Kovacs
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> ___
> 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 mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: python-zstd?


On 08. 04. 19 14:01, Neal Gompa wrote:

On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok  wrote:


On 08. 04. 19 13:28, Neal Becker wrote:

mercurial 4.9 packages zstd and python wrapper.

I think we need to use system zstd.  But I don't see python2-zstd.

Is anyone working on packaging python2-zstd?  It would be needed to proceed
with mercurial 4.9.  (I haven't yet checked on version number
compatibility).


To add new python2 package, an exception from FPC or FESCo is needed.

Can we instead update to directly to hg 5.0 in May and switch to Python 3?



If all the reverse dependencies of Mercurial in Fedora are made ready
in time, we probably could. But that's still past the expected release
date for Fedora 30.

Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
we can do is allow python-zstd in the distribution with an exception
to allow including a python2-zstd subpackage in addition to the
python3-zstd subpackage.


Sure, I'd support such exception. Given that we put hg 5 on python3 to rawhide 
so we can figure it out during the F31 dev cycle.


--
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: F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

2019-04-08 Thread Dominik 'Rathann' Mierzejewski

On Friday, 05 April 2019 at 10:00, Petr Pisar wrote:
[...]
> What's the point of encrypting /boot? All the executed bits from /boot
> (grub, kernel, and initramdisk) are measured by TPM. Thus if somebody
> tampers them, root file system decryption that uses TPM will fail.

Not everyone has a TPM chip in their machine...

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: vanishing abrt logs

2019-04-08 Thread Miroslav Suchý

Dne 08. 04. 19 v 13:18 jfi...@fedoraproject.org napsal(a):
> Hi Kevin,
> 
> I was under the impression that the problem with many emails from Bugzilla 
> has already been fixed:
> https://bugzilla.redhat.com/show_bug.cgi?id=1660157
> https://github.com/abrt/libreport/commit/569bf0e3fed698e93b8e098bf6a0bb2f773aed6a
> 

Yes, it was fixed in libreport-2.10.0. But if somebody report with older 
version, you will receive the Bugzilla spam. :(

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

Re: python-zstd?

2019-04-08 Thread Neal Gompa

On Mon, Apr 8, 2019 at 8:21 AM Neal Becker  wrote:
>
> Neal Gompa wrote:
>
> > On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok  wrote:
> >>
> >> On 08. 04. 19 13:28, Neal Becker wrote:
> >> > mercurial 4.9 packages zstd and python wrapper.
> >> >
> >> > I think we need to use system zstd.  But I don't see python2-zstd.
> >> >
> >> > Is anyone working on packaging python2-zstd?  It would be needed to
> >> > proceed
> >> > with mercurial 4.9.  (I haven't yet checked on version number
> >> > compatibility).
> >>
> >> To add new python2 package, an exception from FPC or FESCo is needed.
> >>
> >> Can we instead update to directly to hg 5.0 in May and switch to Python
> >> 3?
> >>
> >
> > If all the reverse dependencies of Mercurial in Fedora are made ready
> > in time, we probably could. But that's still past the expected release
> > date for Fedora 30.
> >
> > Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
> > we can do is allow python-zstd in the distribution with an exception
> > to allow including a python2-zstd subpackage in addition to the
> > python3-zstd subpackage.
> >
>
> I think mercurial 5.0 on python3 is not quite ready for production use.  I
> prefer to plan on mercurial 4.9 and package python-zstd, including a
> python2-zstd.

I'd like for us to ship Mercurial 5.0 on Python 3 in Fedora Rawhide
for sure. I think the six(ish) months of baking in Rawhide should be
sufficient for getting Mercurial ready to go for production use on
Python 3 and getting the reverse dependencies ported.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: vanishing abrt logs

2019-04-08 Thread jfilak

I agree, but the file /proc/meminfo is not present, right?
And yes, the abrt thing just reads the data from journal and

stores them on filesystem to be able to upload them to Bugzilla.

Regarding the missing logs, the journal log lines should

be extracted by this thing:

https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25
(https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25)

which is a little bit complex, so no wonder if it is broken

(I am just not sure why the abrt test suite is not failing though).

Regarding the core files, I was under the impression that

the core files can be attached only if the reporter wants to attach it.

IOW the core files were never attached automatically (due to security
issues).

If you need some information that is relevant only to your packages,

we can work together to create a new abrt configuration which will

gather that information for your packages

(for example, dnf ships its own abrt configuration).

Regards,

Jakub

-- Původní e-mail --

Od: Zbigniew Jędrzejewski-Szmek 
Komu: Development discussions related to Fedora 
Datum: 8. 4. 2019 13:49:41
Předmět: Re: vanishing abrt logs
"On Mon, Apr 08, 2019 at 01:27:10PM +0200, jfi...@fedoraproject.org wrote:
> Hi Zbyszek,
>
>
>
> If you want more files attached to ABRT Bugzilla reports, please add them
to
> systemd-coredump first :)
>
> https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L
1074
> (https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L
1074)

In a sense, they already *are* attached to systemd-coredump. coredumpctl is
basically just a journal query, and all the information I asked for is also
present in the journal. abrt already extract *some* logs from the journal,
so it's a question of adjusting the filters.

The other thing which is missing from abrt reports is the corefile. In the
past we used to have that attached. It would be great to have it again. 
(For example in case of memory structure errors, the backtrace itself is 
not particularly useful, but a lot could be diagnosed by examining the
structures
in memory. But I can't look at all reports quickly, and when I ask
reporters if they have the core file, after a month or two the answer is 
usually "not anymore".).

I *am* trying to solve the abrt reports that are files for my packages, but
it's getting harder to do.

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
"

___
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: python-zstd?

Neal Gompa wrote:

> On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok  wrote:
>>
>> On 08. 04. 19 13:28, Neal Becker wrote:
>> > mercurial 4.9 packages zstd and python wrapper.
>> >
>> > I think we need to use system zstd.  But I don't see python2-zstd.
>> >
>> > Is anyone working on packaging python2-zstd?  It would be needed to
>> > proceed
>> > with mercurial 4.9.  (I haven't yet checked on version number
>> > compatibility).
>>
>> To add new python2 package, an exception from FPC or FESCo is needed.
>>
>> Can we instead update to directly to hg 5.0 in May and switch to Python
>> 3?
>>
> 
> If all the reverse dependencies of Mercurial in Fedora are made ready
> in time, we probably could. But that's still past the expected release
> date for Fedora 30.
> 
> Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
> we can do is allow python-zstd in the distribution with an exception
> to allow including a python2-zstd subpackage in addition to the
> python3-zstd subpackage.
> 

I think mercurial 5.0 on python3 is not quite ready for production use.  I 
prefer to plan on mercurial 4.9 and package python-zstd, including a 
python2-zstd.
___
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: Anitya not working again?

2019-04-08 Thread Robert-André Mauchin

On Monday, 8 April 2019 13:40:15 CEST Michal Konecny wrote:
> Hi,
> 
> it took some time, but it's done now.
> 
> Regards,
> mkonecny
> 

Thanks!

___
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 1697126] perl-Excel-Writer-XLSX-1.00 is available

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



--- Comment #1 from Fedora Update System  ---
perl-Excel-Writer-XLSX-1.00-1.fc30 has been submitted as an update to Fedora
30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba8f0510

-- 
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 1697126] perl-Excel-Writer-XLSX-1.00 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Excel-Writer-XLSX-1.00
   ||-1.fc31
   Assignee|dd...@cpan.org  |jples...@redhat.com



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

Re: python-zstd?

2019-04-08 Thread Neal Gompa

On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok  wrote:
>
> On 08. 04. 19 13:28, Neal Becker wrote:
> > mercurial 4.9 packages zstd and python wrapper.
> >
> > I think we need to use system zstd.  But I don't see python2-zstd.
> >
> > Is anyone working on packaging python2-zstd?  It would be needed to proceed
> > with mercurial 4.9.  (I haven't yet checked on version number
> > compatibility).
>
> To add new python2 package, an exception from FPC or FESCo is needed.
>
> Can we instead update to directly to hg 5.0 in May and switch to Python 3?
>

If all the reverse dependencies of Mercurial in Fedora are made ready
in time, we probably could. But that's still past the expected release
date for Fedora 30.

Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing
we can do is allow python-zstd in the distribution with an exception
to allow including a python2-zstd subpackage in addition to the
python3-zstd subpackage.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: hg + zstd packaging

Neal Becker wrote:

> Hi, I'm helping to maintain hg on Fedora.
> 
> Fedora has a policy of using system libraries where possible.
> 
> Fedora currently has libzstd (1.3.8), but does not appear to have python2-
> zstd module.
> 
> I think we need to build hg to use the system libzstd, and to also package
> python2-zstd seperately.
> 
> Does this plan sound OK?
> ___
Sorry, sent to wrong list! 
___
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: Anitya not working again?

2019-04-08 Thread Michal Konecny


Hi,

it took some time, but it's done now.

Regards,
mkonecny

On 08/04/19 01:18, Robert-André Mauchin wrote:

On Wednesday, 3 April 2019 16:53:06 CEST Michal Konecny wrote:

Done, you should see new bugs in a few minutes.

mkonecny


May I ask you to do it again for the following list of Python packages?
There are more than 600.

Thanks,

Robert-André



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


___
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: vanishing abrt logs

2019-04-08 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Apr 08, 2019 at 01:27:10PM +0200, jfi...@fedoraproject.org wrote:
> Hi Zbyszek,
> 
> 
> 
> If you want more files attached to ABRT Bugzilla reports, please add them to
> systemd-coredump first :)
> 
> https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074
> (https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074)

In a sense, they already *are* attached to systemd-coredump. coredumpctl is
basically just a journal query, and all the information I asked for is also
present in the journal. abrt already extract *some* logs from the journal,
so it's a question of adjusting the filters.

The other thing which is missing from abrt reports is the corefile. In the
past we used to have that attached. It would be great to have it again.
(For example in case of memory structure errors, the backtrace itself is
not particularly useful, but a lot could be diagnosed by examining the 
structures
in memory. But I can't look at all reports quickly, and when I ask
reporters if they have the core file, after a month or two the answer is
usually "not anymore".).

I *am* trying to solve the abrt reports that are files for my packages, but
it's getting harder to do.

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: python-zstd?


On 08. 04. 19 13:28, Neal Becker wrote:

mercurial 4.9 packages zstd and python wrapper.

I think we need to use system zstd.  But I don't see python2-zstd.

Is anyone working on packaging python2-zstd?  It would be needed to proceed
with mercurial 4.9.  (I haven't yet checked on version number
compatibility).


To add new python2 package, an exception from FPC or FESCo is needed.

Can we instead update to directly to hg 5.0 in May and switch to Python 3?

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

hg + zstd packaging

Hi, I'm helping to maintain hg on Fedora.

Fedora has a policy of using system libraries where possible.

Fedora currently has libzstd (1.3.8), but does not appear to have python2-
zstd module.

I think we need to build hg to use the system libzstd, and to also package 
python2-zstd seperately. 

Does this plan sound OK?
___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Apr 08, 2019 at 12:50:06PM +0200, Kalev Lember wrote:
> 
> On 4/8/19 11:13, Florian Weimer wrote:
> >* Peter Hutterer:
> >
> >>On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor Gnatenko wrote:
> >>>Hello,
> >>>
> >>>While fixing mesa build which was slow due to a lot off debug stuff
> >>>(assert()), I've added -Db_ndebug=true into the %meson macro.
> >>>
> >>>This seemed like good approach because in Fedora we should not use debug
> >>>bits in runtime (not related to debuginfo). However this caused some
> >>>breakage in some packages like libratbag which was relying on assert() in
> >>>tests. This should be really fixed in affected packages..
> >>>
> >>>I am not convinced that we should revert meson change.. Let me know if you
> >>>think otherwise and why.
> >>
> >>IMO if asserts cause a slow build in mesa, mesa should disable asserts.
> >>
> >>Pushing this into the build system means you're changing the behaviour of
> >>every package build with meson. I rely on asserts in several packages for
> >>paths that must not happen - removing those asserts means instead of
> >>crashing we now have undefined behaviour, probably leaking things.
> >
> >I agree.
> >
> >Fedora should follow upstream defaults here, like most other
> >distributions.  Most upstreams leave assertions enabled.
> 
> I agree as well. Please don't override -Db_ndebug in distro-wide %meson
> macro and instead move the override to mesa packaging if it's needed there.

FWIW, we also build systemd in Fedora with assertions enabled in hope
of catching bugs early, and I was surprised when I noticed that it got
disabled by the macro. If the macro was being introduced now, I wouldn't
have a strong opinion whether b_ndebug=true or b_ndebug=false is the
right default. But I agree that we shouldn't *change* the setting, at
least not without making the change much more visible.

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

python-zstd?

mercurial 4.9 packages zstd and python wrapper.

I think we need to use system zstd.  But I don't see python2-zstd.

Is anyone working on packaging python2-zstd?  It would be needed to proceed 
with mercurial 4.9.  (I haven't yet checked on version number 
compatibility).

Thanks,
Neal
___
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: vanishing abrt logs

2019-04-08 Thread jfilak

Hi Zbyszek,



If you want more files attached to ABRT Bugzilla reports, please add them to
systemd-coredump first :)

https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074
(https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074)





so ABRT folks can simply list them in their white-list:

https://github.com/abrt/abrt/blob/master/src/plugins/abrt-dump-journal-core.
c#L35
(https://github.com/abrt/abrt/blob/master/src/plugins/abrt-dump-journal-core.c#L35)








Regards,

Jakub




PS: I forwarded your email to ABRT developers


-- Původní e-mail --
Od: Zbigniew Jędrzejewski-Szmek 
Komu: Development discussions related to Fedora 
Datum: 7. 4. 2019 11:14:37
Předmět: vanishing abrt logs
"Hi,

I was looking at some abrt reports in the bugzilla [1,2,3], and I seems that

the reports contain much less information than in the past. In particular,
the "var_log_messages" attachment is always just a few useless lines that 
a) seems to be cut down just to messages *from* the service, and has no 
messages *about* the service
b) the messages are only from a short time period before the crash

When a service dies, systemd logs quite a bit of useful information [4] 
about the causes. We also have services like pcp, which log information 
about
resource starvation [5].

This extra information would surely be helpful to diagnose abrt reports. 
Can we please make the reports contain useful logs again (at least
full 'journalctl -u' for the service and all logs timed from around the 
crash) ?

More information about the machine, for example /proc/meminfo would be
great too.

Zbyszek

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1660466
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1691889
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1697032n

[4]
$ sudo systemd-run -p WatchdogSec=5 sleep 10
Running as run-re57f9e7da8234592bf74818522ad9644.service...
$ journalctl --no-hostname -o short-precise -u run-re57f9e7da8234592bf
74818522ad9644.service
-- Logs begin at Tue 2019-02-19 02:28:12 CET, end at Sun 2019-04-07 10:55:09
CEST. --
Apr 07 10:47:02.891163 systemd[1]: Started /usr/bin/sleep 100.
Apr 07 10:47:08.071563 systemd[1]: run-re57f9e7da8234592bf74818522ad9644.
service: Watchdog timeout (limit 5s)!
Apr 07 10:47:08.072333 systemd[1]: run-re57f9e7da8234592bf74818522ad9644.
service: Killing process 7704 (sleep) with signal SIGABRT.
Apr 07 10:47:08.403477 systemd[1]: run-re57f9e7da8234592bf74818522ad9644.
service: Main process exited, code=dumped, status=6/ABRT
Apr 07 10:47:08.403608 systemd[1]: run-re57f9e7da8234592bf74818522ad9644.
service: Failed with result 'watchdog'.
Apr 07 10:47:08.403946 systemd[1]: run-re57f9e7da8234592bf74818522ad9644.
service: Consumed 4ms CPU time.

[5] pcp-pmie[3000]: Severe demand for real memory 11.2pgsout/s@krowka
___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Igor Gnatenko

Ok, I have reverted change:

* https://bodhi.fedoraproject.org/updates/FEDORA-2019-42ea21c6e4
* https://bodhi.fedoraproject.org/updates/FEDORA-2019-660ccd306c
* https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-eb940f069c
* https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-d229ead72a
* https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-9f6eea54fe

On Mon, Apr 8, 2019 at 12:59 PM Kalev Lember  wrote:

>
> On 4/8/19 11:13, Florian Weimer wrote:
> > * Peter Hutterer:
> >
> >> On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor Gnatenko wrote:
> >>> Hello,
> >>>
> >>> While fixing mesa build which was slow due to a lot off debug stuff
> >>> (assert()), I've added -Db_ndebug=true into the %meson macro.
> >>>
> >>> This seemed like good approach because in Fedora we should not use
> debug
> >>> bits in runtime (not related to debuginfo). However this caused some
> >>> breakage in some packages like libratbag which was relying on assert()
> in
> >>> tests. This should be really fixed in affected packages..
> >>>
> >>> I am not convinced that we should revert meson change.. Let me know if
> you
> >>> think otherwise and why.
> >>
> >> IMO if asserts cause a slow build in mesa, mesa should disable asserts.
> >>
> >> Pushing this into the build system means you're changing the behaviour
> of
> >> every package build with meson. I rely on asserts in several packages
> for
> >> paths that must not happen - removing those asserts means instead of
> >> crashing we now have undefined behaviour, probably leaking things.
> >
> > I agree.
> >
> > Fedora should follow upstream defaults here, like most other
> > distributions.  Most upstreams leave assertions enabled.
>
> I agree as well. Please don't override -Db_ndebug in distro-wide %meson
> macro and instead move the override to mesa packaging if it's needed there.
>
> Kalev
> ___
> 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: vanishing abrt logs

2019-04-08 Thread jfilak

Hi Kevin,

I was under the impression that the problem with many emails from Bugzilla
has already been fixed:

https://bugzilla.redhat.com/show_bug.cgi?id=1660157
(https://bugzilla.redhat.com/show_bug.cgi?id=1660157)

https://github.com/abrt/libreport/commit/569bf0e3fed698e93b8e098bf6a0bb2f773
aed6a
(https://github.com/abrt/libreport/commit/569bf0e3fed698e93b8e098bf6a0bb2f773aed6a)

Regards,

Jakub

-- Původní e-mail --
Od: Kevin Fenzi 
Komu: devel@lists.fedoraproject.org
Datum: 7. 4. 2019 20:19:40
Předmět: Re: vanishing abrt logs
"On 4/7/19 1:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> I was looking at some abrt reports in the bugzilla [1,2,3], and I seems 
that
> the reports contain much less information than in the past. In particular,

> the "var_log_messages" attachment is always just a few useless lines that
> a) seems to be cut down just to messages *from* the service, and has no 
> messages *about* the service
> b) the messages are only from a short time period before the crash
>
> When a service dies, systemd logs quite a bit of useful information [4] 
> about the causes. We also have services like pcp, which log information 
about
> resource starvation [5].
>
> This extra information would surely be helpful to diagnose abrt reports.
> Can we please make the reports contain useful logs again (at least
> full 'journalctl -u' for the service and all logs timed from around the 
crash) ?
>
> More information about the machine, for example /proc/meminfo would be 
> great too.

I think:

https://github.com/abrt/abrt/

is the correct place to file bugs/RFE's.
I don't know if any of the abrt developers read the list or not.

I really wish someone could fix libreport to only send 1 or 2 emails on 
new abrt bugzilla tickets again. It used to do this, but somehow broke
with bugzilla5 upgrade, so now when someone files an abrt bug you get
like 25 emails for it. I thought I filed a bug on this, but I can't seem 
to find it right now, will look more and refile if I can't find it.

Also, someone noted the other day that abrt/libreport doesn't work with 
the new signin options on bugzilla5. You login with the redhat or fedora 
idps and it will ask you still for a username/password to file the bug. 
:(

kevin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
fedoraproject.org
"
___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Kalev Lember



On 4/8/19 11:13, Florian Weimer wrote:

* Peter Hutterer:


On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor Gnatenko wrote:

Hello,

While fixing mesa build which was slow due to a lot off debug stuff
(assert()), I've added -Db_ndebug=true into the %meson macro.

This seemed like good approach because in Fedora we should not use debug
bits in runtime (not related to debuginfo). However this caused some
breakage in some packages like libratbag which was relying on assert() in
tests. This should be really fixed in affected packages..

I am not convinced that we should revert meson change.. Let me know if you
think otherwise and why.


IMO if asserts cause a slow build in mesa, mesa should disable asserts.

Pushing this into the build system means you're changing the behaviour of
every package build with meson. I rely on asserts in several packages for
paths that must not happen - removing those asserts means instead of
crashing we now have undefined behaviour, probably leaking things.


I agree.

Fedora should follow upstream defaults here, like most other
distributions.  Most upstreams leave assertions enabled.


I agree as well. Please don't override -Db_ndebug in distro-wide %meson
macro and instead move the override to mesa packaging if it's needed there.

Kalev
___
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 1696882] perl-CPAN-Perl-Releases-3.94 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-CPAN-Perl-Releases-3.9
   ||4-1.fc31



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

[Bug 1696882] perl-CPAN-Perl-Releases-3.94 is available

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



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-1.fc29 has been submitted as an update to Fedora
29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1a060feb93

-- 
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 1696882] perl-CPAN-Perl-Releases-3.94 is available

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



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-1.fc30 has been submitted as an update to Fedora
30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-33db30f21d

-- 
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 1696882] perl-CPAN-Perl-Releases-3.94 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.94-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4e6d9989e7

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

Could not execute import_srpm

2019-04-08 Thread Antonio Trande

Hi all.

I can't upload source archive of new package 'smoldyn'

$ fedpkg import ../../smoldyn-2.58-1.fc29.src.rpm
Uploading: /home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz

100.0%
Could not execute import_srpm: Fail to upload files. Server returns
status 408


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.fedoraproject.org/



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

Re: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread Florian Weimer

* Peter Hutterer:

> On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor Gnatenko wrote:
>> Hello,
>> 
>> While fixing mesa build which was slow due to a lot off debug stuff
>> (assert()), I've added -Db_ndebug=true into the %meson macro.
>> 
>> This seemed like good approach because in Fedora we should not use debug
>> bits in runtime (not related to debuginfo). However this caused some
>> breakage in some packages like libratbag which was relying on assert() in
>> tests. This should be really fixed in affected packages..
>> 
>> I am not convinced that we should revert meson change.. Let me know if you
>> think otherwise and why.
>
> IMO if asserts cause a slow build in mesa, mesa should disable asserts.
>
> Pushing this into the build system means you're changing the behaviour of
> every package build with meson. I rely on asserts in several packages for
> paths that must not happen - removing those asserts means instead of
> crashing we now have undefined behaviour, probably leaking things.

I agree.

Fedora should follow upstream defaults here, like most other
distributions.  Most upstreams leave assertions enabled.

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

[Bug 1696928] perl-Locale-SubCountry-2.05 is available

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



--- Comment #4 from Fedora Update System  ---
perl-Locale-SubCountry-2.05-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-23c6655da7

-- 
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 1696928] perl-Locale-SubCountry-2.05 is available

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



--- Comment #3 from Fedora Update System  ---
perl-Locale-SubCountry-2.05-1.fc29 has been submitted as an update to Fedora
29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6960dff6b1

-- 
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 1696928] perl-Locale-SubCountry-2.05 is available