Fedora rawhide compose report: 20180517.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180516.n.0
NEW: Fedora-Rawhide-20180517.n.1

= SUMMARY =
Added images:9
Dropped images:  0
Added packages:  10
Dropped packages:2
Upgraded packages:   167
Downgraded packages: 0

Size of added packages:  4.60 MiB
Size of dropped packages:658.80 KiB
Size of upgraded packages:   6.93 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server dvd ppc64
Path: Server/ppc64/iso/Fedora-Server-dvd-ppc64-Rawhide-20180517.n.1.iso
Image: Scientific_KDE live i386
Path: Labs/i386/iso/Fedora-Scientific_KDE-Live-i386-Rawhide-20180517.n.1.iso
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20180517.n.1.x86_64.tar.xz
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20180517.n.1.aarch64.tar.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20180517.n.1.aarch64.tar.xz
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20180517.n.1.x86_64.tar.xz
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20180517.n.1.iso
Image: AtomicHost dvd-ostree ppc64le
Path: 
AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-Rawhide-20180517.n.1.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20180517.n.1.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-aead-poly1305-0-0.1.20180517git969857f.fc29
Summary: The poly1305 message authentication code
RPMs:golang-github-aead-poly1305-devel
Size:87.03 KiB

Package: golang-github-jedisct1-dnsstamps-0-0.1.20180517git1e49992.fc29
Summary: DNS Stamps library for Go
RPMs:golang-github-jedisct1-dnsstamps-devel
Size:11.08 KiB

Package: golang-github-k-sone-critbitgo-1.2.0-1.fc29
Summary: Crit-bit trees in golang and its applications
RPMs:golang-github-k-sone-critbitgo-devel
Size:17.95 KiB

Package: golang-github-mdlayher-genetlink-0-0.1.20180517git76fecce.fc29
Summary: Generic netlink interactions and data types
RPMs:golang-github-mdlayher-genetlink-devel
Size:21.27 KiB

Package: golang-github-pquerna-cachecontrol-0-0.1.20180517gitfd225a2.fc29
Summary: Golang HTTP Cache-Control Parser and Interpretation
RPMs:golang-github-pquerna-cachecontrol-devel
Size:27.59 KiB

Package: libmml-2.4-2.20180425git07159b0.fc29
Summary: MML Widget
RPMs:libmml-qt4 libmml-qt4-devel libmml-qt5 libmml-qt5-devel
Size:1.11 MiB

Package: nodejs-yarn-1.6.0-1.fc29
Summary: Fast, reliable, and secure dependency management.
RPMs:nodejs-yarn
Size:3.01 MiB

Package: python-collectd_systemd-0.0.1-0.2.20180516gita7018ec.fc29
Summary: Collectd plugin to monitor systemd services
RPMs:python2-collectd_systemd python3-collectd_systemd
Size:27.79 KiB

Package: python-httmock-1.2.6-1.fc29
Summary: A mocking library for requests
RPMs:python2-httmock python3-httmock
Size:30.95 KiB

Package: rubygem-mini_mime-1.0.0-1.fc29
Summary: A lightweight mime type lookup toy
RPMs:rubygem-mini_mime rubygem-mini_mime-doc
Size:278.54 KiB


= DROPPED PACKAGES =
Package: clutter-gst2-2.0.18-5.fc28
Summary: GStreamer integration for Clutter
RPMs:clutter-gst2 clutter-gst2-devel
Size:629.66 KiB

Package: rust-serde_derive_internals-0.23.1-1.fc29
Summary: AST representation used by Serde derive macros
RPMs:rust-serde_derive_internals-devel
Size:29.14 KiB


= UPGRADED PACKAGES =
Package:  0ad-data-0.0.23-1.fc29
Old package:  0ad-data-0.0.22-2.fc28
Summary:  The Data Files for 0 AD
RPMs: 0ad-data
Size: 729.15 MiB
Size change:  64.47 MiB
Changelog:
  * Thu May 17 2018 Igor Gnatenko <ignatenkobr...@fedoraproject.org> - 0.0.23-1
  - Update to 0.0.23


