Re: koji build failure

[Dave Young]

On 02/07/18 at 06:32am, Kalev Lember wrote:
> On 02/07/2018 06:17 AM, Dave Young wrote:
> >   - nothing provides /usr/bin//usr/bin/python3 needed by 
> > glib2-devel-2.55.2-1.fc28.x86_64
> 
> Looks like something gone wrong with new brp-mangle-shebangs script in
> redhat-rpm-config. I've disabled it in glib2 2.55.2-2; can you try
> submitting your build again?

Thank you for quick fix! a new build seem running well now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24775310

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

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

Re: koji build failure

[Kalev Lember]

On 02/07/2018 06:17 AM, Dave Young wrote:
>   - nothing provides /usr/bin//usr/bin/python3 needed by 
> glib2-devel-2.55.2-1.fc28.x86_64

Looks like something gone wrong with new brp-mangle-shebangs script in
redhat-rpm-config. I've disabled it in glib2 2.55.2-2; can you try
submitting your build again?

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

[Bug 1542721] Please provide a package for EPEL7

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2018-02-07 00:18:21



--- Comment #1 from Ralf Corsepius  ---
To cut a long story short: I do not use nor support EPEL, because I consider
packager in EPEL to be unmaintainable.

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

koji build failure

[Dave Young]

Hi all

Anyone has idea bout below error in mock log?

Start: build phase for kexec-tools-2.0.16-4.fc28.src.rpm
Start: build setup for kexec-tools-2.0.16-4.fc28.src.rpm
ERROR: 
Exception(/var/tmp/koji/tasks/2211/24772211/local/work/tasks/2140/24772140/kexec-tools-2.0.16-4.fc28.src.rpm)
 Config(f28-build-11345612-851851) 0 minutes 2 seconds
INFO: Results and/or logs in: /var/lib/mock/f28-build-11345612-851851/result
ERROR: Command failed: 
 # /usr/bin/dnf builddep --installroot 
/var/lib/mock/f28-build-11345612-851851/root/ 
/var/lib/mock/f28-build-11345612-851851/root//builddir/build/SRPMS/kexec-tools-2.0.16-4.fc28.src.rpm
 --setopt=tsflags=nocontexts
Last metadata expiration check: 0:00:00 ago on Wed 07 Feb 2018 04:31:49 AM UTC.
Package pkgconf-pkg-config-1.4.1-2.fc28.x86_64 is already installed, skipping.
Package zlib-1.2.11-5.fc28.x86_64 is already installed, skipping.
Error: 
 Problem: conflicting requests
  - nothing provides /usr/bin//usr/bin/python3 needed by 
glib2-devel-2.55.2-1.fc28.x86_64


build link:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24772211

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

Re: gnome crashes after today upgrade

[Peter Hutterer]

On Wed, Feb 07, 2018 at 02:12:52PM +1000, Peter Hutterer wrote:
> xkeyboard-config-2.23.1-1.fc28 is building and seems to fix the issue
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24771380

First build failed, successful one is:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24772701

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

Re: gnome crashes after today upgrade

[Peter Hutterer]

