Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Adam Williamson]

On Fri, 2018-03-23 at 19:15 -0700, Kevin Fenzi wrote:
> On 03/23/2018 05:24 PM, Adam Williamson wrote:
> > On Fri, 2018-03-23 at 16:30 -0700, Adam Williamson wrote:
> > > poppler was updated from 0.62.0-2 to 0.63.0-1 in Rawhide on 2018-03-23.
> > > This update bumped the soname from libpoppler.so.73 to libpoppler.so.74.
> > > This soname bump was not announced, as it is supposed to be.
> > > 
> > > poppler has many dependencies. This is the list dtardon posted last
> > > time he correctly announced an soname bump:
> > 
> > Update - the person who did the bump did rebuild several dependencies,
> > but importantly not texlive-base or gdal. We are running those now.
> 
> Sadly texlive-base doesn't build with the new poppler...
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1062033
> 
> gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c
> -I/builddir/build/BUILD/texlive-base-20170520/source/work/texk
> -I/builddir/build/BUILD/texlive-base-20170520/source/texk
> -I/usr/include/libpng16  -DPOPPLER_VERSION=\"0.63.0\"
> -I/usr/include/poppler  -I../../../texk/web2c/libmd5
> -I../../../texk/web2c/pdftexdir  -Wall -Wunused -Wimplicit -Wreturn-type
> -Wmissing-prototypes -Wmissing-declarations -Wparentheses -Wswitch
> -Wtrigraphs -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -O2
> -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -mcet
> -fcf-protection -fno-strict-aliasing -Werror=format-security -c -o
> pdftexdir/libpdftex_a-utils.o `test -f 'pdftexdir/utils.c' || echo
> '../../../texk/web2c/'`pdftexdir/utils.c
> ../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function 'void write_epdf()':
> ../../../texk/web2c/pdftexdir/pdftoepdf.cc:971:40: error: use of deleted
> function 'Dict::Dict(const Dict&)'
>  Dict dic1 = page->getGroup();
> ^
> In file included from /usr/include/poppler/Object.h:350,
>  from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:55:
> /usr/include/poppler/Dict.h:60:3: note: declared here
>Dict(const Dict &) = delete;
>^~~~
> /usr/include/poppler/Dict.h:54:3: note:   after user-defined conversion:
> 'Dict::Dict(Dict*)'
>Dict(Dict* dictA);
>^~~~
> ../../../texk/web2c/pdftexdir/pdftoepdf.cc:972:43: error: use of deleted
> function 'Dict::Dict(const Dict&)'
>  Dict dic2 = groupDict.getDict();
>^
> In file included from /usr/include/poppler/Object.h:350,
>  from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:55:
> /usr/include/poppler/Dict.h:60:3: note: declared here
>Dict(const Dict &) = delete;
>^~~~
> /usr/include/poppler/Dict.h:54:3: note:   after user-defined conversion:
> 'Dict::Dict(Dict*)'
>Dict(Dict* dictA);
>^~~~
> 
> If someone wants to fix that, that would be great. ;)

It's due to this change in upstream poppler:

https://cgit.freedesktop.org/poppler/poppler/commit/poppler/Dict.h?id=8794789a72f845b009656e6d7ae6a00b709e09bc

I think it suggests texlive is actually doing something wrong in how it
uses that Dict class provided by poppler, but I am not an expert on C++
classes and not super enthusiastic about trying to become one at 11pm
on a Friday. If no-one else gets to this by tomorrow afternoon I may
take the University of Stack Overflow C++ 201 class and have a go at
it. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to change release-monitoring bug-filing without pkgdb?

[Christopher]

On Sat, Mar 24, 2018 at 12:44 AM Kevin Fenzi  wrote:

> On 03/23/2018 08:27 PM, Christopher wrote:
> > I received the following message about a new version of a package, but
> I'm
> > unable to figure out how to change these settings, because I *AM*
> > interested in bugs being filed (or at least... interested in trying it
> out).
> >
> > It also references pkgdb, but pkgdb is no longer available.
>
> See the downthread post for link...
>
> >
> > Also, why is this confusingly called "the-new-hotness" instead of simply
> "
> > release-monitoring.org". The name makes no sense, and creates
> unnecessary
> > confusion.
>
> It's a different application. release-monitoring (anitya) is the part
> that polls for new releases and keeps track of whats current.
> the-new-hotness listens for messages from that and files bugs for new
> packages and does scratch builds. release-monitoring is distro agnostic,
> but the-new-hotness is specifically for Fedora packages, is tied to koji
> and bugzilla, etc.
>
> Docs could definitely be better.
>
>
Thanks. That clarifies things significantly. "Docs could definitely be
better" is a severe understatement :)

FWIW, I found the-new-hotness code at
https://github.com/fedora-infra/the-new-hotness
I was going to try to do a pull request to improve the email message to
make things a bit more clear, but that repo does not contain the message
template that generated that email... so *shrug*, I don't know where that
code is. It would be nice if one could more easily contribute to Fedora's
infrastructure, much of which still remains a mystery to me.


> kevin
> --
>
> > -- Forwarded message -
> > From: 
> > Date: Fri, Mar 23, 2018 at 11:13 PM
> > Subject: the-new-hotness saw an update for hadoop, but pkgdb says the
> > maintainers are not interested in bugs being filed
> > To: 
> >
> >
> > the-new-hotness saw an update for hadoop, but pkgdb says the maintainers
> > are not interested in bugs being filed
> > https://release-monitoring.org/project/5580/
> >
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to change release-monitoring bug-filing without pkgdb?

[Christopher]

On Sat, Mar 24, 2018 at 12:20 AM Scott Talbert  wrote:

> On Sat, 24 Mar 2018, Christopher wrote:
>
> > I received the following message about a new version of a package, but
> I'm
> > unable to figure out how to change these settings, because I *AM*
> interested
> > in bugs being filed (or at least... interested in trying it out).
> >
> > It also references pkgdb, but pkgdb is no longer available.
> >
> > Also, why is this confusingly called "the-new-hotness" instead of simply
> > "release-monitoring.org". The name makes no sense, and creates
> unnecessary
> > confusion.
>
>
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_change_the_upstream-monitoring.2Fanitya_flag_for_my_packages.3F



There should be some sort of "Other Developer Actions" link to that wiki
page on https://src.fedoraproject.org next to the other links (build
status, koschei, etc.).


>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 873  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 455  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 353  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 185  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 122  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-635348eab4   
php-simplesamlphp-saml2_1-1.10.6-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7150fa5dce   
php-simplesamlphp-saml2-2.3.8-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-673b3314a1   
exim-4.90.1-3.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f41541339   
monitorix-3.10.1-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae3a1eae7e   
glpi-0.90.5-2.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-add4fc19d8   
mosquitto-1.4.15-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1fbdf7f103   
chromium-65.0.3325.181-1.el7


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

libmodulemd-1.1.3-2.el7

Details about builds:



 libmodulemd-1.1.3-2.el7 (FEDORA-EPEL-2018-7b3d55a328)
 Module metadata manipulation library

Update Information:

Fix issue with C headers not compiling in C++ programs  - https://github.com
/fedora-modularity/libmodulemd/issues/30    - Fixes numerous memory-leak
issues    - Revert backwards-incompatible change to nsversion for GObject
Introspection - Make default stream and profiles optional - Fixes:
https://github.com/fedora-modularity/libmodulemd/issues/25 - Fixes:
https://github.com/fedora-modularity/libmodulemd/issues/26 - Fixes:
https://github.com/fedora-modularity/libmodulemd/issues/27    * Adds support
for handling modulemd-defaults YAML documents * Adds peek()/dup() routines to
all object properties * Adds Modulemd.Module.dup_nsvc() to retrieve the
canonical form of the unique module identifier. * Adds support for boolean types
in the XMD section

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: How to change release-monitoring bug-filing without pkgdb?

[Kevin Fenzi]

On 03/23/2018 08:27 PM, Christopher wrote:
> I received the following message about a new version of a package, but I'm
> unable to figure out how to change these settings, because I *AM*
> interested in bugs being filed (or at least... interested in trying it out).
> 
> It also references pkgdb, but pkgdb is no longer available.