Package:  COPASI-4.23.184-5.fc29
Old package:  COPASI-4.23.184-2.fc29
Summary:  Biochemical network simulator
RPMs: COPASI COPASI-data COPASI-doc COPASI-gui COPASI-sharp R-COPASI 
perl-COPASI python2-COPASI python3-COPASI
Size: 226.21 MiB
Size change:  20.14 MiB
Changelog:
  * Sat May 05 2018 Antonio Trande  - 4.23.184-3
  - Now built with Qt5
  - Built against libmml

  * Wed May 16 2018 Tom Callaway <s...@fedoraproject.org> - 4.23.184-4
  - rebuild for R 3.5.0

  * Thu May 17 2018 Antonio Trande  - 4.23.184-5
  - Rebuild with Qt5


Package:  R-Biobase-2.40.0-1.fc29
Old package:  R-Biobase-2.36.2-3.fc27
Summary:  Base functions for Bioconductor
RPMs: R-Biobase
Size: 15.39 MiB
Size change:  1.27 MiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
2.36.2-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed May 16 2018 Tom Callaway <s...@fedorapr

[EPEL-devel] Re: wine 3 package

[Rex Dieter]

Ken Taylor wrote:

> On 05/16/2018 11:00 PM, Rex Dieter wrote:
>> Ken Taylor wrote:
>>
>>> I installed the wine 3 package from epel-testing this morning  on a
>>> newly installed CentOS 7.5 machine. The installation seemed to go fine.
>>> If I may ask two questions...
>>>
>>> Does this version of wine support 32 bit Windows programs on CentOS 7.5?
>> No.  rhel7 (and epel7 by extension) does not support i686 arch, which is
>> required for win32 support

> Based on my experience, rhel7 and centos7 DO support i686. epel has a
> whole bunch of ...-devel.i686 packages. I have been running wine 1.8
> i686 on CentOS 7 for more than two years. I am attempting to build wine
> 3 from source and the epel src.rpm as I write this.
> 
> I guess the question really is... is 32 bit support included in the epel
> binary rpm?

No, I looked.  Here's a snippet from wine.spec hinting at it:
# x86-32 parts
%ifarch %{ix86} x86_64
%if 0%{?fedora} || 0%{?rhel} <= 6
Requires:   wine-core(x86-32) = %{version}-%{release}
Requires:   wine-capi(x86-32) = %{version}-%{release}
Requires:   wine-cms(x86-32) = %{version}-%{release}
Requires:   wine-ldap(x86-32) = %{version}-%{release}
Requires:   wine-twain(x86-32) = %{version}-%{release}
Requires:   wine-pulseaudio(x86-32) = %{version}-%{release}

Note, only included if rhel is <=6

Then I tried to tell you why (that rhel7 has no i686 edition and epel7 has 
no i686 buildroot), but you didn't believe me.  Suit yourself.

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

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[heelsleeh]

good idea, 
EPIC release --> rhel release, centOS release
keep the old RPMS when EPIC package upgrade.
no compatibility issue any more.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/QVRJ4RLWDSNZ3AQJMKJ2SIMNLEYSQPAR/

[389-devel] please review: Ticket 49683 - Add JSON option for lib389 CLI tools

[Mark Reynolds]

https://pagure.io/389-ds-base/issue/49683

https://pagure.io/389-ds-base/pull-request/49699
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/FPR4FEL7WBJDRWYTZVIP3GPDI7TR3MUI/

[Bug 1579574] New: perl-BSON-v1.6.1 is available

[bugzilla]

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

Bug ID: 1579574
   Summary: perl-BSON-v1.6.1 is available
   Product: Fedora
   Version: rawhide
 Component: perl-BSON
  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



Latest upstream release: v1.6.1
Current version/release in rawhide: 1.6.0-1.fc29
URL: http://search.cpan.org/dist/BSON/

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

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

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Stephen John Smoogen]

