Re: Not a bug

2020-01-18 Thread John M. Harris Jr
On Saturday, January 18, 2020 6:31:11 PM MST John Reiser wrote:
> On 2020-01-19 00:21 UTC, Ken Dreyer wrote:
> 
> > On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones 
> > wrote:
>  [[snip]]
> 
> >> Sorry, not a bug.  I remembered that I had put some alternate
> >> certificates into ~/.koji to access another Koji instance.
> 
> 
> 
> > I think there is a usability RFE here. If we get an SSLError *and* the
> > Koji client is configured to use one specific CA bundle file on disk,
> > then we should log that path to the CA file we used.
> 
> 
> +1.  This is analogous to ENOENT, where the error message should include
> the actual path that was attempted, and not just "File not found".
> Even using a pronoun such as "configuration file not found" is not enough;
> give the actual path.

ENOENT is a much different scenario. In the case of ENOENT, what that actually 
means depends on what function you've just tried to call, and you know the 
path, if one is relevant.

-- 
John M. Harris, Jr.
Splentity

___
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 1792689] New: perl-IO-Tty-1.14 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1792689

Bug ID: 1792689
   Summary: perl-IO-Tty-1.14 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Tty
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org,
tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.14
Current version/release in rawhide: 1.12-16.fc31
URL: http://search.cpan.org/dist/IO-Tty/

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


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


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


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

-- 
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 1792689] perl-IO-Tty-1.14 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1792689



--- Comment #1 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!

-- 
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: FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Kevin Fenzi
On Sat, Jan 18, 2020 at 11:32:30PM +0100, Fabio Valentini wrote:
...snip...
> 
> Sounds interesting!
> Koji might suffer from the database dump cron job ... though I'm not
> sure at which time of day it's supposed to run.

The backup runs at 00:00UTC + $RANDOM % 7200 seconds. 

We have tried all kinds of things to lower the impact of it. :(
There's a set of commits in the upcoming 1.20 koji version that I really
hope will help out. I'd also really like to move the database host to
rhel8 (and a newer postgres) which should just help by itself, but also
would allow us to partition the buildroot_listing table (which is most
of the problem, it being inserted into all the time and being 215GB).o

kevin


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


[389-devel] 389 DS nightly 2020-01-19 - 96% PASS

2020-01-18 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2020/01/19/report-389-ds-base-1.4.3.1-20200119gitcf849cc.fc31.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


Re: FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Jerry James
On Sat, Jan 18, 2020 at 3:33 PM Fabio Valentini  wrote:
> Looking at the current report, these are the currently broken OCaml
> packages (be it FTBFS or FTI), keyed by primary POC:
>
[snip]
> defolos: ocaml-bin-prot, ocaml-deriving

Dan and I are working on updating ocaml-bin-prot to the latest Jane
Street version.  However, we will have to add about a dozen more
packages to Fedora before that is possible.  It will take a little
time.

The ocaml-deriving package is not needed and should be retired.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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 1792674] New: perl-IO-Stty-0.04 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1792674

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



Latest upstream release: 0.04
Current version/release in rawhide: 0.03-24.fc31
URL: http://search.cpan.org/dist/IO-Stty/

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


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


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


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

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


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

2020-01-18 Thread updates
The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-360263f378   
libetpan-1.0-3.el6_10
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-db6621b9a8   
perl-Clipboard-0.21-1.el6.1


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

zchunk-1.1.5-1.el6

Details about builds:



 zchunk-1.1.5-1.el6 (FEDORA-EPEL-2020-505c9e8cf8)
 Compressed file format that allows easy deltas

Update Information:

Fix small bug in corner case when handling write failures, making sure to get
proper error messages when out of disk space.

ChangeLog:

* Sat Jan 18 2020 Jonathan Dieter  - 1.1.5-1
- Fix small bug in corner case when handling write failures


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org


[Bug 1792672] New: perl-Catalyst-Runtime-5.90125 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1792672

Bug ID: 1792672
   Summary: perl-Catalyst-Runtime-5.90125 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Catalyst-Runtime
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.90125
Current version/release in rawhide: 5.90124-4.fc31
URL: http://search.cpan.org/dist/Catalyst-Runtime/

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


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


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


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