See the downthread post for link...

> 
> Also, why is this confusingly called "the-new-hotness" instead of simply "
> release-monitoring.org". The name makes no sense, and creates unnecessary
> confusion.

It's a different application. release-monitoring (anitya) is the part
that polls for new releases and keeps track of whats current.
the-new-hotness listens for messages from that and files bugs for new
packages and does scratch builds. release-monitoring is distro agnostic,
but the-new-hotness is specifically for Fedora packages, is tied to koji
and bugzilla, etc.

Docs could definitely be better.

kevin
--

> -- Forwarded message -
> From: 
> Date: Fri, Mar 23, 2018 at 11:13 PM
> Subject: the-new-hotness saw an update for hadoop, but pkgdb says the
> maintainers are not interested in bugs being filed
> To: 
> 
> 
> the-new-hotness saw an update for hadoop, but pkgdb says the maintainers
> are not interested in bugs being filed
> https://release-monitoring.org/project/5580/
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to change release-monitoring bug-filing without pkgdb?

[Scott Talbert]

On Sat, 24 Mar 2018, Christopher wrote:


I received the following message about a new version of a package, but I'm
unable to figure out how to change these settings, because I *AM* interested
in bugs being filed (or at least... interested in trying it out).

It also references pkgdb, but pkgdb is no longer available.

Also, why is this confusingly called "the-new-hotness" instead of simply
"release-monitoring.org". The name makes no sense, and creates unnecessary
confusion.


https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_change_the_upstream-monitoring.2Fanitya_flag_for_my_packages.3F
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-3.fc26 has been pushed to the Fedora 26 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-2018-0d1617f491

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

How to change release-monitoring bug-filing without pkgdb?

[Christopher]

I received the following message about a new version of a package, but I'm
unable to figure out how to change these settings, because I *AM*
interested in bugs being filed (or at least... interested in trying it out).

It also references pkgdb, but pkgdb is no longer available.

Also, why is this confusingly called "the-new-hotness" instead of simply "
release-monitoring.org". The name makes no sense, and creates unnecessary
confusion.

-- Forwarded message -
From: 
Date: Fri, Mar 23, 2018 at 11:13 PM
Subject: the-new-hotness saw an update for hadoop, but pkgdb says the
maintainers are not interested in bugs being filed
To: 


the-new-hotness saw an update for hadoop, but pkgdb says the maintainers
are not interested in bugs being filed
https://release-monitoring.org/project/5580/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Kevin Fenzi]

On 03/23/2018 07:36 PM, Tomasz Kłoczko wrote:
> On 24 March 2018 at 00:24, Adam Williamson  wrote:
> [..]
>>
>> Update - the person who did the bump did rebuild several dependencies,
>> but importantly not texlive-base or gdal. We are running those now.
> 
> BTW In situations like this is possible to observe how really bad idea
> was building ALL Fedora +5.6k texlive* packages from single sec file.

Except that is no longer the case. texlive-base only has ~120 or so
subpackages for each arch and also most of the packages that are deps
for other things. The larger 'texlive' package is now a noarch package
that doesn't need to be rebuilt very often.

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

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Tomasz Kłoczko]

On 24 March 2018 at 00:24, Adam Williamson  wrote:
[..]
>
> Update - the person who did the bump did rebuild several dependencies,
> but importantly not texlive-base or gdal. We are running those now.

BTW In situations like this is possible to observe how really bad idea
was building ALL Fedora +5.6k texlive* packages from single sec file.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-3.fc27 has been pushed to the Fedora 27 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-2018-051664aa73

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

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Kevin Fenzi]

On 03/23/2018 05:24 PM, Adam Williamson wrote:
> On Fri, 2018-03-23 at 16:30 -0700, Adam Williamson wrote:
>> poppler was updated from 0.62.0-2 to 0.63.0-1 in Rawhide on 2018-03-23.
>> This update bumped the soname from libpoppler.so.73 to libpoppler.so.74.
>> This soname bump was not announced, as it is supposed to be.
>>
>> poppler has many dependencies. This is the list dtardon posted last
>> time he correctly announced an soname bump:
> 
> Update - the person who did the bump did rebuild several dependencies,
> but importantly not texlive-base or gdal. We are running those now.

Sadly texlive-base doesn't build with the new poppler...

https://koji.fedoraproject.org/koji/buildinfo?buildID=1062033

gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c
-I/builddir/build/BUILD/texlive-base-20170520/source/work/texk
-I/builddir/build/BUILD/texlive-base-20170520/source/texk
-I/usr/include/libpng16  -DPOPPLER_VERSION=\"0.63.0\"
-I/usr/include/poppler  -I../../../texk/web2c/libmd5
-I../../../texk/web2c/pdftexdir  -Wall -Wunused -Wimplicit -Wreturn-type
-Wmissing-prototypes -Wmissing-declarations -Wparentheses -Wswitch
-Wtrigraphs -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -O2
-g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -mcet
-fcf-protection -fno-strict-aliasing -Werror=format-security -c -o
pdftexdir/libpdftex_a-utils.o `test -f 'pdftexdir/utils.c' || echo
'../../../texk/web2c/'`pdftexdir/utils.c
../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function 'void write_epdf()':
../../../texk/web2c/pdftexdir/pdftoepdf.cc:971:40: error: use of deleted
function 'Dict::Dict(const Dict&)'
 Dict dic1 = page->getGroup();
^
In file included from /usr/include/poppler/Object.h:350,
 from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:55:
/usr/include/poppler/Dict.h:60:3: note: declared here
   Dict(const Dict &) = delete;
   ^~~~
/usr/include/poppler/Dict.h:54:3: note:   after user-defined conversion:
'Dict::Dict(Dict*)'
   Dict(Dict* dictA);
   ^~~~
../../../texk/web2c/pdftexdir/pdftoepdf.cc:972:43: error: use of deleted
function 'Dict::Dict(const Dict&)'
 Dict dic2 = groupDict.getDict();
   ^
In file included from /usr/include/poppler/Object.h:350,
 from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:55:
/usr/include/poppler/Dict.h:60:3: note: declared here
   Dict(const Dict &) = delete;
   ^~~~
/usr/include/poppler/Dict.h:54:3: note:   after user-defined conversion:
'Dict::Dict(Dict*)'
   Dict(Dict* dictA);
   ^~~~

If someone wants to fix that, that would be great. ;)

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

Re: Latest updates-testing for F27

[Bojan Smojver]

Wow! That's what I call a fast turnaround. Before even reading the replies, the 
bug was fixed! :-)

--
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Latest updates-testing for F27

[Kevin Fenzi]