On 17 May 2018 at 18:11, Matthew Miller  wrote:
> On Thu, May 17, 2018 at 04:36:17PM -0400, Stephen John Smoogen wrote:
>> I have been worried about a negative feedback loop here on packagers.
>> This is a new technology and packagers aren't usually people who care
>> about EPEL. Having them to deal with multiple OS's they don't use
>> makes it more likely they don't want to put stuff in modules in the
>> first place. I would prefer to be looser on the uptake of modules to
>> get people comfortable with them in Fedora first. I also don't expect
>> a large demand for modules in EPIC.
>
> Modules solve two problems for EPIC:
>
> First, since each module has a lifecycle definition, they make it easy
> to maintain packages for EPIC without the 10-year commitment (or,
> indeed, any more commitment then the packager makes in Fedora). And
> that works both ways: as a consumer, I can know up front what lifecycle
> I can (at least nominally) expect from a given module stream.
>
> Second, I *do* think there are a lot of cases where different EPIC
> users will want different versions. The Django module we have in Fedora
> now would be immediately useful.
>
> I do also worry about the possible negative feedback loop. I suggest we
> start _building_ for EL by default but not tagging into the repo. Make
> _that_ opt-in.
>
>

First, I am not disagreeing with what you are saying. I wrote the
proposal as things that are inside EPEL's circle of influence with
most of the other items going to take a LOT of release engineering
work to accomplish. I am also writing it for a risk averse consumer
base who want assurances that they can get old stuff even if it is
past its sell by date and that it won't eat their children if they
fat-finger a command. If Fedora wants to build it across all
platforms, I don't have a problem with it.. I just didn't see it as
inside of what we influenced.

>> >>   Extra Packages Inter Community.
>> > Extra Packages for Impassioned Community?
>> > Extra Packages Included by Community?
>> > Extra Packages Introduced by Community?
>> > Extra Packages Including Community?
>> > Extra Packages for Interprise Community? (Or "EPEC"?)

I think with our horrible history of naming this project EPEC is what
we go with. I just want the new logo not to look like a horse's butt
with tail. [I know that isn't what it was meant to be.. it is a sail
on a boat.. but once someone describes it like that.. its like a
Tyranosaurus Rex fighting a Triceratops but not as fun]

>> Extra Packages for Introverted Communities
>
> Extroverted Packages for Introverted Communities!
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ZF72FFOWREWSOHPA7MPJL74ZQNZZQMZX/



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

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Matthew Miller]

On Thu, May 17, 2018 at 04:36:17PM -0400, Stephen John Smoogen wrote:
> I have been worried about a negative feedback loop here on packagers.
> This is a new technology and packagers aren't usually people who care
> about EPEL. Having them to deal with multiple OS's they don't use
> makes it more likely they don't want to put stuff in modules in the
> first place. I would prefer to be looser on the uptake of modules to
> get people comfortable with them in Fedora first. I also don't expect
> a large demand for modules in EPIC.

Modules solve two problems for EPIC:

First, since each module has a lifecycle definition, they make it easy
to maintain packages for EPIC without the 10-year commitment (or,
indeed, any more commitment then the packager makes in Fedora). And
that works both ways: as a consumer, I can know up front what lifecycle
I can (at least nominally) expect from a given module stream.

Second, I *do* think there are a lot of cases where different EPIC
users will want different versions. The Django module we have in Fedora
now would be immediately useful.

I do also worry about the possible negative feedback loop. I suggest we
start _building_ for EL by default but not tagging into the repo. Make
_that_ opt-in.


> >>   Extra Packages Inter Community.
> > Extra Packages for Impassioned Community?
> > Extra Packages Included by Community?
> > Extra Packages Introduced by Community?
> > Extra Packages Including Community?
> > Extra Packages for Interprise Community? (Or "EPEC"?)
> Extra Packages for Introverted Communities

Extroverted Packages for Introverted Communities!

-- 
Matthew Miller

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

[Bug 1579524] New: perl-libs License tag - HSLR or HSRL?