On Wed, Feb 07, 2018 at 12:42:54AM +, Tomasz Kłoczko wrote:
> On 6 February 2018 at 19:33, Bruno Wolff III  wrote:
> 
> > On Fri, Feb 02, 2018 at 20:35:25 +,
> >  Tomasz Kłoczko  wrote:
> >
> >> Hi,
> >>
> >> Looks like today updates are trashing gnome almost completely.
> >> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
> >>
> >> "journalctl -xe" output is in attachment.
> >>
> >
> > If this is rawhide, you might try downgrading m17n-db* . On one machine
> > the latest version is causing lots of applications to crash. On other
> > machines it doesn't happen and I don't know what the difference is. I'm
> > hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> > have much for the maintainer to go on to try to fix things.
> >
> 
> m17n-db has nothing to do with xkb.
> I've done something different.
> I found that m17n-db is only required by m17n-lib package and m17n-lib is
> required only by ibus-m17n, and nothing requires ibus-m17n.
> So I've removed all those three packages and after logout-> loging (under
> gnome or Xfce; both under X11) still gdm has been failing with *exactly*
> the same error messages.
> 
> xkb is about keyboard mappings withing working X11 server.
> 
> Nevertheless just found what is causing tose xkb errors.
> I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
> and on executing:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> Error loading new keyboard description
> [tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
> execve("/usr/bin/setxkbmap", ["setxkbmap", "-v", "pl"], 0x7ffcce6b2830 /*
> 46 vars */) = 0
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
> access("/run/user/1000/gdm/Xauthority", R_OK) = 0
> openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4
> 
> Next was rpm query:
> 
> [tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
> Name: xkeyboard-config
> Version : 2.23
> Release : 1.fc28
> Architecture: noarch
> Install Date: Fri 02 Feb 2018 03:10:22 GMT
> Group   : Unspecified
> Size: 5804719
> License : MIT
> Signature   : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
> e08e7e629db62fb1
> Source RPM  : xkeyboard-config-2.23-1.fc28.src.rpm
> Build Date  : Wed 31 Jan 2018 09:06:48 GMT   HERE 
> Build Host  : buildvm-ppc64le-15.ppc.fedoraproject.org
> Relocations : (not relocatable)
> Packager: Fedora Project
> Vendor  : Fedora Project
> URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
> Summary : X Keyboard Extension configuration data
> Description :
> This package contains configuration data used by the X Keyboard Extension
> (XKB),
> which allows selection of keyboard layouts when using a graphical interface..
> 
> As long as upgrade 2.23 has been done around the time when mine problems
> with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
> downgrade:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> [tkloczko@domek ~]$ łóćźęśźż
> 
> So I'm able now to enter Polish characters :)
> 
> So looks like at least something is wrong with xkeyboard-config-2.23.

yep, thanks, there was a typo in the polish layout. Was fixed upstream, I
just don't 

Re: libiscsi "missing" on s390x?

[Orion Poplawski]

On 02/06/2018 05:22 PM, Richard W.M. Jones wrote:

On Tue, Feb 06, 2018 at 05:10:19PM -0700, Christoph Junghans wrote:

On Tue, Feb 6, 2018 at 5:00 PM, Richard W.M. Jones  wrote:

On Tue, Feb 06, 2018 at 04:56:14PM -0700, Christoph Junghans wrote:

On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans  wrote:

On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  wrote:


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

This build fails, but only on s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023

The strange this is that libiscsi is not installed into the build root
on s390x (but it is on other architectures) and that apparently causes
the missing dependency which causes the build to fail.

It seems the s390x environment needs some work, e.g.
nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515

And I just found:
nothing provides libibverbs.so.1()(64bit) needed by openmpi--2.1.1-7.fc28.s390x
in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507


I don't understand.

libiscsi was built on s390x, see:
https://koji.fedoraproject.org/koji/buildinfo?buildID=979268

Somehow it's not available for further builds, which appears to
be a Koji problem.

Hmm, I tried to rebuild libiscsi in
https://koji.fedoraproject.org/koji/taskinfo?taskID=24761879
but got:
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel'


OK I see now.
There's some further analysis on the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1542728

Rich.



I've built rdma-core for s390x now.  libiscsi builds still don't seem 
happy though - https://koji.fedoraproject.org/koji/taskinfo?taskID=24770625


Working on openmpi and others 

--
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/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Wednesday's FPC Meeting (2018-02-07 18:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-02-07 18:00 UTC in #fedora-meeting-2 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Wednesday =
2018-02-07 10:00 PST  US/Pacific
2018-02-07 13:00 EST  --> US/Eastern <--
2018-02-07 18:00 GMT  Europe/London 
2018-02-07 18:00 UTC  UTC   
2018-02-07 19:00 CET  Europe/Berlin 
2018-02-07 19:00 CET  Europe/Paris  
2018-02-07 23:30 IST  Asia/Calcutta 
--- New Day: Thursday 
2018-02-08 02:00 HKT  Asia/Hong_Kong
2018-02-08 02:00 +08  Asia/Singapore
2018-02-08 03:00 JST  Asia/Tokyo
2018-02-08 04:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #694 Packaging guidelines for application independence 
.fpc 694
https://pagure.io/packaging-committee/issue/694

#topic #702 C/C++ guidelines should say using clang needs an exception
.fpc 702
https://pagure.io/packaging-committee/issue/702

#topic #708 Allocating a static uid and gid for openvswitch
.fpc 708
https://pagure.io/packaging-committee/issue/708

#topic #710 Ruby packaging guidelines update
.fpc 710
https://pagure.io/packaging-committee/issue/710

#topic #713 Forward-looking conditionals by default
.fpc 713
https://pagure.io/packaging-committee/issue/713

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #715 Separately building package documentation
.fpc 715
https://pagure.io/packaging-committee/issue/715

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #723 Guidelines for handling deprecated dependencies during
review 
.fpc 723
https://pagure.io/packaging-committee/issue/723

#topic #726 Review for SELinux Independent Policy packaging Draft   
.fpc 726
https://pagure.io/packaging-committee/issue/726

= New business =

#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc
743
https://pagure.io/packaging-committee/issue/743

#topic #749 Add note about disabling BRP scripts to guidelines
.fpc 749
https://pagure.io/packaging-committee/issue/749

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee
, 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

Pull requests for compat-gcc-34

[Rafal Luzynski]

Hello,

I have opened 3 pull requests for compat-gcc-34:

https://src.fedoraproject.org/rpms/compat-gcc-34/pull-requests

fixing FTBFS errors in 3 currently existing Fedora releases.
Thank you all who helped me with this task. What is the next step
to make them actually merged? I have not received any feedback from
the maintainer, I believe he's just very busy.

Also, just to clarify: I still don't know whether it is correct to just
bump the required version of libstdc++, I just bump it because it has been
done so many times in the past.

Regards,

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

Re: gnome crashes after today upgrade

[Tomasz Kłoczko]

On 6 February 2018 at 19:33, Bruno Wolff III  wrote:

> On Fri, Feb 02, 2018 at 20:35:25 +,
>  Tomasz Kłoczko  wrote:
>
>> Hi,
>>
>> Looks like today updates are trashing gnome almost completely.
>> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
>>
>> "journalctl -xe" output is in attachment.
>>
>
> If this is rawhide, you might try downgrading m17n-db* . On one machine
> the latest version is causing lots of applications to crash. On other
> machines it doesn't happen and I don't know what the difference is. I'm
> hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> have much for the maintainer to go on to try to fix things.
>

m17n-db has nothing to do with xkb.
I've done something different.
I found that m17n-db is only required by m17n-lib package and m17n-lib is
required only by ibus-m17n, and nothing requires ibus-m17n.
So I've removed all those three packages and after logout-> loging (under
gnome or Xfce; both under X11) still gdm has been failing with *exactly*
the same error messages.

xkb is about keyboard mappings withing working X11 server.

Nevertheless just found what is causing tose xkb errors.
I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
and on executing:

[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+pl+inet(evdev)
geometry:   pc(pc105)
Error loading new keyboard description
[tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
execve("/usr/bin/setxkbmap", ["setxkbmap", "-v", "pl"], 0x7ffcce6b2830 /*
46 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
access("/run/user/1000/gdm/Xauthority", R_OK) = 0
openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4

Next was rpm query:

[tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
Name: xkeyboard-config
Version : 2.23
Release : 1.fc28
Architecture: noarch
Install Date: Fri 02 Feb 2018 03:10:22 GMT
Group   : Unspecified
Size: 5804719
License : MIT
Signature   : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
e08e7e629db62fb1
Source RPM  : xkeyboard-config-2.23-1.fc28.src.rpm
Build Date  : Wed 31 Jan 2018 09:06:48 GMT   HERE 
Build Host  : buildvm-ppc64le-15.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
Summary : X Keyboard Extension configuration data
Description :
This package contains configuration data used by the X Keyboard Extension
(XKB),
which allows selection of keyboard layouts when using a graphical interface.

As long as upgrade 2.23 has been done around the time when mine problems
with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
downgrade:

[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+pl+inet(evdev)
geometry:   pc(pc105)
[tkloczko@domek ~]$ łóćźęśźż

So I'm able now to enter Polish characters :)

So looks like at least something is wrong with xkeyboard-config-2.23.
If no one will try to check what has been changed in 2.23 tomorrow will
continue investigation (at the moment have no time to raise ticket).

A .. BTW: looks like m17n-{db,lib} and ibus-m17n are not needed and
everything is working perfectly fine (doesn't matter am I using us, gb or
pl xkb mapping).

Another conclusion: I think that using xkbcomp compile text definition to

[Bug 1542774] New: perl-WebService-Rajce-1.180370 is available

[bugzilla]

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

Bug ID: 1542774
   Summary: perl-WebService-Rajce-1.180370 is available
   Product: Fedora
   Version: rawhide
 Component: perl-WebService-Rajce
  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: 1.180370
Current version/release in rawhide: 1.152.450-4.fc27
URL: http://search.cpan.org/dist/WebService-Rajce/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542771] New: perl-Sub-Quote-2.005000 is available

[bugzilla]

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

Bug ID: 1542771
   Summary: perl-Sub-Quote-2.005000 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Sub-Quote
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.005000
Current version/release in rawhide: 2.004000-2.fc27
URL: http://search.cpan.org/dist/Sub-Quote/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: libiscsi "missing" on s390x?

[Richard W.M. Jones]

On Tue, Feb 06, 2018 at 05:10:19PM -0700, Christoph Junghans wrote:
> On Tue, Feb 6, 2018 at 5:00 PM, Richard W.M. Jones  wrote:
> > On Tue, Feb 06, 2018 at 04:56:14PM -0700, Christoph Junghans wrote:
> >> On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans  
> >> wrote:
> >> > On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  
> >> > wrote:
> >> >>
> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1542728
> >> >>
> >> >> This build fails, but only on s390x:
> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023
> >> >>
> >> >> The strange this is that libiscsi is not installed into the build root
> >> >> on s390x (but it is on other architectures) and that apparently causes
> >> >> the missing dependency which causes the build to fail.
> >> > It seems the s390x environment needs some work, e.g.
> >> > nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
> >> > in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515
> >> And I just found:
> >> nothing provides libibverbs.so.1()(64bit) needed by 
> >> openmpi--2.1.1-7.fc28.s390x
> >> in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507
> >
> > I don't understand.
> >
> > libiscsi was built on s390x, see:
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=979268
> >
> > Somehow it's not available for further builds, which appears to
> > be a Koji problem.
> Hmm, I tried to rebuild libiscsi in
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24761879
> but got:
> DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
> DEBUG util.py:439:  No matching package to install: 'librdmacm-devel'

OK I see now.
There's some further analysis on the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1542728

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1542766] New: perl-Mojolicious-7.63 is available

[bugzilla]

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

Bug ID: 1542766
   Summary: perl-Mojolicious-7.63 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com



Latest upstream release: 7.63
Current version/release in rawhide: 7.62-1.fc28
URL: http://mojolicio.us/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: libiscsi "missing" on s390x?

[Christoph Junghans]

On Tue, Feb 6, 2018 at 5:00 PM, Richard W.M. Jones  wrote:
> On Tue, Feb 06, 2018 at 04:56:14PM -0700, Christoph Junghans wrote:
>> On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans  
>> wrote:
>> > On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  
>> > wrote:
>> >>
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1542728
>> >>
>> >> This build fails, but only on s390x:
>> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023
>> >>
>> >> The strange this is that libiscsi is not installed into the build root
>> >> on s390x (but it is on other architectures) and that apparently causes
>> >> the missing dependency which causes the build to fail.
>> > It seems the s390x environment needs some work, e.g.
>> > nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
>> > in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515
>> And I just found:
>> nothing provides libibverbs.so.1()(64bit) needed by 
>> openmpi--2.1.1-7.fc28.s390x
>> in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507
>
> I don't understand.
>
> libiscsi was built on s390x, see:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=979268
>
> Somehow it's not available for further builds, which appears to
> be a Koji problem.
Hmm, I tried to rebuild libiscsi in
https://koji.fedoraproject.org/koji/taskinfo?taskID=24761879
but got:
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel'

Christoph

>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libiscsi "missing" on s390x?

[Richard W.M. Jones]

On Tue, Feb 06, 2018 at 04:56:14PM -0700, Christoph Junghans wrote:
> On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans  wrote:
> > On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  
> > wrote:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1542728
> >>
> >> This build fails, but only on s390x:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023
> >>
> >> The strange this is that libiscsi is not installed into the build root
> >> on s390x (but it is on other architectures) and that apparently causes
> >> the missing dependency which causes the build to fail.
> > It seems the s390x environment needs some work, e.g.
> > nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
> > in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515
> And I just found:
> nothing provides libibverbs.so.1()(64bit) needed by 
> openmpi--2.1.1-7.fc28.s390x
> in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507

I don't understand.

libiscsi was built on s390x, see:
https://koji.fedoraproject.org/koji/buildinfo?buildID=979268

Somehow it's not available for further builds, which appears to
be a Koji problem.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libiscsi "missing" on s390x?

[Christoph Junghans]

On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans  wrote:
> On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  wrote:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1542728
>>
>> This build fails, but only on s390x:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023
>>
>> The strange this is that libiscsi is not installed into the build root
>> on s390x (but it is on other architectures) and that apparently causes
>> the missing dependency which causes the build to fail.
> It seems the s390x environment needs some work, e.g.
> nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
> in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515
And I just found:
nothing provides libibverbs.so.1()(64bit) needed by openmpi--2.1.1-7.fc28.s390x
in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507

>
> Christoph
>>
>> Rich.
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> virt-top is 'top' for virtual machines.  Tiny program with many
>> powerful monitoring features, net stats, disk stats, logging, etc.
>> http://people.redhat.com/~rjones/virt-top
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> Christoph Junghans
> Web: http://www.compphys.de



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libiscsi "missing" on s390x?

[Christoph Junghans]

On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones  wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1542728
>
> This build fails, but only on s390x:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023
>
> The strange this is that libiscsi is not installed into the build root
> on s390x (but it is on other architectures) and that apparently causes
> the missing dependency which causes the build to fail.
It seems the s390x environment needs some work, e.g.
nothing provides rdma-core-devel(s390-64) needed by hwloc-devel
in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515

Christoph
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: openclonk-0.8 linking fails

[Richard W.M. Jones]

On Tue, Feb 06, 2018 at 08:18:50AM -, Martin Gansser wrote:
> Error running link command: Segmentation fault

What is the stack trace from this link failure?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libiscsi "missing" on s390x?

[Richard W.M. Jones]

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

This build fails, but only on s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023

The strange this is that libiscsi is not installed into the build root
on s390x (but it is on other architectures) and that apparently causes
the missing dependency which causes the build to fail.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1542731] New: Please provide a package for EPEL7

[bugzilla]

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

Bug ID: 1542731
   Summary: Please provide a package for EPEL7
   Product: Fedora
   Version: rawhide
 Component: perl-Sys-Statistics-Linux
  Assignee: emman...@seyman.fr
  Reporter: zebo...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org



Hello,

I am packaging a new program called Ravada and I've been asked to make it
available for EPEL7. It depends on perl-Sys-Statistics-Linux, so could you
please build it for EPEL7?

All the dependencies are already available, it just needs to be merged from
master and rebuild.

Thank you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542727] Please provide a package for EPEL7

[bugzilla]

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

Robert-André Mauchin  changed:

   What|Removed |Added

 Blocks||1525990




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1525990
[Bug 1525990] [RFE] please provide in EPEL
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542727] New: Please provide a package for EPEL7

[bugzilla]

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

Bug ID: 1542727
   Summary: Please provide a package for EPEL7
   Product: Fedora
   Version: rawhide
 Component: perl-experimental
  Assignee: ppi...@redhat.com
  Reporter: zebo...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Hello,

I am packaging a new program called Ravada and I've been asked to make it
available for EPEL7. It depends on perl-Mojolicious, whick itself depends on
perl-experimental so could you please build it for EPEL7?

All the dependencies are already available.

The SPEC from master requires minor changes: namely removing the NO_PACKLIST
option which is only available from perl(ExtUtils::MakeMaker) >= 6.76 and
instead remove the packlist manually.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1525990] [RFE] please provide in EPEL

[bugzilla]

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

Robert-André Mauchin  changed:

   What|Removed |Added

 Depends On||1542727




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1542727
[Bug 1542727] Please provide a package for EPEL7
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1525990] [RFE] please provide in EPEL

[bugzilla]

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

Robert-André Mauchin  changed:

   What|Removed |Added

 CC||zebo...@gmail.com



--- Comment #1 from Robert-André Mauchin  ---
I need this too for Ravada bug#1535207

Only one package is missing: perl(experimental) which is owned by Petr Pisar.

The SPEC from master requires minor changes: namely removing the NO_PACKLIST
option which is only available from perl(ExtUtils::MakeMaker) >= 6.76 and
instead remove the packlist manually.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542721] New: Please provide a package for EPEL7

[bugzilla]

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

Bug ID: 1542721
   Summary: Please provide a package for EPEL7
   Product: Fedora
   Version: rawhide
 Component: perl-Locale-Maketext-Lexicon
  Assignee: rc040...@freenet.de
  Reporter: zebo...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, perl-devel@lists.fedoraproject.org,
rc040...@freenet.de



Hello,

I am packaging a new program called Ravada and I've been asked to make it
available for EPEL7. It depends on perl-Locale-Maketext-Lexicon so could you
please build it for EPEL7?

All the dependencies are available but perl(Text::Haml) which you also own.

The SPEC from master requires minor changes: namely removing the NO_PACKLIST
option which is only available from perl(ExtUtils::MakeMaker) >= 6.76 and
instead remove the packlist manually.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Tue, Feb 06, 2018 at 08:18:27PM +, Terry Barnaby wrote:
> Well, when a program running on a system calls open(), write() etc. to the
> local disk FS the disk's contents is not actually updated. The data is in
> server buffers until the next sync/fsync or some time has passed. So, in
> your parlance, the OS write() call lies to the program. So it is by default
> async unless the "sync" mount option is used when mounting the particular
> file system in question.

That's right, but note applications are written with the knowledge that
OS's behave this way, and are given tools (sync, fsync, etc.) to manage
this behavior so that they still have some control over what survives a
crash.

(But sync & friends no longer do what they're supposed to on an Linux
server exporting with async.)

> Although it is different from the current NFS settings methods, I would have
> thought that this should be the same for NFS. So if a client mounts a file
> system normally it is async, ie write() data is in buffers somewhere (client
> or server) unless the client mounts the file system in sync mode.

In fact, this is pretty much how it works, for write().

It didn't used to be that way--NFSv2 writes were all synchronous.

The problem is that if a server power cycles while it still had dirty
data in its caches, what should you do?

You can't ignore it--you'd just be silently losing data.  You could
return an error at some point, but "we just lost some or your idea, no
idea what" isn't an error an application can really act on.

So NFSv3 introduced a separation of write into WRITE and COMMIT.  The
client first sends a WRITE with the data, then latter sends a COMMIT
call that says "please don't return till that data I sent before is
actually on disk".

If the server reboots, there's a limited set of data that the client
needs to resend to recover (just data that's been written but not
committed.)

But we only have that for file data, metadata would be more complicated,
so stuff like file creates, setattr, directory operations, etc., are
still synchronous.

> Only difference from the normal FS conventions I am suggesting is to
> allow the server to stipulate "sync" on its mount that forces sync
> mode for all clients on that FS.

Anyway, we don't have protocol to tell clients to do that.

> In the case of a /home mount for example, or a source code build file
> system, it is normally only one client that is accessing the dir and if a
> write fails due to the server going down (an unlikely occurrence, its not
> much of an issue. I have only had this happen a couple of times in 28 years
> and then with no significant issues (power outage, disk fail pre-raid etc.).

So if you have reliable servers and power, maybe you're comfortable with
the risk.  There's a reason that's not the default, though.

> > > 4. The 0.5ms RPC latency seems a bit high (ICMP pings 0.12ms) . Maybe this
> > > is worth investigating in the Linux kernel processing (how ?) ?
> > Yes, that'd be interesting to investigate.  With some kernel tracing I
> > think it should be possible to get high-resolution timings for the
> > processing of a single RPC call, which would make a good start.
> > 
> > It'd probably also interesting to start with the simplest possible RPC
> > and then work our way up and see when the RTT increases the most--e.g
> > does an RPC ping (an RPC with procedure 0, empty argument and reply)
> > already have a round-trip time closer to .5ms or .12ms?
> Any pointers to trying this ? I have a small amount of time as work is quiet
> at the moment.

Hm.  I wonder if testing over loopback would give interesting enough
results.  That might simplify testing even if it's not as realistic.
You could start by seeing if latency is still similar.

You could start by googling around for "ftrace", I think lwn.net's
articles were pretty good introductions.

I don't do this very often and don't have good step-by-step
instructions

I beleive the simplest way to do it was using "trace-cmd" (which is
packaged for fedora in a package of the same name).  The man page looks
skimpy, but https://lwn.net/Articles/410200/ looks good.  Maybe run it
while just stat-ing a single file on an NFS partition as a start.

I don't know if that will result in too much data.  Figuring out how to
filter it may be tricky.  Tracing everything may be prohibitive.
Several processes are involved so you don't want to restrict by process.
Maybe restricting to functions in nfsd and sunrpc modules would work,
with something like -l ':mod:nfs' -l ':mod:sunrpc'.

> We have also found that SSD's or at least NAND flash has quite a few write
> latency peculiarities . We use eMMC NAND flash on a few embedded systems we
> have designed and the write latency patterns are a bit random and not well
> described/defined in datasheets etc. Difficult when you have an embedded
> system with small amounts of RAM doing real-time data capture !

That's one of the reasons you want the "enterprise" 

dnf update blocked by dnf-utils

[Przemek Klosowski]

Currently the updates seem to be blocked by a conflict between yum-utils 
and dnf-utils:


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

There are ways to work around it but it's not obvious,  so in the 
interest of resolving this quickly I decided to post here.


TL;DR:

dnf update --skip-broken --best   doesn't help; the only way I could 
find  is:


dnf -y update --exclude=fedora-upgrade

I think an intervention from the packager of dnf-tools or fedora-upgrade 
is required.


As an aside, I guessed which package needs to be excluded, but there 
must be a way to discover it in a more systematic way. From the error 
message I can infer that dnf-utils is to blame, but how do I find out 
which package pulls it in as a dependency?

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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 06/02/18 18:55, J. Bruce Fields wrote:

On Tue, Feb 06, 2018 at 06:49:28PM +, Terry Barnaby wrote:

On 05/02/18 14:52, J. Bruce Fields wrote:

Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a certain
NFS mounted directory over a slow link (NFS over Openvpn over FTTP
80/20Mbps), just after mounting the file system (default NFSv4 mount with
async), it takes about 9 seconds. If I run the same "ls -lR" again, just
after, it takes about 60 seconds.

A wireshark trace might help.

Also, is it possible some process is writing while this is happening?

--b.


Ok, I have made some wireshark traces and put these at:

https://www.beam.ltd.uk/files/files//nfs/

There are other processing running obviously, but nothing that should be
doing anything that should really affect this.

As a naive input, it looks like the client is using a cache but checking the
update times of each file individually using GETATTR. As it is using a
simple GETATTR per file in each directory the latency of these RPC calls is
mounting up. I guess it would be possible to check the cache status of all
files in a dir at once with one call that would allow this to be faster when
a full readdir is in progress, like a "GETATTR_DIR " RPC call. The
overhead of the extra data would probably not affect a single file check
cache time as latency rather than amount of data is the killer.

Yeah, that's effectively what READDIR is--it can request attributes
along with the directory entries.  (In NFSv4--in NFSv3 there's a
seperate call called READDIR_PLUS that gets attributes.)

So the client needs some heuristics to decide when to do a lot of
GETATTRs and when to instead do READDIR.  Those heuristics have gotten
some tweaking over time.

What kernel version is your client on again?

--b.


System is Fedora27, Kernel is: 4.14.16-300.fc27.x86_64 on both client 
and server.


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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 05/02/18 23:06, J. Bruce Fields wrote:

On Thu, Feb 01, 2018 at 08:29:49AM +, Terry Barnaby wrote:

1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE call
all in one. This would reduce the latency of a small file to 1ms rather than
3ms thus 66% faster. Would require the client to delay the OPEN/SETATTR
until the first WRITE. Not sure how possible this is in the implementations.
Maybe READ's could be improved as well but getting the OPEN through quick
may be better in this case ?

2. Could go further with an OPEN-SETATTR-WRITE-CLOSE RPC call. (0.5ms vs
3ms).

The protocol doesn't currently let us delay the OPEN like that,
unfortunately.
Yes, should have thought of that, to focused on network traces and not 
thinking about the program/OS API :)

But maybe  OPEN-SETATTR and SETATTR-CLOSE would be possible.


What we can do that might help: we can grant a write delegation in the
reply to the OPEN.  In theory that should allow the following operations
to be performed asynchronously, so the untar can immediately issue the
next OPEN without waiting.  (In practice I'm not sure what the current
client will do.)

I'm expecting to get to write delegations this year

It probably wouldn't be hard to hack the server to return write
delegations even when that's not necessarily correct, just to get an
idea what kind of speedup is available here.
That sounds good. I will have to read up on NFS write delegations, not 
sure how they work. I guess write() errors would be returned later than 
they actually occurred etc. ?



3. On sync/async modes personally I think it would be better for the client
to request the mount in sync/async mode. The setting of sync on the server
side would just enforce sync mode for all clients. If the server is in the
default async mode clients can mount using sync or async as to their
requirements. This seems to match normal VFS semantics and usage patterns
better.

The client-side and server-side options are both named "sync", but they
aren't really related.  The server-side "async" export option causes the
server to lie to clients, telling them that data has reached disk even
when it hasn't.  This affects all clients, whether they mounted with
"sync" or "async".  It violates the NFS specs, so it is not the default.

I don't understand your proposal.  It sounds like you believe that
mounting on the client side with the "sync" option will make your data
safe even if the "async" option is set on the server side?
Unfortunately that's not how it works.
Well, when a program running on a system calls open(), write() etc. to 
the local disk FS the disk's contents is not actually updated. The data 
is in server buffers until the next sync/fsync or some time has passed. 
So, in your parlance, the OS write() call lies to the program. So it is 
by default async unless the "sync" mount option is used when mounting 
the particular file system in question.


Although it is different from the current NFS settings methods, I would 
have thought that this should be the same for NFS. So if a client mounts 
a file system normally it is async, ie write() data is in buffers 
somewhere (client or server) unless the client mounts the file system in 
sync mode. Only difference from the normal FS conventions I am 
suggesting is to allow the server to stipulate "sync" on its mount that 
forces sync mode for all clients on that FS. I know it is different from 
standard NFS config but it just seems more logical to me :) The 
sync/async option and the ramifications of it are really dependent of 
the clients usage in most cases.


In the case of a /home mount for example, or a source code build file 
system, it is normally only one client that is accessing the dir and if 
a write fails due to the server going down (an unlikely occurrence, its 
not much of an issue. I have only had this happen a couple of times in 
28 years and then with no significant issues (power outage, disk fail 
pre-raid etc.).


I know that is not how NFS currently "works", it just seems illogical to 
me they way it currently does work :)






4. The 0.5ms RPC latency seems a bit high (ICMP pings 0.12ms) . Maybe this
is worth investigating in the Linux kernel processing (how ?) ?

Yes, that'd be interesting to investigate.  With some kernel tracing I
think it should be possible to get high-resolution timings for the
processing of a single RPC call, which would make a good start.

It'd probably also interesting to start with the simplest possible RPC
and then work our way up and see when the RTT increases the most--e.g
does an RPC ping (an RPC with procedure 0, empty argument and reply)
already have a round-trip time closer to .5ms or .12ms?
Any pointers to trying this ? I have a small amount of time as work is 
quiet at the moment.



5. The 20ms RPC latency I see in sync mode needs a look at on my system
although async mode is fine for my usage. Maybe this ends up as 2 x 10ms
drive seeks on ext4 and is thus expected.

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 05/02/18 14:52, J. Bruce Fields wrote:

Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a certain
NFS mounted directory over a slow link (NFS over Openvpn over FTTP
80/20Mbps), just after mounting the file system (default NFSv4 mount with
async), it takes about 9 seconds. If I run the same "ls -lR" again, just
after, it takes about 60 seconds.

A wireshark trace might help.

Also, is it possible some process is writing while this is happening?

--b.


Ok, I have made some wireshark traces and put these at:

https://www.beam.ltd.uk/files/files//nfs/

There are other processing running obviously, but nothing that should be 
doing anything that should really affect this.


As a naive input, it looks like the client is using a cache but checking 
the update times of each file individually using GETATTR. As it is using 
a simple GETATTR per file in each directory the latency of these RPC 
calls is mounting up. I guess it would be possible to check the cache 
status of all files in a dir at once with one call that would allow this 
to be faster when a full readdir is in progress, like a "GETATTR_DIR 
" RPC call. The overhead of the extra data would probably not 
affect a single file check cache time as latency rather than amount of 
data is the killer.



So much for caching ! I have noticed
Makefile based builds (over Ethernet 1Gbps) taking a long time with a second
or so between each directory, I think this maybe why.

Listing the directory using a NFSv3 mount takes 67 seconds on the first
mount and about the same on subsequent ones. No noticeable caching (default
mount options with async), At least NFSv4 is fast the first time !

NFSv4 directory reads after mount:

No. Time   Source Destination   Protocol Length Info
     667 4.560833210    192.168.202.2 192.168.201.1 NFS  304
V4 Call (Reply In 672) READDIR FH: 0xde55a546
     668 4.582809439    192.168.201.1 192.168.202.2 TCP  1405
2049 → 679 [ACK] Seq=304477 Ack=45901 Win=1452 Len=1337 TSval=2646321616
TSecr=913651354 [TCP segment of a reassembled PDU]
     669 4.582986377    192.168.201.1 192.168.202.2 TCP  1405
2049 → 679 [ACK] Seq=305814 Ack=45901 Win=1452 Len=1337 TSval=2646321616
TSecr=913651354 [TCP segment of a reassembled PDU]
     670 4.583003805    192.168.202.2 192.168.201.1 TCP  68
679 → 2049 [ACK] Seq=45901 Ack=307151 Win=1444 Len=0 TSval=913651376
TSecr=2646321616
     671 4.583265423    192.168.201.1 192.168.202.2 TCP  1405
2049 → 679 [ACK] Seq=307151 Ack=45901 Win=1452 Len=1337 TSval=2646321616
TSecr=913651354 [TCP segment of a reassembled PDU]
     672 4.583280603    192.168.201.1 192.168.202.2 NFS  289
V4 Reply (Call In 667) READDIR
     673 4.583291818    192.168.202.2 192.168.201.1 TCP  68
679 → 2049 [ACK] Seq=45901 Ack=308709 Win=1444 Len=0 TSval=913651377
TSecr=2646321616
     674 4.583819172    192.168.202.2 192.168.201.1 NFS  280
V4 Call (Reply In 675) GETATTR FH: 0xb91bfde7
     675 4.605389953    192.168.201.1 192.168.202.2 NFS  312
V4 Reply (Call In 674) GETATTR
     676 4.605491075    192.168.202.2 192.168.201.1 NFS  288
V4 Call (Reply In 677) ACCESS FH: 0xb91bfde7, [Check: RD LU MD XT DL]
     677 4.626848306    192.168.201.1 192.168.202.2 NFS  240
V4 Reply (Call In 676) ACCESS, [Allowed: RD LU MD XT DL]
     678 4.626993773    192.168.202.2 192.168.201.1 NFS  304
V4 Call (Reply In 679) READDIR FH: 0xb91bfde7
     679 4.649330354    192.168.201.1 192.168.202.2 NFS  2408
V4 Reply (Call In 678) READDIR
     680 4.649380840    192.168.202.2 192.168.201.1 TCP  68
679 → 2049 [ACK] Seq=46569 Ack=311465 Win=1444 Len=0 TSval=913651443
TSecr=2646321683
     681 4.649716746    192.168.202.2 192.168.201.1 NFS  280
V4 Call (Reply In 682) GETATTR FH: 0xb6d01f2a
     682 4.671167708    192.168.201.1 192.168.202.2 NFS  312
V4 Reply (Call In 681) GETATTR
     683 4.671281003    192.168.202.2 192.168.201.1 NFS  288
V4 Call (Reply In 684) ACCESS FH: 0xb6d01f2a, [Check: RD LU MD XT DL]
     684 4.692647455    192.168.201.1 192.168.202.2 NFS  240
V4 Reply (Call In 683) ACCESS, [Allowed: RD LU MD XT DL]
     685 4.692825251    192.168.202.2 192.168.201.1 NFS  304
V4 Call (Reply In 690) READDIR FH: 0xb6d01f2a
     686 4.715060586    192.168.201.1 192.168.202.2 TCP  1405
2049 → 679 [ACK] Seq=311881 Ack=47237 Win=1452 Len=1337 TSval=2646321748
TSecr=913651486 [TCP segment of a reassembled PDU]
     687 4.715199557    192.168.201.1 192.168.202.2 TCP  1405
2049 → 679 [ACK] Seq=313218 Ack=47237 Win=1452 Len=1337 TSval=2646321748
TSecr=913651486 [TCP segment of a reassembled PDU]
     688 4.715215055    192.168.202.2 192.168.201.1 TCP  68
679 → 2049 [ACK] Seq=47237 Ack=314555 Win=1444 Len=0 TSval=913651509
TSecr=2646321748
     689 

Re: gnome crashes after today upgrade

[Bruno Wolff III]

On Fri, Feb 02, 2018 at 20:35:25 +,
 Tomasz Kłoczko  wrote:

Hi,

Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..

"journalctl -xe" output is in attachment.


If this is rawhide, you might try downgrading m17n-db* . On one machine 
the latest version is causing lots of applications to crash. On other 
machines it doesn't happen and I don't know what the difference is. 
I'm hoping the gcc8 rebuild will fix things when it happens. Right now I 
don't have much for the maintainer to go on to try to fix things.

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

Re: Wyland is a disaster

[Adam Williamson]

On Tue, 2018-02-06 at 13:37 -0500, Przemek Klosowski wrote:
> I am beginning to think that in pursuit of flexibility and increased 
> functionality we end up making systems that are too complex and too hard 
> to discover. Users with cognitive or physical limitations have 
> increasingly harder time negotiating the technology:

s/Users with cognitive or physical limitations/Users/ ...
-- 
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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Tue, Feb 06, 2018 at 06:49:28PM +, Terry Barnaby wrote:
> On 05/02/18 14:52, J. Bruce Fields wrote:
> > > Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a certain
> > > NFS mounted directory over a slow link (NFS over Openvpn over FTTP
> > > 80/20Mbps), just after mounting the file system (default NFSv4 mount with
> > > async), it takes about 9 seconds. If I run the same "ls -lR" again, just
> > > after, it takes about 60 seconds.
> > A wireshark trace might help.
> > 
> > Also, is it possible some process is writing while this is happening?
> > 
> > --b.
> > 
> Ok, I have made some wireshark traces and put these at:
> 
> https://www.beam.ltd.uk/files/files//nfs/
> 
> There are other processing running obviously, but nothing that should be
> doing anything that should really affect this.
> 
> As a naive input, it looks like the client is using a cache but checking the
> update times of each file individually using GETATTR. As it is using a
> simple GETATTR per file in each directory the latency of these RPC calls is
> mounting up. I guess it would be possible to check the cache status of all
> files in a dir at once with one call that would allow this to be faster when
> a full readdir is in progress, like a "GETATTR_DIR " RPC call. The
> overhead of the extra data would probably not affect a single file check
> cache time as latency rather than amount of data is the killer.

Yeah, that's effectively what READDIR is--it can request attributes
along with the directory entries.  (In NFSv4--in NFSv3 there's a
seperate call called READDIR_PLUS that gets attributes.)

So the client needs some heuristics to decide when to do a lot of
GETATTRs and when to instead do READDIR.  Those heuristics have gotten
some tweaking over time.

What kernel version is your client on again?

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

Re: Wyland is a disaster

[Przemek Klosowski]

On 02/06/2018 11:53 AM, Howard Howell wrote:

On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:

On 02/05/2018 01:35 PM, Howard Howell wrote:

My eyes hurt after a few hours trying to find the smaller and darker default 
cursors.

Do you know that you can simply increase the size of the cursors?

You are on my hero's list.  Somebody figure out how to make this part
of gnome-tweak-tool, PLEASE, or on the accessibility menu.
We older folk need to support each other; let us start the Fedora 
Grandpa Edition :)


Trigger warning: what follows is a rant from an older person in your 
midst. I don't know what's the right solution to the issues I raise, but 
I do think I have a point. I hope the young developers consider these in 
future design decisions.


I am beginning to think that in pursuit of flexibility and increased 
functionality we end up making systems that are too complex and too hard 
to discover. Users with cognitive or physical limitations have 
increasingly harder time negotiating the technology:


 * My 82-year-old dad  has difficulties operating his iPhone simply
   because there are too many options on it
 * on your stereo, is netflix on Fire, Chromecast, Blueray player or
   cable box?

I do like the functionality when it 'just works' but when it doesn't, 
it's often a debacle. There should be a way to dial back the complexity; 
show less options, etc. The old tradeoff was between simple systems with 
limited functionality, and complex but capable systems. Maybe there's a 
way to have both: annotate OS features by how fancy they are, and 
provide a dial that selects more or less of those advanced features, to 
accommodate both power users and those who want a simple, basic, 
utilitarian system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1542666] New: perl-Net-OpenSSH package fails to pull in required IO:: Pty module

[bugzilla]

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

Bug ID: 1542666
   Summary: perl-Net-OpenSSH package fails to pull in required
IO::Pty module
   Product: Fedora
   Version: rawhide
 Component: perl-Net-OpenSSH
  Assignee: steve.tray...@cern.ch
  Reporter: la...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch



perl-Net-OpenSSH needs to have IO::Pty to operate properly. The specfile has:

  Suggests: perl(IO::Pty)

but that is wrong on two counts:

1) IO::Pty is actually just included as a part of IO:Tty

2) The Suggests: isn't "strong enough" to actually get the proper module
installed, so when I try to use Net::OpenSSH, I get this error:


unable to load Perl module IO::Pty: Can't locate IO/Pty.pm in @INC (you may
need to install the IO::Pty module) (@INC contains: /usr/local/lib64/perl5
/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 48)
line 1.
 at /usr/share/perl5/vendor_perl/Net/OpenSSH.pm line 917.

The fix that I found is to change the above Suggests to this:

  Requires: perl(IO::Tty)

Both changes are needed - I tried "Suggests: perl(IO::Tty)" and that didn't get
IO:Tty installed as a dependency.

I'm filing this against rawhide, but the same change needs to be made in F26
and F27.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Jakub Cajka" 

Hi Jakub,

>> And I'm sure any
>> attempt to strip the WIP bits from my side will be met with energetic
>> protests.

> Have you tried that? What make you assume that? I'm sure that if you do it in 
> constructive way, they will be accepted.

My experience with humans is that they get attached to their bits of text even 
when they have no time to finish them. But yes, I haven't tried, I don't want 
to see a wiki page for a month after writing and formatting and revising two 
separate packaging drafts.

> I believe that technically exhausting document is needed as Go packaging is 
> far from trivial. Sure it would be great to have
> (trivial) quick start guide. I think that your proposal fits that bill more 
> than full documentation.

IMHO that's exactly what FPC expects: a quick start document, not an in-depth 
encyclopædia. In-depth is too hardcore to be validated by domain laymen, is 
useless to onboard new packagers (which is the primary objective of Fedora 
guidelines), is never finished because the state of the art changes, and can't 
be applied to check whether a spec is good or not because in-depth concerns 
*complex* cases where the "right" choice is not obvious, depends on many 
factors that change over time, and usually requires asking the domain experts 
directly.

So you have the simple common cases, which are sufficient for most packagers, 
and can be addressed by a formal document FPC can review and enforce, and 
"other things" which are valuable but can not ever attain the formalness and 
strictness level expected of Fedora guidelines, require continuous freedom to 
edit, and are hosted in other Fedora wiki pages. At least that's how real-life 
law is written (law text + expert commentaries) and how other Fedora packaging 
SIGs function and got their guidelines approved.

> They are used primarily to minimize build root size, by reducing the deps 
> size and code size.

Stripping example material from gopath installation filelists achieves the same 
objective without all the complexity of managing packages that share 
directories Go considers indivisible.

>> 7. even core Go people refuse to touch the subject with a 10 foot pole. Sam
>> Boyer tried to demo a very small part of what would be necessary this week
>> end at FOSDEM and this part of his demo *failed*. I don't have the level of
>> Go understanding Sam Boyer Has.

> What has been demoed?? Unfortunately I could not make it there

Sam Boyer presented the current state of his go dep prototype, and explained 
his design choices (for example no nested projects which means the go import 
path root becomes a core concept and it's useless to invest in splitting 
projects as that usually requires nesting). He ended up stating go dep will 
ignore tests by default, tried to demo optional test handling, and that failed. 
He had another conference the next day I couldn't get to as I was stuck in 
another part of the campus.

> Have you met with Jan there?

Unfortunately FOSDEM was its usual crazy stuff with multiple interesting 
conferences at any given time and no hope of being admitted in a room if you're 
late. So I've just been running from conf room to conf room without any hope of 
meeting anyone :(

> Your packaging proposal seems fairly monolithic and disregarding any prior 
> art, so extensions will be very painful.

Well, the creation of the proposal was a long suite of extending to cover more 
cases (that's why some macros are rather long and convoluted), so I'm quite 
sure extension is possible. Of course I may miss something, if you identify a 
roadblock please point it out.

>> You want to test one of my packages, fine, just rebuild it. That will run
>> unit tests *and* build the project binaries (which are also a form of code
>> testing, and a very thorough one at that).

> I don't think that is great user experience nor packagers/maintainers 
> experience.

That's pretty much how rpm prefers it to be (use %check and Builddeps) and also 
how Go prefers it to be (no provision for splitting directories). Of course 
anyone interested can try to fight the design of both of them to achieve 
something else, and would try to help, but I'm not interested in being this 
person.

>> > and shipping pre-built shared libraries.
>> 
>> The pre-build shared libraries the old guidelines refuse to build or
>> document? Why exactly are you stating it's a major use case, Fedora is not
>> doing it today. 

> ?? I'm bit confused. Yes, it is not mentioned there yet as Jan have been 
> working on stabilizing APIs, so it will be feasible
> and added there.

My maybe naïve POW is that shared libraries are just another container for the 
elements currently installed in %gopath/src, so doing them is mostly adding a 
separate stage in %build and making %goinstall install the result instead of 
installing raw files. 

The hardest part is to get compatible code bases, defining what needs stripping 
in 

Re: Review swaps

[Ben Rosser]

On Tue, Feb 6, 2018 at 1:09 PM, Robert-André Mauchin  wrote:
> Hello,
>
> I have a handful of packages that I'd like to be reviewed. I'm available for
> any reviews you want in exchange (to the best of my ability).

Hello,

I'm happy to take ddgr and QEverCloud. Are you willing to review the
following in exchange?

ocaml-lambda-term: https://bugzilla.redhat.com/show_bug.cgi?id=1538259

bitlbee-discord: https://bugzilla.redhat.com/show_bug.cgi?id=1542663

> Bug 4769 - Review Request: qtox - Feature-rich Tox client
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4769

I am a member of RPM Fusion-- would you care to take dwarftherapist
(https://bugzilla.rpmfusion.org/show_bug.cgi?id=4059) in exchange for
this one too?

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

Re: Orphaned packages seeking new point of contact

[Michael Schwendt]

On Mon, 5 Feb 2018 07:42:45 -0500, Josh Boyer wrote:

> >> rpms/gqview  
> >
> > Really?!  
> 
> Congratulations, you have just explained why absentee maintainers are
> bad and why we orphan things.

No. I've only shown how surprised I am to discover that it is an orphan
in the Fedora package collection for many years. Or that maybe somebody
has adapted it despite the dead.package message I had added many years
ago:

  https://src.fedoraproject.org/cgit/rpms/gqview.git/plain/dead.package

Till Maas has found the culprit apparently.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

[Robert-André Mauchin]

Hello,

I have a handful of packages that I'd like to be reviewed. I'm available for 
any reviews you want in exchange (to the best of my ability).

 - This package was requested by Artur Iwicki on the list:

Review Request: jid - Json Incremental Digger
https://bugzilla.redhat.com/show_bug.cgi?id=1525698

 - These twos are needed to update micro in Rawhide:

Review Request: golang-github-zyedidia-terminal - Vt10x terminal emulation 
backend
https://bugzilla.redhat.com/show_bug.cgi?id=1539189

Review Request: golang-github-zyedidia-pty - PTY interface for Go 
https://bugzilla.redhat.com/show_bug.cgi?id=1539189

 - Simple shell tool to search on Duck Duck Go from the terminal:

Review Request: ddgr - DuckDuckGo from the terminal 
https://bugzilla.redhat.com/show_bug.cgi?id=1539209

 - Python tool to work on multiple archive formats with simple commands:

Review Request: patool - Portable command line archive file manager
https://bugzilla.redhat.com/show_bug.cgi?id=1542646

 - Quentier: a C++ Evernote client. It's still alpha software but already 
usable.

Review Request: quentier - Cross-platform desktop Evernote client
https://bugzilla.redhat.com/show_bug.cgi?id=1542654

   It depends on two libraries:

Review Request: QEverCloud - Unofficial Evernote Cloud API for Qt5
https://bugzilla.redhat.com/show_bug.cgi?id=1542650

Review Request: libquentier - Set of Qt/C++ APIs for feature rich desktop 
clients for Evernote service
https://bugzilla.redhat.com/show_bug.cgi?id=1542651

 - Also if you're a member of RPMFusion I wouldn't mind some love for my first 
package over there:

Bug 4769 - Review Request: qtox - Feature-rich Tox client
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4769

Thanks to all!

Best regards,

Robert-André


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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2018-02-07 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
The EPEL Steering Committee will have a weekly meeting to cover current tasks 
and problems needed to keep EPEL going.


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

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

Re: Wyland is a disaster

[Mathieu Bridon]

On Tue, 2018-02-06 at 08:53 -0800, Howard Howell wrote:
> On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
> > On 02/05/2018 01:35 PM, Howard Howell wrote:
> > > My eyes hurt
> > > after a few hours trying to find the smaller and darker default
> > > cursors.
> > 
> > Do you know that you can simply increase the size of the cursors?
> > 
> > dconf write /org/gnome/desktop/interface/cursor-size 48
> > 
> > I swear I saw it in one of GNOME GUI tools but I can't find it now 
> > (doesn't seem to be in Settings or Gnome-tweaks)
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> You are on my hero's list.  Somebody figure out how to make this part
> of gnome-tweak-tool, PLEASE, or on the accessibility menu.

In GNOME Settings 3.26.2, go to "Universal Access" then change the
"Cursor Size" option.


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

Re: Wyland is a disaster

[Howard Howell]

On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
> On 02/05/2018 01:35 PM, Howard Howell wrote:
> > My eyes hurt
> > after a few hours trying to find the smaller and darker default
> > cursors.
> 
> Do you know that you can simply increase the size of the cursors?
> 
> dconf write /org/gnome/desktop/interface/cursor-size 48
> 
> I swear I saw it in one of GNOME GUI tools but I can't find it now 
> (doesn't seem to be in Settings or Gnome-tweaks)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
You are on my hero's list.  Somebody figure out how to make this part
of gnome-tweak-tool, PLEASE, or on the accessibility menu.

Thank YOU!!!
Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Issue 48085 - Add encryption cl5 test suite

[Simon Pichugin]

Hi team, please, review my rework of Sankar's patch.

https://pagure.io/389-ds-base/issue/48085
https://pagure.io/389-ds-base/issue/raw/files/f78334baf6bc2eab6b9566f79aa2321b262ac604ff6b1a32dba7bf806376-0001-Issue-48085-Add-encryption-cl5-test-suite.patch

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

[Bug 1537517] perl-threads-shared-1.58 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc27 has been pushed to the Fedora 27 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

[Bug 1537516] perl-threads-2.21 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-threads-2.21-1.fc27 has been pushed to the Fedora 27 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

[Bug 1538075] perl-String-Print-0.93 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-String-Print-0.93-1.fc27 has been pushed to the Fedora 27 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

[Bug 1486717] abi-compliance-checker-2.2 is available

[bugzilla]

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



--- Comment #20 from Fedora Update System  ---
abi-compliance-checker-2.2-1.fc27, abi-dumper-1.1-1.fc27,
abi-tracker-1.11-1.fc27 has been pushed to the Fedora 27 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

Re: gnome crashes after today upgrade

[Tomasz Kłoczko]

On 6 February 2018 at 11:48, Sam Varshavchik  wrote:
[..]

> Never had xfce4-notifyd crash on me. Not sure what mission-control is. I
> have chrome running on my Ubuntu laptop, also XFCE desktop, never had it
> crash either.
>

Thiis process is part of the telepathy-mission-control package. It crashed
when I've been trying to use polari Gnome IRC client under xfce.
Looks like this crach has nothing to do with xfce per se, however xfce4-notifyd
looks like it is part of of te xfce.

More details about this process crashes:

Feb 06 10:41:23 domek xfce4-notifyd[23486]: malloc_consolidate(): invalid
chunk size
Feb 06 10:41:29 domek systemd[1]: Started Process Core Dump (PID 30009/UID
0).
-- Subject: Unit systemd-coredump@4-30009-0.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-coredump@4-30009-0.service has finished starting up.
-- 
-- The start-up result is RESULT.
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Main process
exited, code=dumped, status=6/ABRT
Feb 06 10:41:36 domek dbus-daemon[5457]: [session uid=1000 pid=5457]
Activating via systemd: service name='org.freedesktop.Notifications'
unit='xfce4-notifyd.service' requested by ':1.42' (uid=1000 pid=5534
comm="/usr/share/skypeforlinux/skypeforlinux --executed-")
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Failed with
result 'core-dump'.
Feb 06 10:41:36 domek systemd[5399]: Starting XFCE notifications service...
-- Subject: Unit UNIT has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit UNIT has begun starting up.

And gdb stack back trace:

Core was generated by `/usr/lib64/xfce4/notifyd/xfce4-notifyd'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50   return ret;
[Current thread is 1 (Thread 0x7f1b8aa59a80 (LWP 23486))]
(gdb) bt
#0  0x7f1b871f0f6b in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f1b871db591 in __GI_abort () at abort.c:79
#2  0x7f1b87233cab in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f1b8733d95e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f1b8723a1dc in malloc_printerr (str=str@entry=0x7f1b8733f208
"malloc_consolidate(): invalid chunk size") at malloc.c:5353
#4  0x7f1b8723a4da in malloc_consolidate (av=av@entry=0x7f1b87573c40
) at malloc.c:
#5  0x7f1b8723d0a0 in _int_malloc (av=av@entry=0x7f1b87573c40
, bytes=bytes@entry=1352) at malloc.c:3706
#6  0x7f1b8723f5f2 in __libc_calloc (n=n@entry=1,
elem_size=elem_size@entry=1352) at malloc.c:3439
#7  0x7f1b877e9511 in g_malloc0 (n_bytes=n_bytes@entry=1352) at
gmem.c:124
#8  0x7f1b89844ea3 in _gtk_css_lookup_new (relevant=relevant@entry=0x0)
at gtkcsslookup.c:32
#9  0x7f1b898596b3 in gtk_css_static_style_new_compute
(provider=0x7f1b6c00e900, matcher=matcher@entry=0x7fffcfbfff40,
parent=parent@entry=0x0)
at gtkcssstaticstyle.c:183
#10 0x7f1b898475b4 in gtk_css_node_create_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:371
#11 0x7f1b898475b4 in gtk_css_node_real_update_style
(cssnode=0x5640f830aaa0 [GtkCssWidgetNode], change=135, timestamp=0,
style=0x5640f813a040 [GtkCssStaticStyle]) at gtkcssnode.c:425
#12 0x7f1b898463a4 in gtk_css_node_ensure_style
(cssnode=cssnode@entry=0x5640f830aaa0
[GtkCssWidgetNode], current_time=0) at gtkcssnode.c:1007
#13 0x7f1b898465b6 in gtk_css_node_ensure_style
(current_time=, cssnode=0x5640f830aaa0 [GtkCssWidgetNode])
at gtkcssnode.c:992
#14 0x7f1b898465b6 in gtk_css_node_get_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:1033
#15 0x7f1b899a890b in gtk_style_context_lookup_style
(context=0x5640f8172f90 [GtkStyleContext]) at gtkstylecontext.c:493
#16 0x7f1b899a890b in _gtk_style_context_peek_style_property
(context=context@entry=0x5640f8172f90 [GtkStyleContext],
widget_type=94837039369344, pspec=0x7f1b680041e0 [GParamDouble]) at
gtkstylecontext.c:1635
#17 0x7f1b89a5320c in gtk_widget_style_get_valist
(widget=widget@entry=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding", var_args=var_args@entry=0x7fffcfc00160) at gtkwidget.c:13248
#18 0x7f1b89a53598 in gtk_widget_style_get (widget=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding")
at gtkwidget.c:13286
#19 0x5640f67493cd in xfce_notify_window_init (window=0x5640f81242f0
[XfceNotifyWindow]) at xfce4-notifyd/xfce-notify-window.c:227
#20 0x7f1b87ae22c5 in g_type_create_instance (type=94837039369344) at
gtype.c:1866
#21 0x7f1b87ac2518 in g_object_new_internal
(class=class@entry=0x5640f8112820,
params=params@entry=0x7fffcfc00570, n_params=n_params@entry=1) at
gobject.c:1797
#22 0x7f1b87ac445e in g_object_new_valist 

Re: F27 strange rpmbuild failure

[Sérgio Basto]

On Tue, 2018-02-06 at 09:07 -0500, Steve Grubb wrote:
> On Tuesday, February 6, 2018 8:50:17 AM EST Sérgio Basto wrote:
> > On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
> > > On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
> > > > > I think the basic answer is that the byte comoilation script
> > > > > is
> > > > > using  all sorts of strange heuristics. It seems that it
> > > > > determined a
> > > > > that a non-python file was python.
> > > > > 
> > > > > Efforts are under way to redefine things and make the byte
> > > > > compilation more explicit. Until this is done, this is
> > > > > probably not
> > > > > the last error of this sort.
> > > > > 
> > > > > In other words, it's sort of a known bug with fixes under
> > > > > way,
> > > > > slowly...
> > > > 
> > > > I'd like to make sure any Python-related automation is limited
> > > > to
> > > > Python context (/usr/lib*/python*, files with python shebangs,
> > > > etc.).
> > > > I'm not sure why it's not this way now.
> > > > 
> > > > We're preparing a Change to fix this exact issue in Fedora 29.
> > > > Started  just last week, actually:
> > > > https://fedoraproject.org/wiki/Changes/No_more_automagic_Python
> > > > _byt
> > > > ecompilation
> > > > 
> > > > Up to this point I thought this was just a theoretical issue.
> > > > Thank
> > > > you for finding a concrete example -- and sorry it had to be
> > > > you!
> > > 
> > > 
> > > OK. RStudio failing to build was an irritation. Now I have a
> > > serious
> > > problem. The python byte compiler is preventing akmods from
> > > building
> > > kernel modules leaving me with a near unusable system.
> > > 
> > > 2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25
> > > 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16-
> > > 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64
> > > 2018/02/06 07:09:32 akmodsbuild: + mkdir -p
> > > /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> > > 1.fc27.x86_64//usr/lib/modules//4.14.16-
> > > 300.fc27.x86_64//extra/nvidia//
> > > 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755
> > > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko
> > > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko
> > > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko
> > > _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko
> > > /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> > > 1.fc27.x86_64//usr/lib/modules//4.14.16-
> > > 300.fc27.x86_64//extra/nvidia//
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip
> > > /usr/bin/strip
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-
> > > comment-
> > > note /usr/bin/strip /usr/bin/objdump
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static-
> > > archive /usr/bin/strip
> > > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python-
> > > bytecompile /usr/bin/python 1
> > > 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from
> > > /var/tmp/rpm-tmp.5l5Sxs (%install)
> > > 
> > > The issue is this, today a new nvidia driver was release via
> > > rpmfusion. Now my user space does not match kernel modules.
> > > Kernel
> > > modules are failing to build as noted above. When it boots. it
> > > detects
> > > this mismatch and refuses to work.
> > > 
> > > Is there a way to suppress this to get kernel modules to build?
> > 
> > hum haven't you a modified version of rpm-build [1] in your
> > computer ?
> > 
> > [1] rpm -qf /usr/lib/rpm/brp-python-bytecompile -V
> 
> Nope. The whole package passes verification.
> 
> [root@x2 ~]# rpm -qV rpm-build-4.14.0-2.fc27.x86_64
> [root@x2 ~]#
> 
> Any way to generate troubleshooting info to help figure out what's
> wrong? Any 
> good way to suppress this so akmods works?


I tested yesterday akmods of VirtualBox on rawhide without any problem,
So I may deduce that should work also with nvidia and therefore also
may I deduce that is a local issue ... .

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

Re: F27 strange rpmbuild failure

[Steve Grubb]

On Tuesday, February 6, 2018 8:50:17 AM EST Sérgio Basto wrote:
> On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
> > On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
> > > > I think the basic answer is that the byte comoilation script is
> > > > using  all sorts of strange heuristics. It seems that it determined a
> > > > that a non-python file was python.
> > > > 
> > > > Efforts are under way to redefine things and make the byte
> > > > compilation more explicit. Until this is done, this is probably not
> > > > the last error of this sort.
> > > > 
> > > > In other words, it's sort of a known bug with fixes under way,
> > > > slowly...
> > > 
> > > I'd like to make sure any Python-related automation is limited to
> > > Python context (/usr/lib*/python*, files with python shebangs, etc.).
> > > I'm not sure why it's not this way now.
> > > 
> > > We're preparing a Change to fix this exact issue in Fedora 29.
> > > Started  just last week, actually:
> > > https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_byt
> > > ecompilation
> > > 
> > > Up to this point I thought this was just a theoretical issue. Thank
> > > you for finding a concrete example -- and sorry it had to be you!
> > 
> > 
> > OK. RStudio failing to build was an irritation. Now I have a serious
> > problem. The python byte compiler is preventing akmods from building
> > kernel modules leaving me with a near unusable system.
> > 
> > 2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25
> > 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16-
> > 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64
> > 2018/02/06 07:09:32 akmodsbuild: + mkdir -p
> > /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> > 1.fc27.x86_64//usr/lib/modules//4.14.16-
> > 300.fc27.x86_64//extra/nvidia//
> > 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755
> > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko
> > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko
> > _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko
> > _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko
> > /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> > 1.fc27.x86_64//usr/lib/modules//4.14.16-
> > 300.fc27.x86_64//extra/nvidia//
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip
> > /usr/bin/strip
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment-
> > note /usr/bin/strip /usr/bin/objdump
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static-
> > archive /usr/bin/strip
> > 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python-
> > bytecompile /usr/bin/python 1
> > 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from
> > /var/tmp/rpm-tmp.5l5Sxs (%install)
> > 
> > The issue is this, today a new nvidia driver was release via
> > rpmfusion. Now my user space does not match kernel modules. Kernel
> > modules are failing to build as noted above. When it boots. it detects
> > this mismatch and refuses to work.
> > 
> > Is there a way to suppress this to get kernel modules to build?
> 
> hum haven't you a modified version of rpm-build [1] in your computer ?
> 
> [1] rpm -qf /usr/lib/rpm/brp-python-bytecompile -V

Nope. The whole package passes verification.

[root@x2 ~]# rpm -qV rpm-build-4.14.0-2.fc27.x86_64
[root@x2 ~]#

Any way to generate troubleshooting info to help figure out what's wrong? Any 
good way to suppress this so akmods works?

-Steve

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

Re: F27 strange rpmbuild failure

[Sérgio Basto]

On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
> On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
> > > I think the basic answer is that the byte comoilation script is
> > > using
> > > all sorts of strange heuristics. It seems that it determined a
> > > that a
> > > non-python file was python.
> > > 
> > > Efforts are under way to redefine things and make the byte
> > > compilation
> > > more explicit. Until this is done, this is probably not the last
> > > error
> > > of this sort.
> > > 
> > > In other words, it's sort of a known bug with fixes under way,
> > > slowly...
> > 
> > I'd like to make sure any Python-related automation is limited to
> > Python
> > context (/usr/lib*/python*, files with python shebangs, etc.). I'm
> > not
> > sure why it's not this way now.
> > 
> > We're preparing a Change to fix this exact issue in Fedora 29.
> > Started
> > just last week, actually:
> > https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_byt
> > ecompila
> > tion
> > 
> > Up to this point I thought this was just a theoretical issue. Thank
> > you
> > for finding a concrete example -- and sorry it had to be you!
> 
> OK. RStudio failing to build was an irritation. Now I have a serious
> problem.
> The python byte compiler is preventing akmods from building kernel
> modules
> leaving me with a near unusable system.
> 
> 2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25
> 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16-
> 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64
> 2018/02/06 07:09:32 akmodsbuild: + mkdir -p
> /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> 1.fc27.x86_64//usr/lib/modules//4.14.16-
> 300.fc27.x86_64//extra/nvidia//
> 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755
> _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko
> _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko
> _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko
> _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko
> /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-
> 1.fc27.x86_64//usr/lib/modules//4.14.16-
> 300.fc27.x86_64//extra/nvidia//
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip
> /usr/bin/strip
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment-
> note /usr/bin/strip /usr/bin/objdump
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static-
> archive /usr/bin/strip
> 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python-
> bytecompile /usr/bin/python 1
> 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from
> /var/tmp/rpm-tmp.5l5Sxs (%install)
> 
> The issue is this, today a new nvidia driver was release via
> rpmfusion. Now my
> user space does not match kernel modules. Kernel modules are failing
> to build
> as noted above. When it boots. it detects this mismatch and refuses
> to work.
> 
> Is there a way to suppress this to get kernel modules to build?

hum 
haven't you a modified version of rpm-build [1] in your computer ?


[1]

rpm -qf /usr/lib/rpm/brp-python-bytecompile -V

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

Re: F27 strange rpmbuild failure

[Steve Grubb]

On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
> > I think the basic answer is that the byte comoilation script is using
> > all sorts of strange heuristics. It seems that it determined a that a
> > non-python file was python.
> > 
> > Efforts are under way to redefine things and make the byte compilation
> > more explicit. Until this is done, this is probably not the last error
> > of this sort.
> > 
> > In other words, it's sort of a known bug with fixes under way, slowly...
> 
> I'd like to make sure any Python-related automation is limited to Python
> context (/usr/lib*/python*, files with python shebangs, etc.). I'm not
> sure why it's not this way now.
> 
> We're preparing a Change to fix this exact issue in Fedora 29. Started
> just last week, actually:
> https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila
> tion
> 
> Up to this point I thought this was just a theoretical issue. Thank you
> for finding a concrete example -- and sorry it had to be you!

OK. RStudio failing to build was an irritation. Now I have a serious problem.
The python byte compiler is preventing akmods from building kernel modules
leaving me with a near unusable system.

2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25
2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 
4.14.16-300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64
2018/02/06 07:09:32 akmodsbuild: + mkdir -p 
/tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-1.fc27.x86_64//usr/lib/modules//4.14.16-300.fc27.x86_64//extra/nvidia//
2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755 
_kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko 
_kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko 
_kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko 
_kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko 
/tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-1.fc27.x86_64//usr/lib/modules//4.14.16-300.fc27.x86_64//extra/nvidia//
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip /usr/bin/strip
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment-note 
/usr/bin/strip /usr/bin/objdump
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static-archive 
/usr/bin/strip
2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python-bytecompile 
/usr/bin/python 1
2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from 
/var/tmp/rpm-tmp.5l5Sxs (%install)

The issue is this, today a new nvidia driver was release via rpmfusion. Now my
user space does not match kernel modules. Kernel modules are failing to build
as noted above. When it boots. it detects this mismatch and refuses to work.

Is there a way to suppress this to get kernel modules to build?

-Steve

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 937  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 827  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 799  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 409  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 139  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  58  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1049ca4872   
GraphicsMagick-1.3.28-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-369a48191f   
clamav-0.99.3-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab   
tomcat-7.0.84-1.el6


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

picosat-965-2.el6
python-pycosat-0.6.3-1.el6
xrootd-4.8.1-1.el6

Details about builds:



 picosat-965-2.el6 (FEDORA-EPEL-2018-34e7c7b68b)
 A SAT solver

Update Information:

Update to 965:  * ADC code works again (spotted by Himanshu Jain) * fixed
'undefined' + 'ptrdiff_' issues (thanks to Christoph Muessel) * added
'picosat_set_interrupt' and '-a ' command line option * fixed various
issues pointed out by Stefan Hengelein:   - fixed incremental usage of
'picosat_adjust'   - added CPP fixes (STATS, NO_BINARY_CLAUSE versus TRACE mix-
ups)   - removed redundant explicit set to zero on reset * fixed various usage
bugs with 'picomus' (thanks to Stefan Hengelein) * removed '-fno-strict-
aliasing' (thanks to Jerry James)




 python-pycosat-0.6.3-1.el6 (FEDORA-EPEL-2018-7cbca56a2a)
 Python bindings to picosat (a SAT solver)

Update Information:

Update to 0.6.3:  * fix some typos * add official Python 3.5 and 3.6




 xrootd-4.8.1-1.el6 (FEDORA-EPEL-2018-27181c406f)
 Extended ROOT file server

Update Information:

## Version 4.8.1  **Major bug fixes*** **[XrdCl]** Try all IP addresses in
case posix connect fails.   * **[XrdCl]** Fix checksuming in xrdcp for local
files.   * **[Py]** Make sure FileSystem::Copy returns a tuple, fixes #633.   *
**[Py]** Make sure empty strings are not converted to None.   * **[SSI]** Unbind
the request prior to teardown.   * **[SSI]** Avoid SEGV when generating a
request for a new TCPconnection.   * **[SSI]** Fix race
condition that can cause a SEGV during parallelexecution.   *
**[SSI]** Allow zero length requests to be passed to servers.
Fixes #640   * **[SSI]** Make sure to avoid object refs after Finished() is
called   to avoid SEGV.  **Minor bug fixes*** **[XrdPosix]** Fix
various memory related issues.   * **[XrdCrypto]** Fix various small issues.   *
**[Server]** Fix overlapping string copy. Fixes #643   * **[XrdCl]** Provide
compatibility between root://localfile and file://.

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

[Bug 1392472] root is not built for ppc64

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|root-6.12.04-1.fc26 |root-6.12.04-1.fc26
   |root-6.12.04-1.fc27 |root-6.12.04-1.fc27
   ||root-6.12.04-1.el7



--- Comment #11 from Fedora Update System  ---
root-6.12.04-1.el7 has been pushed to the Fedora EPEL 7 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

[Bug 1392478] root is not built for ppc64le

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|root-6.12.04-1.fc26 |root-6.12.04-1.fc26
   |root-6.12.04-1.fc27 |root-6.12.04-1.fc27
   ||root-6.12.04-1.el7



--- Comment #10 from Fedora Update System  ---
root-6.12.04-1.el7 has been pushed to the Fedora EPEL 7 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

Re: Upstream installs AppData file in /usr/share/appdata

[Rex Dieter]

Samuel Rakitničan wrote:

>> Submit a PR upstream to fix it, and use that patch to change it locally.
> So I did, upstream accepted it, but then it applied old location again. As
> it is noted in patch description for compatibility reasons. Now
> application installs on both locations.
> 
> Should I remove now this files from the old location or they can stay?

You should install only one

-- Rex

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

[Bug 1542279] perl-Gearman-2.004.0013 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1540220] perl-Gearman-Client-Async-0.94-28.fc28 FTBFS: Timeout, test fails at t/allinone.t line 62.

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1065  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 827  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 409  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 307  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 139  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  76  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ce6223e559   
GraphicsMagick-1.3.28-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9eb18da891   
moodle-3.1.10-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0d5d190b0   
transmission-2.92-12.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd0bc449d7   
konversation-1.5.1-4.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fb68becde7   
w3m-0.5.3-36.git20180125.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-18ea640f19   
tomcat-native-1.2.16-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f09712d924   
pdns-3.4.11-4.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ac86cef06d   
p7zip-16.02-9.el7


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

adapta-gtk-theme-3.93.0.110-1.el7
dd_rescue-1.99.8-1.el7
jhead-3.00-7.el7
picosat-965-2.el7
python-pycosat-0.6.3-1.el7
xrootd-4.8.1-1.el7
yara-3.7.1-1.el7

Details about builds:



 adapta-gtk-theme-3.93.0.110-1.el7 (FEDORA-EPEL-2018-d906c9d977)
 An adaptive Gtk+ theme based on Material Design Guidelines

Update Information:

- New upstream release

References:

  [ 1 ] Bug #1540388 - adapta-gtk-theme-3.93.0.103 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1540388
  [ 2 ] Bug #1539334 - adapta-gtk-theme-3.93.0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1539334
  [ 3 ] Bug #1537086 - adapta-gtk-theme-3.93.0.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1537086
  [ 4 ] Bug #1542020 - adapta-gtk-theme-3.93.0.110 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1542020




 dd_rescue-1.99.8-1.el7 (FEDORA-EPEL-2018-ca8d3ed459)
 Fault tolerant "dd" utility for rescuing data from bad media

Update Information:

bump to bug-fix release 1.99.8




 jhead-3.00-7.el7 (FEDORA-EPEL-2018-7134fc92a1)
 Tool for displaying EXIF data embedded in JPEG images

Update Information:

Added Debian patch to fix CVE-2018-6612 (#1542049)

References:

  [ 1 ] Bug #1542049 - CVE-2018-6612 jhead: Integer underflow in the 
process_EXIF function
https://bugzilla.redhat.com/show_bug.cgi?id=1542049




 picosat-965-2.el7 (FEDORA-EPEL-2018-b7f79cbe39)
 A SAT solver

Update Information:

Update to 965:  * ADC code works again (spotted by Himanshu Jain) * fixed
'undefined' + 'ptrdiff_' issues (thanks to Christoph Muessel) * added
'picosat_set_interrupt' and '-a ' command line option * fixed various
issues pointed out by Stefan Hengelein:   - fixed incremental usage of
'picosat_adjust'   - added CPP fixes (STATS, NO_BINARY_CLAUSE versus TRACE mix-
ups)   - removed redundant explicit set to zero on reset * fixed various usage
bugs with 'picomus' (thanks to Stefan Hengelein) * removed '-fno-strict-
aliasing' (thanks to Jerry James)

Re: gnome crashes after today upgrade

[Sam Varshavchik]

Tomasz Kłoczko writes:

-- after only 3-4h on m primary desktop I've been able to collect descent  
number of core files




# ls -la /var/lib/systemd/coredump/*
-rw-r-+ 1 root root 1628938240 Feb  6 03:28  
/var/lib/systemd/coredump/core.chrome. 
1000.9b34b2ba89514d86a302484519bf2a53.14303.151788763700
-rw-r-+ 1 root root   37933056 Feb  6 04:10  
/var/lib/systemd/coredump/core.mission-control. 
1000.ad37f99486c24da58887b80804c84322.9243.151789023300


-rw-r-+ 1 root root   28282880 Feb  6 03:34  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.2398.151788803900


-rw-r-+ 1 root root   32505856 Feb  6 04:27  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.5645.151789125800


Never had xfce4-notifyd crash on me. Not sure what mission-control is. I  
have chrome running on my Ubuntu laptop, also XFCE desktop, never had it  
crash either.




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

[Bug 1539470] perl-SNMP-Info-3.43 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-SNMP-Info-3.43-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|w...@gouldfamily.org|jples...@redhat.com
Last Closed||2018-02-06 06:47:39



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1540510] Upgrade perl-SQL-Abstract to 1.85

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-SQL-Abstract-1.85-1.fc
   ||28
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |jples...@redhat.com
Last Closed||2018-02-06 06:28:03



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> 
> Sent: Monday, February 5, 2018 3:27:01 PM
> Subject: Re: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> > Our as Fedora or yours company/org? I believe that your contribution of
> > those in to Fedora will be much
> > appreciated.
> 
> Our was meaning the set of specs we are preparing for inclusion. Can't really
> share them before the macros they depend on are merged in rawhide.
> 
> You can grab most of those from
> https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging
> 
> before I nuke it to launch a new build from scratch (if seems a bit of grpc
> bootstraping failed this run so that's back to build log analysis, add
> constrains, scratch, retry, wait 3 days for the result. I s hate the yum
> version in copr, every time there is a dumb decision to make it will make
> it, it manages to make yum in EL7 look smart)

You have to explicit about the specs, TBH I have had more fun with dnf, when it 
fist came out.

I believe that you can already open pull requests and review requests stating 
the dependency(so it doesn't get merger too soon) as it will take it some time 
to merge and details can get ironed out during merging/review. As IMHO your 
guidelines will require whole distro change/rebuild to make it compliant. I 
feel like you haven't been engaging with current maintainers much.

JC

> 
> > But IMHO even your changes will not change this, if you don't have few
> > dedicated packager around to
> > do all the bidding.
> 
> Sure, the changes will only remove some barriers to new Go packagers, they
> can't replace those packagers, or the people who take care of the baseline
> core.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> , "Discussion of RPM packaging
> standards and practices for Fedora" 
> Sent: Monday, February 5, 2018 4:48:31 PM
> Subject: Re: Proposed Fedora packaging guideline:  More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> Hi Jakub
> 
> > I think that it would be best if Nicolas could fold his proposal in to the
> > original draft as
> > optional part for simple library/binary packages.
> 
> Frankly, that's a lot of work and churn, I don't want the new parts to be
> refused because of something in the old parts, and I certainly do not want
> to spend weeks replacing bits only to put them back in and so on while
> people made up their mind on the things they want replaced or not. The new
> parts are pretty much autonomous and complete, they are sufficient to create
> working Fedora Go packages, they are ready for FPC review.
> 
> If someone wants to extract the ready non discussion parts of the old page
> and get them approved I can work with him to merge both elements
> 
> I didn't want to write about the old page, but since you put it on the table.
> 
> It is full of digressions and elements of no evident applied value while
> packaging Go software. It's not an operational "how to do stuff" document
> it's a "here are various things you may like to know about Go that may or
> may not help you create Fedora Go packages, if they do not help you forget
> about it and run gofed". There are too many WIP non operational bits in the
> old pages to allow merging while in an approval process. And I'm sure any
> attempt to strip the WIP bits from my side will be met with energetic
> protests.

Have you tried that? What make you assume that? I'm sure that if you do it in 
constructive way, they will be accepted.

> 
> People, if you want that page to be ever approved by FPC make it more focused
> and accurate. Remove anything that does not explain to a Fedora Go packager
> how to write a Fedora Go spec file and what to ask upstream Go projects in a
> Fedora packager role. And make sure what remains is succinct, easy to read,
> and applicable without undocumented holes or gofed magic.

I believe that technically exhausting document is needed as Go packaging is far 
from trivial. Sure it would be great to have (trivial) quick start guide. I 
think that your proposal fits that bill more than full documentation.

> 
> I know that's a lot of non-fun work. I did this work on the new page. I don't
> particularly *like* writing documentation. For every line I put in the new
> page, I had to ask myself "is the value to the Fedora packager sufficient to
> justify the time spend writing the text, formatting it, linking in the right
> place, proofing the result". I didn't put in stuff I could not justify
> cleaning up myself. If it was too much work to document it was either of
> insufficient value or better automated rather than explained in a manual
> process.
> 
> Any part of the text that can not be finished or serves another role has no
> place in a guideline submitted to FPC. It should be nuked or moved to a
> separate wiki page. All the half-finished and non operational stuff in there
> is the reason the draft has been stuck in pre-approval stage for four years.
> Just put yourself in FPC's place, its mission is to confirm a guideline is
> ready to be used by the average Fedora packager, not to produce it from
> half-finished half-related messy notes of the domain experts.

I believe I can see myself in their shoes(sure not 100% accurately) and I don't 
see anything that you are describing from their POV, it would be good to have 
the guidelines sooner, but I will have, as you, rather something complete than 
something half baked and semi broken. Please note that they are WIP and 
everybody is welcomed to contribute in constructive way. I don't think that 
there is any request for FPC to create the guidelines on their own and honestly 
it would rather bad idea IMHO.

> 
> > As his proposal doesn't cover at least two major use cases, i.e. separate
> > packaging of tests(they
> > have no place in devel package as they artificially inflate build root
> > size)
> 
> At this point of time my mind is pretty much set. I won't do separate
> packaging of tests because:
> 1. that raises complex dependency handling questions
> 2. the average Go project test code is full of crufty junk
> 3. the average Go test depends on assets not tracked within Go
> 4. Go is not designed to separate elements shipped in the same directory
> 5. no one could answer when I asked the *three* Fedora lists what they were
> using the existing test packages for

They are used primarily to minimize build root size, by reducing the deps size 
and code size.

> 6. from what I've seen many of 

Re: Orphaned packages seeking new point of contact

[Till Maas]

On Mon, Feb 05, 2018 at 07:42:45AM -0500, Josh Boyer wrote:
> On Fri, Feb 2, 2018 at 3:22 PM, Michael Schwendt  wrote:
> > On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
> >
> >> rpms/gqview

> > It is unmaintained for over 10 years.
> >
> > It has been forked into Geeqie (package "geeqie") roughly 10 years
> > ago, and Geeqie at least has seen several releases since then.
> 
> Perhaps just take gqview and retire it then?

Actually Michael retired in 2010 for Fedora. jcapik maintained it in
EPEL 6 according to pkgdb [0]. This inofrmation does not seem to have been
migrated afaics:

https://pagure.io/releng/fedora-scm-requests/raw/master/f/rpms/gqview
should say that jcapik receives the EPEL but reports but it does not
AFAIU.

[0] https://admin.fedoraproject.org/pkgdb/package/rpms/gqview/

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

[Bug 1486717] abi-compliance-checker-2.2 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|abi-compliance-checker-2.2- |abi-compliance-checker-2.2-
   |1.fc25  |1.fc25
   |abi-compliance-checker-2.2- |abi-compliance-checker-2.2-
   |1.el7   |1.el7
   |abi-compliance-checker-2.2- |abi-compliance-checker-2.2-
   |1.el6   |1.el6
   ||abi-compliance-checker-2.2-
   ||1.fc27



--- Comment #19 from Fedora Update System  ---
abi-compliance-checker-2.2-1.fc27, abi-dumper-1.1-1.fc27,
abi-tracker-1.11-1.fc27 has been pushed to the Fedora 27 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

Re: Orphaned packages seeking new point of contact

[Till Maas]

On Tue, Feb 06, 2018 at 10:17:36AM +0100, Vít Ondruch wrote:

> I haven't seen the "Orphaned Packages in rawhide" since September. My
> guess is that the script got broken by deprecation of PkgDb and move to
> Pagure.

Yes, with this change we lost the possibility to track the orphan status
for individual branches. This is tracked here:

https://pagure.io/releng/pull-request/6895
https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/task/826

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

[Bug 1533867] perl-Socket-2.026 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Socket-2.027-1.fc26 has been pushed to the Fedora 26 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

[Bug 1534083] perl-Socket-2.027 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Socket-2.027-1.fc26 has been pushed to the Fedora 26 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

[Bug 1537517] perl-threads-shared-1.58 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc26 has been pushed to the Fedora 26 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

[Bug 1537516] perl-threads-2.21 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-threads-2.21-1.fc26 has been pushed to the Fedora 26 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

[Bug 1542392] perl-RDF-RDFa-Generator-0.192-1.fc28 FTBFS: Failed test ' Pretty generator'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-RDF-RDFa-Generator-0.1
   ||92-2.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-06 05:08:57



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542392] perl-RDF-RDFa-Generator-0.192-1.fc28 FTBFS: Failed test ' Pretty generator'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
External Bug ID||Github
   ||kjetilk/p5-rdf-rdfa-generat
   ||or/issues/2



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542392] New: perl-RDF-RDFa-Generator-0.192-1.fc28 FTBFS: Failed test 'Pretty generator'

[bugzilla]

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

Bug ID: 1542392
   Summary: perl-RDF-RDFa-Generator-0.192-1.fc28 FTBFS: Failed
test 'Pretty generator'
   Product: Fedora
   Version: rawhide
 Component: perl-RDF-RDFa-Generator
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



perl-RDF-RDFa-Generator-0.192-1.fc28 fails to build in F28 because a test
fails:

t/02_kk_trine.t .. ok
#   Failed test 'Literals OK'
#   at t/03_kk_attean.t line 40.
#   '
# http://www.w3.org/1999/xhtml; version="XHTML+RDFa 1.0">
# http://www.w3.org/1999/xhtml/vocab;>
# RDFa Document
# 
# 
# 
# RDFa Document
# Generated by RDF::RDFa::Generator::HTML::Pretty.
# http://www.w3.org/2001/XMLSchema#;
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:ex="http://example.org/;>_:0xE92A9D6A0AEA11E8B60EDCE9F79E0B10http://example.org/else;>ex:elseFoohttp://example.org/pi;>ex:pi3.14http://example.org/foo;>http://example.org/foohttp://example.org/Bar; alt="http://example.org/Bar;
src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAABAQCAYf8/9hBGdBTUEAAK/INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAJ5SURBVDjLpZPNS1RhFMaff2EWLWo5tGnRaqCFRBAM0cZFwVSQpVHNQAWVMQwaSSZWtimLiKnsO5lEjKzs4y1zRK3oItfMj1FnnJkaUtNrjo45H3eejpCKNa5anMX73vs855zfOS9I4n9i2SHbCpvph8q8A9PNcCzcz76EM9EETj+DmmqENaeBiJ3mRyuzQy5mwyVMKqiFbzNN0MxgKZOd2zj5GMZE/ZL5ooHZAntGW89s7Bw5Ws25llWcfQHrzHPYE/51ZOQ0M4Fiitj4UQdbzhZSb+FJ63ZypJqp7p0UsTf+FN6kvoMMl3GmNY9jj+BckcF8/HoFldLzpZIqxhthJPVdkr2cifdb5sXefyAKLFvyzVJJAssisIxstILZ0DEyeJzpHifHfNBGamFZ+C9yC7bhG7BBxCrZZqWQpoiNP6S1TMBFDh4gA0VMdxfy+0NosftQX+8gGKkBY741HLoGhbnXUOZwKTn+gGa4nOlBN9MDxdJzCTmwj+wvEKPDTPUc5Zx+kOk+NxmqZOJTIXsviYGQVgKLAos/n0CbbIAS0ir1eY9kF4O+3UzpBYzehhaugQpdR3DwKth7EeyqEoO/oYzXwyKwDDN0ipme/VKFi0l9L8M3oYW8SwxWnIKI1XT7Vqb6i/ntLoLTHdulhROcUJsZuJJjCsvEPpyf8m8io5U0VB6FtFNIe6da84XFEcYaNrDzLDw5DUZ9cEwqm6zxGWYGPBTShogtQtoerV0rLA5JKy5+ubya7SdzbKKMyRG7ByPeIfvebKfAWszUdQFavKOI0bqNbCuF4XfneAvzIaStQrpOxEpIL746rQKOD2VQbSXwtLiXg/!
 wNTNvAOhsl8oEASUVORK5CYII="
title="http://example.org/Bar"/>http://example.org/something;>ex:something_:0xE92A9D6A0AEA11E8B60EDCE9F79E0B10http://example.org/title;>ex:titleDahut
# 
# '
# doesn't match '(?^:Dahut)'
# Looks like you failed 1 test of 7.
#   Failed test 'Pretty generator'
#   at t/03_kk_attean.t line 41.
# Looks like you failed 1 test of 4.
t/03_kk_attean.t . 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests 

This is cause by upgrading perl-Attean from 0.018 to 0.019.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Orphaned packages seeking new point of contact

[Vít Ondruch]

Dne 5.2.2018 v 21:12 Tomasz Torcz ️ napsal(a):
> On Mon, Feb 05, 2018 at 07:42:45AM -0500, Josh Boyer wrote:
>> On Fri, Feb 2, 2018 at 3:22 PM, Michael Schwendt  wrote:
>>> On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
>>>
 rpms/gqview
>>> Really?!
>> Congratulations, you have just explained why absentee maintainers are
>> bad and why we orphan things.
>>
>>> It is unmaintained for over 10 years.
>>>
>>> It has been forked into Geeqie (package "geeqie") roughly 10 years
>>> ago, and Geeqie at least has seen several releases since then.
>> Perhaps just take gqview and retire it then?
>   Shouldn't it be retired automatically when no one takes it?
>

I haven't seen the "Orphaned Packages in rawhide" since September. My
guess is that the script got broken by deprecation of PkgDb and move to
Pagure.


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

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi Andrew,

On 05-02-18 23:02, Andrew Lutomirski wrote:

On Thu, Feb 1, 2018 at 11:34 AM, Hans de Goede  wrote:


Hi All,

For the "Improved Laptop Battery Life" feature:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

I'm working on for Fedora 28 I would like to also try and enable
Panel Self Refresh on laptops with Intel graphics, some quick tests
have shown this to save another 0.5W (when idle / nothing on the
screen changes). This is currently off be default because it is
known to cause issues on some devices. So I think we will probably
need a white- or black-list. But first we need more data on this.

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html



I suspect that the results may be odd.  After falling into a rabbit
hole when I tried to do this test, I learned a few things about the
i915 driver's PSR support:

  - Intel doesn't currently have any working CI coverage for PSR.

  - There's an Intel person who seems to be actively trying to fix PSR.

  - PSR on 4.15 on newish hardware (at least Skylake) is completely broken.

  - There are other known bugs.

So I'm not sure that trying to tabulate PSR functionality based on
panel type seems like it may be the wrong approach.


Thank you for your poking around wrt this. Can you send me an (off-list)
email with the contact info for the Intel person you are talking about,
before spending more time on this I would like to touch base with him/her.

Regards,

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

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi,

On 05-02-18 22:45, Dominik 'Rathann' Mierzejewski wrote:

Hello, Hans.

On Thursday, 01 February 2018 at 12:34, Hans de Goede wrote:
[...]

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html


That's great! However, I'm getting this:

# cat /sys/kernel/debug/dri/0/i915_edp_psr_status
cat: /sys/kernel/debug/dri/0/i915_edp_psr_status: Operation not permitted

as root on my machine. Does that mean it's not supported?


That means you've secure boot enabled so your not allowed
to access anything under /sys/kernel/debug, which is a bit of
a pain really, as there are some useful bits there like the
i915_edp_psr_status but also vga-switcheroo stuff.

Regards,

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

[Bug 1542279] perl-Gearman-2.004.0013 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Gearman-2.004.0013-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-07f9a538d4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1540220] perl-Gearman-Client-Async-0.94-28.fc28 FTBFS: Timeout, test fails at t/allinone.t line 62.

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Gearman-2.004.0013-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-07f9a538d4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1540220] perl-Gearman-Client-Async-0.94-28.fc28 FTBFS: Timeout, test fails at t/allinone.t line 62.

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Gearman-2.004.0013-1.f
   ||c28



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542279] perl-Gearman-2.004.0013 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Gearman-2.004.0013-1.f
   ||c28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 27.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: binutils 2.30