On 03/23/2018 04:56 PM, Kevin Fenzi wrote:
> On 03/23/2018 04:17 PM, Bojan Smojver wrote:
>> Does anyone know why latest dnf repodata for updates-testing in F27 appears 
>> to be missing some packages that were supposed to be pushed? For instance, 
>> kernel 4.15.12-301 is there, but latest dnsmasq is not and they were 
>> supposedly pushed at the same time.
>>
>> I noticed a similar pattern the day before, so just trying to understand 
>> whether there may be a bug in bodhi in relation to this.
> 
> There does seem to be a real issue here. (I am not sure if it's bodhi or
> something related). The build isn't in the correct tag, and I don't see
> any errors about it. :(
> 
> Can you file a bug at https://github.com/fedora-infra/bodhi/issues and
> we can sort it out? Or if not, let me know and I can file it...

ok. Patrick went and tracked this down. It was a bug in the version we
deployed on thursday. ;(

We have a hotfix applied and a PR filed and will be fixing up the tags
on those updates that didn't properly go out thursday/friday.

Thanks for bringing it up!

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

[Bug 1560133] New: perl-WWW-Mechanize-1.88 is available

[bugzilla]

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

Bug ID: 1560133
   Summary: perl-WWW-Mechanize-1.88 is available
   Product: Fedora
   Version: rawhide
 Component: perl-WWW-Mechanize
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jose.p.oliveira@gmail.com,
ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest upstream release: 1.88
Current version/release in rawhide: 1.87-1.fc28
URL: http://search.cpan.org/dist/WWW-Mechanize/

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

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

[Bug 1560128] New: perl-Text-SimpleTable-2.04 is available

[bugzilla]

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

Bug ID: 1560128
   Summary: perl-Text-SimpleTable-2.04 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Text-SimpleTable
  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



Latest upstream release: 2.04
Current version/release in rawhide: 2.03-22.fc28
URL: http://search.cpan.org/dist/Text-SimpleTable/

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

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

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Adam Williamson]

On Fri, 2018-03-23 at 16:30 -0700, Adam Williamson wrote:
> poppler was updated from 0.62.0-2 to 0.63.0-1 in Rawhide on 2018-03-23.
> This update bumped the soname from libpoppler.so.73 to libpoppler.so.74.
> This soname bump was not announced, as it is supposed to be.
> 
> poppler has many dependencies. This is the list dtardon posted last
> time he correctly announced an soname bump:

Update - the person who did the bump did rebuild several dependencies,
but importantly not texlive-base or gdal. We are running those now.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Latest updates-testing for F27

[Kevin Fenzi]

On 03/23/2018 04:17 PM, Bojan Smojver wrote:
> Does anyone know why latest dnf repodata for updates-testing in F27 appears 
> to be missing some packages that were supposed to be pushed? For instance, 
> kernel 4.15.12-301 is there, but latest dnsmasq is not and they were 
> supposedly pushed at the same time.
> 
> I noticed a similar pattern the day before, so just trying to understand 
> whether there may be a bug in bodhi in relation to this.

There does seem to be a real issue here. (I am not sure if it's bodhi or
something related). The build isn't in the correct tag, and I don't see
any errors about it. :(

Can you file a bug at https://github.com/fedora-infra/bodhi/issues and
we can sort it out? Or if not, let me know and I can file it...

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

Re: Failure on both OpenImageIO and opencv

[Luya Tshimbalanga]

On 2018-03-23 04:21 PM, Adam Williamson wrote:
> On Fri, 2018-03-23 at 16:12 -0700, Luya Tshimbalanga wrote:
>> Hello team,
>>
>> It looks like both OpenImageIO and opencv failed again as I was unable
>> to build LuxRender which depends on them.
> The problem isn't in either of those, it's this:
>
> DEBUG util.py:439:- package opencv-core-3.4.1-2.fc29.x86_64
> requires libgdal.so.20()(64bit), but none of the providers can be
> installed
> DEBUG util.py:439:- conflicting requests
> DEBUG util.py:439:- nothing provides libpoppler.so.73()(64bit) needed by 
> gdal-libs-2.2.3-13.fc29.x86_64
>
> Which is because there was another goddamned unannounced soname bump
> in poppler:
>
> poppler-0.63.0-1.fc29
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1061638
>
> provides libpoppler.so.74()(64bit) , where the previous build (0.62.0-
> 2) provided libpoppler.so.73()(64bit) .
>
> So, we'll need to rebuild everything that builds against libpoppler.

Thanks for the quick response.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Adam Williamson]

poppler was updated from 0.62.0-2 to 0.63.0-1 in Rawhide on 2018-03-23.
This update bumped the soname from libpoppler.so.73 to libpoppler.so.74.
This soname bump was not announced, as it is supposed to be.

poppler has many dependencies. This is the list dtardon posted last
time he correctly announced an soname bump:

boomaga
calligra
cups-filters
evas-generic-loaders
gambas3
gdal
gdcm
inkscape
kf5-kfilemetadata
libreoffice
okular
pdf2djvu
poppler-sharp
texlive
texworks

These and their dependencies are now all broken. This may well break
Rawhide composes until key dependencies are rebuilt.

Once again, folks, *please* announce your soname bumps, and co-ordinate 
rebuilds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Failure on both OpenImageIO and opencv

[Adam Williamson]

On Fri, 2018-03-23 at 16:12 -0700, Luya Tshimbalanga wrote:
> Hello team,
> 
> It looks like both OpenImageIO and opencv failed again as I was unable
> to build LuxRender which depends on them.

The problem isn't in either of those, it's this:

DEBUG util.py:439:- package opencv-core-3.4.1-2.fc29.x86_64
requires libgdal.so.20()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libpoppler.so.73()(64bit) needed by 
gdal-libs-2.2.3-13.fc29.x86_64

Which is because there was another goddamned unannounced soname bump
in poppler:

poppler-0.63.0-1.fc29
https://koji.fedoraproject.org/koji/buildinfo?buildID=1061638

provides libpoppler.so.74()(64bit) , where the previous build (0.62.0-
2) provided libpoppler.so.73()(64bit) .

So, we'll need to rebuild everything that builds against libpoppler.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Latest updates-testing for F27

[Bojan Smojver]

Does anyone know why latest dnf repodata for updates-testing in F27 appears to 
be missing some packages that were supposed to be pushed? For instance, kernel 
4.15.12-301 is there, but latest dnsmasq is not and they were supposedly pushed 
at the same time.

I noticed a similar pattern the day before, so just trying to understand 
whether there may be a bug in bodhi in relation to this.

--
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Failure on both OpenImageIO and opencv

[Luya Tshimbalanga]

Hello team,

It looks like both OpenImageIO and opencv failed again as I was unable
to build LuxRender which depends on them.
Could someone investigate the issue?

Thanks.

Ref:

https://koji.fedoraproject.org/koji/taskinfo?taskID=25908143

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20180323.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 14/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 210660  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/210660
ID: 210668  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/210668
ID: 210669  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210669
ID: 210670  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/210670
ID: 210675  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/210675
ID: 210683  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/210683
ID: 210687  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/210687
ID: 210688  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210688
ID: 210689  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/210689
ID: 210703  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/210703
ID: 210729  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/210729
ID: 210730  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/210730
ID: 210736  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/210736
ID: 210740  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/210740
ID: 210741  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/210741
ID: 210749  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/210749
ID: 210763  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/210763
ID: 210775  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/210775
ID: 210783  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/210783
ID: 210784  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/210784

Soft failed openQA tests: 8/137 (x86_64), 4/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 210632  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/210632
ID: 210646  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210646
ID: 210647  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/210647
ID: 210652  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/210652
ID: 210653  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210653
ID: 210663  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210663
ID: 210666  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210666
ID: 210667  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/210667
ID: 210712  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/210712
ID: 210739  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/210739
ID: 210767  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/210767
ID: 210782  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/210782

Passed openQA tests: 108/137 (x86_64), 14/23 (i386)

Skipped openQA tests: 7 of 162
-- 
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

license change in rust-tokio-{executor,reactor,threadpool}

[Josh Stone]

These three rust crates have changed from a combo "MIT or ASL 2.0"
license to just MIT.

  rust-tokio-executor-0.1.1-1.fc29
  rust-tokio-reactor-0.1.1-1.fc29
  rust-tokio-threadpool-0.1.1-1.fc29

The same change will be coming to rust-tokio-0.1.4 in this update:
https://bugzilla.redhat.com/show_bug.cgi?id=1560061
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Gerald Henriksen]

On Fri, 23 Mar 2018 12:57:19 -0400, you wrote:

>On 03/23/2018 07:23 AM, Petr Viktorin wrote:
>> In case no one steps up, we'd like to start dropping Python 2 support
>> from dependent packages *now*, starting with ported libraries on whose
>> python2 version nothing in Fedora depends. (We keep a list of those at
>> [1].)
>
>I'm +1 to the idea of dropping Python 2 support in general, but I'm not
>sure we should really do it gradually (which is what would effectively
>happen if some packagers start dropping now and others later, and others
>not at all). It seems to me like it'd be cleaner to have a release note
>on Fedora 30 that's just "Python 2 support dropped" and do it all at
>once. Thoughts?

It's not just all the Python 2 code that is packaged in Fedora though,
but also all the Python 2 code people are running on their machines.

By gradually (or sooner than Fedora 30) getting rid of all the
libraries and other Python 2 stuff it at least gives the option for
those people who get surprised to fix things before the Python
interpreter itself goes EOL and doesn't get security fixes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora rawhide compose report: 20180323.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180322.n.0
NEW: Fedora-Rawhide-20180323.n.0

