[Bug 1784195] perl-Net-DBus-1.2.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Net-DBus-1.2.0-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-17 07:56:43



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

[Bug 1784195] perl-Net-DBus-1.2.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value



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

[Bug 1782662] perl-PDL-2.020 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-PDL-2.20.0-1.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2019-12-17 07:07:41



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

Re: rawhide protobuf update with new soname

[Adrian Reber]

On Mon, Dec 16, 2019 at 09:26:16PM -0700, Orion Poplawski wrote:
> On 12/1/19 10:48 AM, Adrian Reber wrote:
> > I prepared a protobuf upgrade from 3.6 to 3.11 in rawhide. It comes with
> > a soname update and requires its dependencies to be rebuilt.
> > 
> > I tested it all in copr and most of the packages are rebuilding except
> > for the following packages:
> > 
> >   * dynafed - compile error:
> > In file included from 
> > /builddir/build/BUILD/dynafed-1.5.1/src/UgrMemcached.pb.h:23,
> >  from 
> > /builddir/build/BUILD/dynafed-1.5.1/src/LocationInfo.cc:21:
> > /usr/include/google/protobuf/io/coded_stream.h:842:16: error: macro
> > "Error" requires 2 arguments, but only 1 given
> >   842 |   uint8* Error() {
> >   |^
> > 
> >   * community-mysql:
> > there is a simple upstream patch to fix the compile error but the test
> > fails in copr with:
> > Failed to connect to systemd notification socket named 
> > /run/systemd/nspawn/notify. Error: 'Permission denied'
> > Does not sound like it is related to the protobuf update
> > 
> >   * mumble - compile error:
> > In file included from BanEditor.cpp:36:
> > Global.h:142:11: error: expected ',' or '...' before '(' token
> >   142 | #define g (*Global::g_global_struct)
> >   |   ^
> > Global.h:142:11: error: expected ',' or '...' before '(' token
> >   142 | #define g (*Global::g_global_struct)
> >   |   ^
> > Global.h:142:11: error: expected ',' or '...' before '(' token
> >   142 | #define g (*Global::g_global_struct)
> >   |
> > 
> >   * paraview - cmake failure:
> > CMake Error at CommandLineExecutables/CMakeLists.txt:77 (get_property):
> >   get_property could not find TARGET pthread.  Perhaps it has not yet 
> > been created.
> > 
> > 
> >   * fts: No matching package to install: 'activemq-cpp-devel'
> > 
> >   * kismet: error: Invalid version (double separator '-'): 2019-08-GIT: 
> > pkgconfig(kismet) = 2019-08-GIT
> > 
> > 
> > Most of the errors do not sound protobuf related.
> > 
> > I want to do the protobuf upgrade in rawhide on Monday, 2019-12-09, just
> > after the rawhide compose has finished to be able to rebuild all
> > dependencies before the next compose.
> > 
> > Please let me know if you want to rebuild your package yourself or if
> > you see other problems with the protobuf upgrade.
> > 
> > Adrian
> 
> This did not appear to have happened.  What's the current plan?

Thanks for the reminder. I would do the upgrade of protobuf and the
corresponding rebuilds tomorrow (2019-12-18) once the compose has
finished.

Adrian


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

Re: Working fedora-active-user script?

[Sérgio Basto]

On Fri, 2019-12-13 at 13:15 +0100, Jun Aruga wrote:
> On Fri, Dec 13, 2019 at 12:17 PM Frank R Dana Jr. 
> wrote:
> > Hmmm. If there's a plan is to get it working again relatively soon,
> > though, I should probably withdraw my PR[1] to remove mention of it
> > from the Non-Responsive Maintainer Policy. (I figured, doesn't make
> > sense to suggest a tool that can't actually be used...)
> > 
> > [1]: https://pagure.io/fesco/fesco-docs/pull-request/23
> 
> The fedora_cert missing dependency issue was fixed on the latest
> master branch [1], though the README is not updated yet.
> I believe that the script is actually used now.
> 
> [1] https://github.com/pypingou/fedora-active-user


Thanks I added this ticket [3] to fedora-packager package.

[3]
https://pagure.io/fedora-packager/issue/159
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rawhide protobuf update with new soname

[Orion Poplawski]

On 12/1/19 10:48 AM, Adrian Reber wrote:

I prepared a protobuf upgrade from 3.6 to 3.11 in rawhide. It comes with
a soname update and requires its dependencies to be rebuilt.

I tested it all in copr and most of the packages are rebuilding except
for the following packages:

  * dynafed - compile error:
In file included from 
/builddir/build/BUILD/dynafed-1.5.1/src/UgrMemcached.pb.h:23,
 from 
/builddir/build/BUILD/dynafed-1.5.1/src/LocationInfo.cc:21:
/usr/include/google/protobuf/io/coded_stream.h:842:16: error: macro
"Error" requires 2 arguments, but only 1 given
  842 |   uint8* Error() {
  |^

  * community-mysql:
there is a simple upstream patch to fix the compile error but the test
fails in copr with:
Failed to connect to systemd notification socket named 
/run/systemd/nspawn/notify. Error: 'Permission denied'

Does not sound like it is related to the protobuf update


  * mumble - compile error:
In file included from BanEditor.cpp:36:
Global.h:142:11: error: expected ',' or '...' before '(' token
  142 | #define g (*Global::g_global_struct)
  |   ^
Global.h:142:11: error: expected ',' or '...' before '(' token
  142 | #define g (*Global::g_global_struct)
  |   ^
Global.h:142:11: error: expected ',' or '...' before '(' token
  142 | #define g (*Global::g_global_struct)
  |

  * paraview - cmake failure:
CMake Error at CommandLineExecutables/CMakeLists.txt:77 (get_property):
  get_property could not find TARGET pthread.  Perhaps it has not yet been 
created.


  * fts: No matching package to install: 'activemq-cpp-devel'

  * kismet: error: Invalid version (double separator '-'): 2019-08-GIT: 
pkgconfig(kismet) = 2019-08-GIT


Most of the errors do not sound protobuf related.

I want to do the protobuf upgrade in rawhide on Monday, 2019-12-09, just
after the rawhide compose has finished to be able to rebuild all
dependencies before the next compose.

Please let me know if you want to rebuild your package yourself or if
you see other problems with the protobuf upgrade.

Adrian


This did not appear to have happened.  What's the current plan?


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

[Bug 1782941] RFE - please build perl-Config-Validator for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Config-Validator-1.3-13.el8 has been pushed to the Fedora EPEL 8 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-EPEL-2019-1f83aab037

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

[Bug 1782935] RFE - build perl-Authen-Credential for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Authen-Credential-1.1-13.el8 has been pushed to the Fedora EPEL 8 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-EPEL-2019-6a6dcfc9e7

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

[Bug 1782932] RFE - build perl-No-Worries for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-No-Worries-1.6-3.el8 has been pushed to the Fedora EPEL 8 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-EPEL-2019-42452503ee

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

[Bug 1678626] Review Request: sbuild - Tool for building Debian binary packages from Debian sources

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1678626
Bug 1678626 depends on bug 1764813, which changed state.

Bug 1764813 Summary: Review Request: apt - Command-line package manager for 
Debian packages
https://bugzilla.redhat.com/show_bug.cgi?id=1764813

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE



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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 6:30:14 PM MST Adam Williamson wrote:
> All you have to do is subscribe to the test-announce@ list and, when a
> mail like this one appears:
> 
> https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproj
> ect.org/thread/TU5YRBVDQIKUHLZCYVRUMFFPENHL3CPZ/
> 
> Go to the 'Installation' result page - so, for that mail, it would be
> this page:
> 
> https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191209.n.0_I
> nstallation
> 
> grab the relevant ISOs (there is a download table at the top of the
> page), test them according to
> https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install , and
> enter your result in the appropriate cell in the 'Default boot and
> install' table. You can do `dnf install relval` then `relval report-
> results` to use a little CLI interface which will edit the page for
> you, if you're not comfortable editing the wiki syntax directly (it's
> quite easy, though).
> 
> It is useful to have results for all the nominated nightly composes,
> but it's *critical* that we get results any time a candidate compose
> appears. Those mails look similar but have a topic like "Fedora 31
> Candidate RC-1.8 Available Now!".

Sounds good, I'll subscribe to that list when I get to work tomorrow. I'll set 
aside a T400 running the standard boot firmware to test optical media on. Past 
that, I'll pick out some system that supports UEFI to test UEFI optical boot 
on. While I may not be able to test *every* version, I'll make sure to test 
every RC, and every nominated nightly compose I can.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 6:30:14 PM MST Adam Williamson wrote:
> Yup. This was anticipated. What's the alternative? We never drop Python
> 2 support in order to keep software that is clearly becoming
> increasingly out of date in a distribution which has "First" as one of
> its core principles? This is just another angle on "it is almost never
> the case that, when Fedora stops caring about something, it's a thing
> that absolutely nobody and nothing wants". There has to be a cut-off.
> There's probably *someone* out there who still has a Python 1
> interpreter installed. And libc 5. On a 386SX. Should Fedora still work
> on it?

In my opinion, this should be supported, even if stuck at the last version 
packaged, until that version no longer works. If nobody wants to put in the 
work to make the package work at that point, THEN is the time to drop it, in 
my opinion.

-- 
John M. Harris, Jr.
Splentity

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

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

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

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

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



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

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Neal Gompa]

On Mon, Dec 16, 2019 at 9:37 PM Kevin Kofler  wrote:
>
> Adam Williamson wrote:
> > BTW, there is another point here which you may not appreciate: Fedora
> > and Debian aren't really in competition. Fedora does not see its job as
> > being to Conquer The World and have everyone run Fedora. Fedora is
> > targeted at particular purposes and particular audiences. If a given
> > feature isn't actually driving Fedora's mission forward in any way,
> > it's reasonable to consider not having it any more, or at least not
> > making it a core part of the distribution and subject to blocking
> > requirements and so on. There comes a point at which we don't need to
> > support Python 2 for the people and use cases at which Fedora is aimed.
> > Will there still be people who need Python 2 for *something* at this
> > point? Probably! But, just as you point out, if so, they can get it
> > somewhere else.
> >
> > Someone using Debian instead of Fedora because they need Python 2 isn't
> > necessarily a *problem* for Fedora. It's only a problem if it would've
> > served Fedora's goals and purposes for that person to be using Fedora.
> > If what they do isn't really a part of Fedora's goals...why should we
> > worry about them using Debian? Debian is a fine distribution. Nothing
> > wrong with it.
> >
> > To put it another way...Debian and Fedora have different purposes and
> > different goals. Us dropping Python 2 earlier than Debian do is *things
> > working the right way*. We (arguably) do more than Debian to drive the
> > adoption and stabilization of new technologies - new stuff tends to
> > show up in Fedora earlier than it shows up in Debian. Debian (arguably)
> > does more than we do to provide long-term support for older software
> > and support for alternate architectures. This is a *good* thing. It's
> > an ecosystem that helps everyone.
>
> Except that this argument does not match actual facts. Debian is actually
> pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3
> several years ago and has already started the process of dropping Qt 4. We
> still support these and even kdelibs 3 and 4 in Fedora (mostly because I am
> keeping these alive – it turns out that this is actually very little work:
> no new upstream releases to care about, just occasionally an FTBFS fix or a
> security fix to backport).
>
> The fact that even Debian is not trying to kick out Python 2 yet shows that
> it is way too early to even consider it. Fedora is the only distribution
> insane enough to do such a radical move with draconian enforcement, even
> over the heads of the maintainers of packages depending on Python 2. (We now
> need explicit permission to depend on a package, a completely unprecedented
> and ridiculous move.)
>

You've been saying this a lot lately, and this isn't actually backed
up by reality.

Debian *is* dropping Python 2 support. As of right now, they are
working on transitioning to making providing Python 2 packages as
a bug of serious severity. This means that packages in unstable providing
Python 2 modules will no longer automatically transition to testing
and need exceptions to do so. In addition, there's discussion underway
to make it rc-blocking as well, meaning that packages may not be able
to transition into testing *without* removing Python 2 support
*first*.

While not all of this is implemented just yet in Debian (everything
moves glacially slow there...), it *is* happening. Debian definitely
does not want to make another release with Python 2 in the
distribution. Ubuntu has already decided to filter out all Python 2
packages from Ubuntu 20.04 LTS, so it's not going to be there either.

And you know what? This was all made possible by Fedora's work over
the last several releases to port lots of software to Python 3,
aggressively migrate to Python 3 by default, and now finally dropping
Python 2 stuff over the last three releases.

We may keep the python27 interpreter package for a while, but I don't
expect us to keep much beyond that.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Carson Black

[Carson Black]

Greetings y'all.

My name is Carson Black & it's nice to meet y'all.
I'm from Frankfort, Kentucky (and no, I'm not interested in bourbon), and
I'm currently a student at one of the high schools here. I'd be lying if I said 
I had
any explicit goals with the Fedora project, as I just do what I feel like doing 
when 
I feel like doing it. ale li pona. :) However, I'm writing this email because I 
recently submitted a
package for review (https://bugzilla.redhat.com/show_bug.cgi?id=1784230). I've 
been doing stuff with
OSS for about over a year now, from doing packaging for openSUSE to abusing 
every last facility GTK+ provides
as maintainer of Breeze GTK for KDE. I have experience with a variety of 
programming languages, but I'm most
familiar with C/C++, Python, Go, & Vala. 

My GPG fingerprint is A133 906C E9F6 6BFD 2F27 7D67 05DF 0193 8FF8 0320.

Looking forward to participating here with y'all.

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

Re: Paul Grosu

[Orion Poplawski]

Paul -


See:

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

because the package has been retired for longer than 8 weeks it needs to 
go through a new review.  I would run fedora-review on the package and 
file a review request bug.


You will need to post the spec and src.rpm in a public location for the 
review.


HTH,

  Orion

On 12/15/19 10:08 PM, Paul Grosu wrote:

Hello Orion and Kevin,

We are almost ready to submit an updated DMTCP version.  Would you 
prefer we put the srpm/spec at a public location for a review request, 
or just use fedpkg?


Also after performing Koji and running rpmlint on the srpm and spec, is 
there anything else we would need to do to ensure everything is proper?


Best regards,
Paul

On Mon, Nov 25, 2019 at 2:14 AM Paul Grosu > wrote:


Hello Orion and Kevin,

Orion, many thanks for sponsoring us!  This helps will help us
tremendously.  I have tested a few server and the connection works
great.  Gene and I are very grateful!

Kevin, thank you greatly also for helping us with sponsorship for
the additional group.

Best regards,
Paul

On Sat, Nov 23, 2019 at 11:58 AM Orion Poplawski mailto:or...@nwra.com>> wrote:

Paul -

     I've sponsored you - welcome aboard.

- Orion

On 11/22/19 3:46 PM, Paul Grosu wrote:
 > Hello Kevin,
 >
 > That would help us out greatly and I filed the following
ticket at this
 > weblink with an additional request for x86_64 machine along
with aarch64:
 >
 > https://pagure.io/fedora-infrastructure/issue/8406
 >
 > In request we are dropping support for armv7, as our
application is
 > geared mainly for the HPC community.  Please let us know what
would be
 > the next steps for us to connect.  Once we have fully tested,
we would
 > be able to proceed with the review process in order to be
properly
 > sponsored.  Orion Poplawski at the following comment
 >
(https://github.com/dmtcp/dmtcp/issues/698#issuecomment-530401895)
 > offered to sponsor us once we perform the review, which
dependent on our
 > testing.
 >
 > Thank you,
 > Paul
 >
 > On Thu, Nov 21, 2019 at 5:42 PM Kevin Fenzi mailto:ke...@scrye.com>
 > >> wrote:
 >
 >     On Wed, Nov 20, 2019 at 10:31:19AM +0300, Vascom wrote:
 >      > pgrosu - is your FAS name?
 >      > Are you in packager group?
 >
 >     Right. Normally you would need to be in the packager
group to have
 >     access to these machines. However, if you are working on
some upstream
 >     open source application and need access we can do that.
Just file a
 >     ticket and let us know what you are looking for:
 >
 > https://pagure.io/fedora-infrastructure/issues
 >
 >     kevin
 >     --
 >      >
 >      > ср, 20 нояб. 2019 г. в 10:20, Paul Grosu
mailto:pgr...@gmail.com>
 >     >>:
 >      > >
 >      > > Hi Vascom,
 >      > >
 >      > > Thank you for the quick reply.  I already added the
SSH public
 >     key, but when I try to ssh with my private key and enter the
 >     username pgrosu at the (login:) it says "No supported
authentication
 >     methods available".  Does it mean I should wait a day for
it to go
 >     through, or should I contact the admin?
 >      > >
 >      > > Thanks,
 >      > > Paul
 >      > >
 >      > > On Wed, Nov 20, 2019 at 2:04 AM Vascom
mailto:vasc...@gmail.com>
 >     >> wrote:
 >      > >>
 >      > >> You need to add your public ssh key at FAS page
 >      > >> https://admin.fedoraproject.org/accounts
 >      > >> And login via ssh.
 >      > >>
 >      > >> Read all information on
 >      > >>
 >

https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
 >      > >>
 >      > >> ср, 20 нояб. 2019 г. в 09:54, Paul Grosu
mailto:pgr...@gmail.com>
 >     >>:
 >      > >> >
 >      > >> > Hello Fedora Development Community,
 >      > >> >
 >      > >> > I work at Northeastern University as a researcher
in the
 >     Gene Cooperman Lab, and will be supporting the DMTCP package
 >     

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kevin Kofler]

Adam Williamson wrote:
> BTW, there is another point here which you may not appreciate: Fedora
> and Debian aren't really in competition. Fedora does not see its job as
> being to Conquer The World and have everyone run Fedora. Fedora is
> targeted at particular purposes and particular audiences. If a given
> feature isn't actually driving Fedora's mission forward in any way,
> it's reasonable to consider not having it any more, or at least not
> making it a core part of the distribution and subject to blocking
> requirements and so on. There comes a point at which we don't need to
> support Python 2 for the people and use cases at which Fedora is aimed.
> Will there still be people who need Python 2 for *something* at this
> point? Probably! But, just as you point out, if so, they can get it
> somewhere else.
> 
> Someone using Debian instead of Fedora because they need Python 2 isn't
> necessarily a *problem* for Fedora. It's only a problem if it would've
> served Fedora's goals and purposes for that person to be using Fedora.
> If what they do isn't really a part of Fedora's goals...why should we
> worry about them using Debian? Debian is a fine distribution. Nothing
> wrong with it.
> 
> To put it another way...Debian and Fedora have different purposes and
> different goals. Us dropping Python 2 earlier than Debian do is *things
> working the right way*. We (arguably) do more than Debian to drive the
> adoption and stabilization of new technologies - new stuff tends to
> show up in Fedora earlier than it shows up in Debian. Debian (arguably)
> does more than we do to provide long-term support for older software
> and support for alternate architectures. This is a *good* thing. It's
> an ecosystem that helps everyone.

Except that this argument does not match actual facts. Debian is actually 
pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3 
several years ago and has already started the process of dropping Qt 4. We 
still support these and even kdelibs 3 and 4 in Fedora (mostly because I am 
keeping these alive – it turns out that this is actually very little work: 
no new upstream releases to care about, just occasionally an FTBFS fix or a 
security fix to backport).

The fact that even Debian is not trying to kick out Python 2 yet shows that 
it is way too early to even consider it. Fedora is the only distribution 
insane enough to do such a radical move with draconian enforcement, even 
over the heads of the maintainers of packages depending on Python 2. (We now 
need explicit permission to depend on a package, a completely unprecedented 
and ridiculous move.)

And this also means that if you need both Qt 3 and Python 2, you are out of 
luck, because Debian refuses to carry the former (for no good reason – it 
takes me absolutely negligible work to keep Qt 3 working, I last had to 
touch it in January) and Fedora refuses to carry the latter (also for no 
good reason).

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

[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1778465
Bug 1778465 depends on bug 1778382, which changed state.

Bug 1778382 Summary: [RFE] EPEL-8 branch for perl-HTTP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1778382

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA



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

[Bug 1756036] [RFE] perl-XML-TreePP build for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-XML-TreePP-0.43-14.el8
 Resolution|--- |ERRATA
Last Closed||2019-12-17 01:57:47



--- Comment #7 from Fedora Update System  ---
perl-XML-TreePP-0.43-14.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1756036] [RFE] perl-XML-TreePP build for epel8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1756036
Bug 1756036 depends on bug 1778382, which changed state.

Bug 1778382 Summary: [RFE] EPEL-8 branch for perl-HTTP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1778382

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA



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

[Bug 1778382] [RFE] EPEL-8 branch for perl-HTTP-Lite

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-HTTP-Lite-2.44-19.el8
 Resolution|--- |ERRATA
Last Closed||2019-12-17 01:57:45



--- Comment #5 from Fedora Update System  ---
perl-HTTP-Lite-2.44-19.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1765495] perl-Role-Tiny-2.001004 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Role-Tiny-2.001004-1.f |perl-Role-Tiny-2.001004-1.f
   |c32 |c32
   ||perl-Role-Tiny-2.001004-1.f
   ||c31
 Resolution|--- |ERRATA
Last Closed|2019-10-25 11:57:08 |2019-12-17 01:44:59



--- Comment #4 from Fedora Update System  ---
perl-Role-Tiny-2.001004-1.fc31 has been pushed to the Fedora 31 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
> 
> Right, my only contributions to Fedora on this account have been Mindshare 
> related, and various Copr builds. I'm not currently a packager, nor am I a 
> member of QA. However, that doesn't change much about my argument. It's still 
> valid, especially in response to the original reasoning given for this 
> Change. 
> If the real reason is simply "The people who currently do it don't want to do 
> it anymore", which is what you describe,
> 
> I've offered to take on responsibility for these tests in this thread, and 
> I'm 
> still open to that. This is still important to many users, and I'm more than 
> happy to volunteer my time to support those users.

If we can actually rely on you to show up and do these tests - within,
remember, sometimes a very short time frame - that'd be great. However,
we've gone through this loop before with some other criteria (we
propose dropping them, someone complains and promises to do the
testing, then doesn't actually do it in the end) enough times that we'd
be a bit cautious about this. Still, we have F32 Beta coming up quite
soon, we could potentially delay this feature and see how that goes -
see if anyone besides RH Fedora QE staff shows up to run the tests...

> > The first time dropping x86 support was proposed, people complained and
> > said they would look after it as an alternate arch, just as we have
> > active teams looking after ARM arches, ppc64le, s390x and so on. An x86
> > SIG was formed. (You didn't join it.) But it barely did anything. Folks
> > in QA and releng followed the process - when x86-specific issues
> > appeared, we flagged them up in an appropriate tracker and notified the
> > SIG about them. But...usually, nothing happened. People *didn't* help
> > fix the bugs. It all just fell on the same people again, most of the
> > time. These are the reasons x86 support was dropped. If you don't like
> > it, that's your right. But there *are* "real reasons".
> 
> I didn't join because I didn't know about it until the followup thread to 
> kill 
> x86 entirely, at which point I did look into the work that was required, and 
> just weeks later x86 was killed. There are real reasons, but it's not the 
> reasons that were actually proposed. Lack of manpower is one thing, but 
> that's 
> not one of the reasons that was cited during the thread.

It's an implied reason pretty much any time the proposal is 'stop doing
this one thing', because if we had infinite resources we'd never have
to stop doing anything. We could do *all the things*. The fact that we
have limited resources is such a basic constraint it's not always
explicitly *stated* in the Change, but it is always there.

> > Python 2 is an even simpler case: Python 2 *is no longer maintained
> > upstream*. The Python developers and the community members and
> > developers who are most passionate about Python's future desperately
> > want projects and users to move *off* Python 2 and *onto* Python 3.
> > Fedora is not a museum piece, it's a living, relatively forward-looking 
> > distribution. A key goal of Fedora is to *drive forward* innovation in
> > F/OSS. Fedora's most important job WRT the Python 3 transition is to
> > push the adoption of Python 3, not to prop up the existence of Python
> > 2. That's not the job Fedora is here to do.
> 
> This doesn't change the fact that many Python scripts *cannot run on Python 
> 3*. Debian is not a museum piece either, and yet they don't just kill the old 
> version. The two versions can, and do, work when both installed in parallel. 

We are, uh, aware of this. They have been installed in parallel on most
Fedora installs for like a decade now.

BTW, there is another point here which you may not appreciate: Fedora
and Debian aren't really in competition. Fedora does not see its job as
being to Conquer The World and have everyone run Fedora. Fedora is
targeted at particular purposes and particular audiences. If a given
feature isn't actually driving Fedora's mission forward in any way,
it's reasonable to consider not having it any more, or at least not
making it a core part of the distribution and subject to blocking
requirements and so on. There comes a point at which we don't need to
support Python 2 for the people and use cases at which Fedora is aimed.
Will there still be people who need Python 2 for *something* at this
point? Probably! But, just as you point out, if so, they can get it
somewhere else.

Someone using Debian instead of Fedora because they need Python 2 isn't
necessarily a *problem* for Fedora. It's only a problem if it would've
served Fedora's goals and purposes for that person to be using Fedora.
If what they do isn't really a part of Fedora's goals...why should we
worry about them using Debian? Debian is a fine distribution. Nothing
wrong with it.

To put it another way...Debian and Fedora have different purposes and
different goals. Us dropping Python 2 earlier than 

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 12:16:29 PM MST Kamil Paral wrote:
> On Mon, Dec 16, 2019 at 4:06 PM John M. Harris Jr 
> 
> wrote:
> > > An older installation medium can be used and the system upgraded. And
> > 
> > older
> > 
> > > installation medium can be used and pointed at latest installation
> > > repositories (this is not guaranteed to work, but works in majority of
> > 
> > cases).
> > 
> > This is just an excuse for exactly what I said would happen: A release
> > with
> > broken optical install media. This is easily avoidable.
> 
> John, you keep repeating the same arguments over and over. You don't need
> to reply to each and every mail and state your position. If you think that
> being overly vocal will change people's perception of the proposal - I
> don't think so. It might just change their perception of you. We've heard
> you. We understand your position. Please don't spam this thread so hard -
> make it easier for others to read it and participate in it as well. Thank
> you.
> 
> If you care so deeply about optical media working in Fedora, the best thing
> you can do is to regularly participate in testing. Fedora is driven by
> people who work on stuff in areas they're passionate about. This can be
> your area and we'll certainly welcome your contribution. Fedora 32 release
> cycle is coming up soon.

I'd be more than happy to volunteer my time to work on that.

As for "making the same argument several times", that is likely the case, in 
those instances I have recently started referring to the earlier email in the 
thread. That said, when a different context comes up, it makes sense to reply 
to the new context.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 10:41:57 AM MST Adam Williamson wrote:
> On Sun, 2019-12-15 at 22:59 -0700, John M. Harris Jr wrote:
> 
> > This is not the only change I am referring to. We've been in the
> > habit of dropping things that work, with no real reasons lately.
> > For example, look at dropped x86 support, and soon we will be
> > dropping Python 2. We have already had several Python 2 packages
> > dropped simply because they refused to move to Python 3. This is an
> > ongoing issue, where everything considered "old" is just abandoned,
> > and it is hurting the user base.
> 
> 
> So, as far as I can tell, you have done no work on anything to do with
> x86 support or Python 2: you have run seven package builds, ever, all
> of one package in 2016.
> 
> You also have never run a Fedora validation test (or edited anything on
> the wiki besides your own user space, the Council page to nominate
> yourself, and the 3D Printing SIG page to add yourself).
> 
> According to your badges you've certainly made some useful
> contributions to Fedora in other areas, which is great! COPR builds,
> package tagging, writing articles, running meetings and so on. But you
> haven't actually done any work in any of the areas you're complaining
> about here, as near as I can tell.
> 
> All of the changes you refer to were changes made for the benefit of
> the people doing that work (and *thus* for the good of the project as a
> whole, because the resources of the people who do the work are limited
> and must be allocated properly). You claim that they were done for "no
> real reason", which I think is a symptom of the fact you haven't done
> any of that work, which perhaps makes it harder to understand the
> actual reasons.

Right, my only contributions to Fedora on this account have been Mindshare 
related, and various Copr builds. I'm not currently a packager, nor am I a 
member of QA. However, that doesn't change much about my argument. It's still 
valid, especially in response to the original reasoning given for this Change. 
If the real reason is simply "The people who currently do it don't want to do 
it anymore", which is what you describe,

I've offered to take on responsibility for these tests in this thread, and I'm 
still open to that. This is still important to many users, and I'm more than 
happy to volunteer my time to support those users.

> Upstream authors are caring less and less about 32-bit support in their
> code. This meant Fedora on x86 was working less and less well over
> time, while at the same time sucking up considerable QA, releng and
> developer time. The way Fedora is currently set up, if a package fails
> to build on *any* arch, the entire build fails and is not pulled in. So
> if we needed to fix a problem but the package didn't build on x86, the
> problem wasn't fixed until someone figured out why not, or just blocked
> the package on x86, which over time would have rendered the arch dead
> by stealth. Because we do actually care about what we ship, if a
> compose went on but was entirely broken on x86 we in QA and releng and
> devel would try and figure out why (just as we do for ppc64le, for
> instance) and that was taking up our time too. Building for x86 also
> cost in terms of hardware resources, resources which could otherwise be
> used for building faster on x86_64.
> 
> The first time dropping x86 support was proposed, people complained and
> said they would look after it as an alternate arch, just as we have
> active teams looking after ARM arches, ppc64le, s390x and so on. An x86
> SIG was formed. (You didn't join it.) But it barely did anything. Folks
> in QA and releng followed the process - when x86-specific issues
> appeared, we flagged them up in an appropriate tracker and notified the
> SIG about them. But...usually, nothing happened. People *didn't* help
> fix the bugs. It all just fell on the same people again, most of the
> time. These are the reasons x86 support was dropped. If you don't like
> it, that's your right. But there *are* "real reasons".

I didn't join because I didn't know about it until the followup thread to kill 
x86 entirely, at which point I did look into the work that was required, and 
just weeks later x86 was killed. There are real reasons, but it's not the 
reasons that were actually proposed. Lack of manpower is one thing, but that's 
not one of the reasons that was cited during the thread.

> Python 2 is an even simpler case: Python 2 *is no longer maintained
> upstream*. The Python developers and the community members and
> developers who are most passionate about Python's future desperately
> want projects and users to move *off* Python 2 and *onto* Python 3.
> Fedora is not a museum piece, it's a living, relatively forward-looking 
> distribution. A key goal of Fedora is to *drive forward* innovation in
> F/OSS. Fedora's most important job WRT the Python 3 transition is to
> push the adoption of Python 3, not to prop up the existence of 

[EPEL-devel] Re: upower in RHEL-8/EPEL-8

[Mukundan Ragavan]

On 12/16/19 9:37 AM, Troy Dawson wrote:
> On Sat, Dec 14, 2019 at 10:31 AM Kevin Fenzi  wrote:
>>
>> On Fri, Dec 13, 2019 at 09:19:16PM -0500, Mukundan Ragavan wrote:
>>> It appears that upower is in RHEL-8 but only in x86_64 and powerpc 64
>>> architectures. Due to this, some of my builds fail. This one for example
>>> - https://koji.fedoraproject.org/koji/taskinfo?taskID=39545162
>>>
>>> Is using excludearch my only option? How can I get this built?
>>
>> I think there's work or at least attempts to ask for these deps on all
>> arches, but I think for now you just need to exclude them.
>>
> 
> Yep, this is a known issue
> https://pagure.io/epel/issue/66
> 
> Currently, exludearch is the best option.
> 
> Troy

Thanks Kevin and Troy for the responses.



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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 11:48:49 AM MST Kevin Kofler wrote:
> Adam Williamson wrote:
> 
> > This is not accurate. You're not accounting for the time it takes to
> > write the disc, and we also have to check that the media check works,
> > which takes quite a while on its own.
> 
> 
> Who cares whether the media check works? If it fails, but the distro still 
> installs, that is not a blocker. I remember how, in the early Fedora days,
> it was entirely normal that the media check would always fail and that we
> all learned to just skip it and stop wasting our time on it. (And if it is
> such a time sink, I would argue to just drop it and boot directly to the
> installer.)

Generally, I'd have to agree with this. I have still skipped it in every 
installation I've done, and I'm pretty sure it actually works now.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 12:52:49 PM MST Kamil Paral wrote:
> On Mon, Dec 16, 2019 at 6:14 PM John M. Harris Jr 
> 
> wrote:
> > On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
> > > This is not accurate. You're not accounting for the time it takes to
> > > write the disc, and we also have to check that the media check works,
> > > which takes quite a while on its own.
> > 
> > I was accounting for that time. Writing to a disk and checking it does not
> > take a long time, ~20 minutes at most. This is why I said "less than an
> > hour"
> > in total. Additionally, during that time, no user interaction is required,
> > once the process is started.
> 
> I guess I should provide some better data for those estimated time
> requirements. I haven't used a stopwatch during the last release cycle, but
> my estimate is that it takes 1-1.5 hours to check a single install medium.
> This includes burning the DVD, booting it in BIOS mode including the
> mandatory and default media check, performing the installation, and then
> repeating the boot and install in UEFI mode. Occasionally there are some
> optical reading-related issues, e.g. when a machine gets stuck because it
> constantly spins up and spins down the disc, having a problem trying to
> read some area. Sometimes the disc access gets unusably slow, just to work
> fine after a reboot. All the usual stuff that you come across when using
> CDs/DVDs. Some of that is definitely caused by our rewritable media being
> scratched, or DVD drives being old and the laser no longer being well
> calibrated. We'd have to buy new drives to improve that experience, but I
> don't really see much sense in that, when optical media is a niche
> technology nowadays (hence this proposal).

It is simply not the case that optical media is niche, especially not in 
enterprise installations, low end consumer, business class systems or new old 
stock systems. For example, at $WORK, we use optical media for all 

> We have 2 release-blocking media, so the total time is somewhere between
> 2-3 hours (likely closer to 2 hours, because netinst installation is way
> faster due to downloading packages from the net instead of copying them
> from the disc). That's not the main problem, though. The main problem is
> that during that time, one or two of our test machines in our office is
> fully occupied with spinning the discs, and we can't use it for anything
> else. That means all other bare-metal testing needs to wait. As Adam
> already pointed out, sometimes we need to check the final candidate
> composes in a single day, i.e. in the standard 8 working hours (and yes, we
> often work overtime in these cases). Blocking half of our bare-metal office
> test machines for 2 hours out of 8 is not a small deal.

Do you need more test hardware? Honestly, that's what this sounds like.

> It's simple to say "no user interaction is required", but that's not
> completely true either. If you want to do the QA job properly, you need to
> have an eye on the media consistency check, because we've had issues in the
> past where it timed out and either considered it a pass or fail (both are
> incorrect). So you can't simply walk away and come back and consider it OK
> when it reached the installer, you really need to watch the progress in
> certain critical points. Once the UI is ready, it is much slower than when
> booting from USB. So you often spend 10, 20 seconds staring at the screen
> until it decides to do something.

Is that due to the hardware under test, or is it a result of scratched media?

> The actual installation progress is unattended yet. But you need to check it
> frequently to see whether it finished, so that you don't waste time of the
> bare metal machine standing idle. There are many more tests waiting in the
> queue.

> The fact that this whole process is a major annoyance (it really makes you
> hate optical media, if you deal with this regularly) is of course
> contributing to the fact that we don't want to do it anymore. We're only
> humans. But we wouldn't have proposed the criterion change if we hadn't
> thought the time is right and that it is no longer an important factor for
> the majority of our users. We've waited very long with this proposal. And I
> still intend to keep testing optical media functionality from time to time,
> even when optical-blocking criterion is removed. But I'll do it once or
> twice per cycle, probably with a Beta GO compose, and not for every release
> candidate created.

I'd happily volunteer to help test this, but this is the standard method of 
installing in many environments, and is also the ONLY option in a good number 
of environments as we've described.

-- 
John M. Harris, Jr.
Splentity

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

[Bug 1784195] New: perl-Net-DBus-1.2.0 is available

[bugzilla]

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

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



Latest upstream release: 1.2.0
Current version/release in rawhide: 1.1.0-16.fc31
URL: http://search.cpan.org/dist/Net-DBus/

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

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

Fedora 32 System-Wide Change proposal: Ruby 2.7

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_2.7

== Summary ==
Ruby 2.7 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.6 in Fedora 31 to
Ruby 2.7 in Fedora 32, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondr...@redhat.com, pval...@redhat.com


== Detailed Description ==
Ruby 2.7 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== Compaction GC ===

This release introduces Compaction GC which can defragment a
fragmented memory space.

Some multi-threaded Ruby programs may cause memory fragmentation,
leading to high memory usage and degraded speed.

The `GC.compact` method is introduced for compacting the heap. This
function compacts live objects in the heap so that fewer pages may be
used, and the heap may be more CoW friendly.

=== Pattern Matching [Experimental] ===

Pattern matching, a widely used feature in functional programming
languages, is introduced as an experimental feature.

It can traverse a given object and assign its value if it matches a pattern.

=== REPL improvement ===

`irb`, the bundled interactive environment (REPL;
Read-Eval-Print-Loop), now supports multi-line editing. It is powered
by `reline`, a `readline`-compatible pure Ruby implementation. It also
provides rdoc integration. In `irb` you can display the reference for
a given class, module, or method.

Besides, source lines shown at `binding.irb` and inspect results for
core-class objects are now colorized.

=== Separation of positional and keyword arguments ===

Automatic conversion of keyword arguments and positional arguments is
deprecated, and conversion will be removed in Ruby 3.

* When a method call passes a Hash at the last argument, and when it
passes no keywords, and when the called method accepts keywords, a
warning is emitted. To continue treating the hash as keywords, add a
double splat operator to avoid the warning and ensure correct behavior
in Ruby 3.
* When a method call passes keywords to a method that accepts
keywords, but it does not pass enough required positional arguments,
the keywords are treated as a final required positional argument, and
a warning is emitted. Pass the argument as a hash instead of keywords
to avoid the warning and ensure correct behavior in Ruby 3.
* When a method accepts specific keywords but not a keyword splat, and
a hash or keywords splat is passed to the method that includes both
Symbol and non-Symbol keys, the hash will continue to be split, and a
warning will be emitted. You will need to update the calling code to
pass separate hashes to ensure correct behavior in Ruby 3.
* If a method does not accept keywords, and is called with keywords,
the keywords are still treated as a positional hash, with no warning.
This behavior will continue to work in Ruby 3.
* Non-symbols are allowed as keyword argument keys if the method
accepts arbitrary keywords.
* `**nil` is allowed in method definitions to explicitly mark that the
method accepts no keywords. Calling such a method with keywords will
result in an ArgumentError.
* Passing an empty keyword splat to a method that does not accept
keywords no longer passes an empty hash, unless the empty hash is
necessary for a required parameter, in which case a warning will be
emitted. Remove the double splat to continue passing a positional
hash.

=== Other Notable New Features ===

* Numbered parameter as the default block parameter is introduced as
an experimental feature.
* A beginless range is experimentally introduced. It might not be as
useful as an endless range, but would be good for DSL purposes.
* `Enumerable#tally` is added. It counts the occurrence of each element.
* Calling a private method on `self` is now allowed.
* `Enumerator::Lazy#eager` is added. It generates a non-lazy
enumerator from a lazy enumerator.

=== Performance improvements ===

* JIT [Experimental]
** JIT-ed code is recompiled to less-optimized code when an
optimization assumption is invalidated.
** Method inlining is performed when a method is considered as pure.
This optimization is still experimental and many methods are NOT
considered as pure yet.
** The default value of `--jit-min-calls` is changed from 5 to 10,000.
** The default value of `--jit-max-cache` is changed from 1,000 to 100.
* The performance of `CGI.escapeHTML` is improved.
* The performance of Monitor and MonitorMixin is improved.

=== Other notable changes since 2.6 ===

* Some standard libraries are updated.
* Big part of stdlib was to default gems.
* `Proc.new` and `proc` with no block in a method called with a block
is warned now.
* `lambda` with no block in a method called with a block errs.
* Update Unicode version and Emoji version from 11.0.0 to 12.0.0.
* Update Unicode version to 12.1.0, adding support for U+32FF 

[Bug 1784170] New: perl-ExtUtils-MakeMaker-7.40 is available

[bugzilla]

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

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



Latest upstream release: 7.40
Current version/release in rawhide: 7.38-1.fc32
URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/

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

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kevin Kofler]

Chris Murphy wrote:
> There is nothing sudden about this proposal. It is not unusual. It has
> been laboriously explained. You just don't like what you're hearing.
> And you are resorting to a variety of slander in mischaracterizing
> people's decisions, through your word selection.

You are the one not liking what you are hearing, and hence accusing John of 
producing logical fallacies. But that itself is a logical fallacy, an ad 
hominem attack.

> Conjecture over bugs that do not exist, demanding they will inevitably
> exist, and hyping that some large number of users will be abandoned
> and injured and powerless to do anything about it, is a logical
> fallacy called appeal to emotion.

There is no fallacy there. It is an undeniable fact that not considering 
something a blocker and stopping to test it (the latter being the reason for 
doing the former to begin with) WILL eventually lead to a release shipping 
with that something not fixed. That is the whole point of having blocker 
criteria to begin with.

> The historic facts presented in this thread show this class of bug to
> be rare, and identifiable by virtual device.

No matter how rare it is, if it is not a blocker, it just has to happen to 
happen on release day (on the day of the RC compose, actually) and the 
release will ship with the bug unfixed.

(And no, "has to happen to happen" is not a typo. :-) )

> It is baseless and useless speculation that dropping this release criteria
> will result in undiscovered and unfixed bugs. Is it possible? Sure. Is it
> probable let alone certain? No. That is conjecture.

Your claiming the opposite is conjecture as well. There is nothing 
guaranteeing that it will not happen if you remove the one thing that is 
actually guaranteeing it now (though arbitrary criteria have already been 
put on the blocker enforcement, restricting the images it applies to, which 
(to my knowledge) have not been approved by the maintainers of the affected 
images – that needs fixing, too).

> Is it likely it will affect most of the user base? No. Most of the user
> base does USB based installs.

True, but for something to be a blocker, it does not necessarily have to 
affect the majority of the users, just a sizable portion.

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kamil Paral]