[Ralf Corsepius]

On 02/06/2018 09:05 AM, Florian Weimer wrote:

On 02/06/2018 09:02 AM, Richard W.M. Jones wrote:

On Tue, Feb 06, 2018 at 08:49:53AM +0100, Florian Weimer wrote:

On 02/06/2018 08:38 AM, Richard W.M. Jones wrote:

binutils 2.30 has been out for about a week.  Will we get it in
Rawhide soon?  It has some modest enhancements related to the RISC-V
architecture.


No, not before Fedora 28 branches.


Is there a particular issue with 2.30, eg. not stable enough for
a stable release of Fedora?


There isn't any specific issue.

Toolchain updates always carry some risk, and we already have enough 
moving parts due to GCC 8 and other low-level changes that landed in 
rawhide recently.


Hmm, IMO, GCC + binutils updates are an ideal candidate to be pushed 
simultaneously and an ideal opportunity for a mass rebuild.


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

[Bug 1540220] perl-Gearman-Client-Async-0.94-28.fc28 FTBFS: Timeout, test fails at t/allinone.t line 62.

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

  Component|perl-Gearman-Client-Async   |perl-Gearman



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

openclonk-0.8 linking fails

[Martin Gansser]

Hi,

compiling openclonk [1] fails with the following error message [2]:

...
[  9%] Linking CXX static library liblibmisc.a
/usr/bin/cmake -P CMakeFiles/libmisc.dir/cmake_clean_target.cmake
/usr/bin/cmake -E cmake_link_script CMakeFiles/libmisc.dir/link.txt --verbose=1
/usr/bin/gcc-ar qc liblibmisc.a  CMakeFiles/libmisc.dir/src/C4Include.cpp.o 
CMakeFiles/libmisc.dir/src/c4group/C4Group.cpp.o 
CMakeFiles/libmisc.dir/src/c4group/C4Update.cpp.o 
CMakeFiles/libmisc.dir/src/c4group/CStdFile.cpp.o 
CMakeFiles/libmisc.dir/src/graphics/C4BltTransform.cpp.o 
CMakeFiles/libmisc.dir/src/lib/C4InputValidation.cpp.o 
CMakeFiles/libmisc.dir/src/lib/C4Markup.cpp.o 
CMakeFiles/libmisc.dir/src/lib/C4Random.cpp.o 
CMakeFiles/libmisc.dir/src/lib/C4SimpleLog.cpp.o 
CMakeFiles/libmisc.dir/src/lib/Standard.cpp.o 
CMakeFiles/libmisc.dir/src/lib/StdBuf.cpp.o 
CMakeFiles/libmisc.dir/src/lib/StdCompiler.cpp.o 
CMakeFiles/libmisc.dir/src/lib/StdResStr2.cpp.o 
CMakeFiles/libmisc.dir/src/netpuncher/C4PuncherPacket.cpp.o 
CMakeFiles/libmisc.dir/src/network/C4NetIO.cpp.o 
CMakeFiles/libmisc.dir/src/network/C4Network2Address.cpp.o 
CMakeFiles/libmisc.dir/src/platform/StdFile.cpp.o 
CMakeFiles/libmisc.dir/src/platform/StdRegistry.cpp.o 
CMakeFiles/libmisc.dir/src/platform/StdScheduler.cpp.o CMakeF
 iles/libmisc.dir/src/platform/StdSchedulerWin32.cpp.o 
