Re: fedora-review seam to not work 8-(

[J. Scheurich]

> What's your version of fedora-review? You should have 0.7.2
>
> Name : fedora-review
> Version  : 0.7.2
> Release  : 1.fc30
$ fedora-review -V
fedora-review version 0.7.2 65d36bb 2019-04-09 16:30:26 -0400
external plugins:
$ yum info fedora-review
...
Installed Packages
Name : fedora-review
Version  : 0.7.2
Release  : 2.fc31
Architecture : noarch
Size : 626 k
Source   : fedora-review-0.7.2-2.fc31.src.rpm

This seams to be release 2.fc31, not 1.fc30.

Should i try to install 1.fc30 ?

so long
MUFTI
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Feedback on Application Streams and modularity

[Christopher]

You're posting this on devel@, I wonder if you'd get different
responses on users@. Some responses to your questions inline below,
but first,

From my perspective as a user:
  I was in the group of users that needed newer tools for development
than what I could get on RHEL/CentOS. I thought SCL was crap, so I
switched to Fedora, because it just had what I needed. I loved Fedora
more than RHEL/CentOS, because it gave me what I needed. Modularity to
solve that problem in Fedora seems like a more "in your face" version
of everything wrong with SCL, but now forced upon me.

From my perspective as a developer:
  Because I grew to love Fedora, I wanted to contribute back... I
became a packager to help maintain tools for my own daily use.
However, when modularity came to Fedora, being a casual packager
became impossible... I had to devote more time to understanding what
was happening to all my BuildRequires, and/or how to use modules when
regular Fedora worked so perfectly for me (at least, I knew where I
stood with it... I understood how to file a bug report and against
which package, and where the package source was to help if
necessary)... OR I had to throw my hands up in the air and complain on
list, and grow more and more frustrated... OR I had to just stop
maintaining my packages that broke because of the mass exodus of
packages I needed as BuildRequires and Requires for my own packages.
Modularity has made the packager experience worse.

One of the best things about Fedora, for me as a Java developer, was
the dependency convergent nature of the distro... normally a huge pain
for Java development, but it was made easy in Fedora, because I could
just converge on what was packaged... if a newer lib was needed, well,
in 6 months, everybody would be converged on the updated version.
Simple. Of course, there were special cases with compat packages, but
those were rare, and with some effort, they could be avoided, too.
When a package was updated, all packages which depend on it moved at
the same time. Things were predictable... stable. Now, I don't know
what is going on... packages are being shipped with embedded static
libs, there's lots of different versions of the same package
everywhere... I have to know not only which repositories I'm pulling
from, but also which modules, and which application streams within
those modules? It's so complicated. I've actually reverted in many
cases to avoiding the packages in Fedora now... I've gone back to
manually downloading Maven and Eclipse from their respective
upstreams... they're more reliable, more up-to-date, and more stable.
I used to like that I could get those "out of the box" in Fedora...
but now the Fedora ones don't work very well, and I have to jump
through hoops to even install them properly.

On Mon, Aug 5, 2019 at 9:52 AM Terry Bowling  wrote:
>
> Hello Fedora friends!
>
> I would like to follow up and collect your input on Application Streams and 
> modularity after all of the discussions over the past month.  We have been 
> listening and brainstorming on how to proceed with both the tooling, user 
> experience, and communicating better upstream for this process.
>
> The team working on modularity in Fedora posted some revisions to the Fedora 
> modularity documentation.  Additionally, I described the end user experience 
> expectations in this thread, essentially describing why fully automated 
> stream switching cannot occur for a sane distro environment- at least at our 
> current level of understanding and tooling.  While my description was 
> certainly focused on the RHEL user perspective, as a long time Fedora user I 
> will say this is equally true for many Fedora users.
>
> That said, I am hoping you could share your collective wisdom and provide us 
> feedback on the following:
>
>  1.  Have we better communicated the current features and goals of 
> Application Streams and modularity, primarily focused on end users?

I do not believe these have been communicated very well at all, nor do
I believe that this effort is primarily focused on end users. I think
the end user experience is worse than it was before. Fedora no longer
moves as one single entity composed of thousands of packages, like a
school of fish, that users could cast their nets into and feed
themselves from its bounty. Now, it seems to move as several different
smaller schools of fish moving in different directions... no one
school big enough for users to even bother throwing a net at it.

>
>  2.  Does this help developers better understand the current limiting 
> state and challenges for both stream and other tooling limitations?

I don't think the problem is that developers don't understand the
limitations. Like many things in life, there are trade-offs. I think
Fedora has traded dependency convergence, good user experience, a
robust set of available packages, lower barrier to entry for new
packagers, and more, in favor of supporting a set of special use cases
that don't 

[Bug 1737393] Upgrade perl-asa to 1.04

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-asa-1.04-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-d6bed12ed2

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1731807] Upgrade perl-CPAN-Perl-Releases to 4.10

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |0-1.fc31|0-1.fc31
   |perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |0-1.fc30|0-1.fc30
   ||perl-CPAN-Perl-Releases-4.1
   ||0-1.fc29



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.10-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737393] Upgrade perl-asa to 1.04

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-asa-1.04-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-9e9ca40955

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1731807] Upgrade perl-CPAN-Perl-Releases to 4.10

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |0-1.fc31|0-1.fc31
   ||perl-CPAN-Perl-Releases-4.1
   ||0-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-08-06 01:18:29



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.10-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1731799] Upgrade perl-BerkeleyDB to 0.63

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-BerkeleyDB-0.63-1.fc31 |perl-BerkeleyDB-0.63-1.fc31
   ||perl-BerkeleyDB-0.63-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-08-06 01:18:28



--- Comment #3 from Fedora Update System  ---
perl-BerkeleyDB-0.63-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1729861] Upgrade perl-Lingua-EN-Tagger to 0.31

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Lingua-EN-Tagger-0.31- |perl-Lingua-EN-Tagger-0.31-
   |1.fc31  |1.fc31
   ||perl-Lingua-EN-Tagger-0.31-
   ||1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-08-06 01:18:25



--- Comment #3 from Fedora Update System  ---
perl-Lingua-EN-Tagger-0.31-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1729862] Upgrade perl-Net-Whois-Raw to 2.99022

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-Whois-Raw-2.99.022 |perl-Net-Whois-Raw-2.99.022
   |-1.fc31 |-1.fc31
   ||perl-Net-Whois-Raw-2.99.022
   ||-1.fc30
 Resolution|RAWHIDE |ERRATA



--- Comment #3 from Fedora Update System  ---
perl-Net-Whois-Raw-2.99.022-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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-08-06 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/06/report-389-ds-base-1.4.1.6-20190805git4159cf6.fc30.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-08-06 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intention to retire Release Notes RPM

[Neal Gompa]

On Mon, Aug 5, 2019 at 8:43 PM Martin Kolman  wrote:
>
> On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote:
> > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
> >  wrote:
> > > Hi All,
> > >
> > > Barring objection, I plan to retire the release notes package from
> > > Fedora on or after August 9, 2019.  The package has not been updated
> > > since F28.  Despite the fact that we have literally shipped a package
> > > containing the F28 release notes in F29 and F30, there have been no
> > > comments.  This has been discussed with the docs team and is
> > > supported.  I am not aware of any dependencies and I believe it was
> > > removed from release criteria in F29.
> > >
> > > I will run `fedpkg retire` and further request removal via
> > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages
> > >
> > > Please reply on list if you have any questions or concerns.
> > >
> >
> > Does Anaconda not support showing the release notes _anywhere_? That
> > was the original impetus for shipping it that way...
> There is currently no screen in either graphical or text interface of 
> Anaconda that would show Fedora release notes.

Aside from it being mildly depressing that there's no way to discover
the release notes for a Fedora release, I guess it's fine to retire.
We don't have any other entry points in the distribution for viewing
the release notes anymore...