On Mon, Dec 16, 2019 at 7:50 PM Kevin Kofler  wrote:

> Adam Williamson wrote:
> > This is not accurate. You're not accounting for the time it takes to
> > write the disc, and we also have to check that the media check works,
> > which takes quite a while on its own.
>
> Who cares whether the media check works? If it fails, but the distro still
> installs, that is not a blocker.


You might not want to speak with such certainty about things you're not
completely familiar with:
https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Media_consistency_verification

If you wanted to say "that should not be a blocker", you're welcome to
propose that change and we'll discuss it, but please do it in a separate
thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kamil Paral]

On Mon, Dec 16, 2019 at 6:14 PM John M. Harris Jr 
wrote:

> On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
> > This is not accurate. You're not accounting for the time it takes to
> > write the disc, and we also have to check that the media check works,
> > which takes quite a while on its own.
>
> I was accounting for that time. Writing to a disk and checking it does not
> take a long time, ~20 minutes at most. This is why I said "less than an
> hour"
> in total. Additionally, during that time, no user interaction is required,
> once the process is started.
>

I guess I should provide some better data for those estimated time
requirements. I haven't used a stopwatch during the last release cycle, but
my estimate is that it takes 1-1.5 hours to check a single install medium.
This includes burning the DVD, booting it in BIOS mode including the
mandatory and default media check, performing the installation, and then
repeating the boot and install in UEFI mode. Occasionally there are some
optical reading-related issues, e.g. when a machine gets stuck because it
constantly spins up and spins down the disc, having a problem trying to
read some area. Sometimes the disc access gets unusably slow, just to work
fine after a reboot. All the usual stuff that you come across when using
CDs/DVDs. Some of that is definitely caused by our rewritable media being
scratched, or DVD drives being old and the laser no longer being well
calibrated. We'd have to buy new drives to improve that experience, but I
don't really see much sense in that, when optical media is a niche
technology nowadays (hence this proposal).