-- 
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 1789498] perl-Swim-0.1.48 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1789498

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Swim-0.1.48-1.fc32 |perl-Swim-0.1.48-1.fc32
   ||perl-Swim-0.1.48-1.fc30
 Resolution|--- |ERRATA
Last Closed||2020-01-19 01:00:36



--- Comment #5 from Fedora Update System  ---
perl-Swim-0.1.48-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 1790712] perl-Log-Any-Adapter-Callback-0.100 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1790712

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Log-Any-Adapter-Callba
   ||ck-0.100-1.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-01-19 01:38:06



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1430536

-- 
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 1791109] perl-Mojolicious-8.31 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1791109

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-8.31-1.fc3
   ||2
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-01-19 01:37:10



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1430537

-- 
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 1792249] perl-CGI-Compile-0.23 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1792249

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CGI-Compile-0.23-1.fc3
   ||2
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-01-19 01:36:13



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1430535

-- 
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: Not a bug

2020-01-18 Thread John Reiser

On 2020-01-19 00:21 UTC, Ken Dreyer wrote:

On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones  wrote:

[[snip]]

Sorry, not a bug.  I remembered that I had put some alternate
certificates into ~/.koji to access another Koji instance.



I think there is a usability RFE here. If we get an SSLError *and* the
Koji client is configured to use one specific CA bundle file on disk,
then we should log that path to the CA file we used.


+1.  This is analogous to ENOENT, where the error message should include
the actual path that was attempted, and not just "File not found".
Even using a pronoun such as "configuration file not found" is not enough;
give the actual path.
___
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 1786801] perl-Encode-3.02 is available

2020-01-18 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1786801

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Encode-3.02-440.fc32   |perl-Encode-3.02-440.fc32
   ||perl-Encode-3.02-11.fc30
 Resolution|--- |ERRATA
Last Closed||2020-01-19 01:00:30



--- Comment #6 from Fedora Update System  ---
perl-Encode-3.02-11.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