-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review seam to not work 8-(

[Kevin Kofler]

I wrote:

> Elliott Sales de Andrade wrote:
>> No, that's not correct. Header-only libraries are not noarch, and
>> disable debug packages.
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header_only_libraries
> 
> Well, if there is no testsuite and if the headers are truly
> architecture-independent (those are the 2 reasons the guidelines give as a
> rationale for making the packages arch-specific), I don't see a good
> reason to not make them noarch.

PS: Oh, and if there is a testsuite to run, but the headers are truly
architecture-independent, you can at least make -devel a noarch subpackage
with no ill effect. (Koji will actually fail your build if the headers turn
out to differ based on the architecture, so it is perfectly safe, unlike the
completely noarch package where it is up to YOU to ensure that the contents
do not depend on the architecture.) Though, in that case (noarch
subpackage), you do still have to disable the debug packages explicitly.

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

Re: fedora-review seam to not work 8-(

[Kevin Kofler]

Elliott Sales de Andrade wrote:
> No, that's not correct. Header-only libraries are not noarch, and
> disable debug packages.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header_only_libraries

Well, if there is no testsuite and if the headers are truly
architecture-independent (those are the 2 reasons the guidelines give as a
rationale for making the packages arch-specific), I don't see a good reason
to not make them noarch.

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

Re: fedora-review seam to not work 8-(

[Elliott Sales de Andrade]

On Mon, 5 Aug 2019 at 18:28, Robert-André Mauchin  wrote:
>
> On Monday, 5 August 2019 18:05:27 CEST J. Scheurich wrote:
> > Hi,
> >
> > (Since the last update ?) fedora-review seams to not work:
> >
> > I am using
> >
> > Spec URL: ftp://ftp.ourproject.org/pub/wdune/vcglib.spec
> > SRPM URL: ftp://ftp.ourproject.org/pub/wdune/vcglib-1.0.1-1.src.rpm
> >
> > as a testcase.
> >
> > $ fedora-review -n vcglib
> > INFO: Processing local files: vcglib
> > INFO: Getting .spec and .srpm Urls from : Local files in /home/home/mufti
> > INFO:   --> SRPM url: file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> > INFO:   --> Spec url: file:///home/home/mufti/vcglib.spec
> > INFO: Using review directory: /home/home/mufti/review-vcglib
> > ERROR: Exception down the road... (logs in
> > /home/mufti/.cache/fedora-review.log)
> >
> > $ less /home/mufti/.cache/fedora-review.log
> > ...
> > 08-05 17:51 root INFO   --> SRPM url:
> > file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> > 08-05 17:51 root INFO   --> Spec url:
> > file:///home/home/mufti/vcglib.spec
> > 08-05 17:51 root DEBUGfind_urls completed: 0.010
> > 08-05 17:51 root INFO Using review directory:
> > /home/home/mufti/review-vcglib
> > 08-05 17:51 root DEBUGAvoiding init of working mock root
> > 08-05 17:51 root DEBUGUrl download completed: 2.384
> > 08-05 15:51 root DEBUGException down the road...
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 236, in run
> > self._do_run(outfile)
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 226, in _do_run
> > self._do_report(outfile)
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 99, in _do_report
> > ...
> >
> > As far as i understand python, a "BaseException" occored in
> > self._do_run(outfile):
> >
> > $ less +232 /usr/lib/python3.7/site-packages/FedoraReview/review_helper.py
> >self.log.debug("fedora-review %s %s started", __version__,
> > BUILD_FULL)
> > self.log.debug("Command  line: %s", " ".join(sys.argv))
> > try:
> > rcode = 0
> > self._do_run(outfile)
> > except ReviewError as err:
> > if isinstance(err, SpecParseReviewError):
> > nvr = _Nvr(self.bug.get_name())
> > result = SimpleTestResult(
> > "SpecFileParseError", "Can't parse the spec file: ",
> > str(err)
> > )
> > write_xml_report(nvr, [result])
> > self.log.debug("ReviewError: %s", str(err), exc_info=True)
> > if not err.silent:
> > msg = "ERROR: " + str(err)
> > if err.show_logs:
> > msg += " (logs in " + Settings.session_log + ")"
> > self.log.error(msg)
> > rcode = err.exitcode
> > except BaseException:
> > self.log.debug("Exception down the road...", exc_info=True)
> > self.log.error(
> > "Exception down the road... (logs in %s)",
> > Settings.session_log
> > ...
> >
> > What i am doing wrong ?
> >
> > so long
> > MUFTI
>
>
> What's your version of fedora-review? You should have 0.7.2
>
> Name : fedora-review
> Version  : 0.7.2
> Release  : 1.fc30
> Architecture : noarch
> Size : 626 k
> Source   : fedora-review-0.7.2-1.fc30.src.rpm
> Repository   : @System
> From repo: updates-testing
> Summary  : Review tool for fedora rpm packages
> URL  : https://pagure.io/FedoraReview
> License  : GPLv2+
> Description  : This tool automates much of the dirty work when reviewing a
> package
>  : for the Fedora Package Collection like:
>  :
>  : * Downloading SRPM & SPEC.
>  : * Download upstream source
>  : * Check md5sums
>  : * Build and install package in mock.
>  : * Run rpmlint.
>  : * Generate a review template, which becomes the starting
>  :   point for the review work.
>  :
>  : The tool is composed of plugins, one for each supported
> language.
>  : As of today, there is plugins for C/C++, Ruby, java, R, perl
> and
>  : python.  There is also support for external tests that can be
> written
>  : in a simple way in bash.
>
>
> For you SPEC, you should drop the main package and only keep devel.
>
> Drop %global debug_package %{nil}  and make the package noarch
>

No, that's not correct. Header-only libraries are not noarch, and
disable debug packages.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header_only_libraries

> Use: Source: https://github.com/cnr-isti-vclab/vcglib/archive/v%{version}/%
> {name}-%{version}.tar.gz
>
> Use cp -a to keep attributes: 

Re: Packages requiring "Python" might be broken in rawhide

[Miro Hrončok]

On 06. 08. 19 0:58, Kevin Kofler wrote:

Miro Hrončok wrote:

mkdir hackpath
ln -s %{__python2} hackpath/python
export PATH=$(pwd)/hackpath:$PATH


These will work as long as nothing hardcodes "#!/usr/bin/python". So far, I
only found the proper "#!/usr/bin/env python" (see now why it is the right
thing to do, even if Fedora packaging guidelines claim otherwise?), but I
haven't scanned all files yet.


Using env shebang is the right thing to do for an upstream project, yes. I've 
never said otherwise.



The custom PATH approach is definitely the first one I'd try.


That's what I have been using as well.


Let me kindly remind you that using /usr/bin/python is against the
packaging guidelines since Fedora 29. Making assumptions about the
versions of /usr/bin/python has been forbidden since I don't know when.


Your packaging guidelines cannot dictate what upstream build systems use, no
matter how much wishful thinking you apply in your shiny fantasy world. And
even if they could, they could still not go back in time and magically fix
legacy software that predates your guidelines by years.


No you cannot. But we can adjust the packages we ship before we do so.


I think the fallout is going to be even worse outside of the Fedora Koji
sandbox (though then again, there, the local admin can just install their
own python2-unversioned-command package or even just add an unpackaged
/usr/bin/python → python2 symlink – I bet many will).


And that completely fine. Another reason why no Fedora packaged software should 
ever use /usr/bin/python.



The python2-unversioned-command would be pulled by users when they install
/usr/bin/python. We don't want that. Python 2 is deprecated and will be
removed, this was communicated loudly and handled slowly for years.


It would not, if you ensure python-unversioned-command gets installed by
default and Conflicts: python2-unversioned-command.


That is most likely correct. Apologies. (It still doesn't make me want that 
package at all but that single argument was not true.)



And even if the users don't have it installed yet, why would
python2-unversioned-command get preferred over python-unversioned-command by
DNF?


Why not? Unless some hackery-suggesty-trickery is used, the preferred package is 
an implementation detail.



If you need to keep Qt 4 qtwebkit in Fedora 32 and it cannot be built with
Python 3 with any reasonable effort, you will need a FESCo exception
anyway.


This is even more ridiculous.

I don't see why Python 2 cannot be held to the same standards of providing
compatibility support as long as applications need it as Qt 3 and Qt 4. We
still ship Qt 3 just fine (and backport security fixes when needed), more
than 11 years after the last upstream release! (And Qt 3 does not depend on
Python 2. ;-) ) Your strict unwillingness to do the same for Python 2 is
creating huge problems for a large class of packagers and end users alike.


Do you want to maintain the stack? We clearly communicated the following over 
the years:


"If someone steps up to maintain Python 2 (including the full ecosystem of 
packages now in Fedora), they can decide to discontinue removing packages, 
revert the Change, or come up with another plan. (Note that in this case, 
current maintainers will most likely orphan many fundamental python2 packages.)"


This offer is still valid. I certainly don't want to maintain it and none of the 
others present Python 2 maintainers either. Note that we will still maintain the 
interpreter for our users. We will simply not maintain it for hundreds of legacy 
packages that somebody packaged years ago and are dead otherwise. Requiring a 
FESCo exception is a way to ensure we only support it for the packages where it 
benefits the project as a whole (might very well be the case for Qt 4, IDK).


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages requiring "Python" might be broken in rawhide

[Kevin Kofler]

Miro Hrončok wrote:
> Maintaining legacy software is impractical. Use a hack. There are some
> options:
> 
> 1) carefully sed python for python2

This assumes I find the files to sed first. They are spread throughout the 
build system. They may or may not all have .py extensions. And blindly 
running sed on all files may have other side effects due to messing up time 
stamps.

> 2) define a function, export it:
> 
> function python() { python2 "$@"; }
> export -f python
> 
> 3) define a custom PATH:
> 
> mkdir hackpath
> ln -s %{__python2} hackpath/python
> export PATH=$(pwd)/hackpath:$PATH

These will work as long as nothing hardcodes "#!/usr/bin/python". So far, I 
only found the proper "#!/usr/bin/env python" (see now why it is the right 
thing to do, even if Fedora packaging guidelines claim otherwise?), but I 
haven't scanned all files yet.

The custom PATH approach is definitely the first one I'd try.

> Let me kindly remind you that using /usr/bin/python is against the
> packaging guidelines since Fedora 29. Making assumptions about the
> versions of /usr/bin/python has been forbidden since I don't know when.

Your packaging guidelines cannot dictate what upstream build systems use, no 
matter how much wishful thinking you apply in your shiny fantasy world. And 
even if they could, they could still not go back in time and magically fix 
legacy software that predates your guidelines by years.

I think the fallout is going to be even worse outside of the Fedora Koji 
sandbox (though then again, there, the local admin can just install their 
own python2-unversioned-command package or even just add an unpackaged 
/usr/bin/python → python2 symlink – I bet many will).

> The python2-unversioned-command would be pulled by users when they install
> /usr/bin/python. We don't want that. Python 2 is deprecated and will be
> removed, this was communicated loudly and handled slowly for years.

It would not, if you ensure python-unversioned-command gets installed by 
default and Conflicts: python2-unversioned-command.

And even if the users don't have it installed yet, why would
python2-unversioned-command get preferred over python-unversioned-command by 
DNF?

> If you need to keep Qt 4 qtwebkit in Fedora 32 and it cannot be built with
> Python 3 with any reasonable effort, you will need a FESCo exception
> anyway.

This is even more ridiculous.

I don't see why Python 2 cannot be held to the same standards of providing 
compatibility support as long as applications need it as Qt 3 and Qt 4. We 
still ship Qt 3 just fine (and backport security fixes when needed), more 
than 11 years after the last upstream release! (And Qt 3 does not depend on 
Python 2. ;-) ) Your strict unwillingness to do the same for Python 2 is 
creating huge problems for a large class of packagers and end users alike.

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

Re: Packages requiring "Python" might be broken in rawhide

[Miro Hrončok]

On 06. 08. 19 0:23, Miro Hrončok wrote:

But we will not provide Python2ish /usr/bin/python2 in a Fedora package.


I meant /usr/bin/python.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages requiring "Python" might be broken in rawhide

[Miro Hrončok]

On 05. 08. 19 23:59, Kevin Kofler wrote:

Miro Hrončok wrote:


On 16. 07. 19 19:25, Kevin Kofler wrote:

At the very least, we need a python2-unversioned-command (and
python-unversioned-command in existing releases needs to Provide it so
that we don't have to add yet another %if boilerplate snippet) so the
packages can keep building as intended by upstream.


No we don't.


So how do you propose I build Qt 4 qtwebkit now?

* The package is no longer supported by upstream, so it will never be fixed
   upstream.
* It has dozens of build scripts expecting python to be Python 2.
* Dozens of applications still depend on it, so dropping it is not an
   option.

Having a python2-unversioned-command available (conflicting with the default
python-unversioned-command) would make for a quick fix to keep it building.
Any other alternative looks highly impractical to me.


Maintaining legacy software is impractical. Use a hack. There are some options:

1) carefully sed python for python2

2) define a function, export it:

function python() { python2 "$@"; }
export -f python

3) define a custom PATH:

mkdir hackpath
ln -s %{__python2} hackpath/python
export PATH=$(pwd)/hackpath:$PATH

-

Let me kindly remind you that using /usr/bin/python is against the packaging 
guidelines since Fedora 29. Making assumptions about the versions of 
/usr/bin/python has been forbidden since I don't know when.



The python2-unversioned-command would be pulled by users when they install 
/usr/bin/python. We don't want that. Python 2 is deprecated and will be removed, 
this was communicated loudly and handled slowly for years.


If you need to keep Qt 4 qtwebkit in Fedora 32 and it cannot be built with 
Python 3 with any reasonable effort, you will need a FESCo exception anyway.


I'm sorry we made your packaging work more hard than it is. But we will not 
provide Python2ish /usr/bin/python2 in a Fedora package. This was an approved 
Fedora change and you have had your chance to argue against it **before** it was 
implemented, if you think this change should be revisited, please explain what 
circumstances have changed.


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kevin Kofler]

Kaleb Keithley wrote:
> The proposal[1] as it stands is to drop all aspects of 32-bit support,
> i.e. client, server, gfapi, etc., going forward from glusterfs-8. This
> should be considered advanced notice that consumers that have dependencies
> need to plan accordingly.
> 
> Please feel free though to add your thoughts to the issue.
> 
> [1] https://github.com/gluster/glusterfs/issues/702

The upstream issue actually says they want to keep building 32-bit in their 
CI, so it should compile just fine, they just won't test it. So an 
ExcludeArch should not be necessary.

It is quite likely that many upstream projects are never tested on armv7hl 
by upstream. That doesn't mean we need to ExcludeArch: armv7hl all of them.

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

Re: Packages requiring "Python" might be broken in rawhide

[Kevin Kofler]

Miro Hrončok wrote:

> On 16. 07. 19 19:25, Kevin Kofler wrote:
>> At the very least, we need a python2-unversioned-command (and
>> python-unversioned-command in existing releases needs to Provide it so
>> that we don't have to add yet another %if boilerplate snippet) so the
>> packages can keep building as intended by upstream.
> 
> No we don't.

So how do you propose I build Qt 4 qtwebkit now?

* The package is no longer supported by upstream, so it will never be fixed
  upstream.
* It has dozens of build scripts expecting python to be Python 2.
* Dozens of applications still depend on it, so dropping it is not an
  option.

Having a python2-unversioned-command available (conflicting with the default 
python-unversioned-command) would make for a quick fix to keep it building. 
Any other alternative looks highly impractical to me.

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Miro Hrončok]

On 05. 08. 19 19:08, Kaleb Keithley wrote:
Er, what about them?  AIUI, there isn't going to be a i686 Fedora  in F31 and 
beyond.