We have 2 release-blocking media, so the total time is somewhere between
2-3 hours (likely closer to 2 hours, because netinst installation is way
faster due to downloading packages from the net instead of copying them
from the disc). That's not the main problem, though. The main problem is
that during that time, one or two of our test machines in our office is
fully occupied with spinning the discs, and we can't use it for anything
else. That means all other bare-metal testing needs to wait. As Adam
already pointed out, sometimes we need to check the final candidate
composes in a single day, i.e. in the standard 8 working hours (and yes, we
often work overtime in these cases). Blocking half of our bare-metal office
test machines for 2 hours out of 8 is not a small deal.

It's simple to say "no user interaction is required", but that's not
completely true either. If you want to do the QA job properly, you need to
have an eye on the media consistency check, because we've had issues in the
past where it timed out and either considered it a pass or fail (both are
incorrect). So you can't simply walk away and come back and consider it OK
when it reached the installer, you really need to watch the progress in
certain critical points. Once the UI is ready, it is much slower than when
booting from USB. So you often spend 10, 20 seconds staring at the screen
until it decides to do something. The actual installation progress is
unattended yet. But you need to check it frequently to see whether it
finished, so that you don't waste time of the bare metal machine standing
idle. There are many more tests waiting in the queue.

The fact that this whole process is a major annoyance (it really makes you
hate optical media, if you deal with this regularly) is of course
contributing to the fact that we don't want to do it anymore. We're only
humans. But we wouldn't have proposed the criterion change if we hadn't
thought the time is right and that it is no longer an important factor for
the majority of our users. We've waited very long with this proposal. And I
still intend to keep testing optical media functionality from time to time,
even when optical-blocking criterion is removed. But I'll do it once or
twice per cycle, probably with a Beta GO compose, and not for every release
candidate created.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kamil Paral]