= SUMMARY =
Added images:12
Dropped images:  2
Added packages:  13
Dropped packages:1
Upgraded packages:   127
Downgraded packages: 0

Size of added packages:  24.20 MiB
Size of dropped packages:3.13 MiB
Size of upgraded packages:   3.00 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20180323.n.0.ppc64le.tar.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20180323.n.0.ppc64le.tar.xz
Image: AtomicWorkstation dvd-ostree x86_64
Path: 
AtomicWorkstation/x86_64/iso/Fedora-AtomicWorkstation-ostree-x86_64-Rawhide-20180323.n.0.iso
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20180323.n.0.ppc64le.qcow2
Image: AtomicHost dvd-ostree ppc64le
Path: 
AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-Rawhide-20180323.n.0.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20180323.n.0.ppc64le.raw.xz
Image: Cloud_Base raw-xz ppc64
Path: Cloud/ppc64/images/Fedora-Cloud-Base-Rawhide-20180323.n.0.ppc64.raw.xz
Image: AtomicHost raw-xz ppc64le
Path: 
AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20180323.n.0.ppc64le.raw.xz
Image: AtomicHost qcow2 ppc64le
Path: 
AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20180323.n.0.ppc64le.qcow2
Image: Cloud_Base qcow2 ppc64
Path: Cloud/ppc64/images/Fedora-Cloud-Base-Rawhide-20180323.n.0.ppc64.qcow2
Image: AtomicHost dvd-ostree aarch64
Path: 
AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-Rawhide-20180323.n.0.iso
Image: AtomicHost dvd-ostree x86_64
Path: 
AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-Rawhide-20180323.n.0.iso

= DROPPED IMAGES =
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20180322.n.0.aarch64.raw.xz
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20180322.n.0.armhfp.tar.xz

= ADDED PACKAGES =
Package: R-R.oo-1.21.0-2.fc29
Summary: R Object-Oriented Programming with or without References
RPMs:R-R.oo
Size:819.70 KiB

Package: R-bindrcpp-0.2-1.fc29
Summary: An 'Rcpp' Interface to Active Bindings
RPMs:R-bindrcpp R-bindrcpp-devel
Size:625.58 KiB

Package: R-callr-2.0.2-2.fc29
Summary: Call R from R
RPMs:R-callr
Size:1.99 MiB

Package: R-clipr-0.4.0-1.fc29
Summary: Read and Write from the System Clipboard
RPMs:R-clipr
Size:35.87 KiB

Package: R-openssl-1.0.1-1.fc29
Summary: Toolkit for Encryption, Signatures and Certificates Based on OpenSSL
RPMs:R-openssl
Size:3.76 MiB

Package: R-poLCA-1.4.1-1.fc29
Summary: Polytomous variable Latent Class Analysis
RPMs:R-poLCA
Size:2.87 MiB

Package: R-rgdal-1.2.18-1.fc29
Summary: Bindings for the 'Geospatial' Data Abstraction Library
RPMs:R-rgdal
Size:11.91 MiB

Package: R-rprintf-0.2.1-2.fc29
Summary: Adaptive Builder for Formatted Strings
RPMs:R-rprintf
Size:27.40 KiB

Package: R-statnet.common-4.0.0-1.fc29
Summary: Common R Scripts and Utilities Used by the Statnet Project Software
RPMs:R-statnet.common
Size:799.73 KiB

Package: R-tkrplot-0.0.23-1.fc29
Summary: TK Rplot
RPMs:R-tkrplot
Size:196.48 KiB

Package: libyami-utils-1.3.0-2.20180207git9b5a311.fc29
Summary: Libyami Utilities
RPMs:libyami-utils
Size:1.05 MiB

Package: php-nikic-php-parser4-4.0.0-1.fc29
Summary: A PHP parser written in PHP
RPMs:php-nikic-php-parser4
Size:139.35 KiB

Package: python-ratelimitingfilter-0.6-1.fc29
Summary: A rate limiting filter for the Python logging system
RPMs:python2-ratelimitingfilter python3-ratelimitingfilter
Size:31.91 KiB


= DROPPED PACKAGES =
Package: compat-tracker1-1.12.4-2.fc28
Summary: Compatibility package with the tracker client-side libraries
RPMs:compat-tracker1
Size:3.13 MiB


= UPGRADED PACKAGES =
Package:  PackageKit-1.1.9-3.fc29
Old package:  PackageKit-1.1.9-2.fc29
Summary:  Package management service
RPMs: PackageKit PackageKit-command-not-found PackageKit-cron 
PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin 
PackageKit-gtk3-module
Size: 8.45 MiB
Size change:  3.22 KiB
Changelog:
  * Thu Mar 22 2018 Kalev Lember <klem...@redhat.com> - 1.1.9-3
  - Create /var/cache/app-info/{icons,xmls} directories


Package:  SDL-1.2.15-31.fc29
Old package:  SDL-1.2.15-30.fc28
Summary:  A cross-platform multimedia library
RPMs: SDL SDL-devel SDL-static
Size: 5.67 MiB
Size change:  -3.75 KiB
Changelog:
  * Thu Mar 22 2018 Petr Pisar <ppi...@redhat.com> - 1.2.15-31
  - Remove post scriptlets with ldconfig


Package:  SLOF-0.1.git20171214-1.fc29

notificati...@fedoraproject.org

[Sérgio Basto]

Hi, 

I have a suggestion. After some confusions that I have made related
with notifications with a big delay . 

Please add the date of notification on the notification .

Thanks, 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28-20180323.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 11/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 210432  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/210432
ID: 210468  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/210468
ID: 210469  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210469
ID: 210470  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/210470
ID: 210478  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/210478
ID: 210481  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/210481
ID: 210483  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/210483
ID: 210487  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/210487
ID: 210488  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210488
ID: 210489  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/210489
ID: 210502  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/210502
ID: 210536  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/210536
ID: 210537  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/210537
ID: 210549  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/210549
ID: 210575  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/210575
ID: 210583  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/210583
ID: 210584  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/210584

Soft failed openQA tests: 9/137 (x86_64), 2/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 210446  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210446
ID: 210447  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/210447
ID: 210452  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/210452
ID: 210463  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/210463
ID: 210466  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210466
ID: 210471  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/210471
ID: 210512  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/210512
ID: 210538  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/210538
ID: 210540  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/210540
ID: 210560  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/210560
ID: 210563  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/210563

Passed openQA tests: 111/137 (x86_64), 16/23 (i386)

Skipped openQA tests: 7 of 162
-- 
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

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/23/18 17:57, Randy Barlow wrote:

On 03/23/2018 07:23 AM, Petr Viktorin wrote:

In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at
[1].)


I'm +1 to the idea of dropping Python 2 support in general, but I'm not
sure we should really do it gradually (which is what would effectively
happen if some packagers start dropping now and others later, and others
not at all). It seems to me like it'd be cleaner to have a release note
on Fedora 30 that's just "Python 2 support dropped" and do it all at
once. Thoughts?