CMakeFiles/libmisc.dir/src/platform/StdSchedulerPoll.cpp.o 
CMakeFiles/libmisc.dir/src/platform/C4TimeMilliseconds.cpp.o 
CMakeFiles/libmisc.dir/src/zlib/gzio.c.o 
CMakeFiles/libmisc.dir/libmisc_autogen/mocs_compilation.cpp.o
Error running link command: Segmentation fault
make[2]: *** [CMakeFiles/libmisc.dir/build.make:697: liblibmisc.a] Error 1
make[2]: Leaving directory '/home/martin/rpmbuild/BUILD/openclonk-8.0/build'
make[1]: *** [CMakeFiles/Makefile2:187: CMakeFiles/libmisc.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
make[2]: Entering directory '/home/martin/rpmbuild/BUILD/openclonk-8.0/build'
...


[1] https://martinkg.fedorapeople.org/Packages/openclonk/openclonk.spec
[2] https://martinkg.fedorapeople.org/Packages/openclonk/openclonk-build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1531010] perl-Gearman-2.004.012 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gearman-2.004.012-1.fc |perl-Gearman-2.004.012-1.fc
   |28  |27
 Resolution|--- |ERRATA
Last Closed||2018-02-06 03:13:19



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1528827] perl-Gearman-2.004.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 03:12: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