[bugzilla]

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

Bug ID: 1579524
   Summary: perl-libs License tag - HSLR or HSRL?
   Product: Fedora
   Version: 28
 Component: perl
  Assignee: jples...@redhat.com
  Reporter: fed...@svgames.pl
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz,
mbar...@fastmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rhug...@redhat.com,
sandm...@redhat.com, tcall...@redhat.com



The License: tag for perl-libs is "(GPL+ or Artistic) and HSLR and MIT and
UCD". I believe that "HSLR" should be changed to "HSRL" ("L" and "R" swapped),
as it's supposed to be an acronym for Henry Spencer Regex Library license. 

The Licensing page on Fedora wiki also uses "HSRL".

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

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Stephen John Smoogen]

On 17 May 2018 at 15:31, Matthew Miller  wrote:
> On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote:
>>   Modules
> [...]
>> EPIC-next
>>
>>The tooling for modules can match how Fedora approaches it. This
>>means that rules for module inclusion will be similar to package
>>inclusion.  EPIC-next modules must not replace/conflict with CentOS
>>modules. They may use their own namespace to offer newer versions
>>than what is offered and those modules may be removed in the next
>>minor release if CentOS offers them then.
>
> I think we should do this part differently. Each Fedora module has its
> own lifespan, separate from that of the base OS. It automatically gets
> built across all currently-supported base OSes. That way, I can
> maintain, say, "calc-2.x" in just one stream (where stream = git
> branch), and it automatically gets built everywhere. Rather than having
> EPIC modules be entirely separate, I'd like to just include them in
> this: by default, build all modules against both the Fedora _and_ EL
> bases.
>
> This has a further implication: these modules _may_ replace or conflict
> with CentOS (and possibly RHEL) modules. But you'd have to opt-in to
> those streams explicitly to do so. With non-modular Yum/DNF, having some
> packages update base software would be horrific because enabling the
> repo and running `yum update` would do who-knows-what. But with
> modules, that's not a problem.
>

I have been worried about a negative feedback loop here on packagers.
This is a new technology and packagers aren't usually people who care
about EPEL. Having them to deal with multiple OS's they don't use
makes it more likely they don't want to put stuff in modules in the
first place. I would prefer to be looser on the uptake of modules to
get people comfortable with them in Fedora first. I also don't expect
a large demand for modules in EPIC.

Most enterprise system administrators are from Missouri. They are
going to want you to prove that it isn't going to eat their systems
before they are going to want to try it in development. They are also
going to want to make sure that it is still being developed in F3X
versus something that just showed up in F28. As 2-4 releases show up
with modules in them, then it is going to be wanted more in EPIC and
by then the procedures and plans for how they are done in Fedora
should be 'solid' enough for the enterprise admin.



>
>>EPIC
>>   Extra Packages Inter Community.
>
> Extra Packages for Impassioned Community?
> Extra Packages Included by Community?
> Extra Packages Introduced by Community?
> Extra Packages Including Community?
> Extra Packages for Interprise Community? (Or "EPEC"?)
>

Extra Packages for Introverted Communities

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



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

Re: Release fedpkg-1.33

[Miro Hrončok]

On 17.5.2018 17:57, Kevin Fenzi wrote:

On 05/17/2018 03:06 AM, Florian Weimer wrote:

On 05/17/2018 07:51 AM, Chenxiong Qi wrote:

fedpkg has been compatible with Python 3, and defaults to Python 3 in
rawhide.


Doesn't this break commands like “fedpkg build” because the Koji
libraries only support Kerberos authentication on Python 2?


Well, it breaks fedpkg clone here. ;)


Actually not broken by being python3 :)

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

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YKXH5I3EGHC6R4UJSV3CMZ3PWBNMYP6C/

Re: Release fedpkg-1.33

[Kevin Fenzi]