Re: Not a bug (was: Re: Can't log into Koji)

2020-01-18 Thread Ken Dreyer
On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones  wrote:
>
> On Sat, Jan 18, 2020 at 12:02:08PM +, Richard W.M. Jones wrote:
> >
> > $ KRB5_TRACE=/dev/stderr koji -d hello
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,619 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,619 [DEBUG] koji: gssapi auth failed: 
> > requests.exceptions.SSLError: 
> > HTTPSConnectionPool(host='koji.fedoraproject.org', port=443): Max retries 
> > exceeded with url: /kojihub/ssllogin (Caused by 
> > SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
> > certificate verify failed: unable to get local issuer certificate 
> > (_ssl.c:1108)')))
> >
> > Traceback (most recent call last):
> >   File "/usr/bin/koji", line 336, in 
> > rv = locals()[command].__call__(options, session, args)
> >   File "/usr/lib/python3.8/site-packages/koji_cli/commands.py", line 7372, 
> > in handle_moshimoshi
> > activate_session(session, options)
> >   File "/usr/lib/python3.8/site-packages/koji_cli/lib.py", line 571, in 
> > activate_session
> > session.krb_login(proxyuser=runas)
> >   File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2258, in 
> > krb_login
> > if self.gssapi_login(principal, keytab, ccache, proxyuser=proxyuser):
> >   File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2415, in 
> > gssapi_login
> > raise AuthError('unable to obtain a session')
> > koji.AuthError: unable to obtain a session
>
> Sorry, not a bug.  I remembered that I had put some alternate
> certificates into ~/.koji to access another Koji instance.

I think there is a usability RFE here. If we get an SSLError *and* the
Koji client is configured to use one specific CA bundle file on disk,
then we should log that path to the CA file we used.

- Ken
___
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: FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Fabio Valentini
On Sat, Jan 18, 2020 at 10:30 PM Richard W.M. Jones  wrote:
>
> On Sat, Jan 18, 2020 at 04:38:27PM +0100, Fabio Valentini wrote:
> > On Sat, Jan 18, 2020 at 1:09 PM Richard W.M. Jones  
> > wrote:
> > >
> > > OCaml 4.10.0 beta1 was released upstream about a week ago
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=1673688).  I'm intending
> > > to build OCaml packages into a side tag starting today, and then
> > > if it seems to work well integrate it into F32.
> > >
> > > The release notes for this are here:
> > >
> > >   https://github.com/ocaml/ocaml/blob/4.10/Changes
> > >
> > > Please note there are some incompatible changes.  The ones which I
> > > think may affect Fedora are below (but there are more, please read the
> > > release notes in full):
> >
> > How will this change the number of OCaml packages that are already
> > broken in rawhide? Will it get better or worse with this rebuild?
> > There seem to be a number of OCaml packages that haven't even been
> > built with either 4.08 or 4.09 yet.
> >
> > OCaml packages cause most of the "broken dependencies" in rawhide
> > right now, and drown out almost everything else:
> > See: 
> > https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md
>
> This is the first I've heard of this.  I can't fix stuff I don't
> know about!

Sure, no pressure - just wanted to make sure you know about it.

> I've just looked at the link you posted, and it seems a bit "biased"
> to OCaml packages because of the way that Fedora packages encode OCaml
> dependencies into RPM dependencies, resulting in many ocaml(Stdlib_*)
> dependencies which are essentially saying the same thing.

Yeah, that's what I figured after looking at the list.
RPM seems to generate large number of AutoProv / AutoReq entries for a
small number of packages, which skews the statistics.

> There are many packages in the list which are orphaned, especially all
> the camlp4 deprecations[1].  Those should be ignored IMO.

Erm ... none of the packages with broken dependencies is orphaned right now.
Looking at Miro's "orphaned packages report", not a single OCaml
package is orphaned right now.
Unless you meant to say that the *missing* things are caused by
packages that were orphaned and then retired (which is a different
issue ...)

> As for the rest, not sure I can action anything unless I can get a
> list of actually broken packages which are not orphaned.  But don't do
> anything until the current rebuild is out of the way.

Looking at the current report, these are the currently broken OCaml
packages (be it FTBFS or FTI), keyed by primary POC:

andyli: ocaml-benchmark, ocaml-rope
avsej: utop
defolos: ocaml-bin-prot, ocaml-deriving
orion: ocaml-plplot
rjones: ocaml-curl, ocaml-json-wheel, ocaml-ocamlnet, ocaml-pxp,
ocaml-ulex, ocaml-xmlrpc-light
tc01: ocaml-dose3, ocaml-lambda-term, ocaml-lwt-log
(orphan: ---)

And don't worry, the report is purely informational. I won't do anything :)
The data does not inform any actions, beside me filing BugZilla
reports for new and obvious breakages when I see them.
I try to generate the report daily, so obvious issues and oversights
can get reported and fixed in a timely fashion.

> About the current rebuild: I finally fixed a bunch of problems with my
> rebuild script (which I'm writing at the same time, see [2]) - but now
> Koji seems to be actually broken ...

Sounds interesting!
Koji might suffer from the database dump cron job ... though I'm not
sure at which time of day it's supposed to run.

Fabio

> Rich.
>
> [1] 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2JBIWB423ECYGBXZ3QCPR7NQ66XGXTU/
>
> [2] 
> https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/
>
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> ___
> 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: FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Richard W.M. Jones
On Sat, Jan 18, 2020 at 04:38:27PM +0100, Fabio Valentini wrote:
> On Sat, Jan 18, 2020 at 1:09 PM Richard W.M. Jones  wrote:
> >
> > OCaml 4.10.0 beta1 was released upstream about a week ago
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1673688).  I'm intending
> > to build OCaml packages into a side tag starting today, and then
> > if it seems to work well integrate it into F32.
> >
> > The release notes for this are here:
> >
> >   https://github.com/ocaml/ocaml/blob/4.10/Changes
> >
> > Please note there are some incompatible changes.  The ones which I
> > think may affect Fedora are below (but there are more, please read the
> > release notes in full):
> 
> How will this change the number of OCaml packages that are already
> broken in rawhide? Will it get better or worse with this rebuild?
> There seem to be a number of OCaml packages that haven't even been
> built with either 4.08 or 4.09 yet.
>
> OCaml packages cause most of the "broken dependencies" in rawhide
> right now, and drown out almost everything else:
> See: 
> https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md

