Linterna Magica
by Antonio Trande
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all.
Linterna Magica (http://linternamagica.org/#what-is-it) is a
userscript for watching web video clips inside a browser without the
proprietary flash technology.
Is it practicable the packaging of this script for Firefox/Icecat on
Fedora?
Are there problems as it is a script?
- --
Antonio Trande
mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x66E15D00
Check on https://keys.fedoraproject.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU04+wAAoJEFyovWBm4V0Aq20P/RTjBhSoJs2h9V+PETl5v7iX
GAaAuJZxylyjsCkUCIT+KKm/0qFGNubj6XwOHDg9qFMsvn9RXHccmdjRVCxYhKRV
HKyM9MASLaI8njlcTqqw/WxbrM6MxXNPxLGt8dln67cKi/ScxJ3V1kgMWgyAVDYU
MjM8NYuv3uHplpXu9GiiLU4aSNe2WDZDIw6BtCFstdAVt9AgKroiZYKHj2DzwXhe
u9JbVN4tLAnI9JQkPnJVEN4YDK9xFNZxbJHDXg0NN2DgsPlsws7rjE7G1nW9+nop
h5xRDfTj7p/ra9asLJaoa97qQyltq8Lgp6tRNt9YzjGZa0dMKf69cjvP0Ixu8PWh
UIma0SkAQrNaMJcDPkL8swDCmaYuqDE/Gu9dISLNrJ7gZgrWsN8tgWKTYXmw6bbl
QyjulvvM8BRq/zNqLWG/HF/rCEVv9BG4C3wLCQjGypqMjXr1dnLqhc7IWRegXNtO
Z5SjdPPTdAlOw7tMD0KiII/36bZ0Rh/2E6AnGlTN0VrFl6cxXyzYN3YOJp/LqR97
v2zYsoHt4egxCzXJLXaW8bbA+99m6wckUok0aBD3tjIOGidnl/JJ41qrxC/fl/Jk
xMtrjqMm8ul94uRlTVlhnMciEMkp5mg6Mn0nEYjTBGSLwvsHxyDWk99RSPYo0uMz
fvWRcGwOny6F7RpHeAg4
=E0Pq
-----END PGP SIGNATURE-----
9 years, 2 months
Heads-up: python{,3}-sphinx-latex subpackage in Rawhide
by Michel Alexandre Salim
Hi all,
>From python-sphinx-1.2.2-6.fc22 onwards support for building LaTeX
documentation using Sphinx has been split off into the -latex subpackage
(so that Sphinx can be installed without pulling in TeXLive).
(There's also a bug discovered when doing this split -- the python3 build
wasn't shipping with locale files).
As we're not doing a mass rebuild this time round, this change should have
minimum impact.
For maintainers of packages that use Sphinx for building documentation,
please check if you're generating PDFs -- and if so, add a BR on
python-sphinx-latex.
Hat tip to Robert Kuska for the suggestion and feedback.
Best regards,
--
Michel Alexandre Salim
9 years, 2 months
Systemd, Spamassassin, and the Missing Portreserve Package
by Tom Rivers
Hello all,
While configuring a new Fedora 21 workstation yesterday evening, I ran
into something that I found interesting. I installed Spamassassin,
tried to start it, and got the following entry in the logs:
systemd: Failed at step EXEC spawning /sbin/portrelease: No such file or
directory
After checking "yum whatprovides /sbin/portrelease", I found it
referenced portreserve-0.0.5-11.fc21.x86_64 which was not installed with
Spamassassin as a dependency. Just for kicks, I looked for portrelease
in the relevant systemd directory and found only Spamassassin was using it:
# grep -R portrelease /usr/lib/systemd/system
/usr/lib/systemd/system/spamassassin.service:ExecStartPre=-/sbin/portrelease
spamd
Does anyone know if this behavior is expected? The fix is easy enough,
but I figured I should ask just in case it's not by design.
Thanks!
Tom
9 years, 2 months
F22 System Wide Change: Systemd Package Split
by Jaroslav Reznik
= Proposed System Wide Change: Systemd Package Split =
https://fedoraproject.org/wiki/Changes/SystemdPackageSplit
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Split systemd-units out of the main systemd package
== Detailed Description ==
Systemd contains many binaries and depends on a fairly large number of
libraries. Packages which carry systemd units currently have to depend on
systemd (through %post, %preun, %postun macros used to install and uninstall
systemd units), which grows the dependency tree and increases the size of
minimal installs.
With this proposal systemd-units subpackages will be split out again:
systemd-units
This subpackage will contain the directories and binaries necessary to satisfy
%post, %preun, %postun macros for packages containing systemd units
(systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config
information (pkg-config files).
The main systemd package would require this package so it will be pulled in on
all existing systems. All packages which have BuildRequires:systemd will also
pull it in transitively.
Systemd previously had a -units subpackage and ~150 packages still depend on
it. Those packages would start using the reduced subpackage immediately. Other
packages wishing to use the reduced dependency, would have to change the
BuildRequires and Requires to systemd-units.
== Scope ==
* Proposal owners: Create the subpackage, test that macros work as expected.
* Other developers: Change the BuildRequires and Requires to systemd-units if
wanted.
* Release engineering: None
* Policies and guidelines: s/systemd/systemd-units/ in the appropriate places.
== Contingency Plan ==
* Revert the packaging change and rebuild systemd. Main systemd package would
provide systemd-units, as it does now, so no other changes should be
necessary.
* Contingency deadline: should be possible at any time.
* Blocks release? No.
* Blocks product? No.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 2 months
FYI: new kojipkgs in place
by Kevin Fenzi
Greetings.
I just thought I would let everyone know that I have moved
kojipkgs.fedoraproject.org over to a new instance.
Old instance was a rhel6 vm with apache/squid and 8gb mem.
New instance is a rhel7 vm with newer apache/squid and 64gb mem.
I have also adjusted squid to try and keep bigger and more objects in
memory since the new instance has memory to spare.
Things seem to be working fine, but if you notice a build failing due
to something that seems related to kojipkgs or notice problems
downloading from kojipkgs, please let me know.
Thanks,
kevin
9 years, 2 months
Proper setting of %ghost file spec section in order to rpm -V to be silent wrt to mode differs ('M') change - handling db & log files
by Jan Lieskovsky
Hello folks,
(apologize for the wide distribution, hopefully someone would be able
to help me with the issue below).
we develop a tool performing security scans / audits of the system. This tool
is able to compare the system in question against various rules. And one of these
rules ('Verify and Correct File Permissions with RPM') fails on common (RHEL-6)
system.
When inspecting the failure more deeply noticed all these files are marked as
%ghost files in particular *.spec file. The test is failing due to changed group
ownership & mode on these files.
Having look at:
[1] http://fedoraproject.org/wiki/PackagingDrafts/Logfiles
suggests it should be possible to define particular *.spec %ghost section that way,
so rpm -V would be silent (at least wrt to 'md5', 'size' & 'mtime' attributes).
Since the files marked as %ghost are kinda special:
[2] http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html
wondering if it's even possible to classify the %ghost file in particular *.spec
file that way, so rpm -V wrt to group ownership & mode changes would be silent.
If I got the %ghost directive meaning [2] correctly:
* RPM knows about the ghosted file (it's saved into RPM db),
* but it will not add it to the package (but in the moment of build
that file needs to be present in the buildroot),
* that file will be marked as owned by the package, and will be
removed when the package is removed,
* that file won't be visible from package file's listing (rpm -ql),
* [2] also mentions it's possible to use 'rpm --setperms' on the ghosted
file to fix it permissions.
The question:
Suppose 'rpm -V' reports group ownership change & mode change failure. The
question is how to write the corresponding *.spec %ghost section this not
to be reported?
Use something like:?
%ghost %verify(not group mode md5 size mtime} file_path
Wouldn't this tell RPM that if there's change in some of group / mode / md5 / size / mtime
attribute of that file, that this change should be ignored?
Or instead of blessing the attribute like above, it's better to get the:
* expected group owner & mode for that %ghost file from RPM db,
* and in the moment of creating that file call 'chgrp / chmod' with
the expected values?
For case someone would be interested in data wrt to these failing files, those
are mainly db / SQLite / log or pid files. Some examples:
* /var/log/gdm
* /var/run/gdm
* /var/run/abrt.pid
* /var/lib/rpm/__db.*
* /var/lib/mlocate/mlocate.db
* /var/lib/PackageKit/transactions.db
* .. etc etc
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
9 years, 2 months
on software updates
by Casey Jao
Warning: long post ahead.
Are there any plans to let packages specify that they do not require a
total system reboot to be updated?
The other day, Gnome software prompted me to reboot just to update google
chrome. Given that nothing depends on chrome, and also that the Linux
version of chrome is specifically designed to tolerate having its files on
disk overwritten (
http://neugierig.org/software/chromium/notes/2011/08/zygote.html),
rebooting the whole system seems overkill to ensure a successful update.
Presenting users with an option to restart only the affected processes and
not their whole computer would improve security by reducing the friction
when applying software updates. While restarting a browser is no big deal
because it takes no more than a few seconds to complete and all your tabs
are restored, restarting the computer is far more disruptive. The latter
procedure not only takes much longer but also closes all the other windows
the user has open, and the state of those windows is typically not
preserved across reboots. The average users would likely put off updating
their web browser if they were asked to quit everything they are doing.
On OS X and Windows, user-facing apps typically manage their own updates,
and the well-designed apps make the experience quite painless. For example,
both Firefox and Chrome on OS X download new versions in the background and
prompt the user to relaunch the browser once the update is fully prepared.
The user transitions to the new version seamlessly.
On Ubuntu, Firefox is updated by the system package manager but prompts the
user to relaunch the program if it is running. This is probably
ubuntu-specific behavior and I don't know how it is accomplished or how
robust it is, but that would seem a nice example to follow, at least in
terms of UX, if it could be implemented using general methods.
Just a stupid idea: perhaps one can specify some dbus method that
that applications declaring support for online updates could implement.
Prior to initiating the update process, Gnome software could 1) check to
see if all the applications in the queue have declared support for online
updates (say, in their appdata manifest), and 2) call said method to warn
each app that it is about to be updated. Each app would then decide how to
proceed; for instance, it could do nothing, ask the user to save and quit
temporarily, or trigger some session-saving mechanism.
In the long term, this issue will undoubtedly be addressed as part of the
push toward frameworks and a clearly defined "base platform". In that
future, the software updater could prompt the user to reboot for framework
updates while giving applications the option to handle some aspects of
their update process.
But is there anything planned for the interim? Prompting users to restart
the system to update a browser seems less than, and the last thing we want
to do is condition users to postpone updates indefinitely like they grew
accustomed to doing on Windows.
9 years, 2 months