So we keep adding ExcludeArch to more and more packages? Transitively, this will 
be harder and harder. Shouldn't we instead only explicitly build and select what 
needs to be built on i686 for multilib?


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review seam to not work 8-(

[Robert-André Mauchin]

On Monday, 5 August 2019 18:05:27 CEST J. Scheurich wrote:
> Hi,
> 
> (Since the last update ?) fedora-review seams to not work:
> 
> I am using
> 
> Spec URL: ftp://ftp.ourproject.org/pub/wdune/vcglib.spec
> SRPM URL: ftp://ftp.ourproject.org/pub/wdune/vcglib-1.0.1-1.src.rpm
> 
> as a testcase.
> 
> $ fedora-review -n vcglib
> INFO: Processing local files: vcglib
> INFO: Getting .spec and .srpm Urls from : Local files in /home/home/mufti
> INFO:   --> SRPM url: file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> INFO:   --> Spec url: file:///home/home/mufti/vcglib.spec
> INFO: Using review directory: /home/home/mufti/review-vcglib
> ERROR: Exception down the road... (logs in
> /home/mufti/.cache/fedora-review.log)
> 
> $ less /home/mufti/.cache/fedora-review.log
> ...
> 08-05 17:51 root INFO   --> SRPM url:
> file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> 08-05 17:51 root INFO   --> Spec url:
> file:///home/home/mufti/vcglib.spec
> 08-05 17:51 root DEBUGfind_urls completed: 0.010
> 08-05 17:51 root INFO Using review directory:
> /home/home/mufti/review-vcglib
> 08-05 17:51 root DEBUGAvoiding init of working mock root
> 08-05 17:51 root DEBUGUrl download completed: 2.384
> 08-05 15:51 root DEBUGException down the road...
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 236, in run
> self._do_run(outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 226, in _do_run
> self._do_report(outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 99, in _do_report
> ...
> 
> As far as i understand python, a "BaseException" occored in
> self._do_run(outfile):
> 
> $ less +232 /usr/lib/python3.7/site-packages/FedoraReview/review_helper.py
>self.log.debug("fedora-review %s %s started", __version__,
> BUILD_FULL)
> self.log.debug("Command  line: %s", " ".join(sys.argv))
> try:
> rcode = 0
> self._do_run(outfile)
> except ReviewError as err:
> if isinstance(err, SpecParseReviewError):
> nvr = _Nvr(self.bug.get_name())
> result = SimpleTestResult(
> "SpecFileParseError", "Can't parse the spec file: ",
> str(err)
> )
> write_xml_report(nvr, [result])
> self.log.debug("ReviewError: %s", str(err), exc_info=True)
> if not err.silent:
> msg = "ERROR: " + str(err)
> if err.show_logs:
> msg += " (logs in " + Settings.session_log + ")"
> self.log.error(msg)
> rcode = err.exitcode
> except BaseException:
> self.log.debug("Exception down the road...", exc_info=True)
> self.log.error(
> "Exception down the road... (logs in %s)",
> Settings.session_log
> ...
> 
> What i am doing wrong ?
> 
> so long
> MUFTI


What's your version of fedora-review? You should have 0.7.2

Name : fedora-review
Version  : 0.7.2
Release  : 1.fc30
Architecture : noarch
Size : 626 k
Source   : fedora-review-0.7.2-1.fc30.src.rpm
Repository   : @System
From repo: updates-testing
Summary  : Review tool for fedora rpm packages
URL  : https://pagure.io/FedoraReview
License  : GPLv2+
Description  : This tool automates much of the dirty work when reviewing a 
package
 : for the Fedora Package Collection like:
 : 
 : * Downloading SRPM & SPEC.
 : * Download upstream source
 : * Check md5sums
 : * Build and install package in mock.
 : * Run rpmlint.
 : * Generate a review template, which becomes the starting
 :   point for the review work.
 : 
 : The tool is composed of plugins, one for each supported 
language.
 : As of today, there is plugins for C/C++, Ruby, java, R, perl 
and
 : python.  There is also support for external tests that can be 
written
 : in a simple way in bash.


For you SPEC, you should drop the main package and only keep devel.

Drop %global debug_package %{nil}  and make the package noarch

Use: Source: https://github.com/cnr-isti-vclab/vcglib/archive/v%{version}/%
{name}-%{version}.tar.gz

Use cp -a to keep attributes: cp -ar vcg img %{buildroot}%{_includedir}/%
{name}

Remove trailing spaces

Not needed:
mkdir -p %{buildroot}%{_docdir}/%{name}
install -m 644 README.md %{buildroot}%{_docdir}/%{name} 

It is automatically included when you use %doc README.md



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Fedora Atomic Host Two Week Release Announcement: 29.20190805.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190805.0
Commit(x86_64): cb40a05e50d5b77cb1e10a5c3675fe483c8ab4e437fc12d30467c3cdbbec208f
Commit(aarch64): 
fabbaee7849aa7d5b9fb08ae8692bb3ca020f45793e0a502b18171f417383738
Commit(ppc64le): 
415660acc0984f7549299259e78fe5bc03af6407d4d9331174f75686c63afa65


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190805.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190805.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190805.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190805.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190805.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190805.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190805.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190805.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190805.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190805.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190805.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190805.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190805.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190805.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190805.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190805.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190805.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190805.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename

fedora-review seam to not work 8-(

[J. Scheurich]

Hi,

(Since the last update ?) fedora-review seams to not work:

I am using

Spec URL: ftp://ftp.ourproject.org/pub/wdune/vcglib.spec
SRPM URL: ftp://ftp.ourproject.org/pub/wdune/vcglib-1.0.1-1.src.rpm

as a testcase.

$ fedora-review -n vcglib
INFO: Processing local files: vcglib
INFO: Getting .spec and .srpm Urls from : Local files in /home/home/mufti
INFO:   --> SRPM url: file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
INFO:   --> Spec url: file:///home/home/mufti/vcglib.spec
INFO: Using review directory: /home/home/mufti/review-vcglib
ERROR: Exception down the road... (logs in
/home/mufti/.cache/fedora-review.log)

$ less /home/mufti/.cache/fedora-review.log
...
08-05 17:51 root INFO   --> SRPM url:
file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
08-05 17:51 root INFO   --> Spec url:
file:///home/home/mufti/vcglib.spec
08-05 17:51 root DEBUG    find_urls completed: 0.010
08-05 17:51 root INFO Using review directory:
/home/home/mufti/review-vcglib
08-05 17:51 root DEBUG    Avoiding init of working mock root
08-05 17:51 root DEBUG    Url download completed: 2.384
08-05 15:51 root DEBUG    Exception down the road...
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 236, in run
    self._do_run(outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 226, in _do_run
    self._do_report(outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 99, in _do_report
...

As far as i understand python, a "BaseException" occored in
self._do_run(outfile):

$ less +232 /usr/lib/python3.7/site-packages/FedoraReview/review_helper.py
   self.log.debug("fedora-review %s %s started", __version__,
BUILD_FULL)
    self.log.debug("Command  line: %s", " ".join(sys.argv))
    try:
    rcode = 0
    self._do_run(outfile)
    except ReviewError as err:
    if isinstance(err, SpecParseReviewError):
    nvr = _Nvr(self.bug.get_name())
    result = SimpleTestResult(
    "SpecFileParseError", "Can't parse the spec file: ",
str(err)
    )
    write_xml_report(nvr, [result])
    self.log.debug("ReviewError: %s", str(err), exc_info=True)
    if not err.silent:
    msg = "ERROR: " + str(err)
    if err.show_logs:
    msg += " (logs in " + Settings.session_log + ")"
    self.log.error(msg)
    rcode = err.exitcode
    except BaseException:
    self.log.debug("Exception down the road...", exc_info=True)
    self.log.error(
    "Exception down the road... (logs in %s)",
Settings.session_log
...

What i am doing wrong ?

so long
MUFTI
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Daniel P . Berrangé]

On Mon, Aug 05, 2019 at 03:56:19PM +0200, Miro Hrončok wrote:
> On 05. 08. 19 15:36, Kaleb Keithley wrote:
> > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
> > 
> > The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
> > will land in Fedora 31/rawhide soon. More than likely though it will not
> > be official until GlusterFS-8, which will probably land, accordingly,
> > after Fedora 31 GA in Fedora 32/rawhide.
> > 
> > 
> > 
> > [1] https://github.com/gluster/glusterfs/issues/702
> 
> What about the dependent packages?
> 
> $ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel
> glusterfs-api-devel-0:6.4-3.fc31.i686
> glusterfs-api-devel-0:6.4-3.fc31.x86_64
> libvirt-0:5.5.0-2.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> uwsgi-0:2.0.18-2.fc31.src
> 
> $ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
> gluster-block-0:0.4-4.fc31.src
> glusterfs-coreutils-0:0.3.1-2.fc31.src
> libvirt-0:5.5.0-2.fc31.src
> nfs-ganesha-0:2.8.2-3.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> scsi-target-utils-0:1.0.70-9.fc31.src
> tcmu-runner-0:1.1.3-2.fc26.src
> uwsgi-0:2.0.18-2.fc31.src

This is no big deal from libvirt/qemu POV. We've already trivially
adapted to ceph being purged from 32-bit archs by adding conditionals.
The same is trivial for glusterfs too.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kaleb Keithley]

On Mon, Aug 5, 2019 at 9:57 AM Miro Hrončok  wrote:

> On 05. 08. 19 15:36, Kaleb Keithley wrote:
> > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
> >
> > The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
> will land
> > in Fedora 31/rawhide soon. More than likely though it will not be
> official until
> > GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA
> in Fedora
> > 32/rawhide.
> >
> >
> >
> > [1] https://github.com/gluster/glusterfs/issues/702
>
> What about the dependent packages?
>
> $ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel
> glusterfs-api-devel-0:6.4-3.fc31.i686
> glusterfs-api-devel-0:6.4-3.fc31.x86_64
> libvirt-0:5.5.0-2.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> uwsgi-0:2.0.18-2.fc31.src
>

Er, what about them?  AIUI, there isn't going to be a i686 Fedora  in F31
and beyond. That just leaves armv7hl. Is anyone really running libvirt,
qemu, or storage on such platforms? If they are,  the number must be
vanishingly small. (My own experience with virt on ARM makes me believe
that the that the number must be truly microscopic.) Of those that are, is
there a reason they can't keep running glusterfs-7 on F30 or F31
indefinitely if they really need 32-bit gluster?

$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
> gluster-block-0:0.4-4.fc31.src
> glusterfs-coreutils-0:0.3.1-2.fc31.src
> libvirt-0:5.5.0-2.fc31.src
> nfs-ganesha-0:2.8.2-3.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> scsi-target-utils-0:1.0.70-9.fc31.src
> tcmu-runner-0:1.1.3-2.fc26.src
> uwsgi-0:2.0.18-2.fc31.src


tcmu-runner and scsi-target-utils is only for gluster-block, which, by
extension should also drop 32-bit at the same time. Likewise,
glusterfs-coreutils should also drop 32-bit support.

That only leaves ganesha and samba, which can drop their FSAL_GLUSTER and
VFS_GLUSTER plug-ins on 32-bit. Something they have already had to do for
Ceph-14 in Fedora 30.

--

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Iñaki Ucar]

On Mon, 5 Aug 2019 at 18:23, Andrew Lutomirski  wrote:
>
> On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik  wrote:
> >
> > Georg Sauthoff writes:
> >
> > > > I ended up tweaking my code to avoid the assertions, rather than 
> > > > disabling
> > > > them. For this particular situation, my original change was to try
> > > >
> > > > std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
> > > >
> > > > But that still tripped the assertion when the foo vector was empty, so I
> > > had
> > > > wrap this inside an if().
> > >
> > > But why don't you use the idiomatic
> > >
> > > copy(foo.begin(), foo.end(), back_inserter(bar));
> > >
> > > ?
> > >
> > > No need to wrap it into an extra if statement.
> >
> > I'm well aware of the alternatives. That's not the point.
> >
> > The point is that there's nothing wrong with this specific form of existing
> > code that now throws exceptions when the hardened build gets turned on.
> > There is no buffer overruns, and nothing to exploit.
> >
> > IIRC, the hardened build did find one real bug in the upstream package that
> > was the original subject matter here, but all of the rest were these kinds
> > of false positives. Now you have a situation when the existing code is known
> > to be working, but needs changing in order to use a hardened build. There's
> > some level of risk of regression in any change, and that gets weighed
> > against the benefits of having a hardened build.
> >
> > The above was just a basic example of this. It is not true that exceptions
> > from hardened code are always evidence of potentially exploitable problem.
> > Sometimes/most of the time, but sometimes they are false positives.
> >
> >
>
> I filed an upstream bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
>
> Depending on the resolution of that bug, I suggest that Fedora
> consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> options.  IMO Fedora's default RPM build options should not cause
> crashes on valid, if less-than-stylistically-great, code.  I don't
> think that package maintainers should need to update package source to
> use C++ in a more polite way.

Upstream response has been quick:

"It's UB, no question. The table of "Optional sequence container
operations" says a[n] is equivalent to *(a.begin() + n) so when
n==a.size() you dereference the past-the-end iterator, which is UB."

"The assertion is entirely correct. Calling operator[] with an invalid
value is UB, it doesn't matter what you do (or don't do) with the
result."

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kaleb Keithley]

On Mon, Aug 5, 2019 at 11:29 AM Peter Robinson  wrote:

> On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley  wrote:
> >
> >
> > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
> >
> > The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
> will land in Fedora 31/rawhide soon. More than likely though it will not be
> official until GlusterFS-8, which will probably land, accordingly, after
> Fedora 31 GA in Fedora 32/rawhide.
>
> Will clients still work, is this server only?
>

Existing 32-bit GlusterFS clients (glusterfs-7 and earlier) should continue
to work just fine — AFAIK — connecting to 64-bit glusterfs servers.

The proposal[1] as it stands is to drop all aspects of 32-bit support, i.e.
client, server, gfapi, etc., going forward from glusterfs-8. This should be
considered advanced notice that consumers that have dependencies need to
plan accordingly.

Please feel free though to add your thoughts to the issue.

[1] https://github.com/gluster/glusterfs/issues/702
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1737402] Upgrade perl-Test-TCP to 2.20

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-08-05 15:52:53



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Mon, Aug 5, 2019 at 8:22 AM Andrew Lutomirski  wrote:
>
> On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik  wrote:
> >
> > Georg Sauthoff writes:
> >
> > > > I ended up tweaking my code to avoid the assertions, rather than 
> > > > disabling
> > > > them. For this particular situation, my original change was to try
> > > >
> > > > std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
> > > >
> > > > But that still tripped the assertion when the foo vector was empty, so I
> > > had
> > > > wrap this inside an if().
> > >
> > > But why don't you use the idiomatic
> > >
> > > copy(foo.begin(), foo.end(), back_inserter(bar));
> > >
> > > ?
> > >
> > > No need to wrap it into an extra if statement.
> >
> > I'm well aware of the alternatives. That's not the point.
> >
> > The point is that there's nothing wrong with this specific form of existing
> > code that now throws exceptions when the hardened build gets turned on.
> > There is no buffer overruns, and nothing to exploit.
> >
> > IIRC, the hardened build did find one real bug in the upstream package that
> > was the original subject matter here, but all of the rest were these kinds
> > of false positives. Now you have a situation when the existing code is known
> > to be working, but needs changing in order to use a hardened build. There's
> > some level of risk of regression in any change, and that gets weighed
> > against the benefits of having a hardened build.
> >
> > The above was just a basic example of this. It is not true that exceptions
> > from hardened code are always evidence of potentially exploitable problem.
> > Sometimes/most of the time, but sometimes they are false positives.
> >
> >
>
> I filed an upstream bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
>
> Depending on the resolution of that bug, I suggest that Fedora
> consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> options.  IMO Fedora's default RPM build options should not cause
> crashes on valid, if less-than-stylistically-great, code.  I don't
> think that package maintainers should need to update package source to
> use C++ in a more polite way.

And the bug has spoken.  v[v.size()] is undefined behavior.  Don't do it!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Untag a build?

[Kevin Fenzi]

On 8/4/19 5:17 AM, Kevin Kofler wrote:

> Can this policy finally get reconsidered? "dnf distro-sync" (and "yum 
> distro-sync" before it) has been available for years now. Is it really worth 
> introducing an Epoch that we will then be stuck with forever, also in 
> releases, just so that Rawhide users can upgrade with "dnf upgrade" rather 
> than "dnf distro-sync"?

You're welcome to ask fesco to reconsider it.

That said, distro-sync is not ideal a lot of times. If you install
locally created packages to test something or fix a bug until a official
build is out, the distro-sync will move them all back to the ones in the
repos. I've also run into cases where distro-sync failed to update at
all due to broken deps, where update did work.

> I absolutely see the necessity of ensuring upgrade paths from release to 
> release, and even from release to Rawhide (because it ensures that the 
> upgrade path will work when Rawhide becomes a release), but from Rawhide to 
> Rawhide, just WHY?

This was discussed in the last big thread on that, and the big thing (at
least to my mind) was that we don't want rawhide to be 'shifting sands'.
Right now if something lands you can be reasonably sure it will get
fixed for issues and that you can count on it being there for rebuilding
against. Sure, someone could do an Epoch and downgrade, but the
resistance to doing that is actually an advantage here. We don't want
people seeing a new build of something they depend on, rebuilding their
entire stack on it, only to have the package downgraded and causing them
tons of work. I think downgrading should be a decision not made lightly.

kevin




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

Re: Orphaned packages looking for new maintainers

[Ankur Sinha]

On Mon, Aug 05, 2019 11:52:20 +0200, Miro Hrončok wrote:
> neuro-sig: ezmorph, mysql-connector-java, pegdown, minlog, jhighlight,
> aws-sdk-java, parboiled, google-oauth-java-client, disruptor, gmetrics,
> groovy18, native-platform, google-http-java-client, kryo, jatl, reflectasm,
> http-builder, jctools, codenarc, jcifs, jmock, json-lib, jdo2-api

Uh---we honestly don't think we can take all of these over to prevent
breakages in the NeuroFedora packages. We'll keep an eye on these and if
things really break, we'll have to decide how to manage these.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: I wish to drop python2-certifi

[Petr Stodulka]

On 05. 08. 19 16:07, Miro Hrončok wrote:

On 29. 07. 19 16:01, Petr Stodulka wrote:

Hi Miro,
thanks for notification. I am thinking about that. From the point, that
Python2 is going to be death... Mabye I would take it, but I am fan of
removing Python2 stuff from Fedora. But Mercurial (hg-git, git-remote-hg,..)
is not compatible with Python3 yet (at least not a version released in
Fedora) but upstream is working on that. From that point, these components
will be updated as well later. So I am thinking whether it makes sense to
take these packages just until Python3-compatible Mercurial will be relased
(v5.0 provides beta support for Python3).
I see that v5.0 is built on OpenSUSE already, so I will look at it later
how does it look like in Fedora rawhide tonight/tomorrow's night.


Hi Petr,

any news on Python 3 mercurial?



Hi Miro.
I apologize for, I will look at it tonight. I switched to the new laptop
and started to use new ssh key and I was not able to authenticate to fedora
servers for the time. Just thought the ssh keys are updated immediately and
there is not 30+ min delay for that (which was longer in my case probably as
I tried to reupload my public key several times). My mistake.

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

Re: Orphaned packages looking for new maintainers

[Ankur Sinha]

On Mon, Aug 05, 2019 11:52:20 +0200, Miro Hrončok wrote:
> python-pykalman   ankursinha, orphan   0 weeks ago

I orphaned this and forgot to remove myself. Done that too now.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Dropping -devel subpackage

[Neal Gompa]

On Mon, Aug 5, 2019 at 11:32 AM Iñaki Ucar  wrote:
>
> Hi,
>
> Quick question not found in the docs. There's a package with a -devel
> subpackage. No package depends on this -devel and upstream removes the
> development files in the new release, so I just dropped the -devel
> subpackage.
>
> Now, it's improbable, but if the old -devel subpackage was installed,
> then "dnf upgrade" complains, obviously:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8c8592ad6
>
> So the question is: should I add "Obsoletes: pkg-devel < $new_version"
> to pkg's SPEC? Is this a proper use of "Obsoletes"?
>

Yes, this is correct usage of Obsoletes.

-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Peter Robinson]

On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley  wrote:
>
>
> There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
>
> The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will 
> land in Fedora 31/rawhide soon. More than likely though it will not be 
> official until GlusterFS-8, which will probably land, accordingly, after 
> Fedora 31 GA in Fedora 32/rawhide.

Will clients still work, is this server only?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik  wrote:
>
> Georg Sauthoff writes:
>
> > > I ended up tweaking my code to avoid the assertions, rather than disabling
> > > them. For this particular situation, my original change was to try
> > >
> > > std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
> > >
> > > But that still tripped the assertion when the foo vector was empty, so I
> > had
> > > wrap this inside an if().
> >
> > But why don't you use the idiomatic
> >
> > copy(foo.begin(), foo.end(), back_inserter(bar));
> >
> > ?
> >
> > No need to wrap it into an extra if statement.
>
> I'm well aware of the alternatives. That's not the point.
>
> The point is that there's nothing wrong with this specific form of existing
> code that now throws exceptions when the hardened build gets turned on.
> There is no buffer overruns, and nothing to exploit.
>
> IIRC, the hardened build did find one real bug in the upstream package that
> was the original subject matter here, but all of the rest were these kinds
> of false positives. Now you have a situation when the existing code is known
> to be working, but needs changing in order to use a hardened build. There's
> some level of risk of regression in any change, and that gets weighed
> against the benefits of having a hardened build.
>
> The above was just a basic example of this. It is not true that exceptions
> from hardened code are always evidence of potentially exploitable problem.
> Sometimes/most of the time, but sometimes they are false positives.
>
>

I filed an upstream bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357

Depending on the resolution of that bug, I suggest that Fedora
consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
options.  IMO Fedora's default RPM build options should not cause
crashes on valid, if less-than-stylistically-great, code.  I don't
think that package maintainers should need to update package source to
use C++ in a more polite way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl10 is now orphaned

[Miro Hrončok]

On 05. 08. 19 16:08, Tomas Mraz wrote:

This is just an announcement that the compat-openssl10 package is now
orphaned.


In that case, python26 is now orphaned as well. It depends on compat-openssl10.

If somebody picks up compat-openssl10, I'll take python26 back.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1737393] Upgrade perl-asa to 1.04

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-9e9ca40955 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9e9ca40955

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737393] Upgrade perl-asa to 1.04

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2019-d6bed12ed2 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-d6bed12ed2

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737395] Upgrade perl-Log-Dispatchouli to 2.019

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Log-Dispatchouli-2.019
   ||-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-05 13:47:42



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737393] Upgrade perl-asa to 1.04

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-asa-1.04-1.fc31



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

