replace unclutter with unclutter-xfixes?
by Henrique Martins
Unclutter seems to be an orphaned package that keeps being
rebuilt, there even is an fc30 rpm. The URL given in the
fc29 package points to a dead link on MIT. I filed a
bugzilla report on this and no one replied.
Rdesktop seems to haven been obsoleted. It has its problems,
mostly excessive refreshes that can freeze the display for
long periods of time. The rdesktop package on my system is
for fc24.
One of its replacements is xfreerdp. No combination of
unclutter's options seem to work without interfering with
xfreerdp, short of making unclutter not hide the cursor in
those windows which I'd like to do. (When unclutter wakes
up to check for mouse moves, it temporarily steals the mouse
from xfreerdp which causes it to reset the keyboard, loosing
the state of modifiers keys, e.g. control being held down.)
There is an utility called unclutter-xfixes on github
http://github.com/Airblader/unclutter-xfixes
which is a rewrite based on the X11-xfixes library and works
much better than the old unclutter.
There is a COPR build of unclutter-xfixes
https://copr.fedorainfracloud.org/coprs/nbeernink/unclutter-xfixes/
Most other distros seem to have it as an optional package.
I've recently submitted a pull request to unclutter-xfixes
that will make it accept all unclutter flags and behave like
unclutter did. It ignores a couple of flags that don't make
sense with xfixes, without any loss of functionality.
Once accepted, it will be an almost drop-in replacement for
unclutter, maybe needing a couple of minor tweaks: it uses
the same binary name, it calls itself unclutter-xfixes under
usage, the man page is unclutter-xfixes, not unclutter.
Could Fedora replace unclutter with unclutter-xfixes?
-- Henrique
5 years, 5 months
A smart cache-y proposal for composes
by Kevin Fenzi
So, I had an idea of one method of attack for composes and lifecycles
that I thought I would toss out there to see what others thought of it.
Instead of redesigning and reimplementing our current build/compose/test
pipeline we improve it by making the current process cache as much of
everything as it possibly can and listening and operating on any changes
in inputs. So, instead of gathering everything all the time from all the
inputs every time we only do 'full' composes every so often (weekly?)
and then less and less often as our caching is fixed.
At each place we currently gather or query an input, we instead query it
and check it against what we already have. If they are the same, go on,
if they are different, cache it and change only those things that are
affected by that input.
Some examples:
a new xfce4-session package is built. The composer sees this and goes
through all things affected by 'new package':
* Does it pass CI?
* remove old package from package caches/repos and update them.
* is it in a deliverable? yes, a Xfce live and a xfce arm image
* make those (just those) and test
* If everything passes, release those deliverables (a updated repo where
you just have the one package updated and new repodata, some images and
checksum files)
A new kernel is built:
* Does it pass CI?
* remove old package from package caches/repos and update them.
* is it in a deliverable? yes, almost all of them.
* build and test each deliverable in order of importance.
* If they all pass, release those deliverables (new repos, new images,
new checksums, etc).
This of course really only works for rawhide, and in practice (at least
at first) we would swamp it pretty easily (ie, kernel and coreutils and
dnf update nearly at the same time could result in tons of activity),
but it could be nice down the road as it would mean we are always ready
for a release anytime we choose to do so.
There will of course be cases of caches not updating, or updating, but
not building all the affected outputs. It would also require a lot of
mapping of input to outputs, but almost any approach we have will need
that.
Thoughts?
or better yet: Other concrete ideas how to approach this re-tooling?
kevin
5 years, 5 months
Last dbus upgrade issues
by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.
NM basen network configuration as well is broker because it needs dbus as
well which is not starting.
So many dependencies on dubs looks really terrible/strange/dangerous IMO.
So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.
Can someomeon tell what needs to be done to bring system to usable state?
Level of the verbosity messages written to system logs about what and by
what failed is close to nothing.
BTW when gdm fails console is completely blocked. Only thing which is
possible to do is reboot, go to single mode and after disable gdm service
and reboot is possible to continue troubleshoot system issues.
kloczek
--
--
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
<http://lnkd.in/FXPWxH>*
5 years, 5 months
Changing nsswitch.conf on a running system (was Re:
/etc/nssswitch.conf is supposed to be a symlink now?)
by Ray Strode
Hi,
On Wed, Nov 28, 2018, 9:45 AM Florian Weimer <fweimer(a)redhat.com wrote:
> /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we
> ship it.
>
> If find out which packages replaces our configuration with a symbolic
> link, please file a bug against that package. If they want to take over
> /etc/nsswitch.conf, this is negotiable, but it needs coordination with
> the glibc package.
>
This is a bit of a tangent, but we probably avoid changing
/etc/nsswitch.conf on a running system at all (defer until next offline
update?) until
https://sourceware.org/bugzilla/show_bug.cgi?id=12459
gets fixed. as it stands, no long running daemon will see changes to the
file, I think, leading to potentially weird bugs sometime after authselect
is run right? (and maybe not in an obviously connected way)
Ray
5 years, 5 months
Fedora 30 Self-Contained Change proposal: Migrate Python-based
Nautilus extensions to Python 3
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NautilusExtensionsPython3
The Python backend for the nautilus-python extension will be updated
from python2 to python3. All Nautilus extensions written in Python
will need to be checked for Python 3 compatibility and updated if
necessary. Extensions compatible only with Python 2 will no longer be
supported.
## Owner
Name: Kalev Lember, Frank Dana
Email: klember(a)redhat.com, ferdnyc(a)gmail.com
Release notes owner:
## Detailed Description
The nautilus-python package allows Nautilus extensions to be written
in the Python scripting language. In Fedora releases up to and
including Fedora 29, these extensions were executed in a Python 2
environment. With the general move to Python 3 as Fedora's default
Python runtime and the impending deprecation of Python 2,
nautilus-python will execute extension code in a Python 3 context.
Compatibility with Python 3 will be required for all Python-based
Nautilus extensions.
(Note: In Fedora 28 the nautilus-python package was named
python2-nautilus. For Fedora 29 the name has been reverted to
nautilus-python to better indicate its status as a Nautilus
component.)
## Benefit to Fedora
In addition to eliminating nautilus-python's direct dependency on
Python 2, this change will remove all Python-based Nautilus extensions
from the list of Fedora components which still require the legacy
Python 2 interpreter (which has been deprecated, and is slated for
removal). It will allow us to ensure that all Python-based Nautilus
extensions still in use are fully compatible with Python 3.
## Scope
Proposal owners: Build nautilus-python with Python 3 support and deploy.
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)
## Upgrade/compatibility impact
N/A (not a System Wide Change)
## How To Test
Launch the Nautilus file manager and verify that any functionality
provided by Python-based extensions is still available.
## User Experience
As long as Python 3 compatibility is verified for all Nautilus Python
extensions, users will see no impact from this change. If any
extensions are not compatible with Python 3 and must be removed, users
may notice loss of certain functionality from Nautilus.
## Dependencies
Any Nautilus extensions which use nautilus-python will have to be
checked for Python 3 compatibility. Repackaging should not be
necessary, as the nautilus-python dependency Required by those
packages will be carried forward to Python 3 builds.
The list of packages in the Fedora 29 repos which depend on
nautilus-python is, as of 2018-11-08:
kde-connect-nautilus
nautilus-font-manager
nautilus-pastebin
nautilus-phatch
nextcloud-client-nautilus
nitroshare-extension-nautilus
onionshare
owncloud-client-nautilus
qdigidoc-nautilus
rabbitvcs-nautilus
tilix-nautilus
tortoisehg-nautilus
## Contingency Plan
Continue shipping builds of nautilus-python based on Python 2.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 5 months
compilation of mlt-freeworld-6.12.0 fails
by Martin Gansser
Hi,
want to compile new mlt-freeworld-6.12.0 [1], but it fails in the %install section
...
%install
%make_install
#before remove it print it to check with main mlt package
find %{buildroot} | grep -vP "mlt/avformat|libmltavformat.so"
# remove all execept avformat (ffmpeg part)
find %{buildroot} -type f | grep -vP "mlt/avformat|libmltavformat.so" | xargs rm
find %{buildroot} -type l -delete
find %{buildroot} -type d -empty -delete
..
The error message is:
+ find /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64 -type f
+ xargs rm
+ grep -vP 'mlt/avformat|libmltavformat.so'
rm: cannot remove '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/lossless/Ut': No such file or directory
rm: cannot remove 'Video': No such file or directory
rm: cannot remove '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Quicktime': No such file or directory
rm: cannot remove 'Animation': No such file or directory
rm: cannot remove '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Ut': No such file or directory
rm: cannot remove 'Video': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.KGk9Ye (%install)
[1] https://martinkg.fedorapeople.org/Packages/test/mlt-freeworld.spec
Thanks
Martin
5 years, 5 months
/etc/nssswitch.conf is supposed to be a symlink now?
by Richard W.M. Jones
Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).
We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink. This machine has been
upgraded from F28 and this is not the case. AFAIK I have never edited
the file.
Also:
# authselect check
[error] [/etc/authselect/system-auth] has unexpected content!
[error] [/etc/authselect/password-auth] has unexpected content!
[error] [/etc/authselect/fingerprint-auth] has unexpected content!
[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] [/etc/authselect/dconf-db] has unexpected content!
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
Current configuration is not valid. It was probably modified outside authselect.
which sounds bad, but the error message is not actionable: no
indication how this happened nor how to fix it.
authselect-1.0.2-1.fc29.x86_64
glibc-2.28-20.fc29.x86_64
nss-mdns-0.14.1-2.fc29.x86_64
systemd-libs-239-6.git9f3aed1.fc29.x86_64
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5 years, 5 months
Re: /etc/nssswitch.conf is supposed to be a symlink now?
by Richard W.M. Jones
On Wed, Nov 28, 2018 at 05:02:17PM +0100, Reindl Harald wrote:
>
>
> Am 28.11.18 um 15:45 schrieb Florian Weimer:
> > * Richard W. M. Jones:
> >
> >> Trying to track down a bug in IPP printing
> >> (https://bugzilla.redhat.com/show_bug.cgi?id=1653276).
> >>
> >> We're down a rabbit hole where it seems that in Fedora 29
> >> /etc/nssswitch.conf ought to be a symlink. This machine has been
> >> upgraded from F28 and this is not the case. AFAIK I have never edited
> >> the file.
> >
> > /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we
> > ship it.
> >
> > If find out which packages replaces our configuration with a symbolic
> > link, please file a bug against that package. If they want to take over
> > /etc/nsswitch.conf, this is negotiable, but it needs coordination with
> > the glibc package.
>
> and that's why i do "chattr +i /etc/nsswitch.conf" and "chattr +i
> /etc/resolv.conf" for year - guys stop mangle around in /etc - this is
> admin area and way too often the mdns crap was added unasked or "mysql"
> for nss-mysql touched in the past years finding you perfectly working
> config in a damned .bak file
>
> everything which touchs /etc at updates is broken by design
Yes I've been doing chattr +i /etc/resolv.conf for a very long time.
However in the case of /etc/nsswitch.conf, changing it (with the
cooperation of glibc of course) to be a symlink seems reasonable.
What I'm (still) missing is what's the actual plan? What should
things look like?
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
5 years, 5 months
What does extended F30 cycle mean for F29?
by Kalev Lember
If F31 is delayed by 6 months and F30 is supported for 6 months longer,
does it mean F29 *also* automatically gets a longer cycle since it by
policy becomes EOL when F31 is out + 1 month?
Can we EOL F29 6 months before F31 is out to not have *two* long term
branches to maintain?
--
Kalev
5 years, 5 months