Rstudio
by Steve Grubb
Hello,
I like to have everything on my system in a package. So, I looked around and
found no recipe or rpm for Rstudio. This is really a shame because every
tutorial on R kinda tells you to install it. Even the Coursera classes in the
Data Science track make you install it and send a screenshot to prove it.
So, I spent some time getting it packaged and working. I am placing the spec
file and necessary patch here so that google finds it and saves other people the
trouble. I'm not wanting to submit the package to Fedora because its more work
than I have time for. If anyone else wants to take it from here and submit
and/or maintain it, feel free.
http://people.redhat.com/sgrubb/files/Rstudio/
Enjoy...
-Steve
6 years, 1 month
SciDAVis and liborigin3 vs liborigin & liborigin2 - bundle or obsolete?
by Alexander Ploumistos
Hello,
Since its retirement from Fedora, SciDAVis[0] has undergone
significant development and I think it is ready to be re-included in
our package collection. After a few months of private builds that I
distributed among co-workers and friends, I set up a copr[1] and I've
been keeping up with the upstream project.
SciDAVis comes with a bundled copy of liborigin[2], which the upstream
developers helped me unbundle. Its version has been bumped to 3.0.0
internally, although there hasn't been a 3.0.0 release yet. In Fedora
we carry liborigin2 (code from the latest public release) and
liborigin (snapshot from 2008) which both help import different
versions of Origin project files. The new release will render them
both obsolete.
SciDAVis and liborigin share a number of contributors, but at the
moment their codebases have diverged; upstream liborigin trunk has
been adjusted to work with development versions of LabPlot 2.x, while
the copy bundled with SciDAVis is closer to that of a future
liborigin-3.0.0 release, but they are not interchangeable. I asked the
developers to clarify their plans and I was told[3] that the two
versions will merge back, though some API changes might come in the
meantime.
I have checked if there are any packages at the moment that require
liborigin* or liborigin*-devel and I have found none (though I'd be
grateful if someone who feels more at ease with dnf could
double-check). If not for this divergence, I would submit scidavis and
liborigin3 for review as separate packages, with Provides & Obsoletes
for the previous liborigin* and liborigin*-devel versions and be done
with it. However I would have to use the unbundled copy from SciDAVis
as source for liborigin3. Should I proceed with that anyway or should
I keep it bundled until such time as the two codebases have merged?
Best regards
Alex
0. https://sourceforge.net/projects/scidavis/
1. https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/
2. https://sourceforge.net/projects/liborigin/
3. https://sourceforge.net/p/scidavis/discussion/708155/thread/4c8da018/#cf6b
6 years, 2 months
Using devtoolset for EPEL builds
by Zuzana Svetlikova
Hi,
I need/want/would like to build new node 6 for EL6, but gcc is too old.
For that reason, I'd like to use devtoolset-4-gcc, but the build fails
(obviously) because the package doesn't exist.
So, is there a way to make that work somehow?
I am not sure about enabling external repos during build, maybe someone
will be wiser.
Here's the build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15970697
Zuzka
6 years, 2 months
apitrace, bundled libbacktrace
by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?
Thanks,
Sandro
6 years, 3 months
Trying to contact developer Axel Thimm
by Stephen John Smoogen
We have been getting bounced emails from Axel Thimm for a while and I
don't have any other way to contact him. He was an early maintainer of
packages but has not been seen in fas since 2013.
He is the co-maintainer of the following packages:
rpms/apt -- Debian's Advanced Packaging Tool with RPM support ( master f26 f25 )
rpms/arpack -- Fortran 77 subroutines for solving large scale
eigenvalue problems ( master f26 f25 )
rpms/chrpath -- Modify rpath of compiled programs ( master f26 f25 )
rpms/courier-unicode -- A library implementing algorithms related to
the Unicode Standard ( master f26 f25 )
rpms/fail2ban -- Daemon to ban hosts that cause multiple
authentication errors ( master f26 f25 )
rpms/fakechroot -- Gives a fake chroot environment ( master f26 f25 )
rpms/fakeroot -- Gives a fake root environment ( master f26 f25 )
rpms/fedora-package-config-apt -- Fedora configuration files for the
apt-rpm package manager ( master f26 f25 )
rpms/freenx-server -- Free Software (GPL) Implementation of the NX
Server ( master f26 f25 )
rpms/ivtv-firmware -- Firmware for the Hauppauge PVR
250/350/150/500/USB2 model series ( master f26 f25 )
rpms/libcdaudio -- Control operation of a CD-ROM when playing audio
CDs ( master f26 f25 )
rpms/maildrop -- Mail delivery agent with filtering abilities ( master f26 f25 )
rpms/perl-Text-CharWidth -- Get number of occupied columns of a string
on terminal ( master f26 f25 )
rpms/perl-Text-WrapI18N -- Line wrapping with support for several
locale setups ( master f26 f25 )
rpms/php-pear-Auth-OpenID -- PHP OpenID ( master f26 f25 )
rpms/po4a -- A tool maintaining translations anywhere ( master f26 f25 )
rpms/synaptic -- Graphical frontend for APT package manager. ( master f26 f25 )
rpms/vtk -- The Visualization Toolkit - A high level 3D visualization
library ( master f26 f25 )
If anyone has had contact with him could he see if can fix his email?
Thanks.
--
Stephen J Smoogen.
6 years, 3 months
Improving Linux laptop battery life: Testers Wanted
by Hans de Goede
Hi All,
My next project for Red Hat is to work on improving Linux laptop battery life.
Part of the (hopefully) low hanging fruit here is using kernel tunables to
enable more runtime powermanagement. My first target here is SATA Link Power
Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
https://mjg59.dreamwidth.org/34868.html
can lead to a significant improvement in battery life.
There is only one small problem, there have been some reports that some
disks/SSDs don't play well with Linux' min_power LPM policy and that this
may lead to system crashes and even data corruption.
As such I've written a new LPM policy, which matches the power-management
defaults from the Intel RST Windows drivers. Since it mimicks Windows,
this new policy will hopefully not hit any SSD firmware bugs like min_power
sometimes does.
So now I'm looking for people with a laptop with a SATA SSD or HDD to help
me test this to make sure this won't cause any issues when we enable this
by default for F28, for more details and test instructions see:
https://hansdegoede.livejournal.com/18412.html
Regards,
Hans
6 years, 3 months
F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik
= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
Change owner(s):
* Kai Engert <kaie(a)redhat.com>
Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).
Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.
Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".
As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.
By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.
The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.
== Scope ==
* Proposal owners:
A small downstream patch needs to be applied to the NSS library
package, which changes the library default.
* Other developers:
It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.
* Release engineering: [1]
No help should be necessary. No mass rebuild necessary.
* Policies and guidelines: N/A
* Trademark approval: N/A
[1] https://pagure.io/releng/issue/6883
Thanks,
Jaroslav
6 years, 3 months
GCL and SELinux: help requested
by Jerry James
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry(a)gmail.com> wrote:
> I don't believe that anybody looks at those pull requests on a regular
> basis. Should somebody be doing so? There are 8 pull requests,
> dating back to about the time of the above conversation. Five of
> those don't contain a single comment.
>
> I opened one for gcl on July 29, and added a comment a month later
> asking if somebody was going to look at it. No response. This is a
> bit annoying, considering that I opened a bugzilla request asking for
> the same thing 4 years ago, and no action has ever been taken on it.
> I thought maybe a PR would finally get something to happen.
Nearly a week has gone by, and no answer. I'm really stumped about
what to do. Let me summarize the whole long saga and solicit help.
GCL is a Common Lisp implementation. It is known for its speed
compared to other CL implementations. It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue. At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon. I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.
Fast forward to 2013. By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator. I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket. In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just. Could. Not. Stay. On. Topic. We talked about the execheap
permission in general, and its place in the universe. Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.
Fast forward to 2017. Attempts to build maxima with gcl on aarch64
started hanging at package install time. See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed
on gcl, incorrectly I believe. As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy. So, policycoreutils maintainers! Something Is Afoot
on aarch64!
But that's not the end of the fun. GCL failed the mass rebuild this
summer. It built successfully on every architecture but s390x. On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders? And, if so, has it been
rectified since? If so, I'll try building again.
I still want the system policy to account for GCL, in some way or
another. But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>. And pointing that out on this list last weekend
has resulted in still more of the crickets.
So ... what is a packager supposed to do???? Why is it so hard to get
any attention for submissions to the system SELinux policy? There
should be a barrier to entry; I understand that. But I can't even get
the gatekeeper to have a conversation with me. Heeeeellllllppppp!!!
Frustratedly yours,
--
Jerry James
http://www.jamezone.org/
6 years, 3 months