compat-openssl10 is now orphaned

[Tomas Mraz]

This is just an announcement that the compat-openssl10 package is now
orphaned.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

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

Re: I wish to drop python2-certifi

[Miro Hrončok]

On 29. 07. 19 16:01, Petr Stodulka wrote:

Hi Miro,
thanks for notification. I am thinking about that. From the point, that
Python2 is going to be death... Mabye I would take it, but I am fan of
removing Python2 stuff from Fedora. But Mercurial (hg-git, git-remote-hg,..)
is not compatible with Python3 yet (at least not a version released in
Fedora) but upstream is working on that. From that point, these components
will be updated as well later. So I am thinking whether it makes sense to
take these packages just until Python3-compatible Mercurial will be relased
(v5.0 provides beta support for Python3).
I see that v5.0 is built on OpenSUSE already, so I will look at it later
how does it look like in Fedora rawhide tonight/tomorrow's night.


Hi Petr,

any news on Python 3 mercurial?

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Dropping -devel subpackage

[Rex Dieter]

Iñaki Ucar wrote:

> On Sun, 4 Aug 2019 at 15:01, Rex Dieter  wrote:
>>
>> Iñaki Ucar wrote:
>>
>> > On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
>> >>
>> >> > So the question is: should I add "Obsoletes: pkg-devel <
>> >> > $new_version" to pkg's SPEC? Is this a proper use of "Obsoletes"?
>> >>
>> >> Yes. Exactly a right thing to do.
>> >
>> > Thanks, Miro. Then, I suggest to add this particular case to the
>> > documentation. Not sure where though, but FWIW, my first search was
>> > "drop subpackage" and *not* the "Obsoletes" subsection.
>>
>> That case should already be covered by the "replace" part of:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
> 
> That's not clear to me. I read that in the first place, and I didn't
> identify this case either as a rename nor a replacement. A replacement
> is like bar that obsoletes foo. But here we have foo and
> foo-something, and at some point the latter is dropped (and not
> provided in foo).