[Bug 1516068] perl-Gearman-2.004.010 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-02-06 03:12:04



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: binutils 2.30

[Florian Weimer]

On 02/06/2018 09:02 AM, Richard W.M. Jones wrote:

On Tue, Feb 06, 2018 at 08:49:53AM +0100, Florian Weimer wrote:

On 02/06/2018 08:38 AM, Richard W.M. Jones wrote:

binutils 2.30 has been out for about a week.  Will we get it in
Rawhide soon?  It has some modest enhancements related to the RISC-V
architecture.


No, not before Fedora 28 branches.


Is there a particular issue with 2.30, eg. not stable enough for
a stable release of Fedora?


There isn't any specific issue.

Toolchain updates always carry some risk, and we already have enough 
moving parts due to GCC 8 and other low-level changes that landed in 
rawhide recently.


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

Re: binutils 2.30

[Richard W.M. Jones]

On Tue, Feb 06, 2018 at 08:49:53AM +0100, Florian Weimer wrote:
> On 02/06/2018 08:38 AM, Richard W.M. Jones wrote:
> >binutils 2.30 has been out for about a week.  Will we get it in
> >Rawhide soon?  It has some modest enhancements related to the RISC-V
> >architecture.
> 
> No, not before Fedora 28 branches.

Is there a particular issue with 2.30, eg. not stable enough for
a stable release of Fedora?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org