upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
1 year, 4 months
by Michael J Gruber
I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
1 year, 8 months
Intel's Clear Linux optimizations
by František Zatloukal
Phoronix recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
Best regards / S pozdravem,
4 years, 3 months
by Steve Grubb
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.
5 years, 4 months
Using devtoolset for EPEL builds
by Zuzana Svetlikova
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:
5 years, 4 months
apitrace, bundled libbacktrace
by Sandro Mani
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
5 years, 5 months
Two more concrete ideas for what a once-yearly+update schedule would
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
Option 1: Big batched update
1. Release F26 according to schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
Fedora Project Leader
5 years, 9 months