Originally I'd considered that the *main* package was effectively replacing 
-devel, though on second thought it's not a full replacement (ie, only 
Obsoletes without Provides).

-- Rex

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Miro Hrončok]

On 05. 08. 19 15:36, Kaleb Keithley wrote:

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.

The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land 
in Fedora 31/rawhide soon. More than likely though it will not be official until 
GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 
32/rawhide.




[1] https://github.com/gluster/glusterfs/issues/702


What about the dependent packages?

$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel
glusterfs-api-devel-0:6.4-3.fc31.i686
glusterfs-api-devel-0:6.4-3.fc31.x86_64
libvirt-0:5.5.0-2.fc31.src
qemu-2:4.1.0-0.1.rc2.fc31.src
samba-2:4.10.6-0.fc31.2.src
uwsgi-0:2.0.18-2.fc31.src

$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
gluster-block-0:0.4-4.fc31.src
glusterfs-coreutils-0:0.3.1-2.fc31.src
libvirt-0:5.5.0-2.fc31.src
nfs-ganesha-0:2.8.2-3.fc31.src
qemu-2:4.1.0-0.1.rc2.fc31.src
samba-2:4.10.6-0.fc31.2.src
scsi-target-utils-0:1.0.70-9.fc31.src
tcmu-runner-0:1.1.3-2.fc26.src
uwsgi-0:2.0.18-2.fc31.src

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Ben Cotton]

On Mon, Aug 5, 2019 at 9:51 AM Kaleb Keithley  wrote:
>
>
> There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
>
> The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will 
> land in Fedora 31/rawhide soon. More than likely though it will not be 
> official until GlusterFS-8, which will probably land, accordingly, after 
> Fedora 31 GA in Fedora 32/rawhide.
>
> [1] https://github.com/gluster/glusterfs/issues/702
>

Kaleb, when this is determined upstream, can you please file this as a
Fedora 32 (or whatever version) change proposal? Note that the Fedora
31 Change proposal deadline has already passed and that F31 branches
from rawhide on 13 August.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kaleb Keithley]

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.

The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will
land in Fedora 31/rawhide soon. More than likely though it will not be
official until GlusterFS-8, which will probably land, accordingly, after
Fedora 31 GA in Fedora 32/rawhide.



[1] https://github.com/gluster/glusterfs/issues/702

--

Kaleb
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kaleb Keithley]

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.

The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will
land in Fedora 31/rawhide soon. More than likely though it will not be
official until GlusterFS-8, which will probably land, accordingly, after
Fedora 31 GA in Fedora 32/rawhide.



[1] https://github.com/gluster/glusterfs/issues/702

--

Kaleb
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: New graphical dependency visualiser prototype

[Adam Samalik]

On Sun, Aug 4, 2019 at 8:16 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> How does it deal with rich dependencies? Does it take conflicts into the
> account? What about multiple provides which satisfy dependency?
>

It doesn't at the moment deal with rich dependencies. It's an early
prototype I made in a single day for people to try and potentially expand.
:)

Since the script evaluates an actual installation where decisions have been
already made (as opposed to repositories that can potentially provide many
options) the script doesn't take conflict nor multiple provides into
account.

That said, in the future updates, I can see it taking repositories into
account and based on that offering alternative options to some packages,
even showing the potential impact or even making suggestions.



>
> On Sun, Aug 4, 2019, 19:41 Adam Samalik  wrote:
>
>> I wrote a script to visualise dependencies of RPM installations [1]. It
>> supports file paths and container images as an input.
>>
>> The script generates a graph of packages and their relations including
>> sizes of all individual packages and some basic clustering. Clicking on a
>> package highlights its relations to other packages. [2]
>>
>> Hopefully this will be useful for the Minimization objective [3].
>>
>> [1] https://pagure.io/minimization/dependency-visualiser
>> [2] https://asamalik.fedorapeople.org/showme/fedora-base-image.svg
>> [3] https://docs.fedoraproject.org/en-US/minimization/
>>
>> --
>>
>> Adam Šamalík
>> ---
>> Senior Software Engineer
>> Red Hat
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kaleb Keithley]

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.

The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will
land in Fedora 31/rawhide soon. More than likely though it will not be
official until GlusterFS-8, which will probably land, accordingly, after
Fedora 31 GA in Fedora 32/rawhide.



[1] https://github.com/gluster/glusterfs/issues/702

--

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

Feedback on Application Streams and modularity

[Terry Bowling]

Hello Fedora friends!

I would like to follow up and collect your input on Application Streams and
modularity after all of the discussions over the past month.  We have been
listening and brainstorming on how to proceed with both the tooling, user
experience, and communicating better upstream for this process.

The team working on modularity in Fedora posted some revisions to the Fedora
modularity documentation .
Additionally, I described the end user experience expectations in this
thread
,
essentially describing why fully automated stream switching cannot occur
for a sane distro environment- at least at our current level of
understanding and tooling.  While my description was certainly focused on
the RHEL user perspective, as a long time Fedora user I will say this is
equally true for many Fedora users.

That said, I am hoping you could share your collective wisdom and provide
us feedback on the following:

 1.  Have we better communicated the current features and goals of
Application Streams and modularity, primarily focused on end users?

 2.  Does this help developers better understand the current limiting
state and challenges for both stream and other tooling limitations?

 3. What can you share from commercial ISV and/or community developer
perspectives, and with respect to the user experience and stable distro
goals previously described for Application Streams, do you have
recommendations or requests for specific behaviors or tooling needed to
benefit the Fedora and RHEL ecosystems?  Such as but not limited :

  a. How to provide the ability to switch streams without breaking
a user's choice or need for a different AppStream in the dependency chain.

  b. What feature or tooling gaps still exist for creating
community or commercial products for RHEL & Fedora?

  c. Anything I did not think to ask?

Thank you for your feedback!
---
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2019-08-05)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

We have no issues tagged for the meeting. I will open the
meeting for Open Floor if we have quorum.

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

or run:
  date -d '2019-08-05 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 =
Non-responsive maintainer: ricardohttps://pagure.io/fesco/issue/2194
Approved (+4, 0, -0)

F31 Self-Contained Change: Bundler 2.0https://pagure.io/fesco/issue/2183
Approved (+4, 0, -0)

F31 Self-Contained Change: Mono 5.20https://pagure.io/fesco/issue/2182
Approved (+4, 0, -0)

Unresponsive Maintainer: dchenhttps://pagure.io/fesco/issue/2171
Approved (+3, 0, -0)

Discussion on SGX packaginghttps://pagure.io/fesco/issue/2153
FESCo permits the use of pre-signed Intel SGX components under the firmware
clause of the Licensing Guidelines, provided that Fedora Legal concurs.
(+3, 0, -0)

= Followups =

There are no follow-up issues tagged for the meeting.

= New business =

There are no new issues tagged for the meeting.

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found
athttps://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 athttps://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.
-BEGIN PGP SIGNATURE-
Version: Mailvelope v4.0.0
Comment: https://www.mailvelope.com

wkYEAREIAAYFAl1IIo4ACgkQeiVVYja6o6PfjQCgg2hLd/TgkxNerHKSwE++
64GdiAMAn1X0dEpENa8xkZLEKnrVF92XYoGg
=C+Dq
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 05. 08. 19 14:02, Mikolaj Izdebski wrote:

gradle-local package can't be removed yet because other packages
depend on it. Removing dependency involves porting packages from
Gradle to Maven, which can only be done by package maintainers.
However most of Java package maintainers are not really active. Only
after gradle package is retired, packages that transitively
build-depend on it (through graldle-local) will become FTBFS and I
will be allowed to fix them per provenpackager policy.


Oh. If you know how to fix the packages per provenpackager policy, it means we 
can retire gradle right away?


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: 20190805.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190804.n.0
NEW: Fedora-Rawhide-20190805.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  9
Dropped packages:0
Upgraded packages:   76
Downgraded packages: 1

Size of added packages:  580.15 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.15 GiB
Size of downgraded packages: 1.40 MiB

Size change of upgraded packages:   -1.88 MiB
Size change of downgraded packages: -174.49 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-c2-chacha-0.2.2-1.fc31
Summary: ChaCha family of stream ciphers
RPMs:rust-c2-chacha+byteorder-devel rust-c2-chacha+default-devel 
rust-c2-chacha+lazy_static-devel rust-c2-chacha+rustcrypto_api-devel 
rust-c2-chacha+simd-devel rust-c2-chacha+std-devel 
rust-c2-chacha+stream-cipher-devel rust-c2-chacha-devel
Size:71.58 KiB

Package: rust-rand0.6-0.6.5-1.fc31
Summary: Random number generators and other randomness functionality
RPMs:rust-rand0.6+alloc-devel rust-rand0.6+default-devel 
rust-rand0.6+i128_support-devel rust-rand0.6+log-devel 
rust-rand0.6+nightly-devel rust-rand0.6+packed_simd-devel 
rust-rand0.6+rand_os-devel rust-rand0.6+serde1-devel 
rust-rand0.6+simd_support-devel rust-rand0.6+std-devel 
rust-rand0.6+stdweb-devel rust-rand0.6+wasm-bindgen-devel rust-rand0.6-devel
Size:188.70 KiB

Package: rust-rand_chacha0.1-0.1.1-1.fc31
Summary: ChaCha random number generator
RPMs:rust-rand_chacha0.1+default-devel rust-rand_chacha0.1-devel
Size:27.30 KiB

Package: rust-rand_core0.4-0.4.0-1.fc31
Summary: Core random number generator traits and tools for implementation
RPMs:rust-rand_core0.4+alloc-devel rust-rand_core0.4+default-devel 
rust-rand_core0.4+serde-devel rust-rand_core0.4+serde1-devel 
rust-rand_core0.4+serde_derive-devel rust-rand_core0.4+std-devel 
rust-rand_core0.4-devel
Size:70.59 KiB

Package: rust-rand_hc0.1-0.1.0-1.fc31
Summary: HC128 random number generator
RPMs:rust-rand_hc0.1+default-devel rust-rand_hc0.1-devel
Size:26.93 KiB

Package: rust-rand_isaac0.1-0.1.1-1.fc31
Summary: ISAAC random number generator
RPMs:rust-rand_isaac0.1+default-devel rust-rand_isaac0.1+serde-devel 
rust-rand_isaac0.1+serde1-devel rust-rand_isaac0.1+serde_derive-devel 
rust-rand_isaac0.1-devel
Size:52.55 KiB

Package: rust-rand_jitter0.1-0.1.4-1.fc31
Summary: Random number generator based on timing jitter
RPMs:rust-rand_jitter0.1+default-devel rust-rand_jitter0.1+log-devel 
rust-rand_jitter0.1+std-devel rust-rand_jitter0.1-devel
Size:48.13 KiB

Package: rust-rand_pcg0.1-0.1.2-1.fc31
Summary: Selected PCG random number generators
RPMs:rust-rand_pcg0.1+default-devel rust-rand_pcg0.1+serde-devel 
rust-rand_pcg0.1+serde1-devel rust-rand_pcg0.1+serde_derive-devel 
rust-rand_pcg0.1-devel
Size:48.23 KiB

