How to build one TeXLive subpackage for EPEL-7?
by Matěj Cepl
Hi,
I would like to build lilypond for EPEL-7, but unfortunately it
requires texlive-metapost which we don't have in the RHEL-7
texlive. Now, the question is how to build just one subpackage
(or any required other subpackages) from the monstrosity which
the current texlive? Anybody any suggestions?
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Ty zlý dávaj’ ty hodný pryč. // Those evil ones put away those good ones.
-- Magda Ceplová
8 years, 9 months
F23 System Wide Change: Netizen Spin
by Jan Kurik
= Proposed Self Contained Change: Netizen Spin =
https://fedoraproject.org/wiki/Changes/Netizen_Spin
Change owner(s): Corey Leong <cleong at fedoraproject dot org>
A Fedora Spin for promoting and supporting internet citizenship and citizen engagement.
== Detailed Description ==
Fedora Netizen is an open source operating system for enabling internet citizens to engage with online services and communities. The goal for Netizen is to pattern the operating system's features after Maslow's Hierarchy of Needs which was published in his 1943 paper, "A Theory of Human Motivation". As a professor of pyschology, Abraham Maslow theorized that individuals attempt to experience five stages of needs starting with physiological, safety, social, esteem, and then ending with self-actualization. Beginning with the first level of physiological needs, individuals' motivational needs ascend upwards to higher levels of needs in order, however, only after establishing lower levels of needs first before ascending to the next level.
The philosophy for Netizen closely relates to Maslow's Hierarchy of Needs by establishing three primary software package levels in a hierarchical model. The first and lowest software package level addresses the need for Netizen Privacy in the areas of personal privacy, informational privacy, and communication privacy. After Netizen Privacy, the second software package level addresses the need for Netizen Security in the areas of data security, local security, and network security. After Netizen Security, the third software package level addresses the need for Netizen Engagement in the areas of publishing, education, and social engagement.
Future Netizen software package levels will address analytics, awareness, design, develop, and others.
== Scope ==
A Netizen theme is the final requirement to be developed per marketing department support of a look and feel in order to replace the current default theme. This is an isolated change.
* Other developers: N/A (not a System Wide Change)
* Release engineering: Add spin to spin-kickstarts, ensure spin has been tested, and release with rest of spins
* Policies and guidelines: N/A (not a System Wide Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 10 months
GCC 5 compatibility problems: GCC 4.10?
by Paolo Bonzini
Hi all,
I'm encountering a few problems with GCC 5 due to code that fails to
work with GCC major releases above 4. In particular, there are at least
problems with the kernel and with Coverity.
Unfortunately, downgrading to Fedora 21's GCC 4.9 is very hard in Fedora
22, unless you only care about the C compiler. This is because the C++
compiler wants a matching libstdc++, and most C++ packages need the GCC
5 libstdc++ (maybe because of the ABI changes, I don't know).
Is it outrageous to ask for a "compatibility" GCC package that declares
itself as 4.10? This is similar to how kernel 3.0 was initially
packaged as 2.6.40. Or perhaps there is another possibility that I
haven't thought of?
Thanks,
Paolo
8 years, 10 months
Intel driver pain
by Sergio Belkin
Hi,
Could you tell me if anyone else is having this kind of issues:
[vie may 29 07:01:22 2015] [drm] Initialized drm 1.1.0 20060810
[vie may 29 07:01:22 2015] [drm] Memory usable by graphics device = 2048M
[vie may 29 07:01:22 2015] fb: switching to inteldrmfb from EFI VGA
[vie may 29 07:01:22 2015] [drm] Replacing VGA console driver
[vie may 29 07:01:22 2015] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[vie may 29 07:01:22 2015] [drm] Driver supports precise vblank timestamp
query.
[vie may 29 07:01:22 2015] [drm] Initialized i915 1.6.0 20150130 for
0000:00:02.0 on minor 0
[vie may 29 07:01:22 2015] fbcon: inteldrmfb (fb0) is primary device
[vie may 29 07:01:22 2015] [drm:intel_set_pch_fifo_underrun_reporting
[i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[vie may 29 07:01:22 2015] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
*ERROR* PCH transcoder A FIFO underrun
[vie may 29 07:01:23 2015] i915 0000:00:02.0: fb0: inteldrmfb frame buffer
device
Thanks in advance
--
--
Sergio Belkin http://www.sergiobelkin.com
LPIC-2 Certified - http://www.lpi.org
8 years, 10 months
libblockdev reaches the 1.0 milestone!
by Vratislav Podzimek
A year ago, I started working on a new storage library for low-level
operations with various types of block devices -- *libblockdev*. Today,
I'm happy to announce that the library reached the **1.0** milestone
which means that it covers all the functionality that has been stated
in the initial goals and it's going to keep the API stable.
Read the blog post I wrote for more information:
http://blog-vpodzime.rhcloud.com/?p=61
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
8 years, 10 months
fedup for F23 and beyond
by Will Woods
[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]
Hey all,
F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work (and how they fail).
We've come to the conclusion that the current design is unsupportable,
mostly due to upgrade.img, which turns out to cause more problems than
it solves[1].
So! For F23, fedup needs to be redesigned. Here's how it should work:
1) Download packages for the new system
2) Use the systemd Offline Updates[2] facility to install packages
This is really simple - simple enough that it should probably be
provided by the system packaging tools themselves.
As a proof-of-concept, I've implemented it as a DNF plugin, which you
can see here[3]: https://github.com/wgwoods/dnf-plugin-fedup
This behavior could also be implemented by PackageKit, which would make
it easy to write a proper GUI.
So that's the plan: drop upgrade.img, move upgrade support into the
system packaging tools. Sometimes simpler is better.
-w
[1] For example, here are three F22 release-blockers, all caused by
upgrade.img:
https://bugzilla.redhat.com/show_bug.cgi?id=1185604
https://bugzilla.redhat.com/show_bug.cgi?id=1209941
https://bugzilla.redhat.com/show_bug.cgi?id=1207251
That first one is a nasty crash inside systemd, which led to a
mailing-list discussion[1a] where Lennart concludes that the
double-switchroot thing we're doing with upgrade.img is just not
supportable[1b]. And I totally agree.
[1a] http://lists.freedesktop.org/archives/systemd-devel/2015-March/029030.html
[1b] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031013.html
[2] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
[3] It works just fine in F21, if you're feeling brave..
8 years, 10 months
Unison in Fedora
by Richard W.M. Jones
[Previous discussion here:
https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.htm... ]
Unison is a fairly widely used file synchronization package. Think of
it as a more efficient, multi-directional 'rsync'.
Unison has the unfortunate property that versions of Unison are not
compatible with each other unless they have the exact same major.minor
release. eg. Unison 2.40.128 is compatible with Unison 2.40.102, but
incompatible with Unison 2.48.3 (the latest upstream).
The reason that matters is you might be running Unison across multiple
machines, running different Linux distros, which have different
versions of Unison.
For this reason, Fedora packages three different Unison branches in
separate packages:
- unison213 (currently Unison 2.13.16)
- unison227 (currently Unison 2.27.57)
- unison240 (currently Unison 2.40.128)
- There was a "unison" package, but it is retired
We don't package the latest upstream (Unison 2.48.3) at all[1].
For comparison, Debian packages:
- unison2.27.57
- unison2.32.52
- unison (which contains 2.40.x)
- unison-all, a meta-package, which pulls in all of the above
AFAICT Debian also does not package the latest upstream version.
So you can see that someone who needed to synchronize across Fedora
and Debian machines would have two compatible choices:
- Fedora unison227 <-> Debian unison2.27.57
- Fedora unison240 <-> Debian unison
Anyway, I think this situation is crazy. One reason is that in order
to add the latest upstream Unison (2.48) I'm going to have to submit a
new unison248 package[1]. And then if there's another version, I'll
have to submit a new package for that.
I think Fedora should have a single "unison" source package, and it
should contain the multiple upstream branch sources and build
different binary subpackages. The binary subpackages would have the
same names as now (unison227 etc), making this a compatible update for
existing Fedora Unison users.
This way I only need to submit a single new package review, we can
delete the unison2xx source packages, and there'll be a single place
for unison in Fedora for ever more.
Discuss ...
Rich.
[1] BTW there is a COPR build of unison248 if you search for it.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
8 years, 10 months