On Mon, Dec 16, 2019 at 6:04 PM Adam Williamson 
wrote:

> On Mon, 2019-12-16 at 13:13 +0100, Kamil Paral wrote:
> > It's also important to understand the current state of optical media
> > release criteria. We've dropped the blocker requirement for most
> > installation media two years ago. Only Everything netinst and Workstation
> > Live remained. This proposal suggests that we drop these last two as
> well.
> > If you're concerned about Server DVD or KDE Live or something else -
> there
> > is no change for you.
>
> As per my mail earlier in the thread, I'd suggest this is inaccurate.
>
> Back at the time we reduced the set of tested images, the idea was
> explicitly that we can test just *one* live image and just *one*
> installer image as 'representatives' of the others. If one live image
> boots, we can be fairly sure all live images boot. If one installer
> image boots, we can be fairly sure all installer images boot. This is
> because all lives are built identically so far as boot stuff goes, as
> are all installer images.
>
> This is *specifically* the idea we sold that change on, so it's kinda
> logically invalid to then try and sell *this* Change on "well we only
> test these two images ANYWAY so if you don't use them you shouldn't
> care". It'd be trying to have things two opposite ways.
>

Fair point, that was an invalid argument from my side. Even though e.g.
Server DVD hasn't been optical-blocking for some time, it still gained the
benefits of test coverage or fixes in other media which were
optical-blocking.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kamil Paral]

On Mon, Dec 16, 2019 at 4:06 PM John M. Harris Jr 
wrote:

> > An older installation medium can be used and the system upgraded. And
> older
> > installation medium can be used and pointed at latest installation
> > repositories (this is not guaranteed to work, but works in majority of
> cases).
>
> This is just an excuse for exactly what I said would happen: A release
> with
> broken optical install media. This is easily avoidable.
>