Package: rust-rand_xorshift0.1-0.1.1-1.fc31
Summary: Xorshift random number generator
RPMs:rust-rand_xorshift0.1+default-devel rust-rand_xorshift0.1+serde-devel 
rust-rand_xorshift0.1+serde1-devel rust-rand_xorshift0.1+serde_derive-devel 
rust-rand_xorshift0.1-devel
Size:46.13 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  FAudio-19.08-1.fc31
Old package:  FAudio-19.03-2.fc31
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 778.02 KiB
Size change:  63.27 KiB
Changelog:
  * Sun Aug 04 2019 Michael Cronenworth  - 19.08-1
  - Update to 19.08


Package:  OpenImageIO-2.0.10-1.fc31
Old package:  OpenImageIO-2.0.9-1.fc31
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 35.36 MiB
Size change:  -69.30 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
2.0.9-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sun Aug 04 2019 Richard Shaw  - 2.0.10-1
  - Update to 2.0.10.


Package:  R-units-0.6.3-2.fc31
Old package:  R-units-0.6.3-1.fc31
Summary:  Measurement Units for R Vectors
RPMs: R-units
Size: 4.57 MiB
Size change:  1.06 KiB
Changelog:
  * Sun Aug 04 2019 I??aki ??car  - 0.6.3-2
  - Add dropped -devel subpackage to Obsoletes


Package:  bcm283x-firmware-20190801-1.3822340.fc31
Old package:  bcm283x-firmware-20190715-1.cba4be2.fc31
Summary:  Broadcom bcm283x firmware for the Raspberry Pi
RPMs: bcm283x-firmware
Size: 12.68 MiB
Size change:  40.71 KiB
Changelog:
  * Sun Aug 04 2019 Peter Robinson  
20190801-1.3822340
  - Latest firmware update


Package:  blackbox-0.74-1.fc31
Old package:  blackbox-0.70.1-31.fc28
Summary:  Very small and fast Window Manager
RPMs: blackbox blackbox-devel
Size: 2.71 MiB
Size change:  839.50 KiB
Changelog:
  * Thu Jul 12 2018 Fedora Release Engineering  - 
0.70.1-32
  - Rebuilt for https://fedoraproject.org/wiki

Re: Orphaned packages looking for new maintainers

[Mikolaj Izdebski]

On Mon, Aug 5, 2019 at 1:50 PM Hans de Goede  wrote:
>
> Hi Fabio,
>
> On 05-08-19 13:37, Fabio Valentini wrote:
> > On Mon, Aug 5, 2019 at 1:15 PM Mikolaj Izdebski  wrote:
> >>
> >> On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede  wrote:
> >>> In the extended version: 
> >>> https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
> >>> I see that javapackages-tools is still on the list (because it depends on 
> >>> gradle)
> >>> and that in turn brings problems for lot of other packages.
> >>>
> >>> So I wonder what the plan forward is. I've been looking at my own packages
> >>> which depend on javapackages-tools and they really only need 2 things:
> >>
> >>  From my side as owner of javapackages-tools the plan is to do nothing
> >> as there is no problem with javapackages-tools packages (that I know
> >> of). If at some point of time javapackages-tools becomes FTBFS or FTI
> >> due to gradle or another of its dependencies being retired, I will fix
> >> the problem in an adequate way.
> >>
> >>>
> >>> 1) javapackages-filesystem
> >>> 2) %jpackage_script macro (and it deps)
> >>>
> >>> Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty 
> >>> much
> >>> the minimum set of what packages need to follow the guidelines. It seems 
> >>> that
> >>> javapackages-tools contains way more then this and I'm wondering if it 
> >>> would
> >>> be a good idea to do a javapackages-tools-minimal as a separate package 
> >>> and
> >>> move the 2 items from above there. Then over time we can move 
> >>> java-packages
> >>> in the base package set to use javapackages-tools-minimal and eventually 
> >>> drop
> >>> the full javapackages-tools from the base package set.
> >>
> >> I don't see any reason to add javapackages-tools-minimal or migrate
> >> any packages. If there are any issues with javapackages-tools then
> >> please open bugs and I will respond to them.
> >
> > To clarify, the package that *does* depend on a number of orphans is
> > gradle, which also marks javapackages-tools and its sub-packages as
> > affected.
> > gradle is currently owned by the Stewardship SIG, but there is no
> > reason for us to "maintain" it indefinitely. In fact, the gradle
> > packaging is problematic in some ways:
> >
> > - the version packaged by fedora (and every other distro building it
> > from source) is really outdated (4.4.1, released Dec 2017, vs. 5.5.1,
> > released July 2019)
> > - the build process is rather involved, and gradle currently can't
> > even build itself
> >
> > Only about 10 "active" fedora packages are built with gradle, and they
> > could be ported to use maven instead. There's already some fedora
> > packages which are built with maven "downstream" instead of with the
> > upstream gradle build system - including junit5, testng, and
> > aqute-bnd.
> >
> > So, I am currently preparing to drop gradle after f31 was branched
> > from rawhide (but keep it working in f31), unless somebody else steps
> > up to maintain gradle and the dozens of dependencies it pulls in. If /
> > when gradle support is eventually dropped, then we'll then have to
> > remove gradle-local from javapackages-tools as well (which is easy,
> > since that change already happened in modular branches).
>
> Thank you for all your work on this I'm happy to hear that the
> gradle -> javapackages-tools -> lots of packages dep chain is
> going to get fixed for F31.
>
> I do wonder though if the modular version of javapackages-tools has
> already dropped gradle-local, perhaps we can move ahead and already
> do the same thing in Fedora (31+)? Less cross package deps seems like
> a good thing to me? But I guess that some other packages in the base
> repo still depend on gradle-local?

gradle-local package can't be removed yet because other packages
depend on it. Removing dependency involves porting packages from
Gradle to Maven, which can only be done by package maintainers.
However most of Java package maintainers are not really active. Only
after gradle package is retired, packages that transitively
build-depend on it (through graldle-local) will become FTBFS and I
will be allowed to fix them per provenpackager policy.

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

Fedora-Rawhide-20190805.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
13 of 45 required tests failed, 8 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: 39/147 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20190804.n.0):

ID: 429304  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/429304

Old failures (same test failed in Fedora-Rawhide-20190804.n.0):

ID: 429200  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/429200
ID: 429206  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/429206
ID: 429211  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/429211
ID: 429212  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429212
ID: 429214  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/429214
ID: 429215  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/429215
ID: 429216  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/429216
ID: 429217  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/429217
ID: 429218  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/429218
ID: 429219  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/429219
ID: 429220  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429220
ID: 429221  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/429221
ID: 429222  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/429222
ID: 429223  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/429223
ID: 429225  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/429225
ID: 429230  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429230
ID: 429231  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429231
ID: 429240  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429240
ID: 429243  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429243
ID: 429246  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/429246
ID: 429247  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/429247
ID: 429248  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/429248
ID: 429249  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/429249
ID: 429258  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429258
ID: 429261  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/429261
ID: 429263  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/429263
ID: 429264  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/429264
ID: 429325  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429325
ID: 429326  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429326
ID: 429327  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/429327
ID: 429328  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429328
ID: 429331  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/429331
ID: 429332  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/429332
ID: 429333  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429333
ID: 429335  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/429335
ID: 429336  Test: x86_64 

Re: Orphaned packages looking for new maintainers

[Hans de Goede]

Hi Fabio,

On 05-08-19 13:37, Fabio Valentini wrote:

On Mon, Aug 5, 2019 at 1:15 PM Mikolaj Izdebski  wrote:


On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede  wrote:

In the extended version: 
https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
I see that javapackages-tools is still on the list (because it depends on 
gradle)
and that in turn brings problems for lot of other packages.

So I wonder what the plan forward is. I've been looking at my own packages
which depend on javapackages-tools and they really only need 2 things:


 From my side as owner of javapackages-tools the plan is to do nothing
as there is no problem with javapackages-tools packages (that I know
of). If at some point of time javapackages-tools becomes FTBFS or FTI
due to gradle or another of its dependencies being retired, I will fix
the problem in an adequate way.



1) javapackages-filesystem
2) %jpackage_script macro (and it deps)

Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much
the minimum set of what packages need to follow the guidelines. It seems that
javapackages-tools contains way more then this and I'm wondering if it would
be a good idea to do a javapackages-tools-minimal as a separate package and
move the 2 items from above there. Then over time we can move java-packages
in the base package set to use javapackages-tools-minimal and eventually drop
the full javapackages-tools from the base package set.


I don't see any reason to add javapackages-tools-minimal or migrate
any packages. If there are any issues with javapackages-tools then
please open bugs and I will respond to them.


To clarify, the package that *does* depend on a number of orphans is
gradle, which also marks javapackages-tools and its sub-packages as
affected.
gradle is currently owned by the Stewardship SIG, but there is no
reason for us to "maintain" it indefinitely. In fact, the gradle
packaging is problematic in some ways:

- the version packaged by fedora (and every other distro building it
from source) is really outdated (4.4.1, released Dec 2017, vs. 5.5.1,
released July 2019)
- the build process is rather involved, and gradle currently can't
even build itself

Only about 10 "active" fedora packages are built with gradle, and they
could be ported to use maven instead. There's already some fedora
packages which are built with maven "downstream" instead of with the
upstream gradle build system - including junit5, testng, and
aqute-bnd.

So, I am currently preparing to drop gradle after f31 was branched
from rawhide (but keep it working in f31), unless somebody else steps
up to maintain gradle and the dozens of dependencies it pulls in. If /
when gradle support is eventually dropped, then we'll then have to
remove gradle-local from javapackages-tools as well (which is easy,
since that change already happened in modular branches).


Thank you for all your work on this I'm happy to hear that the
gradle -> javapackages-tools -> lots of packages dep chain is
going to get fixed for F31.

I do wonder though if the modular version of javapackages-tools has
already dropped gradle-local, perhaps we can move ahead and already
do the same thing in Fedora (31+)? Less cross package deps seems like
a good thing to me? But I guess that some other packages in the base
repo still depend on gradle-local?

Regards,

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Neal Gompa]

On Mon, Aug 5, 2019 at 3:49 AM Simo Sorce  wrote:
>
> On Fri, 2019-08-02 at 19:13 +0200, Björn 'besser82' Esser wrote:
> > Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
> > > The upstream KiCAD project has requested that I remove
> > > GLIBCXX_ASSERTIONS from the Fedora package, as described here:
> > > https://bugs.launchpad.net/kicad/+bug/1838448
> > >
> > > What is the best way to do that?  I can add "%undefine
> > > _hardened_build" (which I am testing now) but I think that will remove
> > > other hardening features that I might want to leave enabled.
> > >
> > > Steve
> >
> > Simply add this to your spec file:
> >
> > # Upstream recommends to turn off _GLIBCXX_ASSERTIONS.
> > # See: $UPSTREAM_BUG
> > %global optflags %optflags -U_GLIBCXX_ASSERTIONS
>
> Am I the only one worried of seeing way too many people jumping on and
> telling how to suppress these hardening features without a word of
> cautiousness ?
>
> I feel like we should scan all spec files for this kind of stuff and
> raise bugs if we find more than a handful of packages with this kind of
> "workarounds" ...
>

Not many people are equipped to figure these out, and usually when
these new flags are introduced, they come with no help and no
information from the people introducing them.

The last time I had to deal with this, I didn't even know this was the
culprit initially, and I was stubborn and got upstream to help fix the
issue. Koschei logs of dependency shifts with successes and failures
helped me pinpoint the flaw.

My experience with these issues is why I've never proposed increasing
our default hardening. It's far too difficult to debug and the
compiler people are unable or unwilling to help in most circumstances.