On 05/17/2018 03:06 AM, Florian Weimer wrote:
> On 05/17/2018 07:51 AM, Chenxiong Qi wrote:
>> fedpkg has been compatible with Python 3, and defaults to Python 3 in
>> rawhide.
> 
> Doesn't this break commands like “fedpkg build” because the Koji
> libraries only support Kerberos authentication on Python 2?

Well, it breaks fedpkg clone here. ;)

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

kevin



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

[Bug 1578594] perl-BSON-v1.6.0 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-BSON-1.6.0-1.fc28 has been pushed to the Fedora 28 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ae035cb55b

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

[EPEL-devel] Re: wine 3 package

[Ken Taylor]

On 05/16/2018 11:00 PM, Rex Dieter wrote:

Ken Taylor wrote:


I installed the wine 3 package from epel-testing this morning  on a
newly installed CentOS 7.5 machine. The installation seemed to go fine.
If I may ask two questions...

Does this version of wine support 32 bit Windows programs on CentOS 7.5?

No.  rhel7 (and epel7 by extension) does not support i686 arch, which is
required for win32 support

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


Based on my experience, rhel7 and centos7 DO support i686. epel has a 
whole bunch of ...-devel.i686 packages. I have been running wine 1.8 
i686 on CentOS 7 for more than two years. I am attempting to build wine 
3 from source and the epel src.rpm as I write this.


I guess the question really is... is 32 bit support included in the epel 
binary rpm?


Thanks,

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

Re: F29 System Wide Change: Let's Label Our Variants!

[Kevin Kofler]

Jan Kurik wrote:
> Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
> Spins, Labs and the base container image rather than just the main
> Fedora Editions.

While I agree that this needs to be handled the same way for Editions and 
Spins (because I think this distinction is arbitrary to begin with), I think 
we should actually drop those fields in the Editions instead of trying to 
fill them in everywhere. A Fedora installation can be customized in many 
ways. In the end, what you get is and should be Fedora, no matter what media 
you initially installed from. Any VARIANT distinction is just meaningless.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RZPOTF45VQDB5URNESPEMQ5ABY6WXKUK/

Schedule for Friday's FESCo Meeting (2018-05-18)

[Zbigniew Jędrzejewski-Szmek]

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

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

or run:
  date -d '2018-05-18 15:00 UTC'


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

= Followups =

#topic #1892 F29 Self Contained Change: MySQL 8
.fesco 1892
https://pagure.io/fesco/issue/1892

#topic #1890 updating the FTBFS cleanup policy
.fesco 1890
https://pagure.io/fesco/issue/1890

#topic #1877 large number of packages FTBFS in F28
.fesco 1877
https://pagure.io/fesco/issue/1877

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

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

Re: What services / tools still require NIS domain?

[Stephen John Smoogen]

On 17 May 2018 at 07:34, Florian Weimer  wrote:
> On 05/17/2018 01:54 AM, Ian Kent wrote:
>>
>> I think you'll find NIS is still quite widely used.
>>
>> NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely
>> used.
>> LDAP is another attempt to provide much of the table information provided
>> by NIS
>> but it is far more complicated to administer.
>>
>> NIS remains the simplest and easiest way to centrally manage (key, value)
>> stores
>> such as password, group, netgroup, hosts etc. so it has endured.
>
>
> On the other hand, LDAP can be run over TLS, so that people need to do a bit
> more than manipulate networks to gain unauthorized access to systems.
>
> I've also been told that people use NIS because it doesn't have a search
> domain limit.  But we removed that from Fedora 26 (in updates) and Red Hat
> Enterprise Linux 7.5, so there should be one reason less to run NIS.
>

Most of the NIS I have run in has been set up and configured to be
that way since the late 1980's or 1990's. The original hardware may
only be in a museum, but it embedded itself in the site
administration, training, and scripts. If the site has any
ISO/ITIL/etc plans, NIS got implanted deeply into all of that
documentation which will require acts of God (aka computer center hit
by a meteorite) to remove. All of this makes the replacing of NIS a
political and social struggle versus a technical one.