John, you keep repeating the same arguments over and over. You don't need
to reply to each and every mail and state your position. If you think that
being overly vocal will change people's perception of the proposal - I
don't think so. It might just change their perception of you. We've heard
you. We understand your position. Please don't spam this thread so hard -
make it easier for others to read it and participate in it as well. Thank
you.

If you care so deeply about optical media working in Fedora, the best thing
you can do is to regularly participate in testing. Fedora is driven by
people who work on stuff in areas they're passionate about. This can be
your area and we'll certainly welcome your contribution. Fedora 32 release
cycle is coming up soon.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kevin Kofler]

Adam Williamson wrote:
> This is not accurate. You're not accounting for the time it takes to
> write the disc, and we also have to check that the media check works,
> which takes quite a while on its own.

Who cares whether the media check works? If it fails, but the distro still 
installs, that is not a blocker. I remember how, in the early Fedora days, 
it was entirely normal that the media check would always fail and that we 
all learned to just skip it and stop wasting our time on it. (And if it is 
such a time sink, I would argue to just drop it and boot directly to the 
installer.)

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Chris Murphy]

On Mon, Dec 16, 2019 at 1:28 AM John M. Harris Jr  wrote:

> This is based on random choice and personal whim, not objective reasoning.
> That there is a process does not mean that the outcome is based on anything
> more than various individuals' personal opinions.

whim
/(h)wim/
a sudden desire or change of mind, especially one that is unusual or
unexplained.

Personal preference, how people and the Project choose to prioritize,
what they choose to spend their time and effort on, is subjective. It
is neither arbitrary nor random, and not whimsical. And it's
inappropriate for you to say it is.

There is nothing sudden about this proposal. It is not unusual. It has
been laboriously explained. You just don't like what you're hearing.
And you are resorting to a variety of slander in mischaracterizing
people's decisions, through your word selection.


> > >This is not the only change I am
> > >
> > > referring to. We've been in the habit of dropping things that work, with
> > > no real reasons lately. For example, look at dropped x86 support, and
> > > soon we will be dropping Python 2. We have already had several Python 2
> > > packages dropped simply because they refused to move to Python 3. This is
> > > an ongoing issue, where everything considered "old" is just abandoned,
> > > and it is hurting the user base. It is clear that is where we're headed
> > > with this Change as well. As soon as these tests don't need to be done
> > > before a release, they won't be done before a release, and we'll have a
> > > release that has broken CD/ DVD images.
> >
> >
> > Why demand that people become emotionally traumatized in advance of
> > fantasy bugs, instead of sticking to facts and logical arguments? You
> > do a disservice to valid arguments in favor of retaining the release
> > criterion.
>
> Emotionally traumatized? Fantasy bugs? I'm afraid that I don't know what
> you're referring to.

Conjecture over bugs that do not exist, demanding they will inevitably
exist, and hyping that some large number of users will be abandoned
and injured and powerless to do anything about it, is a logical
fallacy called appeal to emotion.

The historic facts presented in this thread show this class of bug to
be rare, and identifiable by virtual device. It is baseless and
useless speculation that dropping this release criteria will result in
undiscovered and unfixed bugs. Is it possible? Sure. Is it probable
let alone certain? No. That is conjecture. Is it likely it will affect
most of the user base? No. Most of the user base does USB based
installs.


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

Re: EXTERNAL: Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Wells, Roger K. via devel]

On 12/16/19 1:07 PM, Andreas Tunek wrote:


Den mån 16 dec. 2019 kl 18:42 skrev Adam Williamson 
mailto:adamw...@fedoraproject.org>>:


Sometimes someone will propose that we've crossed the line when we
haven't, and usually we realize this and the proposal fails (excellent
example: the recentish "x86-64 micro-architecture update" proposal,
which met such universal raspberries it's probably not coming back for
a long time). It's possible that sometimes we get this call wrong,
we're only human. But it's wrong to suggest that decisions about what
we can and can't maintain, test and support are made for "no real
reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
--

Thank you for a very informative and detailed post!

+1
/Andreas


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



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



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Andreas Tunek]

Den mån 16 dec. 2019 kl 18:42 skrev Adam Williamson <
adamw...@fedoraproject.org>:

>
>
> Sometimes someone will propose that we've crossed the line when we
> haven't, and usually we realize this and the proposal fails (excellent
> example: the recentish "x86-64 micro-architecture update" proposal,
> which met such universal raspberries it's probably not coming back for
> a long time). It's possible that sometimes we get this call wrong,
> we're only human. But it's wrong to suggest that decisions about what
> we can and can't maintain, test and support are made for "no real
> reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
> --


Thank you for a very informative and detailed post!

/Andreas


>
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: upower in RHEL-8/EPEL-8

[Andrew C Aitchison]

On Mon, 16 Dec 2019, Troy Dawson wrote:


On Mon, Dec 16, 2019 at 7:45 AM Yaakov Selkowitz  wrote:


On Mon, 2019-12-16 at 06:37 -0800, Troy Dawson wrote:

On Sat, Dec 14, 2019 at 10:31 AM Kevin Fenzi  wrote:

On Fri, Dec 13, 2019 at 09:19:16PM -0500, Mukundan Ragavan wrote:

It appears that upower is in RHEL-8 but only in x86_64 and powerpc 64
architectures. Due to this, some of my builds fail. This one for example
- https://koji.fedoraproject.org/koji/taskinfo?taskID=39545162

Is using excludearch my only option? How can I get this built?


I think there's work or at least attempts to ask for these deps on all
arches, but I think for now you just need to exclude them.



Yep, this is a known issue
https://pagure.io/epel/issue/66

Currently, exludearch is the best option.


Is there a tracker for such cases so that we could go back and
enable these arches once the requisite packages land in RHEL thereon?


Not that I know of.
I just know of the packages I'm maintaining that I have to do this to.
If someone does have a tracker, it would be nice if they responded to
this thread so we could do that, cuz it seems like a good idea.


Is it possible to have a pseudo-arch or a macro ?

With something like (this probably has at least three errors):
  excludeNotInRHEL80 = "excludearch i30 arm64"
we can flip it when the issue 66 is fixed to
  excludeNotInRHEL80 = ""
and either everything will just work, or we will know what doesn't,
even before we remove the obsolete "exclude".

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sun, 2019-12-15 at 22:59 -0700, John M. Harris Jr wrote:
> This is not the only change I am referring to. We've been in the
> habit of dropping things that work, with no real reasons lately.
> For example, look at dropped x86 support, and soon we will be
> dropping Python 2. We have already had several Python 2 packages
> dropped simply because they refused to move to Python 3. This is an
> ongoing issue, where everything considered "old" is just abandoned,
> and it is hurting the user base.

So, as far as I can tell, you have done no work on anything to do with
x86 support or Python 2: you have run seven package builds, ever, all
of one package in 2016.

You also have never run a Fedora validation test (or edited anything on
the wiki besides your own user space, the Council page to nominate
yourself, and the 3D Printing SIG page to add yourself).

According to your badges you've certainly made some useful
contributions to Fedora in other areas, which is great! COPR builds,
package tagging, writing articles, running meetings and so on. But you
haven't actually done any work in any of the areas you're complaining
about here, as near as I can tell.

All of the changes you refer to were changes made for the benefit of
the people doing that work (and *thus* for the good of the project as a
whole, because the resources of the people who do the work are limited
and must be allocated properly). You claim that they were done for "no
real reason", which I think is a symptom of the fact you haven't done
any of that work, which perhaps makes it harder to understand the
actual reasons.

Upstream authors are caring less and less about 32-bit support in their
code. This meant Fedora on x86 was working less and less well over
time, while at the same time sucking up considerable QA, releng and
developer time. The way Fedora is currently set up, if a package fails
to build on *any* arch, the entire build fails and is not pulled in. So
if we needed to fix a problem but the package didn't build on x86, the
problem wasn't fixed until someone figured out why not, or just blocked
the package on x86, which over time would have rendered the arch dead
by stealth. Because we do actually care about what we ship, if a
compose went on but was entirely broken on x86 we in QA and releng and
devel would try and figure out why (just as we do for ppc64le, for
instance) and that was taking up our time too. Building for x86 also
cost in terms of hardware resources, resources which could otherwise be
used for building faster on x86_64.

The first time dropping x86 support was proposed, people complained and
said they would look after it as an alternate arch, just as we have
active teams looking after ARM arches, ppc64le, s390x and so on. An x86
SIG was formed. (You didn't join it.) But it barely did anything. Folks
in QA and releng followed the process - when x86-specific issues
appeared, we flagged them up in an appropriate tracker and notified the
SIG about them. But...usually, nothing happened. People *didn't* help
fix the bugs. It all just fell on the same people again, most of the
time. These are the reasons x86 support was dropped. If you don't like
it, that's your right. But there *are* "real reasons".

Python 2 is an even simpler case: Python 2 *is no longer maintained
upstream*. The Python developers and the community members and
developers who are most passionate about Python's future desperately
want projects and users to move *off* Python 2 and *onto* Python 3.
Fedora is not a museum piece, it's a living, relatively forward-looking 
distribution. A key goal of Fedora is to *drive forward* innovation in
F/OSS. Fedora's most important job WRT the Python 3 transition is to
push the adoption of Python 3, not to prop up the existence of Python
2. That's not the job Fedora is here to do.

Again, maintaining Python 2 support is not free, and becomes
increasingly costly over time. Python is an ecosystem, bits depend on
other bits; if we hold some of it back to support Python 2 we hurt
other bits that want to move forward to Python 3. As upstreams
increasingly adopt 3 and either intentionally use features of 3 that
don't work in 2, or just stop testing their code on 2 and
unintentionally introduce 3-isms, it becomes increasingly hard to ship
new versions while still working on 2; this is work that falls on the
packagers, it is not free. Time they spend doing that is time they
don't spend otherwise improving the package or other packages.

With optical media: as I mentioned in another post, your '25 minutes'
estimate for running an optical media boot test is substantially off,
it is closer to an hour factoring in time to write the medium and run
the consistency check. That may not sound like a lot, but we frequently
produce release candidates less than 48 hours before we intend to sign
off on them. (Sometimes we have done it less than *24* hours before we
signed off). In the context of us having less than 48 hours to test the
entire 

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
> This is not accurate. You're not accounting for the time it takes to
> write the disc, and we also have to check that the media check works,
> which takes quite a while on its own.

I was accounting for that time. Writing to a disk and checking it does not 
take a long time, ~20 minutes at most. This is why I said "less than an hour" 
in total. Additionally, during that time, no user interaction is required, 
once the process is started.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Neal Gompa]

On Mon, Dec 16, 2019 at 6:45 AM Kevin Kofler  wrote:
>
> Chris Murphy wrote:
> > On Sun, Dec 15, 2019 at 7:37 PM John M. Harris Jr 
> > wrote:
> >> It's certainly true that Apple will not service your hardware if you've
> >> got an OS other than their proprietary nonsense installed.
> >
> > In no way is it true, let alone certainly true.
> >
> > They've explicitly supported Windows (i.e. not their proprietary
> > nonsense) on Macs for 13 years via Boot Camp. Software they include in
> > default installations of macOS. I've had Fedora on Macs for many
> > years, including on one sent for service and they didn't care.
>
> I guess the main difference is whether you install Fedora as a dual boot
> next to macOS (semi-supported with Boot Camp – they don't really support
> anything other than Windows, but it will not void your warranty) or whether
> you wipe macOS and install Fedora on the whole disk. I assume that the
> latter is more likely to lead to them refusing to service the machine,
> though I don't know anybody who tried that.
>

I did this. They service my hardware if I can prove it's a hardware
fault. It's not that different from other OEMs in that regard.

I have a MacBook that has only Fedora on it and another that has a
dual-boot with macOS. Apple is fine with both.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Mon, 2019-12-16 at 13:13 +0100, Kamil Paral wrote:
> It's also important to understand the current state of optical media
> release criteria. We've dropped the blocker requirement for most
> installation media two years ago. Only Everything netinst and Workstation
> Live remained. This proposal suggests that we drop these last two as well.
> If you're concerned about Server DVD or KDE Live or something else - there
> is no change for you.