I'm afraid we won't be able to handle the massive breakage in random 
build scripts, infrastructure, and (especially) areas we don't yet know 
will break. The likely outcome of such a flag day would be that the 
change would need to be reverted immediately. (You're welcome to try 
this locally. The problems start with the buildroot broken in ways I 
didn't know could exist, and continue from there.)
Even if the base distro would end up usable, we wouldn't be able to help 
all the non-"essential" packages if all problems appear at once.


Instead we want to start with the things we *know* can be dropped, and 
work on getting more things into that state. That should bring a steady 
stream of problems, which can be tackled one by one.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 983  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 873  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 844  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 455  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 184  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
 103  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  26  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4bcfff2d5e   
tor-0.2.9.15-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0f3319c1ea   
php-simplesamlphp-saml2_1-1.10.6-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-57cbc61216   
php-simplesamlphp-saml2-2.3.8-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-910749f9c8   
exim-4.90.1-3.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-10ff026fa8   
monitorix-3.10.1-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f5cd94db4e   
tomcat-7.0.85-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a67ea8c563   
golang-1.9.4-1.el6


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

libstoragemgmt-1.6.1-1.el6
openblas-0.2.20-6.el6
purple-facebook-0.9.5-4.9ff9acf9fa14.el6
python-recaptcha-client-2.0.1-1.el6

Details about builds:



 libstoragemgmt-1.6.1-1.el6 (FEDORA-EPEL-2018-e2ea111824)
 Storage array management library

Update Information:

Upgrade to latest upstream version 1.6.1.




 openblas-0.2.20-6.el6 (FEDORA-EPEL-2018-c53bb31492)
 An optimized BLAS library based on GotoBLAS2

Update Information:

Disables CPU affinity that had been enabled upstream by mistake.

References:

  [ 1 ] Bug #1558091 - Different processor affinity for Fedora and 
julialang.org builds
https://bugzilla.redhat.com/show_bug.cgi?id=1558091




 purple-facebook-0.9.5-4.9ff9acf9fa14.el6 (FEDORA-EPEL-2018-0dc8b45283)
 Facebook protocol plugin for purple2

Update Information:

This fixes a [crash in Pidgin after Facebook login](https://github.com/dequis
/purple-facebook/issues/403) and ["Failed to read fixed header" due to TLS
1.3](https://github.com/dequis/purple-facebook/issues/410).  Read [this notice
about Pidgin <= 2.12.0](https://github.com/dequis/purple-facebook/issues/408)
and connecting to Facebook using TLS 1.3.




 python-recaptcha-client-2.0.1-1.el6 (FEDORA-EPEL-2018-0fe2b8a3e8)
 Python module for reCAPTCHA and reCAPTCHA Mailhide

Update Information:

New upstream release

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Request for testing: dbus-broker as system and user bus

[Kevin Fenzi]

On 03/23/2018 04:24 AM, Tom Gundersen wrote:
> Hi Kevin,
> 
> Thanks for testing!
> 
> We attempted to keep the logging to a minimum, in particular we try to only
> log in case of a potential problem.
> 
> The main log message is terse, but we include a lot of metadata (and we are
> open to adding more). Query the journal with `-o verbose` to see more
> information.

Ah ha. Yep. That gives the sort of info I was looking for.

Might mention that in the man pages or README or change page.

Thanks!

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

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

[bugzilla]

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

Sergio Monteiro Basto  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Mail-Box-3.004-1.fc27
 Resolution|--- |ERRATA
Last Closed|2018-01-11 10:07:49 |2018-03-23 14:03:22



--- Comment #8 from Sergio Monteiro Basto  ---
This update has been pushed to stable. 2 months ago

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

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-3.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c4fb1d3e12

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

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-3.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-051664aa73

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

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-File-Copy-Recursive-0.40-3.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0d1617f491

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1110  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 873  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 455  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 352  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 184  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 121  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  26  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-635348eab4   
php-simplesamlphp-saml2_1-1.10.6-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7150fa5dce   
php-simplesamlphp-saml2-2.3.8-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-673b3314a1   
exim-4.90.1-3.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f41541339   
monitorix-3.10.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae3a1eae7e   
glpi-0.90.5-2.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-add4fc19d8   
mosquitto-1.4.15-1.el7


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

chromium-65.0.3325.181-1.el7
fleet-commander-admin-0.10.6-3.el7
openblas-0.2.20-6.el7
purple-facebook-0.9.5-4.9ff9acf9fa14.el7
python-recaptcha-client-2.0.1-1.el7
python-testing.postgresql-1.1.0-3.el7
python34-3.4.8-1.el7

Details about builds:



 chromium-65.0.3325.181-1.el7 (FEDORA-EPEL-2018-1fbdf7f103)
 A WebKit (Blink) powered web browser

Update Information:

Update to Chromium 65. For EPEL7, it has been a long time since a successful
build has been possible, so this will fix a LOT of CVEs.  CVE-2017-15396
CVE-2017-15407 CVE-2017-15408 CVE-2017-15409 CVE-2017-15410 CVE-2017-15411
CVE-2017-15412 CVE-2017-15413 CVE-2017-15415 CVE-2017-15416 CVE-2017-15417
CVE-2017-15418 CVE-2017-15419 CVE-2017-15420 CVE-2017-15422  CVE-2018-6056
CVE-2018-6406 CVE-2018-6057 CVE-2018-6058 CVE-2018-6059 CVE-2018-6060
CVE-2018-6061 CVE-2018-6062 CVE-2018-6063 CVE-2018-6064 CVE-2018-6065
CVE-2018-6066 CVE-2018-6067 CVE-2018-6068 CVE-2018-6069 CVE-2018-6070
CVE-2018-6071

References:

  [ 1 ] Bug #1552500 - CVE-2018-6083 chromium-browser: incorrect processing of 
appmanifests
https://bugzilla.redhat.com/show_bug.cgi?id=1552500
  [ 2 ] Bug #1552499 - CVE-2018-6082 chromium-browser: circumvention of port 
blocking
https://bugzilla.redhat.com/show_bug.cgi?id=1552499
  [ 3 ] Bug #1552498 - CVE-2018-6081 chromium-browser: xss in interstitials
https://bugzilla.redhat.com/show_bug.cgi?id=1552498
  [ 4 ] Bug #1552497 - CVE-2018-6080 chromium-browser: information disclosure 
in ipc call
https://bugzilla.redhat.com/show_bug.cgi?id=1552497
  [ 5 ] Bug #1552496 - CVE-2018-6079 chromium-browser: information disclosure 
via texture data in webgl
https://bugzilla.redhat.com/show_bug.cgi?id=1552496
  [ 6 ] Bug #1552495 - CVE-2018-6078 chromium-browser: url spoof in omnibox
https://bugzilla.redhat.com/show_bug.cgi?id=1552495
  [ 7 ] Bug #1552494 - CVE-2018-6077 chromium-browser: timing attack using svg 
filters
https://bugzilla.redhat.com/show_bug.cgi?id=1552494
  [ 8 ] Bug #1552493 - CVE-2018-6076 chromium-browser: incorrect handling of 
url fragment identifiers in blink
https://bugzilla.redhat.com/show_bug.cgi?id=1552493
  [ 9 ] Bug #1552492 - CVE-2018-6075 chromium-browser: overly permissive cross 
origin downloads
https://bugzilla.redhat.com/show_bug.cgi?id=1552492
  [ 10 ] Bug #1552491 - CVE-2018-6074 chromium-browser: mark-of-the-web bypass
https://bugzilla.redhat.com/show_bug.cgi?id=1552491
  [ 11 ] Bug #1552490 - CVE-2018-6073 chromium-browser: heap bufffer overflow 
in webgl
https://bugzilla.redhat.com/show_bug.cgi?id=1552490
  [ 12 ] Bug #1552489 - CVE-2018-6072 chromium-browser: integer overflow in 
pdfium
https://bugzilla.redhat.com/show_bug.cgi?id=1552489
  [ 13 ] Bug #1552488 - CVE-2018-6071 chromium-browser: heap bufffer overflow 
in skia
https://bugzilla.redhat.com/show_bug.cgi?id=1552488
  [ 14 ] Bug #1552487 - CVE-2018-6070 chromium-browser: csp bypass through 
extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1552487
  [ 15 ] Bug #1552486 - CVE-2018-6069 chromium-browser: stack buffer overflow 
in skia
https://bugzilla.redhat.com/show_bug.cgi?id=1552486
  [ 16 ] Bug #1552485 - CVE-2018-6068 

Fedora 28 compose report: 20180323.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180322.n.0
NEW: Fedora-28-20180323.n.0

= SUMMARY =
Added images:8
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-28-20180323.n.0.ppc64le.tar.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-28-20180323.n.0.ppc64le.tar.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-28-20180323.n.0.ppc64le.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-28-20180323.n.0.ppc64le.raw.xz
Image: Cloud_Base raw-xz ppc64
Path: Cloud/ppc64/images/Fedora-Cloud-Base-28-20180323.n.0.ppc64.raw.xz
Image: AtomicHost raw-xz ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180323.n.0.ppc64le.raw.xz
Image: AtomicHost qcow2 ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180323.n.0.ppc64le.qcow2
Image: Cloud_Base qcow2 ppc64
Path: Cloud/ppc64/images/Fedora-Cloud-Base-28-20180323.n.0.ppc64.qcow2

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Randy Barlow]

On 03/23/2018 07:23 AM, Petr Viktorin wrote:
> In case no one steps up, we'd like to start dropping Python 2 support
> from dependent packages *now*, starting with ported libraries on whose
> python2 version nothing in Fedora depends. (We keep a list of those at
> [1].)

I'm +1 to the idea of dropping Python 2 support in general, but I'm not
sure we should really do it gradually (which is what would effectively
happen if some packagers start dropping now and others later, and others
not at all). It seems to me like it'd be cleaner to have a release note
on Fedora 30 that's just "Python 2 support dropped" and do it all at
once. Thoughts?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Adam Williamson]