That said, it doesn't mean an OS like Fedora can't put a "we aren't
looking to support NIS after Fedora 34" line in the sand. Whether the
tide of inevitability will come in and wash it away is another
question.


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



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

Re: how to become maintainer or co-maintainer of orphaned package

[Martin Gansser]

thanks,
have already opened a ticket at pagure
https://pagure.io/releng/issue/7504
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NNZ53RIQ6PBEE6TDHWQWB2PKYQJEFIYD/

Re: how to become maintainer or co-maintainer of orphaned package

[Robert-André Mauchin]

On jeudi 17 mai 2018 14:09:35 CEST Martin Gansser wrote:
> Hi,
> i have a question regarding this package:
> https://apps.fedoraproject.org/packages/vdr-epgfixer
 
> Thanks
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> /message/VVDBY5MJ47VLUECSYRTZOSP6EXF6KURI/

Follow the steps from here: https://fedoraproject.org/wiki/
Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
 
to unretire the package.

It was orphaned in March 2017: https://lists.fedorahosted.org/archives/list/
devel@lists.fedoraproject.org/message/LK2YMCBM636C46R2FFFJJRF3YFS2UNM7/
Upstream seems dead though.

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

[Bug 1579340] New: perl-Test-mysqld-1.0000 is available

[bugzilla]

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

Bug ID: 1579340
   Summary: perl-Test-mysqld-1. is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-mysqld
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.
Current version/release in rawhide: 0.21-4.fc28
URL: http://search.cpan.org/dist/Test-mysqld/

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

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

Re: how to become maintainer or co-maintainer of orphaned package

[Vascom]

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

чт, 17 мая 2018 г. в 15:10, Martin Gansser :

> Hi,
> i have a question regarding this package:
> https://apps.fedoraproject.org/packages/vdr-epgfixer
>
> Thanks
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VVDBY5MJ47VLUECSYRTZOSP6EXF6KURI/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7H46V6JJZQAHVFL3TLE7W2KGKJB52Q4U/

how to become maintainer or co-maintainer of orphaned package

[Martin Gansser]

Hi,
i have a question regarding this package: 
https://apps.fedoraproject.org/packages/vdr-epgfixer

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

Re: What services / tools still require NIS domain?

[Florian Weimer]

On 05/17/2018 01:54 AM, Ian Kent wrote:

I think you'll find NIS is still quite widely used.

NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely used.
LDAP is another attempt to provide much of the table information provided by NIS
but it is far more complicated to administer.

NIS remains the simplest and easiest way to centrally manage (key, value) stores
such as password, group, netgroup, hosts etc. so it has endured.


On the other hand, LDAP can be run over TLS, so that people need to do a 
bit more than manipulate networks to gain unauthorized access to systems.


I've also been told that people use NIS because it doesn't have a search 
domain limit.  But we removed that from Fedora 26 (in updates) and Red 
Hat Enterprise Linux 7.5, so there should be one reason less to run NIS.


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

[Modularity] Working Group IRC meeting minutes (2018-05-15)

[Nils Philippsen]

=
#fedora-meeting-3: Meeting of the Modularity Working Group (once every two 
weeks)
=


Meeting started by nils at 14:00:54 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-05-15/modularity_wg.2018-05-15-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-05-15/modularity_wg.2018-05-15-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-05-15/modularity_wg.2018-05-15-14.00.log.html


Meeting summary
---
* Roll Call  (nils, 14:01:02)

* Agenda  (nils, 14:07:05)
  * Open Floor  (nils, 14:07:08)

* Open Floor  (nils, 14:07:12)
  * ACTION: asamalik figure out how we could ask [dnf?] "what version of
$thing is available on my system" when one version is standard RPMS
and the other one is a module  (asamalik, 14:23:51)
  * ACTION: asamalik figure out how we could ask [dnf?] "what version of
$thing is available on my system" when one version is standard RPMS
and the other one is a module  (asamalik, 14:25:52)

Meeting ended at 15:00:54 UTC.




Action Items