As per my mail earlier in the thread, I'd suggest this is inaccurate.

Back at the time we reduced the set of tested images, the idea was
explicitly that we can test just *one* live image and just *one*
installer image as 'representatives' of the others. If one live image
boots, we can be fairly sure all live images boot. If one installer
image boots, we can be fairly sure all installer images boot. This is
because all lives are built identically so far as boot stuff goes, as
are all installer images.

This is *specifically* the idea we sold that change on, so it's kinda
logically invalid to then try and sell *this* Change on "well we only
test these two images ANYWAY so if you don't use them you shouldn't
care". It'd be trying to have things two opposite ways.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote:
> 
> Wishlist item:  Can we just have cdn.fedoraproject.org download urls
> please?

If you mean 'a URL that redirects you to a mirror that carries the
file', that's what download.fedoraproject.org is.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sun, 2019-12-15 at 20:48 -0700, John M. Harris Jr wrote:
> Instead of trying to make arguments against those who use CDs, why not keep 
> 
> what already works maintained? The level of effort required here is 
> 
> surprisingly small, testing installation from a physical CD takes, with a 
> SATA 
> 
> II connection to a hard drive, approximately 25 minutes, and only ~2 minutes 
> 
> of that require user interaction.

This is not accurate. You're not accounting for the time it takes to
write the disc, and we also have to check that the media check works,
which takes quite a while on its own.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Great article by Valentin Rothberg on Running Podman in systemd unit files.

[Daniel Walsh]

This is one of our most common questions, and why we are adding

podman generate systemd ...

People are interested in running containers as standard services on
linux systems.  Valentin dug deep into how to do this. He explains it
all here. 

https://www.redhat.com/sysadmin/podman-shareable-systemd-services

Please social media this.

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

[EPEL-devel] Re: upower in RHEL-8/EPEL-8

[Troy Dawson]

On Mon, Dec 16, 2019 at 7:45 AM Yaakov Selkowitz  wrote:
>
> On Mon, 2019-12-16 at 06:37 -0800, Troy Dawson wrote:
> > On Sat, Dec 14, 2019 at 10:31 AM Kevin Fenzi  wrote:
> > > On Fri, Dec 13, 2019 at 09:19:16PM -0500, Mukundan Ragavan wrote:
> > > > It appears that upower is in RHEL-8 but only in x86_64 and powerpc 64
> > > > architectures. Due to this, some of my builds fail. This one for example
> > > > - https://koji.fedoraproject.org/koji/taskinfo?taskID=39545162
> > > >
> > > > Is using excludearch my only option? How can I get this built?
> > >
> > > I think there's work or at least attempts to ask for these deps on all
> > > arches, but I think for now you just need to exclude them.
> > >
> >
> > Yep, this is a known issue
> > https://pagure.io/epel/issue/66
> >
> > Currently, exludearch is the best option.
>
> Is there a tracker for such cases so that we could go back and
> enable these arches once the requisite packages land in RHEL thereon?
>
Not that I know of.
I just know of the packages I'm maintaining that I have to do this to.
If someone does have a tracker, it would be nice if they responded to
this thread so we could do that, cuz it seems like a good idea.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Fedora rawhide compose report: 20191216.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191215.n.0
NEW: Fedora-Rawhide-20191216.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  1
Dropped packages:0
Upgraded packages:   45
Downgraded packages: 0

Size of added packages:  6.94 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.55 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-starship-0.30.1-2.fc32
Summary: Cross-shell prompt for astronauts
RPMs:rust-starship+battery-devel rust-starship+default-devel 
rust-starship-devel starship
Size:6.94 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  cmake-3.16.1-1.fc32
Old package:  cmake-3.16.0-1.fc32
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 45.73 MiB
Size change:  43.81 KiB
Changelog:
  * Sat Dec 14 2019 Bj??rn Esser  - 3.16.1-1
  - Update to 3.16.1
  - Re-enable test "kwsys.testProcess-5" on S390X