On Fri, 2018-03-23 at 10:55 -0500, Ian Pilcher wrote:
> On 03/22/2018 07:40 AM, Daniel Mach wrote:
> > We are pleased to announce that development of DNF 3 has started. This 
> > version is focused on performance improvements, new API and 
> > consolidating the whole software management stack.
> > 
> > Please read more details on our blog:
> > https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
> 
> Can someone explain how DNF 2 can be considered "finished", when it
> still can't provide the dependency information that yum did?

Neither the mail nor the announcement makes any claim that DNF 2 is
considered "finished".
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 23.3.2018 15:16, Jerry James wrote:

And please don't start dropping python 2 subpackages that are actually
used by other packages in Fedora without talking to the maintainers
first.  I just got bitten by this change to python-nose-cov:

* Thu Mar 22 2018 John Dulaney  - 1.6-13 -
Drop python2 subpackage

And now koschei is sending me emails about how all of my packages that
use python-nose-cov have broken dependencies in Rawhide.  I'm not
ready to drop python2 support for those packages yet; they are
dependencies of still other packages.  We need to start this process
from the leaves and work back towards the roots, not the other way
around.


Exactly. You can check if your package is a leaf at [1].

[1] http://fedora.portingdb.xyz/#legacy-leaf


For each of these, I can of course simply run %check for the python3
subpackage, and skip the python2 subpackage, but then breakages to the
python2 subpackage might go unnoticed.


Please don't do hacks. Non-leaf packages should not be removed (at least 
not without prior talk to your dependent packages maintainers). If a 
maintainer removes a non-leaf package, please report to them that they 
break things (like you just did, 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

Re: Intent to orphan Python 2

[Randy Barlow]

On 03/23/2018 11:07 AM, Ralf Corsepius wrote:
> Face it, your plan is naive and has failed even before it begun.

This is not useful feedback, and is hostile. Please use only
constructive criticism in the future.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 28 Branched 20180323.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 28 Branched 20180323.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20180320.n.0: anaconda-28.22.2-4.fc28.src, 20180323.n.0: 
anaconda-28.22.2-5.fc28.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/28

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180323.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Ian Pilcher]

On 03/22/2018 07:40 AM, Daniel Mach wrote:
We are pleased to announce that development of DNF 3 has started. This 
version is focused on performance improvements, new API and 
consolidating the whole software management stack.


Please read more details on our blog:
https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/


Can someone explain how DNF 2 can be considered "finished", when it
still can't provide the dependency information that yum did?

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

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Ralf Corsepius]

On 03/23/2018 12:23 PM, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.

Bummer - I am speechless.

Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.

Correct.

Face it, your plan is naive and has failed even before it begun.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Jerry James]

On Fri, Mar 23, 2018 at 7:29 AM, Matěj Cepl  wrote:
> Just a note of warning: don’t to be too over-eager with dropping
> everything Python 2 related in EPEL-7. Its EOS is only sometime
> after 2024
> (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle)
> and the question whether the packages which can use both Python2
> and Python3 as its dependency (e.g., youtube-dl) should switch
> to Python3 or use the base RHEL-provided Python 2.7.

And please don't start dropping python 2 subpackages that are actually
used by other packages in Fedora without talking to the maintainers
first.  I just got bitten by this change to python-nose-cov:

* Thu Mar 22 2018 John Dulaney  - 1.6-13 -
Drop python2 subpackage

And now koschei is sending me emails about how all of my packages that
use python-nose-cov have broken dependencies in Rawhide.  I'm not
ready to drop python2 support for those packages yet; they are
dependencies of still other packages.  We need to start this process
from the leaves and work back towards the roots, not the other way
around.

For each of these, I can of course simply run %check for the python3
subpackage, and skip the python2 subpackage, but then breakages to the
python2 subpackage might go unnoticed.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matěj Cepl]

On 2018-03-23, 11:23 GMT, Petr Viktorin wrote:
> Python 2.7 will reach end of upstream support on 1st of 
> January, 2020, after almost 10 years (!) of volunteer 
> maintenance.

Just a note of warning: don’t to be too over-eager with dropping 
everything Python 2 related in EPEL-7. Its EOS is only sometime 
after 2024 
(https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle) 
and the question whether the packages which can use both Python2 
and Python3 as its dependency (e.g., youtube-dl) should switch 
to Python3 or use the base RHEL-provided Python 2.7.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
It is a rare mind indeed that can render the hitherto
non-existent blindingly obvious. The cry “I could have thought of
that” is a very popular and misleading one, for the fact is that
they didn’t, and a very significant and revealing fact it is too.
  -- Douglas Adams, Dirk Gently's Holistic Detective Agency
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 982  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 872  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 844  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 455  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 184  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
 103  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  26  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4bcfff2d5e   
tor-0.2.9.15-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0f3319c1ea   
php-simplesamlphp-saml2_1-1.10.6-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-57cbc61216   
php-simplesamlphp-saml2-2.3.8-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-910749f9c8   
exim-4.90.1-3.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-10ff026fa8   
monitorix-3.10.1-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f5cd94db4e   
tomcat-7.0.85-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a67ea8c563   
golang-1.9.4-1.el6


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

mimedefang-2.84-1.el6

Details about builds:



 mimedefang-2.84-1.el6 (FEDORA-EPEL-2018-9e3b6d37f8)
 E-Mail filtering framework using Sendmail's Milter interface

Update Information:

MIMEDefang 2.84 ===* mimedefang.pl: Correctly use "$mon" rather
than "$min" to generate quarantine file names.   * mimedefang-multiplexor: Make
"workerinfo nnn" show how long ago the last state change was for a given worker.

References:

  [ 1 ] Bug #1559208 - mimedefang-2.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1559208

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Request for testing: dbus-broker as system and user bus

[Tom Gundersen]

Hi Kevin,

Thanks for testing!

On Fri, Mar 23, 2018, 1:00 AM Kevin Fenzi  wrote:

> So everything seems to be working fine for me with it, but I did notice
> that the logs are... quite a bit more terse.
>
> Here's the 4 messages I have so far:
>
> Mar 22 16:46:20 taim.scrye.com systemd[1]: Starting D-Bus System Message
> Bus...
> Mar 22 16:46:20 taim.scrye.com systemd[1]: Started D-Bus System Message
> Bus.
> Mar 22 16:46:26 taim.scrye.com dbus-broker[1284]: :1.27 failed to send
> message, due to policy.
> Mar 22 16:46:26 taim.scrye.com dbus-broker[1284]: :1.27 failed to send
> message, due to policy.
>

[...]

I don't know if we need to log every success by default, but perhaps we
> could find a middle ground? at least the failed sends might have more
> information so we could see what was doing that?
>

We attempted to keep the logging to a minimum, in particular we try to only
log in case of a potential problem.

The main log message is terse, but we include a lot of metadata (and we are
open to adding more). Query the journal with `-o verbose` to see more
information.

Cheers,

Tom

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Intent to orphan Python 2

[Petr Viktorin]

tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.



Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded 
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2 
alive, we won't be the ones doing it – at least not at the current 
magnitude".

Here are the details.


