Firefox not working anymore over ssh?
by Juan Quintela
Hi
since last Monday or so, I have been able to run firefox over ssh
anymore. I thought it was my setup, but further investigation showed
that it is something specific to firefox.
My setup is a bit more convoluted than this, but I am able to do:
$ ssh -X localhost gnome-terminal
And it shows a terminal as expected
$ ssh -X localhost firefox
Without a firefox running will hang there forever, no output at all. I
tried doing strace of it, and see that is waiting for futexes. But
haven't been able to see what is happening.
Until last Tuesday or so (I am on F23) firefox worked over ssh without
any problems. I have been running it like that for something like a
year.
Anyone has any suggestion? I tried also
$ ssh -Y localhost firefox
And it didn't helped at all (not that I am sure of the difference either).
Later, Juan.
PD. Really, what I normally do is run ssh to a virtual manchine in the
same host.
7 years, 10 months
GPG2 as default /usr/bin/gpg
by Christopher
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175
It's not a huge deal (and there are several workarounds, for git and for
other tools which default ot using 'gpg'), but it highlights the mismatch
between the default /usr/bin/gpg running gpg1, when other tools, like
gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in
RHEL6.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least
rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1
instead? This seems overdue. Is there any reason not to do this?
7 years, 10 months
Support for PCLMUL, AVX, FMA, etc.
by Jerry James
I am one of the maintainers of the ntl package, which is used by some
numeric applications (e.g., Macaulay2 and sagemath). Upstream
supports use of the PCLMUL instruction, the AVX instructions, and the
FMA instructions to speed up various computations. We can't use any
of those in Fedora, since we have to support a baseline x86_64.
Well, that's kind of a downer. I could advertise that people with
newer CPUs ought to rebuild the ntl package for their own CPUs, but
what's a distribution for if people have to rebuild packages? I've
been looking for a way to automatically support more recent CPUs.
Yesterday I sent a patch upstream that uses gcc's indirect function
support together with __attribute__((target ...)) to build vanilla
x86_64, PCLMUL-enabled, AVX-enabled, and FMA-enabled varieties of
several functions. Upstream was initially excited about this but
then, on further reflection, offered the opinion that this approach is
dangerous. The problem is that some of the types involved may change
ABI depending on the instruction set in use, and therefore it would be
necessary to build larger portions of the library for each supported
CPU variant. At that point, as upstream said, we might as well just
build the entire library for each variant. The problem then is how to
choose which version of the library to use at load time.
On some platforms, ld.so offers "hardware capabilities", such as sse2
on i386. By dropping a vanilla library into /usr/lib and an
SSE2-enabled build into /usr/lib/sse2, applications can get the
version of the library appropriate for the CPU in use. But there
don't seem to be any defined hardware capabilities for x86_64.
Has anybody already thought this through? What's the best approach to
take? For this package, the speedups are substantial, so this is
worth doing, if it can be done well.
Thank you,
--
Jerry James
http://www.jamezone.org/
7 years, 10 months
F25 Self Contained Change: Replace UDisks2 by Storaged
by Jan Kurik
= Proposed Self Contained Change: Replace UDisks2 by Storaged =
https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged
Change owner(s):
* Peter Hatina <phatina redhat com>
* Tomáš Smetana <tsmetana redhat com >
Storaged extends UDisks2 API by exporting several enterprise features
(in form of plugins), such as LVM2 and iSCSI. This project is a
drop-in replacement for UDisks2, either from D-Bus or binary point of
view. The main motivation of this change is to provide the unified
D-Bus API for all the clients who are willing to manage LVM2, iSCSI,
Btrfs, BCache, LSM and ZRam.
== Detailed Description ==
Aim of Storaged is to provide unified higher level management
interface for various clients who are willing to query and manage
storage bits of the system. We plan to replace UDisks2 by Storaged,
since the Storaged itself is the fork of UDisks2 and these 2 projects
in its core haven't diverged so much (Storaged got some improvements
which popped up while using it).
== Scope ==
Proposal owners: To implement this Change
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 11 months
Kernel plans for Fedora 24
by Justin Forbes
With the 4.5 kernel out and the merge window for 4.6 opened up, we had
to make a decision on what the release kernel for F24 would be. The
decision has been made to ship F24 with the 4.5 kernel with 4.6
available as an update once it is ready. Timing wise, 4.6 *should*
release just before the final freeze for F24, but that is cutting it
insanely close. Should Fedora move on as scheduled, and 4.6 have some
delay due to a bug that impacts users, that would be unfortunate.
This means we have a good bit of time to make sure that everything is
working as intended with 4.5 in Fedora. It also means that any
installer critical fixes will need to be backported to 4.5.
Thanks,
Justin
8 years
orphaning all my packages
by François Cami
Hello,
I'll orphan all my packages at 2PM UTC+2 tomorrow.
rpms/bats -- Bash Automated Testing System ( master f24 f23 f22 epel7 el6 )
rpms/djview4 -- DjVu viewer ( epel7 )
rpms/djvulibre -- DjVu viewers, encoders, and utilities ( master f24
f23 f22 epel7 el6 )
rpms/enet -- Thin, simple and robust network layer on top of UDP (
master f24 f23 f22 epel7 )
rpms/gpsd -- Service daemon for mediating access to a GPS ( epel7 )
rpms/pdf2djvu -- PDF to DjVu converter ( master f24 f23 f22 epel7 )
rpms/pngcrush -- Optimizer for PNG (Portable Network Graphics) files (
master f24 f23 f22 el6 )
rpms/pyliblzma -- Python bindings for lzma ( master f24 f23 f22 el6 )
rpms/python-fpconst -- Python module for handling IEEE 754 floating
point special values ( master f24 f23 f22 )
rpms/stardict-xmllittre -- Authoritative 19th century French
dictionary ( master f24 f23 f22 )
rpms/throttle -- Bandwidth limiting pipe ( master f24 f23 f22 epel7 el6 el5 )
rpms/tinyxml -- A simple, small, C++ XML parser ( master f24 f23 f22 epel7 )
rpms/tinyxml2 -- Simple, small and efficient C++ XML parser ( master
f24 f23 f22 epel7 el6 el5 )
rpms/unittest-cpp -- Lightweight unit testing framework for C++ (
master f24 f23 f22 epel7 el6 )
rpms/uriparser -- URI parsing library - RFC 3986 ( master f24 f23 f22 )
rpms/vtk -- The Visualization Toolkit - A high level 3D visualization
library ( epel7 )
I'm also co-maintainer for the list below, it would be nice if others
could step up and help their maintainers too:
rpms/LuxRender -- Lux Renderer, an unbiased rendering system ( master
f24 f23 f22 epel7 )
rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( f23 f22 )
rpms/blender -- 3D modeling, animation, rendering and post-production
( master f24 f23 f22 epel7 )
rpms/bullet -- 3D Collision Detection and Rigid Body Dynamics Library
( master f24 f23 f22 epel7 el6 )
rpms/ceph-ansible -- Ansible playbooks for Ceph ( master f24 f23 f22 epel7 )
rpms/cppcheck -- Tool for static C/C++ code analysis ( master f24 f23
f22 epel7 el6 el5 )
rpms/dbus-c++ -- Native C++ bindings for D-Bus ( master f24 f23 f22 epel7 )
rpms/disper -- On-the-fly display switch utility ( master f24 f23 f22
epel7 el6 )
rpms/djview4 -- DjVu viewer ( master f24 f23 f22 )
rpms/dvblinkremote -- Tool for interacting with a DVBLink Connect!
Server ( master f24 f23 f22 )
rpms/freenx-server -- Free Software (GPL) Implementation of the NX
Server ( master f24 f23 f22 )
rpms/geany -- A fast and lightweight IDE using GTK2 ( master f24 f23
f22 epel7 el6 el5 )
rpms/girara -- Simple user interface library ( master f24 f23 f22 epel7 el6 )
rpms/gitolite3 -- Highly flexible server for git directory version
tracker ( master f24 f23 f22 epel7 el6 )
rpms/iperf3 -- Measurement tool for TCP/UDP bandwidth performance (
master f24 f23 f22 epel7 el6 )
rpms/jack-audio-connection-kit -- The Jack Audio Connection Kit (
master f24 f23 f22 epel7 el6 )
rpms/jfsutils -- Utilities for managing the JFS filesystem ( master
f24 f23 f22 )
rpms/key-mon -- A screen cast utility that displays your keyboard and
mouse status ( master f24 f23 f22 epel7 )
rpms/libffado -- Free firewire audio driver library ( master f24 f23 f22 epel7 )
rpms/libmediainfo -- Library for supplies technical and tag
information about a video or audio file ( master f24 f23 f22 epel7 el6
)
rpms/librelp -- The Reliable Event Logging Protocol library ( master
f24 f23 f22 )
rpms/ocl-icd -- OpenCL ICD Bindings ( master f24 f23 f22 )
rpms/openal-soft -- Open Audio Library ( master f24 f23 f22 epel7 )
rpms/portaudio -- Free, cross platform, open-source, audio I/O library
( master f24 f23 f22 epel7 )
rpms/python-pyopengl -- Python bindings for OpenGL ( master f24 )
rpms/rssh -- Restricted shell for use with OpenSSH, allowing only scp
and/or sftp ( epel7 )
rpms/sir -- A simple application for resizing images ( master f24 f23 f22 )
rpms/speed-dreams -- The Open Racing Car Simulator ( master f24 f23 f22 )
rpms/surf -- Simple web browser ( f23 f22 )
rpms/unhide -- Tool to find hidden processes and TCP/UDP ports from
rootkits ( master f24 f23 f22 )
rpms/vtk -- The Visualization Toolkit - A high level 3D visualization
library ( master f24 f23 f22 )
rpms/vtkdata -- Example data file for VTK ( f22 )
rpms/xfce4-xkb-plugin -- XKB layout switcher for the Xfce panel (
master f24 f23 f22 )
rpms/xonotic -- Multiplayer, deathmatch oriented first person shooter
( master f24 f23 f22 el6 el5 )
rpms/xonotic-data -- Game data for the Xonotic first person shooter (
master f24 f23 f22 el6 el5 )
rpms/zathura -- A lightweight document viewer ( master f24 f23 f22 epel7 el6 )
rpms/zathura-cb -- Comic book support for zathura ( master f24 f23 f22 epel7 )
rpms/zathura-djvu -- DjVu support for zathura ( master f24 f23 f22 epel7 el6 )
rpms/zathura-pdf-mupdf -- PDF support for zathura via mupdf ( master f24 f23 )
rpms/zathura-pdf-poppler -- PDF support for zathura via poppler (
master f24 f23 f22 epel7 el6 )
rpms/zathura-ps -- PS support for zathura via libspectre ( master f24
f23 f22 epel7 el6 )
It's been a fun ride.
François
8 years
RFC: Fedora Docker Layered Image Guidelines
by Adam Miller
Hello all,
We're wrapping up the first phase of the Fedora Docker Layered Image
Build Service[0] and the time has come to start thinking about what we as a
Project need to do to formalize what it means to be shipping Docker Layered
Images once we are capable of building and distributing them.
These are effectively going to compliment their RPM counterpart at least
in the beginning since we as a Project have never shipped any build artifact
other than RPMs as a part of the distribution before. We can grow organically
from there if we want to extend beyond the initial offering for Docker
Layered Images but I thought following RPM as a guide in the beginning was a
reasonable goal to achieve. Some areas that seemed pertinant right off the
bat are below, for each of them I have alread created a Draft document that
I would appreciate feedback on.
Docker Layered Image "packaging" Guidelines [1]
Package Review Process with a Docker Containers section [2]
Docker Layered Images Naming Guildelines [3]
The Fedora Cloud SIG has done a first-pass review of these (thanks Cloud
SIG!) so hopefully there's a certainly level of sanity to them but I'm
absolutely open to new ideas and extending the content with more coverage.
Another point to note is that we need to determine how this should be handled
in BZ components for bug reporting as well as for filing review requests.
Something else what was brought up when I originally submitted these ideas to
FESCo[4] (aside from the fact that this should go to devel list first) was
that it is probably a good idea to establish a Container-centric Guidelines
Committee much in the way there is a Fedora Packaging Committee (which focuses
on RPMs). My question to everyone on that topic is, would there be enough
interest to establish such a committee?
As a side note and just a matter of opinion but I think the idea of forming
a Committee to help shepherd these new types of deliverables through Fedora
will help to enable aspects of Fedora Modularization[5] which ultimately will
be good for the whole of the Fedora Project.
I look forward to questions and feedback.
Thank you,
-AdamM
[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
[1] - https://fedoraproject.org/wiki/PackagingDrafts/Containers
[2] - https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_wit...
[3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGu...
[4] - https://fedorahosted.org/fesco/ticket/1573
8 years
GCC 6 constexpr errors?
by Michael Schwendt
audacious-plugins-3.7.2 in Rawhide koji failed to build with constexpr
errors in various plugins.
What exactly has changed?
https://kojipkgs.fedoraproject.org//work/tasks/5212/13645212/build.log
metronom.cc:50:30: in constexpr expansion of 'InputPlugin::InputInfo(0).InputPlugin::InputInfo::with_schemes(((const char* const*)(& Metronome::schemes)))'
metronom.cc:50:30: error: accessing uninitialized array element
.with_schemes(schemes);
^
8 years
