koji build failure
by 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
6 years, 3 months
COPR + pagure + rpkg HOWTO?
by Richard Shaw
I would like to manage a COPR via SCM (in this case pagure)
I'm assuming using rpkg would be a good way to do this? Or should I forget
that and just use plain git+copr-cli?
There is OK documentation for the independent tools but I can't seem to
find a HOWTO that ties it all together.
I want to use my pagure project: https://pagure.io/NBEMS
To tie into my COPR project:
https://copr.fedorainfracloud.org/coprs/hobbes1069/NBEMS/
so I can stop uploading package to my fedorapeople public_html site and
build via URLs.
Second question. My plan is to use this to mainly build packages for EL7 of
all the most useful applications from http://w1hkj.com for emergency
communications on a stable and LTS platform.
Some of them are already in EPEL but need newer versions of dependent
libraries than are available to build the latest versions.
I was thinking of using a git branch per application but that's not a
typical workflow, but seems better than just using master and a bunch of
subdirectories.
Thoughts?
6 years, 3 months
Orphaning apigen, nette framework and some others
by Remi Collet
I just orphaned, because lack of time, lack of interest and lack of
upstream collaboration :
apigen
php-apigen-theme-bootstrap
php-apigen-theme-default
php-kdyby-events
php-kdyby-strict-objects
php-latte
php-nette
php-nette-application
php-nette-bootstrap
php-nette-caching
php-nette-component-model
php-nette-database
php-nette-deprecated
php-nette-di
php-nette-finder
php-nette-forms
php-nette-http
php-nette-mail
php-nette-neon
php-nette-php-generator
php-nette-reflection
php-nette-robot-loader
php-nette-safe-stream
php-nette-security
php-nette-tester
php-nette-tokenizer
php-nette-utils
php-tracy
Remi
6 years, 3 months
openclonk-0.8 linking fails
by 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
6 years, 3 months
gnome crashes after today upgrade
by Tomasz Kłoczko
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.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6 years, 3 months
dnf update blocked by dnf-utils
by 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?
6 years, 3 months
Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async
working
by J. Bruce Fields
On Tue, Feb 06, 2018 at 06:49:28PM +0000, 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 <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.
6 years, 3 months
Wyland is a disaster
by Howard Howell
Hi, guys,
I'm sorry, but wyland is a disaster for me. I do work on lots
of different software platforms, and things are just not working well.
They kind-of-work, which is the really worst condition one can have.
My new video board won't work with wyland, my pixycam software won't
work with wyland, some other graphics have changed colors, or don't
fully resolve with wyland, and finding compatible third party products
which was tough enough on linux to begin with is now virtually
impossible. The web compatible products work, like MPLABX from
microchip, but occasionally crash. Gscheme crashes randomly, and there
are others I haven't tried recently, but which I expect to have issues
supporting.
Whatever the impetus was to change, it must have been driven by
somebody that doesn't really use the system. I have tried starting as
an Xorg login, but somehow that seems less than operating for similar
reasons, all surrounding graphics I suspect. So whether it is wyland
or the new graphics driver, kind-of-working is not a good deal. Yes, I
can change distributions, and if that is the only solution, I will, but
isn't that contradictory to the idea of becoming the OS of choice?
I expected that all these nagging issues would be worked out by
now. But there is no sign of improvement. Worse I am not getting my
stuff done. Granted I am just a hobbyiest, but doesn't this also
affect your more professional users?
Regards,
Les H
6 years, 3 months