Thankfully with *my* packages, I've gotten rid of most of filter-outs.
But my D language packages require me to filter out quite a bit since
our flags are enforced regardless of compiler, and currently all D
software uses LDC, not GDC. We should probably fix that, but it's not
the only language that forces us to deal with the "problem child" that
is LLVM and the Clang stack.


-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intention to retire Release Notes RPM

[Martin Kolman]

On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote:
> On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
>  wrote:
> > Hi All,
> > 
> > Barring objection, I plan to retire the release notes package from
> > Fedora on or after August 9, 2019.  The package has not been updated
> > since F28.  Despite the fact that we have literally shipped a package
> > containing the F28 release notes in F29 and F30, there have been no
> > comments.  This has been discussed with the docs team and is
> > supported.  I am not aware of any dependencies and I believe it was
> > removed from release criteria in F29.
> > 
> > I will run `fedpkg retire` and further request removal via
> > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages
> > 
> > Please reply on list if you have any questions or concerns.
> > 
> 
> Does Anaconda not support showing the release notes _anywhere_? That
> was the original impetus for shipping it that way...
There is currently no screen in either graphical or text interface of Anaconda 
that would show Fedora release notes.
> 
> 
> 
> -- 
> 真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Fabio Valentini]

On Mon, Aug 5, 2019 at 1:15 PM Mikolaj Izdebski  wrote:
>
> On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede  wrote:
> > In the extended version: 
> > https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
> > I see that javapackages-tools is still on the list (because it depends on 
> > gradle)
> > and that in turn brings problems for lot of other packages.
> >
> > So I wonder what the plan forward is. I've been looking at my own packages
> > which depend on javapackages-tools and they really only need 2 things:
>
> From my side as owner of javapackages-tools the plan is to do nothing
> as there is no problem with javapackages-tools packages (that I know
> of). If at some point of time javapackages-tools becomes FTBFS or FTI
> due to gradle or another of its dependencies being retired, I will fix
> the problem in an adequate way.
>
> >
> > 1) javapackages-filesystem
> > 2) %jpackage_script macro (and it deps)
> >
> > Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty 
> > much
> > the minimum set of what packages need to follow the guidelines. It seems 
> > that
> > javapackages-tools contains way more then this and I'm wondering if it would
> > be a good idea to do a javapackages-tools-minimal as a separate package and
> > move the 2 items from above there. Then over time we can move java-packages
> > in the base package set to use javapackages-tools-minimal and eventually 
> > drop
> > the full javapackages-tools from the base package set.
>
> I don't see any reason to add javapackages-tools-minimal or migrate
> any packages. If there are any issues with javapackages-tools then
> please open bugs and I will respond to them.

To clarify, the package that *does* depend on a number of orphans is
gradle, which also marks javapackages-tools and its sub-packages as
affected.
gradle is currently owned by the Stewardship SIG, but there is no
reason for us to "maintain" it indefinitely. In fact, the gradle
packaging is problematic in some ways:

- the version packaged by fedora (and every other distro building it
from source) is really outdated (4.4.1, released Dec 2017, vs. 5.5.1,
released July 2019)
- the build process is rather involved, and gradle currently can't
even build itself

Only about 10 "active" fedora packages are built with gradle, and they
could be ported to use maven instead. There's already some fedora
packages which are built with maven "downstream" instead of with the
upstream gradle build system - including junit5, testng, and
aqute-bnd.

So, I am currently preparing to drop gradle after f31 was branched
from rawhide (but keep it working in f31), unless somebody else steps
up to maintain gradle and the dozens of dependencies it pulls in. If /
when gradle support is eventually dropped, then we'll then have to
remove gradle-local from javapackages-tools as well (which is easy,
since that change already happened in modular branches).

Come to my flock talk if you want to hear more horror stories like this ;)


Fabio

> --
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Zbigniew Jędrzejewski-Szmek]

On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
> Whoop this is great!
> But I wonder why the scratch build sizes have gone up this dramatically in
> f31?

Also, there are still some obvious packages to trim:

No udev, but device-mapper, device-mapper-libs, which are not useful
without udev.

Also, there's a bunch of -devel packages? What pulls those in?
libmount-devel, libblkid-devel, glib2-devel, libassuan,
libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
pcre2-devel, zlib-devel.

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

[Bug 1737396] Upgrade perl-Math-NumSeq to 73

[bugzilla]

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

Miro Hrončok  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Math-NumSeq-73-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-05 10:21:07



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Orphaning some Perl packages

[Miro Hrončok]

I plan to orphan the following packages during this week:

perl-ExtUtils-Typemap
perl-IO-Socket-PortState
perl-Lingua-EN-Numbers
perl-Math-ConvexHull
perl-Math-ConvexHull-MonotoneChain
perl-Math-Geometry-Voronoi
perl-UUID-Tiny

They were previously needed by slic3r, but no longer appear to be.

Let me know if you want some.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737396] Upgrade perl-Math-NumSeq to 73

[bugzilla]

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

Miro Hrončok  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Miro Hrončok  ---
On it!

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737402] New: Upgrade perl-Test-TCP to 2.20

[bugzilla]

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

Bug ID: 1737402
   Summary: Upgrade perl-Test-TCP to 2.20
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-TCP
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.19 version. Upstream released 2.20. When you have free
time, please upgrade it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1385002] Upgrade perl-Pod-PseudoPod-LaTeX to 1.20190729

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com
Summary|Upgrade |Upgrade
   |perl-Pod-PseudoPod-LaTeX to |perl-Pod-PseudoPod-LaTeX to
   |1.20160626  |1.20190729



--- Comment #3 from Jitka Plesnikova  ---
Latest Fedora delivers 1.20110710 version. Upstream released 1.20190729.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737396] New: Upgrade perl-Math-NumSeq to 73

[bugzilla]

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

Bug ID: 1737396
   Summary: Upgrade perl-Math-NumSeq to 73
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-NumSeq
  Assignee: mhron...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 72 version. Upstream released 73. When you have free
time, please upgrade it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737395] New: Upgrade perl-Log-Dispatchouli to 2.019

[bugzilla]

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

Bug ID: 1737395
   Summary: Upgrade perl-Log-Dispatchouli to 2.019
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Dispatchouli
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.017 version. Upstream released 2.019. When you have
free time, please upgrade it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737394] New: Upgrade perl-Dancer2 to 0.208001

[bugzilla]

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

Bug ID: 1737394
   Summary: Upgrade perl-Dancer2 to 0.208001
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dancer2
  Assignee: dd...@cpan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.208000 version. Upstream released 0.208001. When you
have free time, please upgrade it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1737393] New: Upgrade perl-asa to 1.04

[bugzilla]

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

Bug ID: 1737393
   Summary: Upgrade perl-asa to 1.04
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-asa
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.03 version. Upstream released 1.04. When you have free
time, please upgrade it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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 looking for new maintainers

[Mikolaj Izdebski]

On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede  wrote:
> In the extended version: 
> https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
> I see that javapackages-tools is still on the list (because it depends on 
> gradle)
> and that in turn brings problems for lot of other packages.
>
> So I wonder what the plan forward is. I've been looking at my own packages
> which depend on javapackages-tools and they really only need 2 things:

From my side as owner of javapackages-tools the plan is to do nothing
as there is no problem with javapackages-tools packages (that I know
of). If at some point of time javapackages-tools becomes FTBFS or FTI
due to gradle or another of its dependencies being retired, I will fix
the problem in an adequate way.

>
> 1) javapackages-filesystem
> 2) %jpackage_script macro (and it deps)
>
> Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much
> the minimum set of what packages need to follow the guidelines. It seems that
> javapackages-tools contains way more then this and I'm wondering if it would
> be a good idea to do a javapackages-tools-minimal as a separate package and
> move the 2 items from above there. Then over time we can move java-packages
> in the base package set to use javapackages-tools-minimal and eventually drop
> the full javapackages-tools from the base package set.

I don't see any reason to add javapackages-tools-minimal or migrate
any packages. If there are any issues with javapackages-tools then
please open bugs and I will respond to them.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 05. 08. 19 12:07, Hans de Goede wrote:

Hi all,

On 05-08-19 11:52, 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.

See the report at https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
Grep ti for your FAS username and follow the dependency chain.


Miro, thank you for generating these reports.

In the extended version: 
https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
I see that javapackages-tools is still on the list (because it depends on 
gradle)
and that in turn brings problems for lot of other packages.

So I wonder what the plan forward is. I've been looking at my own packages
which depend on javapackages-tools and they really only need 2 things:

1) javapackages-filesystem
2) %jpackage_script macro (and it deps)

Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much
the minimum set of what packages need to follow the guidelines. It seems that
javapackages-tools contains way more then this and I'm wondering if it would
be a good idea to do a javapackages-tools-minimal as a separate package and
move the 2 items from above there. Then over time we can move java-packages
in the base package set to use javapackages-tools-minimal and eventually drop
the full javapackages-tools from the base package set.

In the mean time I guess we need to fix the gradle problem to fix all these
broken dependency chains for F31, I guess ideally by dropping the gradle dep if
possible...


https://pagure.io/stewardship-sig/issue/35


Miro, it seems that the full report is still not picking up all the additional
problems caused by javapackage-tools also being the sole provider of\
javapackages-filesystem ?


Unfortunately, I won't be able to fix this any time soon.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Panu Matilainen]

On 7/30/19 6:10 PM, Jason L Tibbitts III wrote:

"PM" == Panu Matilainen  writes:


PM> So a big +1 for sysusers in sub-packages + file trigger to handle
PM> running systemd-sysusers. It solves more problems than the current
PM> sysusers-proposal and in a far more elegant way at that.

It's great that you agree.  That leaves all of the details.  What's the
simplest way to accomplish this in a way that's easy for packagers to
use?  Is there any way for RPM to do this internally?

I would really like to avoid this becoming a bunch of extra boilerplate
in the relevant packages, or rather, for this conversion to result in a
net reduction of boilerplate.  Can the subpackage generation be
reasonably hidden behind macros?  Or is it possible to use a mechanism
similar to the way debuginfo packages are generated to automatically
define the subpackages when necessary?


No idea. I'd suggest taking a look at what OpenSUSE has done in this 
area. I haven't looked at the details at all, that somebody is using 
sysusers this way I only learned from this thread last week.




A related question is whether there are any cases where multiple
packages (from different SRPMs) which don't depend on each other but all
depend on the same user being created.  Our current methods handle this
well enough (all of the packages just create the user) but that probably
won't work in any scheme using sysusers.  The way to handle that seems
relatively obvious (just have a separate SRPM that creates the user upon
which the other packages can depend) but I don't know if it's a case
that would need to be documented.


A separate source package is one way, but it could be just as well 
created by a sub-package by one of those multiple packages. Or maybe 
such a thing would belong in setup, or a sysuser sub-package from it. 
Again, I'd just look at what others have done before reinventing anything.


- Panu -



  - J<


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

Orphaning pgtoolkit

[Miro Hrončok]

I'm orphaning pgtoolkit, I don't remember why I have the package.


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning some Perl packages

[Miro Hrončok]

I plan to orphan the following packages during this week:

perl-ExtUtils-Typemap
perl-IO-Socket-PortState
perl-Lingua-EN-Numbers
perl-Math-ConvexHull
perl-Math-ConvexHull-MonotoneChain
perl-Math-Geometry-Voronoi
perl-UUID-Tiny

They were previously needed by slic3r, but no longer appear to be.

Let me know if you want some.
--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Hans de Goede]

Hi all,

On 05-08-19 11:52, 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.

See the report at https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
Grep ti for your FAS username and follow the dependency chain.


Miro, thank you for generating these reports.

In the extended version: 
https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
I see that javapackages-tools is still on the list (because it depends on 
gradle)
and that in turn brings problems for lot of other packages.

So I wonder what the plan forward is. I've been looking at my own packages
which depend on javapackages-tools and they really only need 2 things:

1) javapackages-filesystem
2) %jpackage_script macro (and it deps)

Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much
the minimum set of what packages need to follow the guidelines. It seems that
javapackages-tools contains way more then this and I'm wondering if it would
be a good idea to do a javapackages-tools-minimal as a separate package and
move the 2 items from above there. Then over time we can move java-packages
in the base package set to use javapackages-tools-minimal and eventually drop
the full javapackages-tools from the base package set.

In the mean time I guess we need to fix the gradle problem to fix all these
broken dependency chains for F31, I guess ideally by dropping the gradle dep if
possible...

Regards,

Hans

p.s.

Miro, it seems that the full report is still not picking up all the additional
problems caused by javapackage-tools also being the sole provider of\
javapackages-filesystem ?

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

Re: Join the new Minimization Team

[Clement Verna]

On Mon, 5 Aug 2019 at 10:59, Alexander Bokovoy  wrote:
>
> On ma, 05 elo 2019, Clement Verna wrote:
> >On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:
> >>
> >> >> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> >> >>  wrote:
> >> >> >
> >> >> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> >> >> > > I've already done some experiments with that. I used multi-stage 
> >> >> > > builds
> >> >> > > with podman, but it's the same in principle. And yes, the sizes are
> >> >> > > smaller. What was interesting though that some additional packages 
> >> >> > > (ones
> >> >> > > that wouldn't appear in the images using the Fedora base image) has 
> >> >> > > been
> >> >> > > dragged in as dependencies. Some of them are even related to 
> >> >> > > hardware. (See
> >> >> > > the report [1] and the github repo [2].)
> >> >> >
> >> >> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> >> >> > anymore.
> >> >> >
> >> >> > A lot of the stuff in those images seems completely unnecessary:
> >> >> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> >> >> > grubby, systemd-bootchart, systemd-udev.
> >> >> >
> >> >> > > So that might be one area to focus on — to make sure that these 
> >> >> > > "from
> >> >> > > scratch" installations don't drag unnecessary stuff.
> >> >> >
> >> >> > Yep, that sounds like a good start. I suspect that F30 might be 
> >> >> > already
> >> >> > better in this regard.
> >> >>
> >> >> Yes quite a bit has happened on the base image since F29, we have
> >> >> removed quite a few things and trimmed down the latest rawhide to
> >> >> 208MB. I am sure that can still be improved and I welcome any help on
> >> >> that :-).
> >> >
> >> >
> >> > I've regenerated it for f30 and f31: 
> >> > https://asamalik.fedorapeople.org/container-randomness/report.html
> >> >
> >> > I see the fedora:f31 image is 195 MB, woot!
> >>
> >> Is there a plan to add some form of CI to monitor this? It would make
> >> it easy to monitor ups/downs over time and pick up mistakes that bloat
> >> deps by accident.
> >
> >I started some effort in that sense last year, to have the Fedora CI
> >pipeline to trigger on container builds[0]. Unfortunately the CI
> >pipeline for containers is not working [1] and it seems that nobody
> >has cycles to try to fix it.
> >We could also get some inspiration from what the Docker Hub folks are
> >doing [2][3].
> >
> >And finally I would love to sunset registry.fp.o and just use quay.io
> >as our main registry that would give us for CVE scanning for free
> >using Clair[4] (that would also be one less thing to care about on the
> >infra side), but here again there is some work to be done to make that
> >possible :-)
> Do we have all the same containers in quay.io?
>
> FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
> for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
> quay.io/fedora/ project.

Nope and that's what I meant by saying that this needs some works to
make it possible :-) (Pretty much configure OSBS to publish images to
quay.io instead of registry.fp.o). We also need to make sure that we
can deliver flatpaks from quay.io.

>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning/retiring 3 Java packages

[Miro Hrončok]

On 05. 08. 19 9:57, Mikolaj Izdebski wrote:

On Tue, Jul 23, 2019 at 5:24 PM Miro Hrončok  wrote:


On 23. 07. 19 16:08, Mikolaj Izdebski wrote:

On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:

I acknowledge that it is your right to orphan essentially anything you want,
however the motivation here seems a bit... nonempathetic.

Would you mind to reconsider?


Definitely - this is the reason I wrote to the list. Do you have any
proposal what to do with these packages instead of orphaning them?


Keep maintaining them in normal Fedora until modular packages can be used in
nonmodular builds? CCing contyk, he might have some news about that.


OK, I will see how the situation develops and will then reconsider my
decision. For now I will keep maintaining these packages.


Thank You!

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning/retiring 3 Java packages

[Mikolaj Izdebski]

On Wed, Jul 24, 2019 at 8:04 PM Peter Boy  wrote:
> Sorry for jumping in. I think this might be an opportunity to participate in 
> the Fedora Projekt. I’ve a lot of experience in java development and in 
> creating application rpms, but none in the specialties of Fedora packaging. 
> Would you accept me as co-maintainer and provide some guidance at the 
> beginning?

I suppose you're not a packager yet. Regarding guidance, you can start
with reading Java Packaging HOWTO [1] and Fedora packaging
documentation on the wiki. If you have any questions then feel free to
contact Java SIG [2] members through IRC or our mailing list. You
don't need to be co-maintainer to contribute to Fedora packages - you
can attach patches to bugs (either existing ones, or newly opened by
you). Some maintainers also accept pull requests. Once you prove
yourself you may be sponsored as packager and added as co-maintainer.

[1] https://fedora-java.github.io/howto
[2] https://fedoraproject.org/wiki/SIGs/Java

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Alexander Bokovoy]

On ma, 05 elo 2019, Clement Verna wrote:

On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:


>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages (ones
>> > > that wouldn't appear in the images using the Fedora base image) has been
>> > > dragged in as dependencies. Some of them are even related to hardware. 
(See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>
>
> I've regenerated it for f30 and f31: 
https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!

Is there a plan to add some form of CI to monitor this? It would make
it easy to monitor ups/downs over time and pick up mistakes that bloat
deps by accident.


I started some effort in that sense last year, to have the Fedora CI
pipeline to trigger on container builds[0]. Unfortunately the CI
pipeline for containers is not working [1] and it seems that nobody
has cycles to try to fix it.
We could also get some inspiration from what the Docker Hub folks are
doing [2][3].

And finally I would love to sunset registry.fp.o and just use quay.io
as our main registry that would give us for CVE scanning for free
using Clair[4] (that would also be one less thing to care about on the
infra side), but here again there is some work to be done to make that
possible :-)

Do we have all the same containers in quay.io?

FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
quay.io/fedora/ project.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning/retiring 3 Java packages

[Mikolaj Izdebski]

On Tue, Jul 23, 2019 at 5:24 PM Miro Hrončok  wrote:
>
> On 23. 07. 19 16:08, Mikolaj Izdebski wrote:
> > On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:
> >> I acknowledge that it is your right to orphan essentially anything you 
> >> want,
> >> however the motivation here seems a bit... nonempathetic.
> >>
> >> Would you mind to reconsider?
> >
> > Definitely - this is the reason I wrote to the list. Do you have any
> > proposal what to do with these packages instead of orphaning them?
>
> Keep maintaining them in normal Fedora until modular packages can be used in
> nonmodular builds? CCing contyk, he might have some news about that.

OK, I will see how the situation develops and will then reconsider my
decision. For now I will keep maintaining these packages.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Clement Verna]

On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:
>
> >> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> >>  wrote:
> >> >
> >> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> >> > > I've already done some experiments with that. I used multi-stage builds
> >> > > with podman, but it's the same in principle. And yes, the sizes are
> >> > > smaller. What was interesting though that some additional packages 
> >> > > (ones
> >> > > that wouldn't appear in the images using the Fedora base image) has 
> >> > > been
> >> > > dragged in as dependencies. Some of them are even related to hardware. 
> >> > > (See
> >> > > the report [1] and the github repo [2].)
> >> >
> >> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> >> > anymore.
> >> >
> >> > A lot of the stuff in those images seems completely unnecessary:
> >> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> >> > grubby, systemd-bootchart, systemd-udev.
> >> >
> >> > > So that might be one area to focus on — to make sure that these "from
> >> > > scratch" installations don't drag unnecessary stuff.
> >> >
> >> > Yep, that sounds like a good start. I suspect that F30 might be already
> >> > better in this regard.
> >>
> >> Yes quite a bit has happened on the base image since F29, we have
> >> removed quite a few things and trimmed down the latest rawhide to
> >> 208MB. I am sure that can still be improved and I welcome any help on
> >> that :-).
> >
> >
> > I've regenerated it for f30 and f31: 
> > https://asamalik.fedorapeople.org/container-randomness/report.html
> >
> > I see the fedora:f31 image is 195 MB, woot!
>
> Is there a plan to add some form of CI to monitor this? It would make
> it easy to monitor ups/downs over time and pick up mistakes that bloat
> deps by accident.

I started some effort in that sense last year, to have the Fedora CI
pipeline to trigger on container builds[0]. Unfortunately the CI
pipeline for containers is not working [1] and it seems that nobody
has cycles to try to fix it.
We could also get some inspiration from what the Docker Hub folks are
doing [2][3].

And finally I would love to sunset registry.fp.o and just use quay.io
as our main registry that would give us for CVE scanning for free
using Clair[4] (that would also be one less thing to care about on the
infra side), but here again there is some work to be done to make that
possible :-)

[0] - https://src.fedoraproject.org/container/tools/pull-request/6
[1] - https://pagure.io/fedora-ci/general/issue/47
[2] - 
https://github.com/docker-library/official-images/pull/6394#issuecomment-517452501
[3] - 
https://github.com/docker-library/official-images/pull/6394#issuecomment-517454047
[4] - https://github.com/coreos/clair
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Simo Sorce]

On Fri, 2019-08-02 at 19:13 +0200, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
> > The upstream KiCAD project has requested that I remove
> > GLIBCXX_ASSERTIONS from the Fedora package, as described here: 
> > https://bugs.launchpad.net/kicad/+bug/1838448
> > 
> > What is the best way to do that?  I can add "%undefine
> > _hardened_build" (which I am testing now) but I think that will remove
> > other hardening features that I might want to leave enabled.
> > 
> > Steve
> 
> Simply add this to your spec file:
> 
> # Upstream recommends to turn off _GLIBCXX_ASSERTIONS.
> # See: $UPSTREAM_BUG
> %global optflags %optflags -U_GLIBCXX_ASSERTIONS

Am I the only one worried of seeing way too many people jumping on and
telling how to suppress these hardening features without a word of
cautiousness ?

I feel like we should scan all spec files for this kind of stuff and
raise bugs if we find more than a handful of packages with this kind of
"workarounds" ...

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

Re: Rolling out Phase I of rawhide package gating

[Florian Weimer]

* Pierre-Yves Chibon:

> On Sat, Aug 03, 2019 at 11:20:35AM -0700, Kevin Fenzi wrote:
>> On 8/2/19 11:13 AM, Florian Weimer wrote:
>> > * Pierre-Yves Chibon:
>> > 
>> >> When you run `fedpkg build` on Rawhide, your package will be built in
>> >> a new koji tag (which will be the default target for Rawhide). The
>> >> package will be picked up from this koji tag, signed and moved onto a
>> >> second tag. Bodhi will be notified by koji once this new build is
>> >> signed and will automatically create an update for it (you will be
>> >> notified about this by email by bodhi directly) with a “Testing”
>> >> status. If the package maintainer has not opted in into the CI
>> >> workflow, the update will be pushed to “Stable” and the build will be
>> >> pushed into the regular Rawhide tag, making it available in the
>> >> Rawhide buildroot, just as it is today.
>> > 
>> > I see both “Status stable” and a “Push to Testing” button in the upper
>> > right here:
>> > 
>> >   
>> > 
>> > Is this a UI issue?
>> 
>> It's an issue of some kind definitely... either it should not show that
>> or not allow it.
>
> +1
>
> Could you please make a ticket of this at:
> https://github.com/fedora-infra/bodhi/issues/ ?

Done: 

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org