* asamalik figure out how we could ask [dnf?] "what version of $thing is
  available on my system" when one version is standard RPMS and the
  other one is a module
* asamalik figure out how we could ask [dnf?] "what version of $thing is
  available on my system" when one version is standard RPMS and the
  other one is a module




Action Items, by person
---
* asamalik
  * asamalik figure out how we could ask [dnf?] "what version of $thing
is available on my system" when one version is standard RPMS and the
other one is a module
  * asamalik figure out how we could ask [dnf?] "what version of $thing
is available on my system" when one version is standard RPMS and the
other one is a module
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* contyk (64)
* langdon (61)
* nils (46)
* bowlofeggs (41)
* asamalik (32)
* linuxmodder (18)
* zodbot (16)
* praiskup (3)
* tflink (1)
* dgilmore (1)
* mikedep333 (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CJ35NCCWLU5WLUCNNINVAS7XMRNEA5ZT/

Re: What services / tools still require NIS domain?

[David Kaspar [Dee'Kej]]

Thank you all for you replies, it helped a lot! :)

On Thu, May 17, 2018 at 1:54 AM, Ian Kent  wrote:

> On 16/05/18 23:17, David Kaspar [Dee'Kej] wrote:
> > On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher  > wrote:
> >
> > I don't think SSSD or FreeIPA *require* it. They offer netgroup
> functionality that can be used with it. Maybe I misunderstood your
> question? Are you just asking which things in the distro interact with NIS
> domains at all?
> >
> > Perhaps it would be better if you explained the rationale for the
> question. For example, are you trying to figure out if we can remove all of
> NIS from the distro?
> >
> >
> > ​Sorry, I don't know much about NIS. I was coming out from what I've
> been told.
>
> I think you'll find NIS is still quite widely used.
>
> NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely
> used.
> LDAP is another attempt to provide much of the table information provided
> by NIS
> but it is far more complicated to administer.
>
> NIS remains the simplest and easiest way to centrally manage (key, value)
> stores
> such as password, group, netgroup, hosts etc. so it has endured.
>
> Automount maps are another (key, value) store that can be centrally
> managed by
> NIS and there are still a surprising number of autofs users that continue
> to
> use it.
>
> >
> > I'm trying to figure out, which application / tool / service still
> actually need the fedora-domainname.service to be present in Fedora in
> order to function correctly?
>
> The question is kind-off ambiguous.
>
> It's not so much applications that need the service but rather services
> that can utilize the (key, value) information stored in NIS tables for the
> functionality they provide that need the NIS domain to be set.
>
> For example autofs can use NIS as an automount map source but it doesn't
> depend on NIS, it can also use automount maps stored in files, LDAP, sss
> etc.
>
> Ian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UJQMCAUCS3JSVE7IDSO7OPOUURGWH5XX/

Re: Release fedpkg-1.33

[Florian Weimer]

On 05/17/2018 07:51 AM, Chenxiong Qi wrote:

fedpkg has been compatible with Python 3, and defaults to Python 3 in
rawhide.


Doesn't this break commands like “fedpkg build” because the Koji 
libraries only support Kerberos authentication on Python 2?


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

Re: [systemd-devel] Running “telinit u” on glibc update

[Florian Weimer]

On 05/16/2018 11:52 PM, Lennart Poettering wrote:


Hence, please go aahead and drop it from the rpm scripts.


Thanks for the clear advice.  I filed

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

to track the removal.

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

[rpms/perl-Catalyst-Plugin-Session-State-URI] New Commits To "rpms/perl-Catalyst-Plugin-Session-State-URI" (f28)

[pagure]

The following commits were pushed to the repo 
rpms/perl-Catalyst-Plugin-Session-State-URI on branch
f28, which you are following:
6961010867f6150973433d260d0e74b6e81f48b2Jitka PlesnikovaSpecify all 
dependencies; Modernize spec file



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Catalyst-Plugin-Session-State-URI/commits/f28
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[rpms/perl-Catalyst-Plugin-Session-State-URI] New Commits To "rpms/perl-Catalyst-Plugin-Session-State-URI" (master)

[pagure]

The following commits were pushed to the repo 
rpms/perl-Catalyst-Plugin-Session-State-URI on branch
master, which you are following:
6961010867f6150973433d260d0e74b6e81f48b2Jitka PlesnikovaSpecify all 
dependencies; Modernize spec file



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Catalyst-Plugin-Session-State-URI/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

On Thu, 17 May 2018, 1:08 p.m. Peter Robinson,  wrote:

> On Thu, May 17, 2018 at 8:25 AM, Manas Mangaonkar
>  wrote:
> >> Put the patch name in ~/rpmbuild/SPECS/kernel.spec just before END OF
> >> PATCHES.
> >>
> >> Run rpmbuild -bb kernel.spec
> >>
> >> You will have the kernel rpm files in ~/rpmbuild/RPMS/x86_64
> >>
> >> The gotchas are left as an exercise for the reader (if you are a
> >> newbie, there will be lots of them).  :-)  And it's rough, there is a
> >> lot of optimization that I left out.
> >>
> >> So it's a lot of work, but a great learning experience if you are up
> >> for it.
> >>
> >>
> >
> > okay,i'll give it a shot sounds fun will get to learn something. Cant
> > guarantee a completion data though.15-20 days should be enough i guess.
>
> Maintaining a kernel isn't a one off event it's an ongoing process.
> The vast majority of the work is getting the initial build working but
> from there it's an ongoing process to keep it up to date to ensure
> your users aren't vulnerable to CVEs etc.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


 Ah,yes.Proposed the the above mentioned timeline for the initial build.I
am ready to dedicate time to maintain it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1579091] perl-AnyEvent-Handle-UDP-0.049 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-AnyEvent-Handle-UDP-0.
   ||049-1.fc29
 Resolution|--- |RAWHIDE
   Assignee|dd...@cpan.org  |jples...@redhat.com
Last Closed||2018-05-17 03:47:21



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

[rpms/perl-AnyEvent-Handle-UDP] New Commits To "rpms/perl-AnyEvent-Handle-UDP" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-AnyEvent-Handle-UDP on 
branch
master, which you are following:
5d20c58a0ffd0450dd234160b8bf4818913005f2Jitka Plesnikova0.049 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-AnyEvent-Handle-UDP/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[Peter Robinson]

On Thu, May 17, 2018 at 8:25 AM, Manas Mangaonkar
 wrote:
>> Put the patch name in ~/rpmbuild/SPECS/kernel.spec just before END OF
>> PATCHES.
>>
>> Run rpmbuild -bb kernel.spec
>>
>> You will have the kernel rpm files in ~/rpmbuild/RPMS/x86_64
>>
>> The gotchas are left as an exercise for the reader (if you are a
>> newbie, there will be lots of them).  :-)  And it's rough, there is a
>> lot of optimization that I left out.
>>
>> So it's a lot of work, but a great learning experience if you are up
>> for it.
>>
>>
>
> okay,i'll give it a shot sounds fun will get to learn something. Cant
> guarantee a completion data though.15-20 days should be enough i guess.

Maintaining a kernel isn't a one off event it's an ongoing process.
The vast majority of the work is getting the initial build working but
from there it's an ongoing process to keep it up to date to ensure
your users aren't vulnerable to CVEs etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

>
> Put the patch name in ~/rpmbuild/SPECS/kernel.spec just before END OF
> PATCHES.
>
> Run rpmbuild -bb kernel.spec
>
> You will have the kernel rpm files in ~/rpmbuild/RPMS/x86_64
>
> The gotchas are left as an exercise for the reader (if you are a
> newbie, there will be lots of them).  :-)  And it's rough, there is a
> lot of optimization that I left out.
>
> So it's a lot of work, but a great learning experience if you are up
> for it.
>
>
>
okay,i'll give it a shot sounds fun will get to learn something. Cant
guarantee a completion data though.15-20 days should be enough i guess.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org