Package:  conda-4.8.0-1.fc32
Old package:  conda-4.7.12-1.fc32
Summary:  Cross-platform, Python-agnostic binary package manager
RPMs: conda python3-conda
Size: 801.96 KiB
Size change:  -35.08 KiB
Changelog:
  * Sat Dec 14 2019 Orion Poplawski  - 4.8.0-1
  - Update to 4.8.0
  - Make "conda shell.bash hook" work (bz#1737165)
  - Unbundle more libraries


Package:  drupal7-admin_language-1.0-2.fc32
Old package:  drupal7-admin_language-1.0-0.12.dev.20130226.fc31
Summary:  Displays administration pages in preferred language
RPMs: drupal7-admin_language
Size: 24.80 KiB
Size change:  2.73 KiB
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 1.0-1
  - Update to 1.0 (RHBZ #1747540)
  - Add .info file to repo

  * Sun Dec 15 2019 Shawn Iwinski  - 1.0-2
  - Fix license filesystem location


Package:  drupal7-drush_language-1.6-0.1.rc3.fc32
Old package:  drupal7-drush_language-1.5-9.fc31
Summary:  Drush language commands
RPMs: drupal7-drush_language
Size: 21.39 KiB
Size change:  2.31 KiB
Changelog:
  * Sat Dec 14 2019 Shawn Iwinski  - 1.6-0.1.rc3
  - Update to 1.6-rc3 (BZ #1552586)
  - Add .info file to repo


Package:  drupal7-entity_translation-1.1-1.fc32
Old package:  drupal7-entity_translation-1.0-2.fc31
Summary:  Allows entities to be translated into different languages
RPMs: drupal7-entity_translation
Size: 95.35 KiB
Size change:  2.38 KiB
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 1.1-1
  - Update to 1.1 (RHBZ #1776035)
  - Add .info files to repo


Package:  drupal7-field_permissions-1.1-1.fc32
Old package:  drupal7-field_permissions-1.0-7.fc31
Summary:  Set field-level permissions to create, update or view fields
RPMs: drupal7-field_permissions
Size: 32.93 KiB
Size change:  36 B
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 1.1-1
  - Update to 1.1 (RHBZ #1758348)
  - Add .info file to repo


Package:  drupal7-file_entity-2.27-1.fc32
Old package:  drupal7-file_entity-2.25-2.fc31
Summary:  File entity (fieldable files)
RPMs: drupal7-file_entity
Size: 101.10 KiB
Size change:  1.29 KiB
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 2.27-1
  - Update to 2.27
  - Add .info files to repo


Package:  drupal7-honeypot-1.26-1.fc32
Old package:  drupal7-honeypot-1.25-2.fc31
Summary:  Mitigates spam form submissions using the honeypot method
RPMs: drupal7-honeypot
Size: 29.47 KiB
Size change:  91 B
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 1.26-1
  - Update to 1.26 (RHBZ #1783577)
  - Add .info file to repo


Package:  drupal7-l10n_update-2.3-1.fc32
Old package:  drupal7-l10n_update-2.2-5.fc31
Summary:  Provides automatic downloads and updates for translations
RPMs: drupal7-l10n_update
Size: 84.72 KiB
Size change:  241 B
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 2.3-1
  - Updated to 2.3 (RHBZ #1757939)
  - Add .info file to repo


Package:  drupal7-link-1.7-1.fc32
Old package:  drupal7-link-1.6-2.fc31
Summary:  Defines simple link field types
RPMs: drupal7-link
Size: 54.85 KiB
Size change:  9.23 KiB
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 1.7-1
  - Update to 1.7 (RHBZ #1772459)
  - Add .info file to repo


Package:  drupal7-webform-4.21-1.fc32
Old package:  drupal7-webform-4.19-2.fc31
Summary:  Enables the creation of forms and questionnaires
RPMs: drupal7-webform
Size: 214.06 KiB
Size change:  1.43 KiB
Changelog:
  * Sun Dec 15 2019 Shawn Iwinski  - 4.21-1
  - Update to 4.21 (RHBZ #1742293, SA-CONTRIB-2019-096)
  - https://www.drupal.org/sa-contrib-2019-096
  - Add .info file to repo


Package:  eccodes-2.15.0-1.fc32
Old package:  eccodes-2.14.1-1.fc32
Summary:  WMO data format decodi

[389-devel] Branched master to 1.4.2

[Mark Reynolds]

Heads up!

Master branch is now:  389-ds-base-1.4.3

No more enhancements should be going into the 1.4.2 branch. 
389-ds-base-1.4.0 is essentially dead, so moving forward all bugs fixes 
need to be back ported to 1.4.1, and 1.4.2.


Thanks,
Mark

--

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

[EPEL-devel] Re: upower in RHEL-8/EPEL-8

[Yaakov Selkowitz]

On Mon, 2019-12-16 at 06:37 -0800, Troy Dawson wrote:
> On Sat, Dec 14, 2019 at 10:31 AM Kevin Fenzi  wrote:
> > On Fri, Dec 13, 2019 at 09:19:16PM -0500, Mukundan Ragavan wrote:
> > > It appears that upower is in RHEL-8 but only in x86_64 and powerpc 64
> > > architectures. Due to this, some of my builds fail. This one for example
> > > - https://koji.fedoraproject.org/koji/taskinfo?taskID=39545162
> > > 
> > > Is using excludearch my only option? How can I get this built?
> > 
> > I think there's work or at least attempts to ask for these deps on all
> > arches, but I think for now you just need to exclude them.
> > 
> 
> Yep, this is a known issue
> https://pagure.io/epel/issue/66
> 
> Currently, exludearch is the best option.

Is there a tracker for such cases so that we could go back and
enable these arches once the requisite packages land in RHEL thereon?

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Summary/Minutes from today's FESCo Meeting (2019-12-16)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2019-12-16)
=

Meeting started by contyk at 15:00:06 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-12-16/fesco.2019-12-16-15.00.log.html


Meeting summary
---
* init process  (contyk, 15:00:19)

* Next week's chair  (contyk, 15:03:13)
  * ACTION: contyk will chair the next meeting again  (contyk, 15:03:22)

* Open floor  (contyk, 15:03:29)

Meeting ended at 15:07:31 UTC.

Action Items

* contyk will chair the next meeting again

Action Items, by person
---
* contyk
  * contyk will chair the next meeting again

People Present (lines said)
---
* contyk (19)
* zodbot (15)
* decathorpe (4)
* mhroncok (2)
* zbyszek (2)
* ignatenkobrain (1)
* bookwar (1)
* bcotton (1)
* nirik (0)
* dcantrell (0)
* sgallagh (0)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 18/165 (x86_64), 1/2 (arm)

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

ID: 498854  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/498854
ID: 498857  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/498857
ID: 498878  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/498878
ID: 498930  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/498930

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

ID: 498859  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/498859
ID: 498860  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/498860
ID: 498861  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/498861
ID: 498862  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/498862
ID: 498863  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/498863
ID: 498874  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/498874
ID: 498876  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/498876
ID: 498880  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/498880
ID: 498918  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/498918
ID: 498936  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/498936
ID: 498991  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/498991
ID: 498992  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/498992
ID: 499004  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/499004
ID: 499006  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/499006
ID: 499008  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/499008

Soft failed openQA tests: 70/165 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 498849  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/498849
ID: 498850  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/498850
ID: 498851  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/498851
ID: 498852  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/498852
ID: 498853  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/498853
ID: 498869  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/498869
ID: 498877  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/498877
ID: 498931  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/498931
ID: 498932  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/498932
ID: 498933  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/498933
ID: 498934  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/498934
ID: 498938  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/498938
ID: 498939  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/498939
ID: 498940  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/498940
ID: 498941  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/498941
ID: 498943  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/498943
ID: 498944  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/498944
ID: 498945  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/498945
ID: 498947  Test: x86_64 universal 

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 5:13:11 AM MST Kamil Paral wrote:
> It's very important to understand that dropping a release criterion for
> optical boot doesn't mean Fedora can't be installed from a DVD in the
> future. The bugs that affect just bare-metal optical booting (and not
> virtual machines or usb booting) are very rare.

Sure, but it still happens, and it's low hanging fruit to make sure it works 
so that these users don't wind up unable to install Fedora.

> Adam and Chris have provided some numbers and references. If such a
> problem is detected soon enough, we will definitely do our best to make
> sure it's resolved by the official release time.

Where are these numbers and references?

> In the worst case scenario, where no one spotted it in advance and all
> installation media are affected, there are still avenues for affected users.

Like what? Anything that the end user will actually go through the trouble of? 
Put on your user hat for a minute here. You want to install Fedora. You've got 
a system that will only boot via CD/DVD, and a DVD that won't boot. What do 
you do?

> An older installation medium can be used and the system upgraded. And older
> installation medium can be used and pointed at latest installation
> repositories (this is not guaranteed to work, but works in majority of 
cases).

This is just an excuse for exactly what I said would happen: A release with 
broken optical install media. This is easily avoidable.

> And we can also spin up unofficial install media post-release, once
> the bug is fixed (we've done this in the past). There are even community
> members who do these "media refreshes" regularly. Overall, yes, it might be
> uncomfortable if you have such hardware, but it's *not* game over.

Considering that the other major options still have working optical install 
media, it basically is game over. These users would likely flock to a distro 
that isn't supporting their primary install method anymore, such as openSUSE, 
Ubuntu or Debian.

-- 
John M. Harris, Jr.
Splentity

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

[EPEL-devel] Re: upower in RHEL-8/EPEL-8

[Troy Dawson]

On Sat, Dec 14, 2019 at 10:31 AM Kevin Fenzi  wrote:
>
> On Fri, Dec 13, 2019 at 09:19:16PM -0500, Mukundan Ragavan wrote:
> > It appears that upower is in RHEL-8 but only in x86_64 and powerpc 64
> > architectures. Due to this, some of my builds fail. This one for example
> > - https://koji.fedoraproject.org/koji/taskinfo?taskID=39545162
> >
> > Is using excludearch my only option? How can I get this built?
>
> I think there's work or at least attempts to ask for these deps on all
> arches, but I think for now you just need to exclude them.
>

Yep, this is a known issue
https://pagure.io/epel/issue/66

Currently, exludearch is the best option.

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

List of long term FTBFS packages to be retired in February (release candidate)

[Miro Hrončok]

Dear maintainers.

Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags and represents a preliminary list of packages.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

The main purpose is to gather feedback.

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers   Latest build

dnssec-nodes  hardaker Fedora 27
elasticsearch hubbitus, jvanek, lbazan,Fedora 24
  zbyszek
expresso  jamielinux, nodejs-sig,  Fedora 28
  patches
gnomint   verdurin Fedora 24
libocrdma ocrdma   Fedora 27
lilyterm  cwickert Fedora 27
nuvola-app-google-calendarmartinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media-martinkg Fedora 29
server
nuvola-app-plex   martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music   martinkg Fedora 29
rubygem-connection_pool   anujmore Fedora 24
rubygem-session   gomixFedora 29
shim-unsigned-aarch64 pjones   Fedora 28
shim-unsigned-x64 pjones   Fedora 28
target-isns   grover, mlombard Fedora 27
tcmu-runner   mlombard Fedora 26
telepathy-gabble  aperezbios   Fedora 29
telepathy-salut   aperezbios, johnpFedora 29

The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2

Depending on: rubygem-connection_pool (45)
rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
rubygem-activestorage-5.2.3-3.fc31.src requires 
rubygem(connection_pool) = 2.2.0-1

	rubygem-activesupport (maintained by: jaruga, jstribny, kanarip, mmorsi, 
pvalena, ruby-packagers-sig, sseago, vondruch)
		rubygem-activesupport-1:5.2.3-2.fc31.src requires rubygem(connection_pool) = 
2.2.0-1


	rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, pvalena, 
ruby-packagers-sig, sseago, tdawson, vondruch)

rubygem-rails-1:5.2.3-2.fc31.noarch requires 
rubygem(activestorage) = 5.2.3

rubygem-railties (maintained by: mmorsi, pvalena, vondruch)
rubygem-railties-5.2.3-3.fc31.src requires 
rubygem(activestorage) = 5.2.3

	rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, mmorsi, pvalena, 
ruby-packagers-sig, sseago, vondruch)

rubygem-actionpack-1:5.2.3-3.fc31.noarch requires 
rubygem(activesupport) = 5.2.3
rubygem-actionpack-1:5.2.3-3.fc31.src requires 
rubygem(activesupport) = 5.2.3

rubygem-actionview (maintained by: jaruga, pvalena, ruby-packagers-sig)
rubygem-actionview-5.2.3-3.fc31.noarch requires 
rubygem(activesupport) = 5.2.3
rubygem-actionview-5.2.3-3.fc31.src requires 
rubygem(activesupport) = 5.2.3

rubygem-activejob (maintained by: pvalena, vondruch)
rubygem-activejob-5.2.3-2.fc31.noarch requires 
rubygem(activesupport) = 5.2.3
rubygem-activejob-5.2.3-2.fc31.src requires 
rubygem(activesupport) = 5.2.3

rubygem-activemodel (maintained by: jstribny, mmorsi, pvalena, vondruch)
rubygem-activemodel-5.2.3-3.fc31.noarch requires 
rubygem(activesupport) = 5.2.3
rubygem-activemodel-5.2.3-3.fc31.src requires 
rubygem(activesupport) = 5.2.3

rubygem-activemodel-serializers-xml (maintained by: vondruch)
		rubygem-activemodel-serializers-xml-1.0.1-8.fc31.noarch requires 
rubygem(activesupport) = 5.2.3
		

[Bug 1783629] perl-Package-New-0.08 is available

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2019-12-16 13:40:45



--- Comment #2 from Tom "spot" Callaway  ---
In Rawhide.

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Solomon Peachy]

On Mon, Dec 16, 2019 at 09:19:55AM +0100, Lukas Brabec wrote:
> The oldest laptops I have experience with are HP 4520s and Lenovo 
> X201i, both from 2010, both support USB boot.

I still have two AMD server motherboards deployed that don't support 
booting off of USB sticks.  But to give an idea of their age, they were 
introduced in mid-2006 and mid-2007, respectively, and saw their final 
BIOS updates in early 2009 and mid-2010, respectively.

The older motherboard should finally be retired (again) after Xmas.  But 
I'll probably stash it in case its replacement gets taken out by a 
lightning strike.  Again.

(As an aside, I discovered the newer one didn't like USB booting when 
 the F29-F30 upgrade I did twelve days ago resulted in a "No Operating 
 System Present" failure to boot, and neither of my Fedora USB sticks 
 worked.  I couldn't find any blank media around the lab, but one of my 
 colleagues had an Ubuntu DVD lying around -- with that, I was able to 
 grub2-install the system back to life...)

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

[Bug 1783984] fusioninventory-agent-2.5.2 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
The following Sources of the specfile are not valid URLs so we cannot
automatically build the new version for you.  Please use URLs in your Source
declarations if possible.

- fusioninventory-agent.cron
- fusioninventory-agent.service

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

[Bug 1783984] New: fusioninventory-agent-2.5.2 is available

[bugzilla]

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

Bug ID: 1783984
   Summary: fusioninventory-agent-2.5.2 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: fusioninventory-agent
  Keywords: FutureFeature, Triaged
  Assignee: maria...@tuxette.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jo...@x-tnd.be, maria...@tuxette.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.5.2
Current version/release in rawhide: 2.5.1-4.fc31
URL: http://www.fusioninventory.org/

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

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

Schedule for Mondays's FESCo Meeting (2019-12-16)

[Petr Šabata]

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

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

or run:
  date -d '2019-12-16 15:00 UTC'


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

= Discussed and Voted in the Ticket =

F32 Self-Contained Change: Rebase apt package from apt-rpm to Debian's apt
https://pagure.io/fesco/issue/2292
APPROVED (+6, 0, -0)

F32 System-Wide Change: Disallow Empty Password By Default
https://pagure.io/fesco/issue/2291
REJECTED (+0, 0, -9)
Note: We also agreed to instantly reject tickets once they get
seven or more negative votes; this is anologous to the ticket
acceptance criteria.

F32 System-Wide Change: The GNU C Library version 2.31
https://pagure.io/fesco/issue/2289
APPROVED (+6, 0, -0)

Nonresponsive maintainer: Cédric OLIVIER: cquad
https://pagure.io/fesco/issue/2286
APPROVED (+5, 0, -0)

Nonresponsive maintainer: Eric Smith (brouhaha)
https://pagure.io/fesco/issue/2283
APPROVED (+3, 0, -0)

= Followups =

No floowups.

= New business =

No new business.

Note: We'll hold the meeting for a couple of minutes in case there is
anything for the open floor.

= Open Floor =

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

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kamil Paral]

On Thu, Dec 12, 2019 at 9:40 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>
> = Drop Optical Media Release Criterion =
>
> == Summary ==
> Proposal to make all Fedora optical media non-blocking. This means
> we'd stop blocking on bugs found during the installation of Fedora
> from optical media (like CDs and DVDs). This doesn't mean that
> installation from optical media would stop working, just that the
> Fedora Release wouldn't be blocked on any issues that can pop up in
> Fedora installation using this method. Installation from USB devices
> will remain blocking.
>

This has been a long discussion. Let me sum up some answers and
misunderstandings, as a member of the QA team.

The sole reason for the proposal is that testing optical media is a long
and tedious process and we believe that their importance has gone down
massively in the last years. We understand that there are people whose
hardware still requires optical media for installation. There will always
be people like that, even in 10 years. And we don't revel in presenting
them with additional obstacles. But we also have duties, priorities and
limited resources, and must regularly re-assess what we do. In our opinion,
optical media have fallen below the cut-off line. Especially with the
recent deprecation of i386 architecture in terms of kernel/boot support, we
assume that the number of affected hardware and people is just a very small
minority in our user base. That's why we want to drop the release-blocking
requirement and invest the time into testing something that affects more
people.

It's very important to understand that dropping a release criterion for
optical boot doesn't mean Fedora can't be installed from a DVD in the
future. The bugs that affect just bare-metal optical booting (and not
virtual machines or usb booting) are very rare. Adam and Chris have
provided some numbers and references. If such a problem is detected soon
enough, we will definitely do our best to make sure it's resolved by the
official release time. In the worst case scenario, where no one spotted it
in advance and all installation media are affected, there are still avenues
for affected users. An older installation medium can be used and the system
upgraded. And older installation medium can be used and pointed at latest
installation repositories (this is not guaranteed to work, but works in
majority of cases). And we can also spin up unofficial install media
post-release, once the bug is fixed (we've done this in the past). There
are even community members who do these "media refreshes" regularly.
Overall, yes, it might be uncomfortable if you have such hardware, but it's
*not* game over.

It's also important to understand the current state of optical media
release criteria. We've dropped the blocker requirement for most
installation media two years ago. Only Everything netinst and Workstation
Live remained. This proposal suggests that we drop these last two as well.
If you're concerned about Server DVD or KDE Live or something else - there
is no change for you.

Regarding virtual machines, you can rest assured that we'll still block on
VMs booting from ISO files mounted as virtual optical drives. If Adam
thinks this is a bit under-defined at the moment, we'll define it properly
as part of this proposal.

Regarding the topic of how many laptops/workstations/servers sell with an
optical drives nowadays - this is completely irrelevant, let's just not
waste time with this discussion. The important topic is how many of
existing hardware can't boot using other means (that would be mostly USB
for laptops/workstations and network for servers).

Also, this is not something that has been announced suddenly. We've been
discussing this for multiple years, and a year ago it was even proposed by
Matthew Miller (Fedora Project Leader). This gets perhaps more visibility
due to being a Change proposal, as we usually discuss QA matters in test or
test+devel lists. And that's fine, we very much appreciate feedback. I'm
just clarifying this is not some shocking news of the year.

To reply to Justin Flory about Fedora Mindshare Committee - I think this is
more of an engineering decision, really. Of course you'll find users who
will want optical boot 100% supported (and that's true probably about
anything). The question is how much testing we can provide and whether we
want to block the whole release train on such issues, and that's likely
just an engineering prioritization. Of course it's good to have user
feedback.

Regarding Miro Hrončok's proposal "let QA skip testing, but block on it if
somebody else finds the problem" - yes, it's possible. QA is by definition
best effort, even though we've considered a full test matrix coverage
somewhat mandatory lately. We do practice this approach for many criteria
for which we don't even have test cases written. In terms of boot support,
though, I'm not particularly fond of it. Without regular 

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kevin Kofler]

Chris Murphy wrote:
> On Sun, Dec 15, 2019 at 7:37 PM John M. Harris Jr 
> wrote:
>> It's certainly true that Apple will not service your hardware if you've
>> got an OS other than their proprietary nonsense installed.
> 
> In no way is it true, let alone certainly true.
> 
> They've explicitly supported Windows (i.e. not their proprietary
> nonsense) on Macs for 13 years via Boot Camp. Software they include in
> default installations of macOS. I've had Fedora on Macs for many
> years, including on one sent for service and they didn't care.

I guess the main difference is whether you install Fedora as a dual boot 
next to macOS (semi-supported with Boot Camp – they don't really support 
anything other than Windows, but it will not void your warranty) or whether 
you wipe macOS and install Fedora on the whole disk. I assume that the 
latter is more likely to lead to them refusing to service the machine, 
though I don't know anybody who tried that.

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Kevin Kofler]

Ryan Walklin wrote:
> Those are pretty vague references to old workstations and servers rather
> than specific make/model. Can you not use a generic rescue DVD/CD running
> something like rEFInd http://www.rodsbooks.com/refind to then actually
> boot from USB? Then you wouldn't have to faff keeping your optical media
> up to date anyway.

Surely that is not an officially supported (by Fedora) boot method and as 
such can also break at any time. And some of the bugs that prevent booting 
directly from optical media will also prevent booting from such a setup. 
(E.g., if it is the fact that there is an optical media inserted that 
confuses the listing of potential target devices in Anaconda.)

> As a tangent. this is pretty annoying, even when installing from USB I
> have to manually go out and grab firmware and NetworkManager packages for
> my laptop. Even worse they seem to be installed on the live images
> themselves and so WiFi works in Anaconda but not in the installed system.

I don't really see how that can happen. The liveinst mode of Anaconda just 
rsyncs everything that is installed on the live image to the target disk. It 
is not going to exclude firmware or any other installed packages. (Not even 
Anaconda itself, despite it not being needed on the installed system.)

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

Announcing the SciTech packager group

[Ankur Sinha]

Hello,

To better co-ordinate the maintenance of Science and Technology related
packages, we've created the scitech_sig group on FAS for package
maintainers[1]. If you are a package maintainer and maintain or are
interested in maintaining general packages related to Science and
Technology, please:

- apply for membership to the FAS group,
- give commit privileges to the scitech_sig group on src.fp.o to add
  them to the team's packages (you will have to wait till your FAS group
  membership has been approved, then log out and back in to src.fp.o for
  your profile to sync)
- subscribe to the notification mailing list:
  scitech-b...@lists.fedoraproject.org[2].

Community discussion around Science and Technology in Fedora will
continue on the SciTech mailing list:
scit...@lists.fedoraproject.org[3]. We also have the IRC channel at
#fedora-science on Freenode.

We encourage you to join the team and help Fedora promote Free/Open
Science and Technology! Please feel free to e-mail the discussion
mailing list for any comments at all.

Please note that for security, the bug notification mailing list is
limited to package maintainers only, and the archives will be
kept private.

[1] https://admin.fedoraproject.org/accounts/group/view/scitech_sig
[2] 
https://lists.fedoraproject.org/admin/lists/scitech-bugs.lists.fedoraproject.org/
[2] https://lists.fedoraproject.org/admin/lists/scitech.lists.fedoraproject.org/

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


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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Gerd Hoffmann]

  Hi,

> Soon after release, weeks, this first update payload is easily the
> size of the Workstation Live ISO. Is it typical to setup a local
> mirror to mitigate this problem?  If it were easier to setup a local
> mirror, or locally mirror a subset of the RPMs in a release, would
> that help make netinstall more viable in addition to making it easier
> to provide up to date installations?

/me has a local Server mirror for VM installs.

Mirroring the Everything and updates repos is too much data.

Mirroring a subset of the RPMs is too much work (maintaining the subset
you need is a PITA because it constantly changes).

What works best is downloading though a caching proxy.  Needs tweaking
the repofiles though:  Comment out metalink, add baseurl with a fixed
mirror instead, otherwise you'll end up re-downloading unmodified
repodata and packages just because yum/dnf picked another mirror this
time.

Wishlist item:  Can we just have cdn.fedoraproject.org download urls
please?

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

[Bug 1772789] Upgrade perl-Type-Tiny to 1.008000

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade perl-Type-Tiny to   |Upgrade perl-Type-Tiny to
   |1.006000|1.008000



--- Comment #1 from Jitka Plesnikova  ---
Latest Fedora delivers 1.004004 version. Upstream released 1.008000. When you
have free time, please upgrade it.

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

Steve Jenkins contact

[Tomas Korbar]

Hi,
I would like to ask if anyone knows how to contact Steve Jenkins (fas:
stevej). I tried his mail but without success. All the bugs assigned to him
[0] are untouched and in NEW state, so I created Non-responsive maintainer
check bug [1].
Thanks for any information you can provide.

[0] -
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=steve%40stevejenkins.com_to1=1=substring_id=10720216_format=advanced
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1783911
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1783933] New: Upgrade perl-Dancer2 to 0.208002