The current maintainers of python2 would like to "orphan" the python2 
package in 2020 (~ Fedora 30):

- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is 
a security-critical package and will be abandoned upstream), or

- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent 
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support 
from dependent packages *now*, starting with ported libraries on whose 
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested 
packagers, as long as there's an understanding that we won't just 
support python2 forever.


If you are a maintainer of anything at [1] we ask you kindly to consider 
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora > 
29. (On the current schedule, Fedora 30 will be the first release still 
supported after 2020-01-01.)


If no one steps up to maintain python2 after 2020, we're prepared to 
package a "legacy" python27 package, similar to what we do for e.g. 
python33 [2], to:

- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if 
their upstreams don't manage to port to Python 3 in time




[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Pavel Hrdina

[Pavel Hrdina]

Hello everyone,

My name is Pavel Hrdina. I live in Brno and I work for Red Hat
for several years.

I mostly work on libvirt and virt-manager projects and I have some
experience with maintaining downstream packages.

My first package submission is D-Bus binding for libvirt.



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: josm orphaned

[Vít Ondruch]

Dne 22.3.2018 v 19:08 Ricardo Martinelli Oliveira napsal(a):
> I never packaged something for Fedora before, but can you give me a
> chance to see how is the effort to maintain the package before I adopt
> it?

This should be good place to start your journey:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

V.


>
> On Thu, Mar 22, 2018 at 3:51 AM, Till Maas  wrote:
>> Hi
>>
>> I orphaned josm (https://src.fedoraproject.org/rpms/josm), the java
>> openstreetmap editor on request by the original maintainer. Please adopt
>> it. It needs to be updated regularly to follow the current openstreetmap
>> guidelines, currently it is outdated (also in EPEL).
>>
>> Kind regards
>> Till
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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



--- Comment #3 from Petr Pisar  ---
The generator intentionally ignores non-top-level run-time-loaded modules,
indented "require Foo":

my $glob = sub {
my ( $do, $src_glob, @args ) = @_;

local $CPRFComp = 1;
require File::Glob;

my @rt;
for my $path ( File::Glob::bsd_glob($src_glob) ) {
my @call = [ $do->( $path, @args ) ] or return;
push @rt, \@call;
}

return @rt;
};

I believe the reason is many false positives like branches that never execute
on Fedora, e.g:

if ($^O eq 'MSWin32') {
  require Win32::Foo;
}

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

Re: josm orphaned, or why are we packaging

[Till Maas]

On Thu, Mar 22, 2018 at 01:49:27PM -0400, Przemek Klosowski wrote:

> 1. ELF binaries
> 2. binary run-time loadable libraries
> 3. script files for scripting language environments (java programs
>could be arguably placed here)
> 4. scripting language libraries
> 5. java applets running in the browser
> 6. javascript running in the browser
> 
> Clearly, we want to package 1. and 2., and we aren't going to start
> packaging 6; there's a big discussion as to what's the right approach for 3
> and 4 (npm, conda, cargo, etc).

Actually 6. is also packaged for web applications that we package. Not
sure if there are still stand-alone packages for jquery but the code is
at least bundled in other packages.

> One way of looking at it is that packaging provides an assurance that the
> software we're running is the software we think you're running, as opposed
> to downloading random binaries and scripts from the internet (curl |
> /bin/sh). In this way of thinking, software downloaded from secure
> (TLS/https) connections to trusted sites could  be considered as good as
> packaged---we're doing it to javascript so why not java and other things.

One big difference is that Javascript is sandboxed in the browser. Also
download code just via https is not as good as it being packaged. With
packages you can also rollback to older versions or decide when to
upgrade. Also signed packages make sure that everyone gets the same
thing because there is only one signed RPM for each NVR which also
allows for QA. See for example the NPM bug:

http://www.zdnet.com/article/show-stopping-bug-appears-in-npm-node-js-package-manager/

Also there have been instances where upstream downloads were compromised
in the past.

> The .jnlp file that provides JOSM is essentially an XML file which starts
> the java machinery running the OSM-provided java application--I can see how
> people could argue that it's no different from maps.google.com starting a
> javascript mapping application in your browser.

Google maps is not FLOSS and a stand-alone application has still
advantages over a web application. So using a java web start application
might be as good as using a javascript web app, but a stand-alone
application can still be better. For example, is it possible to add a
java web start application to the gnome favorites? I guess it is only
possible with manually writing a .desktop file.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora-Atomic 27-20180323.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Michal Novotny]

On Fri, Mar 23, 2018 at 7:24 AM, Michal Novotny  wrote:
> On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza  wrote:
>> On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny  wrote:
>>>
>>> The question here is why don't we actually implement the modularity
>>> the simple way.
>>>
>>> Let's suppose I would like to make nodejs-8 available in EPEL7.
>>>
>>> The most effortless way would be to create subdirectory called 8 at
>>> src.fedoraproject.org/rpms/nodejs
>>> with the updated spec file and sources for the bumped major version of
>>> the nodejs package.
>>
>>
>> What if your module contains packages coming from multiple SRPMs and they
>> depend on each other?
>
> Well, my module wouldn't be coming from multiple SRPMs because my
> module is just a normal package.
>
> The problem with modularity is that the name does not really fit what
> it does, which is kind of important because wrong names make
> implementation much harder as you cannot rely on your common
> sense.
>
> When I think of a module, rpm ultimately comes to mind. That's kind of
> a unit that makes up an operating system.
>
> I highly doubt modularity can change it unless it invents its own package
> format. So I think it would be good to call it differently even in the 
> tooling.
>
> So let's try to figure out a better name for modulemd.
>
> Basically, the final product of modulemd is a repo with some built rpm
> packages in it (if I saw the latest development correctly, we were squashing
> multiple of those repos into a single one but we wouldn't need to do that).
>
> For users, a repo represents something like a stream of content. So
> streammd would be already a better name.
>
> But even a better name would be coprmd because you can think about
> the current "modulemd" as a copr (community project) being formally
> described in a file. Product of a copr project is also a repo so it fits.
>
> Stream name here:
>
> https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L13
>
> is basically a project name.
>
>
> The content specified here:
>
> https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L305
>
> are basically definitions of SCM packages.

That link should have pointed here:
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L233

>
> And then there are some fields like:
>
> version: 20160927144203
>
> context: c0ffee43
>
> which doesn't really belong there imho but instead belong to the final
> built repository (= copr snapshot) as a part of repodata (if anywhere).
>
> So I think it would be good to keep talking about packages when
> we talk about modules.
>
> clime
>
>>
>> Jan Kaluza
>>
>>>
>>>
>>> For fedpkg to be able to upload and download sources for that
>>> subdirectory (submodule), the attached
>>> single-line patch is needed in python-rpkg. There are a few more
>>> changes needed to make srpm
>>> importing work but it should be basically almost done as well.
>>>
>>> Koji then just needs to learn how to build DistGit repositories
>>> containing submodules where
>>> submodule is any subdirectory containing a spec file. When Koji
>>> discovers all the submodules
>>> in a repository, it can start an srpm and a consequent rpm build for
>>> each of them.
>>>
>>> It is a very similar approach to what find_packages from python
>>> setuptools implements. It
>>> recognizes subpackages based on the presence of __init__.py file. The
>>> only difference here
>>> is that we will be recognizing subpackages (=submodules) by the
>>> presence of *.spec file.
>>>
>>> Everything else should be pretty much the same otherwise. Koji builds
>>> nodejs-6 and nodejs-8 rpms
>>> both with el7 disttag and both of these can go through the Bodhi
>>> update process separately.
>>>
>>> Of course, the question is if you can actually build and run nodejs-8
>>> in EL7 successfully but
>>> I think that will always be a problem no matter what the implementation
>>> is.
>>>
>>> clime
>>>
>>> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza  wrote:
>>> >
>>> >
>>> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>>> >  wrote:
>>> >>
>>> >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>>> >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>>> >> > > So you think having to send a request to a web service instead of
>>> >> > > just
>>> >> > > parsing a string locally with one line of code is a good trade-off
>>> >> > > for
>>> >> > > allowing dashes?
>>> >> >
>>> >> > This has been mentioned several times in this thread and I think
>>> >> > there's
>>> >> > a misunderstanding around this.
>>> >> >
>>> >> > So: When your tool/whatever works with modules it will have to have
>>> >> > module metadata available in some form.
>>> >>
>>> >> What if I don't want to work with modules at all, just with information
>>> >> about modules?
>>> >>
>>> >> What if I just want to write a tool that 

[Bug 1558427] Useless dependency on perl(Path::Iter) prevents from bootstrapping Perl packages

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #2 from Ralf Corsepius  ---
Thanks for the patch.

Any insights, why rpm's dep-generator doesn't catch perl(File::Glob)?

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Michal Novotny]

On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza  wrote:
> On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny  wrote:
>>
>> The question here is why don't we actually implement the modularity
>> the simple way.
>>
>> Let's suppose I would like to make nodejs-8 available in EPEL7.
>>
>> The most effortless way would be to create subdirectory called 8 at
>> src.fedoraproject.org/rpms/nodejs
>> with the updated spec file and sources for the bumped major version of
>> the nodejs package.
>
>
> What if your module contains packages coming from multiple SRPMs and they
> depend on each other?

Well, my module wouldn't be coming from multiple SRPMs because my
module is just a normal package.

The problem with modularity is that the name does not really fit what
it does, which is kind of important because wrong names make
implementation much harder as you cannot rely on your common
sense.

When I think of a module, rpm ultimately comes to mind. That's kind of
a unit that makes up an operating system.

I highly doubt modularity can change it unless it invents its own package
format. So I think it would be good to call it differently even in the tooling.

So let's try to figure out a better name for modulemd.

Basically, the final product of modulemd is a repo with some built rpm
packages in it (if I saw the latest development correctly, we were squashing
multiple of those repos into a single one but we wouldn't need to do that).

For users, a repo represents something like a stream of content. So
streammd would be already a better name.

But even a better name would be coprmd because you can think about
the current "modulemd" as a copr (community project) being formally
described in a file. Product of a copr project is also a repo so it fits.

Stream name here:

https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L13

is basically a project name.


The content specified here:

https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L305

are basically definitions of SCM packages.

And then there are some fields like:

version: 20160927144203

context: c0ffee43

which doesn't really belong there imho but instead belong to the final
built repository (= copr snapshot) as a part of repodata (if anywhere).

So I think it would be good to keep talking about packages when
we talk about modules.

clime

>
> Jan Kaluza
>
>>
>>
>> For fedpkg to be able to upload and download sources for that
>> subdirectory (submodule), the attached
>> single-line patch is needed in python-rpkg. There are a few more
>> changes needed to make srpm
>> importing work but it should be basically almost done as well.
>>
>> Koji then just needs to learn how to build DistGit repositories
>> containing submodules where
>> submodule is any subdirectory containing a spec file. When Koji
>> discovers all the submodules
>> in a repository, it can start an srpm and a consequent rpm build for
>> each of them.
>>
>> It is a very similar approach to what find_packages from python
>> setuptools implements. It
>> recognizes subpackages based on the presence of __init__.py file. The
>> only difference here
>> is that we will be recognizing subpackages (=submodules) by the
>> presence of *.spec file.
>>
>> Everything else should be pretty much the same otherwise. Koji builds
>> nodejs-6 and nodejs-8 rpms
>> both with el7 disttag and both of these can go through the Bodhi
>> update process separately.
>>
>> Of course, the question is if you can actually build and run nodejs-8
>> in EL7 successfully but
>> I think that will always be a problem no matter what the implementation
>> is.
>>
>> clime
>>
>> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza  wrote:
>> >
>> >
>> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>> >  wrote:
>> >>
>> >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>> >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>> >> > > So you think having to send a request to a web service instead of
>> >> > > just
>> >> > > parsing a string locally with one line of code is a good trade-off
>> >> > > for
>> >> > > allowing dashes?
>> >> >
>> >> > This has been mentioned several times in this thread and I think
>> >> > there's
>> >> > a misunderstanding around this.
>> >> >
>> >> > So: When your tool/whatever works with modules it will have to have
>> >> > module metadata available in some form.
>> >>
>> >> What if I don't want to work with modules at all, just with information
>> >> about modules?
>> >>
>> >> What if I just want to write a tool that parses fedmsgs about module
>> >> builds in Koji and does something that depends on module names, streams
>> >> and versions? (e.g. some sort of changelog thing)
>> >
>> >
>> > Your tool can use good old buildsys.build.state.change fedmsg with the
>> > well
>> > known name/version/release fields like this:
>> >
>> >
>> > 

Re: Announcing DNF 3 development

[Fabio Valentini]

On Thu, Mar 22, 2018, 23:13 Nico Kadel-Garcia  wrote:

> On Thu, Mar 22, 2018 at 5:49 PM, John Reiser  wrote:
> > On 03/22/2018 01:51 PM, Nico Kadel-Garcia wrote:
> >>
> >> On Thu, Mar 22, 2018 at 10:52 AM, John Reiser 
> >> wrote:
> >>>
> >>> On 03/22/2018 05:40 AM, Daniel Mach wrote:
> 
> 
>  We are pleased to announce that development of DNF 3 has started. This
>  version is focused on performance improvements, new API and
>  consolidating
>  the whole software management stack.
> >>>
> >>>
> >>>
> >>> How does RPM fit into DNF's view of "the whole software management
> >>> stack"?
> >>> RPM is a slug (moves very slowly): no parallelism (at any point all
> >>> packages
> >>> with no remaining predecessors could be updated/installed in parallel),
> >>> not even manually pipelined (decompress to memory, manipulate
> filesystem,
> >>> update database.)
> >>
> >>
> >> Parallelizing software updates or installations would be *begging* for
> >> pain. It would be difficult for me to recommend strongly enough
> >> against this.
> >
> >
> > Please be specific about the pain points that you fear.
>
> RPM, itself, is single threaded.
>
> %pre and %post operations would have to be re-evaluated for
> parallelization. system account creation, in particular, would have to
> be made thread safe.
>
> RPM installation can fail partly through deployment due to SELinux,
> disk space, or network based mount point failure: keeping it single
> threaded makes it much safer to unravel failed or partial RPM
> installation.
>
> Unweaving partial dependency deployment could be quite destructive
> with a parallelized approach.
>
> Daemons that need to be restarted and may have incompatible component
> updates, such httpd with its modules, are particularly vulnerable to
> fascinating failures from the daemon restarting with only some updated
> components. Avoiding that would seem to require even more dependency
> management for RPM installation, rather than each update itself
> triggering an update.
>
> > The three-stage "manual" pipeline achieves 2x to 3x faster throughput
> > with error states that are isomorphic to present RPM.  (Consider the
> > Turning machine model: if you don't write to the filesystem, then
> > there is no change of external state.)
>
> Turing machines don't have to deal with all the possible
>
> > The "parallelize everything that has no remaining predecessors" strategy
> > requires parallel transactions in the database (they cannot interfere
> > because that would be a predecessor constraint) and checking for
> > resource exhaustion (file space, inodes, etc.) as a global
> > predecessor constraint.  What else?
>
> Parallelizing the installations means losing the milestones at which
> one update has succeeded, and the second update has not. Unweaving
> that to find out which update triggered the failure sounds like pain,
> and makes testing the update process more difficult. It becomes
> difficult to manage or guess what the state of the system was at the
> time of the RPM update, since another RPM update may be in progress at
> the time.
>
> There is an infamous quote by Donald Knuth that "premature
> optimization is the root of all evil". There are systems that benefit
> the time benefits of parallelization, but for ordinary RPM
> installations and system updates, I think that the slow update time is
> because of other factors, such as disk IO and download time of
> repodata, RPM database updates, and download times for the packages.
>

Well ... if you want to take this argument to the extreme, an update
process where the update is downloaded and prepared in the background, and
then applied atomically, would be the most "efficient" (because it happens
instantaneous, with a reboot) and resilient against errors (at no point in
time there is a broken, half-updated system) - just like rpm-ostree does
things ...

*ducks*

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org