This is the first I've heard of this.  I can't fix stuff I don't
know about!

I've just looked at the link you posted, and it seems a bit "biased"
to OCaml packages because of the way that Fedora packages encode OCaml
dependencies into RPM dependencies, resulting in many ocaml(Stdlib_*)
dependencies which are essentially saying the same thing.

There are many packages in the list which are orphaned, especially all
the camlp4 deprecations[1].  Those should be ignored IMO.

As for the rest, not sure I can action anything unless I can get a
list of actually broken packages which are not orphaned.  But don't do
anything until the current rebuild is out of the way.

About the current rebuild: I finally fixed a bunch of problems with my
rebuild script (which I'm writing at the same time, see [2]) - but now
Koji seems to be actually broken ...

Rich.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2JBIWB423ECYGBXZ3QCPR7NQ66XGXTU/

[2] 
https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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


[EPEL-devel] Re: Software Collection packages for EPEL

2020-01-18 Thread Dmitry Butskoy

Stephen John Smoogen wrote:

On Sat, 11 Jan 2020 at 12:13, Dmitry Butskoy  wrote:

Kevin Fenzi wrote:

OK we are now syncing to rhel-7-server-devtools-rpms and those have
the needed rust-toolset, llvm-toolset and other tools which someone
needing to rebuild chromium or seamonkey. Please test and let me know
what you run into.


Seems nothing changed yet,

DEBUG util.py:596:  No matching package to install: 'rust-toolset-1.35-rust'
DEBUG util.py:596:  No matching package to install: 'rust-toolset-1.35-cargo'
DEBUG util.py:596:  No matching package to install: 'llvm-toolset-7.0'
DEBUG util.py:596:  No matching package to install: 
'llvm-toolset-7.0-llvm-devel'

See https://koji.fedoraproject.org/koji/taskinfo?taskID=40377953

I did a repo regen, can you try again when:
https://koji.fedoraproject.org/koji/taskinfo?taskID=40393080

is done?

Now it cannot find devtoolset-8 :

DEBUG util.py:596:  No matching package to install: 'devtoolset-8-gcc'
DEBUG util.py:596:  No matching package to install: 'devtoolset-8-gcc-c++'
DEBUG util.py:596:  No matching package to install: 
'devtoolset-8-libatomic-devel'

See https://koji.fedoraproject.org/koji/taskinfo?taskID=40411197


OK this is just messed up. The newer version only has the older
devtoolset, and the what I thought was the older version only has the
newer devtoolset but not the other libraries you need. I am guessing I
will need to add both the buildroot as separate secondary channels but
I have no idea if things will work. This is what I get for putting in
work on a Friday to production.

My apologies for the broken set.


Is there any progress in this?

~buc
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org


Re: RFC: Python minimization in Fedora

2020-01-18 Thread James Cassell

On Thu, Jan 16, 2020, at 5:16 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 
> A quick benchmark:
> $ time python3 -c 'import importlib as i, pydoc_data.topics as t; 
> [i.reload(t) for _ in range(1)]'
> python3 -c   4.16s user 0.45s system 99% cpu 4.646 total
[...]
> sudo rm /usr/lib64/python3.7/pydoc_data/__pycache__/topics.cpython-37.*
> 
> $ time python3 -c 'import importlib as i, pydoc_data.topics as t; 
> [i.reload(t) for _ in range(1000)]'
> python3 -c   13.73s user 0.46s system 96% cpu 14.728 total
[...]
> But the effect of having *some* .pyc file is not. For this file (which
> is 600+kb), the difference is 147.28/4.646 ≈ 30 times. So we clearly
> need to keep the possibility of installing .pyc files, at least optionally.
> 

Thanks for doing these benchmarks! I think you misplaced a decimal in the 
analysis, though; it's closer to 3 times performance difference, not 30 times.  
(Unless I missed something.)

V/r,
James Cassell
___
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: Mock build Fedora package on CentOS 7

2020-01-18 Thread Nico Kadel-Garcia
This is turning into a "debug mock on CentOS" discussion, not a Fedora
discussion per se. Please let me know if it should be over in the mock
github.com issues instead.

On Sat, Jan 18, 2020 at 10:56 AM Ian Pilcher  wrote:
>
> On 1/18/20 5:07 AM, Nico Kadel-Garcia wrote:
> > The inserted arguments are order sensitive, and need to be in the
> > right place in fedora-31.tmpl on the latest release of mock and
> > mock-core-cnfigs. See my notes at:
> >
> >  https://github.com/rpm-software-management/mock/issues/390
> >
> > And use this in /etc/mock/templates/fedora-31.tmpl
> >
> >  config_opts['bootstrap_image'] = 'fedora:31'
> >  config_opts['use_bootstrap_image'] = True
> >  config_opts['use_bootstrap_container'] = True
> >
> > This uses podman to download an OS image, installs that, uses that to
> > run mock tools to build a new image, etc. It's a bootstrap process,
> > it's slow, and I've found it to be burdensome and fragile, not
> > allowing operation on certain host server filesystems. And no, I don't
> > remember the list of forbidden filesystems.
>
> I was aware of that issue, but I wasn't aware that it affected the
> command-line options.  After editing fedora-31.tpl, I can now see mock
> pulling the container image and rebuilding the root cache.

I don't use the command line options for this. Since I found the
selected options in the config files to be order sensitive and
unstable unless inserted in certain order in certain places, I don't
have complete confidence in the Python command line options and simply
write my own config files. Since mock lets you select a locally edited
and source controlled config file, this is much safer for me.

> Unfortunately, I still get the same error in the end:
>
>   Start: build phase for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
>   Start: build setup for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
>   warning: line 206: It's not recommended to have unversioned Obsoletes:
> Obsoletes:  thunderbird-lightning
>   warning: extra tokens at the end of %endif directive in line 625:
> %endif # build_langpacks

Yeah Fedora 31 rpmbuild is a lot nosier about these.

>   Building target platfms: x86_64
>   Building for target x86_64
>   setting SOURCE_DATE_EPOCH=157896
>   Wrote: /builddir/build/SRPMS/thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
>   Failed to set locale, defaulting to C.UTF-8
>   No matches found for the following disable plugin patterns: local,
> spacewalk
>   No such command: builddep. Please use /usr/bin/dnf --help
>   It could be a DNF plugin command, try: "dnf install
> 'dnf-command(builddep)'"
>   Finish: build setup for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
>   Finish: build phase for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
>   ERROR: Exception(thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm)
> Config(fedora-31-x86_64) 3 minutes 5 seconds
>   INFO: Results and/or logs in: /var/lib/mock/fedora-31-x86_64/result
>   ERROR: builddep command missing.
>   Please install package dnf-plugins-core.

I think you're missing some of the options I've suggested for dnf
based operating systems, or fedora-31.tmpl in particular in my
published mock-core-configs.spec file.  And is you "mock" up to the
latest reason from EPEL I'll urge you to publish a diff between the
RPM published fedora-31.tmpl and yours to isolate the issue.
___
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: Mock build Fedora package on CentOS 7

2020-01-18 Thread Ian Pilcher

On 1/18/20 5:07 AM, Nico Kadel-Garcia wrote:

The inserted arguments are order sensitive, and need to be in the
right place in fedora-31.tmpl on the latest release of mock and
mock-core-cnfigs. See my notes at:

 https://github.com/rpm-software-management/mock/issues/390

And use this in /etc/mock/templates/fedora-31.tmpl

 config_opts['bootstrap_image'] = 'fedora:31'
 config_opts['use_bootstrap_image'] = True
 config_opts['use_bootstrap_container'] = True

This uses podman to download an OS image, installs that, uses that to
run mock tools to build a new image, etc. It's a bootstrap process,
it's slow, and I've found it to be burdensome and fragile, not
allowing operation on certain host server filesystems. And no, I don't
remember the list of forbidden filesystems.


I was aware of that issue, but I wasn't aware that it affected the
command-line options.  After editing fedora-31.tpl, I can now see mock
pulling the container image and rebuilding the root cache.

Unfortunately, I still get the same error in the end:

 Start: build phase for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
 Start: build setup for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
 warning: line 206: It's not recommended to have unversioned Obsoletes: 
Obsoletes:  thunderbird-lightning
 warning: extra tokens at the end of %endif directive in line 625: 
%endif # build_langpacks


 Building target platforms: x86_64
 Building for target x86_64
 setting SOURCE_DATE_EPOCH=157896
 Wrote: /builddir/build/SRPMS/thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
 Failed to set locale, defaulting to C.UTF-8
 No matches found for the following disable plugin patterns: local, 
spacewalk

 No such command: builddep. Please use /usr/bin/dnf --help
 It could be a DNF plugin command, try: "dnf install 
'dnf-command(builddep)'"

 Finish: build setup for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
 Finish: build phase for thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
 ERROR: Exception(thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm) 
Config(fedora-31-x86_64) 3 minutes 5 seconds

 INFO: Results and/or logs in: /var/lib/mock/fedora-31-x86_64/result
 ERROR: builddep command missing.
 Please install package dnf-plugins-core.

--

 In Soviet Russia, Google searches you!

___
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: FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Fabio Valentini
On Sat, Jan 18, 2020 at 1:09 PM Richard W.M. Jones  wrote:
>
> OCaml 4.10.0 beta1 was released upstream about a week ago
> (https://bugzilla.redhat.com/show_bug.cgi?id=1673688).  I'm intending
> to build OCaml packages into a side tag starting today, and then
> if it seems to work well integrate it into F32.
>
> The release notes for this are here:
>
>   https://github.com/ocaml/ocaml/blob/4.10/Changes
>
> Please note there are some incompatible changes.  The ones which I
> think may affect Fedora are below (but there are more, please read the
> release notes in full):

How will this change the number of OCaml packages that are already
broken in rawhide? Will it get better or worse with this rebuild?
There seem to be a number of OCaml packages that haven't even been
built with either 4.08 or 4.09 yet.

OCaml packages cause most of the "broken dependencies" in rawhide
right now, and drown out almost everything else:
See: 
https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md

Fabio

>   * #1859, #9117: enforce safe (immutable) strings by removing
> the -unsafe-string option by default. This can be overridden by
> a configure-time option (available since 4.04 in 2016):
> --disable-force-safe-string since 4.08, -no-force-safe-since
> between 4.07 and 4.04.
>
> I don't intend to enable this option in our build.  If my greps are
> right there is one package (coccinelle) which is still hanging on
> to -unsafe-string.
>
>   In the force-safe-string mode (now the default), the return type of the
>   String_val macro in C stubs is `const char*` instead of
>   `char*`. This change may break C FFI code.
>   (Kate Deplaix)
>
> This will probably affect more packages, but is a trivial
> const-correctness fix.
>
>   * #8713: Introduce a state table in the runtime to contain the global 
> variables.
> (The Multicore runtime will have one such state for each domain.)
>
>  This changes the name of some internal variables of the OCaml runtime;
>  in many cases  provides a compatibility macro with
>  the old name, but programs using runtime internals may need to be fixed.
>
> Properly written FFI extensions shouldn't hit this, but I imagine
> there will be some that are affected.  I will try to fix these on a
> case by case basis.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> 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


Not a bug (was: Re: Can't log into Koji)

2020-01-18 Thread Richard W.M. Jones
On Sat, Jan 18, 2020 at 12:02:08PM +, Richard W.M. Jones wrote:
> 
> $ KRB5_TRACE=/dev/stderr koji -d hello
> 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> 2020-01-18 12:00:47,619 [DEBUG] koji: Opening new requests session
> 2020-01-18 12:00:47,619 [DEBUG] koji: gssapi auth failed: 
> requests.exceptions.SSLError: 
> HTTPSConnectionPool(host='koji.fedoraproject.org', port=443): Max retries 
> exceeded with url: /kojihub/ssllogin (Caused by 
> SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
> certificate verify failed: unable to get local issuer certificate 
> (_ssl.c:1108)')))
> 
> Traceback (most recent call last):
>   File "/usr/bin/koji", line 336, in 
> rv = locals()[command].__call__(options, session, args)
>   File "/usr/lib/python3.8/site-packages/koji_cli/commands.py", line 7372, in 
> handle_moshimoshi
> activate_session(session, options)
>   File "/usr/lib/python3.8/site-packages/koji_cli/lib.py", line 571, in 
> activate_session
> session.krb_login(proxyuser=runas)
>   File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2258, in 
> krb_login
> if self.gssapi_login(principal, keytab, ccache, proxyuser=proxyuser):
>   File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2415, in 
> gssapi_login
> raise AuthError('unable to obtain a session')
> koji.AuthError: unable to obtain a session

Sorry, not a bug.  I remembered that I had put some alternate
certificates into ~/.koji to access another Koji instance.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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


FYI: OCaml 4.10.0 beta1 will go into Fedora 32 soonish

2020-01-18 Thread Richard W.M. Jones
OCaml 4.10.0 beta1 was released upstream about a week ago
(https://bugzilla.redhat.com/show_bug.cgi?id=1673688).  I'm intending
to build OCaml packages into a side tag starting today, and then
if it seems to work well integrate it into F32.

The release notes for this are here:

  https://github.com/ocaml/ocaml/blob/4.10/Changes

Please note there are some incompatible changes.  The ones which I
think may affect Fedora are below (but there are more, please read the
release notes in full):

  * #1859, #9117: enforce safe (immutable) strings by removing
the -unsafe-string option by default. This can be overridden by
a configure-time option (available since 4.04 in 2016):
--disable-force-safe-string since 4.08, -no-force-safe-since
between 4.07 and 4.04.

I don't intend to enable this option in our build.  If my greps are
right there is one package (coccinelle) which is still hanging on
to -unsafe-string.

  In the force-safe-string mode (now the default), the return type of the
  String_val macro in C stubs is `const char*` instead of
  `char*`. This change may break C FFI code.
  (Kate Deplaix)

This will probably affect more packages, but is a trivial
const-correctness fix.

  * #8713: Introduce a state table in the runtime to contain the global 
variables.
(The Multicore runtime will have one such state for each domain.)

 This changes the name of some internal variables of the OCaml runtime;
 in many cases  provides a compatibility macro with
 the old name, but programs using runtime internals may need to be fixed.

Properly written FFI extensions shouldn't hit this, but I imagine
there will be some that are affected.  I will try to fix these on a
case by case basis.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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-Cloud-31-20200118.0 compose check report

2020-01-18 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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


Can't log into Koji

2020-01-18 Thread Richard W.M. Jones

$ KRB5_TRACE=/dev/stderr koji -d hello
2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
2020-01-18 12:00:47,619 [DEBUG] koji: Opening new requests session
2020-01-18 12:00:47,619 [DEBUG] koji: gssapi auth failed: 
requests.exceptions.SSLError: 
HTTPSConnectionPool(host='koji.fedoraproject.org', port=443): Max retries 
exceeded with url: /kojihub/ssllogin (Caused by 
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify failed: unable to get local issuer certificate 
(_ssl.c:1108)')))

Traceback (most recent call last):
  File "/usr/bin/koji", line 336, in 
rv = locals()[command].__call__(options, session, args)
  File "/usr/lib/python3.8/site-packages/koji_cli/commands.py", line 7372, in 
handle_moshimoshi
activate_session(session, options)
  File "/usr/lib/python3.8/site-packages/koji_cli/lib.py", line 571, in 
activate_session
session.krb_login(proxyuser=runas)
  File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2258, in 
krb_login
if self.gssapi_login(principal, keytab, ccache, proxyuser=proxyuser):
  File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2415, in 
gssapi_login
raise AuthError('unable to obtain a session')
koji.AuthError: unable to obtain a session

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: Mock build Fedora package on CentOS 7

2020-01-18 Thread Nico Kadel-Garcia
On Thu, Jan 16, 2020 at 10:50 AM Ian Pilcher  wrote:
>
> On 1/16/20 9:39 AM, Miroslav Suchý wrote:
> > https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap
>
> Right, but it still doesn't work.
>
> [pilcher@breadbox ~]$ cat /etc/centos-release
> CentOS Linux release 7.7.1908 (Core)
>
> [pilcher@breadbox ~]$ cd /etc/mock/templates
> [pilcher@breadbox templates]$ grep bootstrap_image fedora-31.tpl
> config_opts['bootstrap_image'] = 'fedora:31'
>
> [pilcher@breadbox templates]$ cd
> [pilcher@breadbox ~]$ mock --bootstrap-chroot --use-bootstrap-image -r
> fedora-31-x86_64 thunderbird-68.4.1-1.mzbz1526765.fc31.src.rpm
> INFO: mock.py version 1.4.21 starting (python version = 3.6.8)...

The inserted arguments are order sensitive, and need to be in the
right place in fedora-31.tmpl on the latest release of mock and
mock-core-cnfigs. See my notes at:

https://github.com/rpm-software-management/mock/issues/390

And use this in /etc/mock/templates/fedora-31.tmpl

config_opts['bootstrap_image'] = 'fedora:31'
config_opts['use_bootstrap_image'] = True
config_opts['use_bootstrap_container'] = True

This uses podman to download an OS image, installs that, uses that to
run mock tools to build a new image, etc. It's a bootstrap process,
it's slow, and I've found it to be burdensome and fragile, not
allowing operation on certain host server filesystems. And no, I don't
remember the list of forbidden filesystems.
___
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: RFC: Python minimization in Fedora

2020-01-18 Thread Barry Scott


> On 15 Jan 2020, at 17:05, Miro Hrončok  wrote:
> 
> In Python Maint, we sat down and we came up with several ideas how to 
> minimize the filesystem footprint of Python. Unfortunately, the result is 
> horribly long, sorry about that.

Did you calculate file sizes including rounding up by the
"filesystem block size" (statvfs f_bsize)?

What was the f_bsize of the file system you collected stats on?

The work to stop needing libpython is going to drop the number of files by 1
for the min install.

Can you link some of the .so's from stdlib into the main python image?

If all stdlib .so are linked into the main python and you have .zip for the
.py/.pyc files you can get python down to a handful of files.

Python app making software often exploits a trick that you can concatenate
the .zip on the end of the python image. I'm guessing that would break too many
of the constraints.

I'm not sure how you would do it but what if you created a SquashFS image
for python to lose the f_bsize overhead and use its compression?

Today python has 2 optimised file types. But the python devs have been talking
about ways to implement more optimisations and cache those results as well.
I'll failed to track down the discussion on python dev. I recall wanting to
reduce the file size by storing line number data for traceback outside of
the .pyc.

Barry

___
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: Update: AAA replacement login Initiative

2020-01-18 Thread Fabio Valentini
On Sat, Jan 18, 2020, 05:51 Andrew Lutomirski  wrote:

> On Fri, Jan 17, 2020 at 1:22 PM Kevin Fenzi  wrote:
>
>> On Fri, Jan 17, 2020 at 11:51:35AM -0800, Andrew Lutomirski wrote:
>> > > On Jan 16, 2020, at 3:48 AM, Sarah Finn  wrote:
>> > >
>> > > 
>> > > Hi all,
>> > >
>> > > I hope you are all well.
>> > >
>> > > I would like to invite you to contribute to our new initiative: AAA
>> replacement login.
>> > >
>> >
>> > I’ll offer a couple of suggestions:
>> >
>>
>> Can you please offer these to gnome developers?
>>
>> https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues
>>
>
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/100
>
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/101
>

Interesting. I think if you set up Kerberos login with
gnome-online-accounts, it is actually supposed to autorenew (if it works).

At least I haven't had to type my password to manually renew the Kerberos
ticket on my machine in years :)

Fabio


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