[bugzilla]

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

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



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

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

[Bug 1782941] RFE - please build perl-Config-Validator for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-1f83aab037 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1f83aab037

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

[Bug 1782935] RFE - build perl-Authen-Credential for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-6a6dcfc9e7 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a6dcfc9e7

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 1:19:55 AM MST Lukas Brabec wrote:
[snip]
> I'm the one who usually does it [1][3][4][5], sometimes it is cmurf [2].

I saw. It's odd that Fedora supports that walled garden environment, though 
that's neither here nor there. The fact that it is actually tested is why I 
didn't follow up.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Monday, December 16, 2019 12:20:32 AM MST Chris Murphy wrote:
> First, I haven't claimed it's not getting tested.

Sorry, must have been a misunderstanding on my part.

> Second, you have used a fallacy of circular reasoning. The test is
> being done because it's required to be done. That the test is being
> done is not a supporting fact that testing should be compulsory.

That is simply not the case. The test is being done to ensure that users can 
still install Fedora using optical media.

> That it's usually a full time Red Hat employee doing the testing,
> suggests that this criterion is not important to the community -
> except apparently when it comes time to complain about dropping the
> release criterion.

By "the community", you mean "developers" here? The users just use it. All 
they care about is whether or not it works. They don't want to be involved in 
making sure it continues to work. I've already volunteered to help out in this 
thread. This is important for users.

> > Please see above. Additionally, there is no reason to be hostile about
> > this.
> 
> 
> Please don't waste your time, you can't make me angry.

I wouldn't attempt to do so.

> > That is, by definition, not hyperbole. It was meant to be taken seriously,
> > and is an issue that needs to be addressed.
> 
> 
> I refuse because the word you used has a meaning contrary to the facts at
> hand:
 
> ar·bi·trar·y
> /ˈärbəˌtrerē/
> adjective: arbitrary
> based on random choice or personal whim, rather than any reason or system.

This is based on random choice and personal whim, not objective reasoning. 
That there is a process does not mean that the outcome is based on anything 
more than various individuals' personal opinions.

> This proposal is not based on anyone's personal whim. The change
> process being used are not based on whim. They are part of a rational
> system, one which you are mischaracterizing and prejudging the
> outcome. You do this by claiming the process is random when plainly it
> is not at all random. It has a structure that you merely do not like,
> not that it is lacking in structure.

It is not *random*, but see above.

> >This is not the only change I am
> >
> > referring to. We've been in the habit of dropping things that work, with
> > no real reasons lately. For example, look at dropped x86 support, and
> > soon we will be dropping Python 2. We have already had several Python 2
> > packages dropped simply because they refused to move to Python 3. This is
> > an ongoing issue, where everything considered "old" is just abandoned,
> > and it is hurting the user base. It is clear that is where we're headed
> > with this Change as well. As soon as these tests don't need to be done
> > before a release, they won't be done before a release, and we'll have a
> > release that has broken CD/ DVD images.
> 
> 
> Why demand that people become emotionally traumatized in advance of
> fantasy bugs, instead of sticking to facts and logical arguments? You
> do a disservice to valid arguments in favor of retaining the release
> criterion.

Emotionally traumatized? Fantasy bugs? I'm afraid that I don't know what 
you're referring to.

What I've described is precisely what WILL happen, if this Change is accepted. 
That is precisely what this sets us up for.

> You are pulling off a bandaid on old wounds, making a false connection
> between them and this one, and then appeal to the users as higher
> authority. And it amounts to sadfishing, and doing so on their behalf
> without their permission. I've told you before, I will not participate
> in these attempts at emotional manipulation.

You've mischaracterized my argument as an appeal to emotion. It is not. I'm 
stating what will happen. I'm saying this because it has happened in the past 
with several issues that started out in a similar manner.

> There are many hundreds of bugs fixed prior to each release, and they
> are discovered and fixed by the Fedora community despite no release
> criterion existing.

Additionally, many are not, especially not before the actual release. If this 
is not a release blocker, Fedora WILL have a release with broken CD/DVD 
install media. I suspect that would occur within two releases, though that's 
just my estimate.

-- 
John M. Harris, Jr.
Splentity

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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Lukas Brabec]

I'm +1.

The oldest laptops I have experience with are HP 4520s and Lenovo X201i, both
from 2010, both support USB boot.

Two biggest online stores in Czechia:
- CZC.cz lists 1422 laptops without optical drive, 128 with.
- Alza.cz lists 2223 without optical drive filter, 138 with.

Every autumn, we do Fedora Installfest and I don't even think we met someone
with a laptop that doesn't support USB boot.


On Fri, Dec 13, 2019 at 12:03 PM Miro Hrončok  wrote:
>
> Juts a random idea, not very thought-out:
>
> Could we keep optical media bugs reported by users as blocking, but not 
> require
> it during validation testing?
>
>
> aka: Fedora QE would no longer have to verify optical media works.
> but: If a tester finds an optical media  bug, it is still blocking.
>

Well, not ideal, but if this should be the middle ground we agree on,
I'd be okay with it.


On Mon, Dec 16, 2019 at 5:36 AM John M. Harris Jr  wrote:
>
> On Sunday, December 15, 2019 9:03:06 PM MST Chris Murphy wrote:
> > https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#OS_X_dual_boot
>
> Thank you, I'll see if anyone actually tests that, and see if we can get a
> Change proposal to drop that requirement if not.
>

I'm the one who usually does it [1][3][4][5], sometimes it is cmurf [2].

[1] 
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation#Fedora_Media_Writer
[2] 
https://fedoraproject.org/wiki/Test_Results:Fedora_28_RC_1.1_Installation#Fedora_Media_Writer
[3] 
https://fedoraproject.org/wiki/Test_Results:Fedora_29_RC_1.2_Installation#Fedora_Media_Writer
[4] 
https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Installation#Fedora_Media_Writer
[5] 
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.3_Installation#Fedora_Media_Writer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing new anitya integration and de-orphaning process

[Pierre-Yves Chibon]

On Fri, Dec 13, 2019 at 06:41:35AM -0500, Rahul Sundaram wrote:
>Hi
>On Mon, Dec 9, 2019 at 11:43 AM Pierre-Yves Chibon
><[1]pin...@pingoured.fr> wrote:
> 
>  `Monitoring` means: you get a bugzilla ticket
>  `Monitoring and scrach builds` means: you get the bugzilla ticket and an
>      attempt to do a scratch build for the new version
> 
>I was wondering how hard it would be to open a pull request if a scratch
>build was successful.  For minor version bumps, this can be helpful for
>maintainers

It's on the roadmap but there is no ETA for this yet.
I believe the idea is even to replace entirely the bugzilla ticket by a PR.


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