KP_end
by Patrick Dupre
Hello,
In fedora 24, I observe a different behavior than under fc22.
I am using a french keyboard (alternative)
The key "page down" generates a KP_End
and the key "page up" generates a KP_Home
while "end" generates a End
and "home" generates a Home
I would have expect a KP_Prior or a KP_Next.
When a make a man
the key "page down" and "end" give the same result: End
the key "page up" and "home" give the same result: Home
It means that I do not have any page up or page down with man.
Also, the numerical pad does not help either because the KP_Prior
does the same as a Home, and KP_Next does a End
Any clue?
Thank
===========================================================================
Patrick DUPRÉ | | email: pdupre(a)gmx.com
Laboratoire de Physico-Chimie de l'Atmosphère | |
Université du Littoral-Côte d'Opale | |
Tel. (33)-(0)3 28 23 76 12 | | Fax: 03 28 65 82 44
189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===========================================================================
7 years, 7 months
rpmbuild
by Patrick Dupre
Hello,
I tried to build my own package perl-PAR-Packer from
Url: http://search.cpan.org/dist/PAR-Packer/
(see rpmfind.net)
I run cpanspec
and then
rpmbuild -bb
and I got the following error message:
RPM build errors:
File not found: /home/pdupre/rpmbuild/BUILDROOT/perl-PAR-Packer-1.035-1.fc24.x86_64/usr/lib64/perl5/vendor_perl/auto/*
File not found: /home/pdupre/rpmbuild/BUILDROOT/perl-PAR-Packer-1.035-1.fc24.x86_64/usr/lib64/perl5/vendor_perl/PAR*
Here is the spec file:
Name: perl-PAR-Packer
Version: 1.035
Release: 1%{?dist}
Summary: PAR Packager
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/PAR-Packer/
Source0: http://www.cpan.org/modules/by-module/PAR/PAR-Packer-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl >= 1:5.8.1
BuildRequires: perl(Archive::Zip) >= 1.02
BuildRequires: perl(Compress::Zlib) >= 1.30
BuildRequires: perl(Digest)
BuildRequires: perl(Digest::SHA)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp) >= 0.05
BuildRequires: perl(Getopt::ArgvFile) >= 1.07
BuildRequires: perl(IO::Compress::Gzip)
BuildRequires: perl(Module::ScanDeps) >= 1.21
BuildRequires: perl(Module::Signature)
BuildRequires: perl(PAR) >= 1.010
BuildRequires: perl(PAR::Dist) >= 0.22
BuildRequires: perl(Text::ParseWords)
BuildRequires: perl(Tk)
BuildRequires: perl(Tk::ColoredButton)
BuildRequires: perl(Tk::EntryCheck)
BuildRequires: perl(Tk::Getopt)
Requires: perl(Archive::Zip) >= 1.02
Requires: perl(Compress::Zlib) >= 1.30
Requires: perl(Digest)
Requires: perl(Digest::SHA)
Requires: perl(File::Temp) >= 0.05
Requires: perl(Getopt::ArgvFile) >= 1.07
Requires: perl(IO::Compress::Gzip)
Requires: perl(Module::ScanDeps) >= 1.21
Requires: perl(Module::Signature)
Requires: perl(PAR) >= 1.010
Requires: perl(PAR::Dist) >= 0.22
Requires: perl(Text::ParseWords)
Requires: perl(Tk)
Requires: perl(Tk::ColoredButton)
Requires: perl(Tk::EntryCheck)
Requires: perl(Tk::Getopt)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
%description
This module implements the App::Packer::Backend interface, for generating
stand-alone executables, perl scripts and PAR files.
%prep
%setup -q -n PAR-Packer-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc AUTHORS Changes README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/PAR*
%{_mandir}/man3/*
%changelog
* Wed Nov 02 2016 Patrick Dupre <pdupre(a)gmx.com> 1.035-1
- Specfile autogenerated by cpanspec 1.78.
Can somebody help me ?
I tried to modify or remove the lines
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/PAR*
but it did not help.
Thank.
===========================================================================
Patrick DUPRÉ | | email: pdupre(a)gmx.com
Laboratoire de Physico-Chimie de l'Atmosphère | |
Université du Littoral-Côte d'Opale | |
Tel. (33)-(0)3 28 23 76 12 | | Fax: 03 28 65 82 44
189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===========================================================================
7 years, 7 months
Can't suspend F23 due to mate-settings-daemon and mate-multiload-applet
by Kevin Cummings
Have anyone else noticed this?
If I boot any of the recent 4.7 kernels, I can immediately suspend my
laptop without incident. If I leave the system up for some reasonable
amount of time, then everytime I try to suspend, it fails. journalctl
shows that 2 Mate daemons refuse to Freeze:
Here is just one exert from my journal:
> Oct 26 12:43:04 kjclap4 kernel: PM: Preparing system for sleep (freeze)
> Oct 26 12:43:04 kjclap4 kernel: Freezing user space processes ...
> Oct 26 12:43:04 kjclap4 kernel: Freezing of tasks failed after 20.004 seconds (2 tasks refusing to freeze, wq_busy=0):
> Oct 26 12:43:04 kjclap4 kernel: mate-settings-d D ffff8800aed2fc20 0 1419 1192 0x00000004
> Oct 26 12:43:04 kjclap4 kernel: ffff8800aed2fc20 ffff8800aed68000 ffff880119ddba80 ffff8800aed2fc00
> Oct 26 12:43:04 kjclap4 kernel: ffff8800aed30000 ffff8800aed2fc50 ffff8800befae260 ffff880095e7c000
> Oct 26 12:43:04 kjclap4 kernel: fffffffffffffe00 ffff8800aed2fc38 ffffffffad7e0c65 ffff8800befae190
> Oct 26 12:43:04 kjclap4 kernel: Call Trace:
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e0c65>] schedule+0x35/0x80
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087879b>] request_wait_answer+0x15b/0x250 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad0e2d80>] ? wake_atomic_t_function+0x70/0x70
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b61>] __fuse_request_send+0x71/0x80 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b97>] fuse_request_send+0x27/0x30 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087be4c>] fuse_simple_request+0xcc/0x1a0 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0886251>] fuse_statfs+0xe1/0x150 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad27936c>] statfs_by_dentry+0x6c/0x90
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2793ab>] vfs_statfs+0x1b/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad279488>] user_statfs+0x58/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2794f7>] SYSC_statfs+0x27/0x60
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2796de>] SyS_statfs+0xe/0x10
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e4f72>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> Oct 26 12:43:04 kjclap4 kernel: mate-multiload- D ffff8800a8c4bc20 0 1698 1 0x00000004
> Oct 26 12:43:04 kjclap4 kernel: ffff8800a8c4bc20 ffff8800a72b3a80 ffff8800abfb1d40 ffff8800a8c4bc00
> Oct 26 12:43:04 kjclap4 kernel: ffff8800a8c4c000 ffff8800a8c4bc50 ffff8800befae0d0 ffff880095e7c000
> Oct 26 12:43:04 kjclap4 kernel: fffffffffffffe00 ffff8800a8c4bc38 ffffffffad7e0c65 ffff8800befae000
> Oct 26 12:43:04 kjclap4 kernel: Call Trace:
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e0c65>] schedule+0x35/0x80
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087879b>] request_wait_answer+0x15b/0x250 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad0e2d80>] ? wake_atomic_t_function+0x70/0x70
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b61>] __fuse_request_send+0x71/0x80 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b97>] fuse_request_send+0x27/0x30 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087be4c>] fuse_simple_request+0xcc/0x1a0 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0886251>] fuse_statfs+0xe1/0x150 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad27936c>] statfs_by_dentry+0x6c/0x90
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2793ab>] vfs_statfs+0x1b/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad279488>] user_statfs+0x58/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2794f7>] SYSC_statfs+0x27/0x60
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2796de>] SyS_statfs+0xe/0x10
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e4f72>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> Oct 26 12:43:04 kjclap4 kernel:
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: The canary thread is apparently starving. Taking action.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Demoting known real-time threads.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1545 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 kernel: Restarting tasks ... done.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1533 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1460 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Demoted 3 threads.
> Oct 26 12:43:04 kjclap4 kernel: video LNXVIDEO:01: Restoring backlight state
Can anyone shed some light on this? It continues through kernel 4.7.9.
(I have not yet booted 4.7.10.)
If I try and suspend, it fails, and restores the kernel to a fully
running state, usually on battery, and usually with the laptop fan
continuing to run, expelling heat into my laptop case if I don't notice it!
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
7 years, 7 months
Re: WD My Passport Ultra 3T usb drive problem
by George R Goffe
Hi,
This situation sounds a lot like the problems I had when I went from 2tb drives to 3tb -> 6tb drives connected via USB 2/3 to docking stations. 2tb drives worked well. 3tb drives were all screwed up. It turns out that the firmware in the Kwin dual drive docking station could NOT support > 2tb drives. Something to do with the number of bits. I went to SIIG usb3 dual port docking stations and poof, the size of the drive didn't matter any more. The SIIG product has been removed from the market I think. Other issues: fans get noisy after a short period of time and my favorite bug. The drives in a station drop ready (for lack of a better word) under heavy i/o load. I suspect that they still draw power from the usb interface even though they are powered themselves. The drive(s) get busy, draw more power... past a threshold and the drive drops away... the system sees the drive go... i/o stops... the power draw goes down... drive comes back... possibly at a different drive letter... A REAL PAIN.
Most of my big drives are 1 partition but some have several due to performance issues with large numbers of files in a 6tb file system.
All systems are various Fedora... I'm on Fedora 25 now... still have the power drop with heavy i/o problem and the performance problem with # of files in one big partition. ext4 fs type and even tried xfs... found bugs... went back.
I guess the newer systems have usb ports with > 32bit capable interfaces (I don't think this is the right word though). The interface handles drives > 2tb is what I mean.
Hope this helps.
George...
7 years, 7 months