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
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 8 months
Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler
Hi,
the current xine-lib maintainer speaking. :-)
The Xine project:
http://www.xine-project.org/home
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/...
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
server.
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
Comments? Objections?
Kevin Kofler
9 years, 11 months
appliance-creator: how can I shorten the grub timeout in kickstart?
by Matthew Miller
This perplexing to me. In my %post section, I tried both writing
"GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set
timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the
config file after doing those things.
But on boot, grub.cfg file always contains timeout=5. Why / how is this
happening?
I'm using appliance-creator, in case that's doing anything silly.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10 years, 3 months
replacing folders with symlinks leads to rpm cpio rename errors
by Julian Sikorski
Hi list,
one of the updates I am preparing is supposed to replace some of the
folders with symlinks. Unfortunately, this leads to rpm cpio: rename
errors upon an update attempt. Is there a standard way of dealing with this?
Regards,
Julian
10 years, 3 months
Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
by Simone Caronni
Spinning of from this, I think there is some mess around the Virtio
drivers; I would be glad if someone could explain that to me.
Sorry for the length of this mail but I could not shorten it.
Let's say I would like to grab the latest virtio drivers and tools for my
Windows guest and the accompanying source code; this is what I found:
1) Recent version from Fedora in iso format
- No WHQL, no changelog, no QXL drivers, no Spice Agent available, no source
- Updated every once in a while
http://secondary.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
2) Roughly the same versions of Fedora, in zip format
- No WHQL, no changelog, no QXL drivers, no Spice Agent but the changelog
available.
- All the changelog points to an internal Redhat git repository.
- From my understanding, these tarballs are the one that every once in a
while make their way into the Fedora iso and the "pre WHQL" Redhat ones.
- The source is there in a zip file.
http://people.redhat.com/vrozenfe/
3) Official Spice Agent (very old and buggy):
http://spice-space.org/download/binaries/vdagent-win32_20111124.zip
4) Spice Guest Tools setup
- Unofficial Spice Agent, built from the latest sources using the mingw
based package:
- Latest Fedora iso drivers
- Recent built from source QXL driver, but unfortunately unsigned so it
doesn't work properly in Fedora.
- The Balloon Service is not installed as part of the setup
http://spice-space.org/download/binaries/spice-guest-tools/
5) Official RHEL drivers (need an account for this)
- virtio-win-1.5.3-1.el6_3.noarch.rpm
- Contains signed and WHQL drivers for everything.
- Always a bit older than the Fedora ones.
- Follows the same numbering and logs as no. 2.
- Contains signed WHQL drivers for Windows XP and Windows 7 32/64 bits, but
outside of the normal iso (why?)
- Does not contain the Spice Agent.
6) Yan Vugenfirer's repository
- Contains only source, and is public.
- Does not match with Fedora or RHEL provided drivers.
- Contains only the Virtio drivers, no Spice Agent or QXL driver.
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commits/master
7) QXL drivers for various targets
- Sometime, someone builds an updated driver and posts it to the
spice-devel mailing list.
- All the drivers are not signed, of course.
======
So far, my best setup is to recreate an iso everytime there is an update to
the following:
- Latest Fedora drivers for Windows XP, 2003
- Latest QXL binary from the Spice Guest Tools for Windows XP
- Latest signed RHEL drivers for Windows Vista and up
- Latest signed QXL driver for Windows Vista and up
- Latest Spice Agent binary from the Spice Guest Tools
I would say this is suboptimal, especially when I try to explain someone
moving from Windows that si trying to virtualize Windows on their newly
converted laptop.
At the best case, they don't have the QXL driver, causing lag in the
desktop, no Spice Agent for cut&paste and usually a lot of problems with
Windows 7.
Before this, I used to compile drivers myself with the DDK following the
instructions. This gave me the option to compile the QXL drivers for
Windows 2003 and Windows 2008 targets as well, but I always had the same
problems with signing.
======
Since all the problems go back to signing the binaries for making them work
out of the box in Windows Vista/7/2008/2008r2/8, I would like to know if
it's possible to do this from time to time:
- Have Fedora build the latest Virtio drivers (this is already done)
- Build also the Spice Agent for 32/64 bit (this is done at
spice-space.orgas part of the Spice Guest Tools)
- Build the latest QXL drivers for all the Windows targets supported by the
Virtio drivers (I know the Windows 8 XWDM driver will come eventually later)
- Sign everything with the Redhat key, as it's doing for the drivers at
point 2.
- Pack everything into an iso.
I'm not asking for WHQL as I understand this is a "benefit" for the Redhat
subscriptions.
All the bits are there except they are dispersed everywhere, so I don't
think it's a big effort.
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
10 years, 4 months
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
by Jakub Jelinek
Hi!
As part of preparations for possible switch of system compiler in F19
to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass
rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19
on x86_64, and for those packages that failed also rebuilt the same
package with gcc-4.7.2-9.fc19 to quickly remove from the list packages
that fail for non-gcc related reasons.
11687 packages built fine, 933 packages failed to build with
both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm
(ignored for this analysis, unlikely to be gcc 4.8 related).
The remaining packages, that failed to build with 4.8.0-0.1
and succeeded with 4.7.2-9 are listed below. 67 of these look
like issues on the package side, 22 gcc bugs that were supposedly
fixed by now upstream and thus should be ok in 4.8.0-0.3 when
it is built next week and 3 are not yet fixed gcc issues.
CCing Benjamin if he is again interested in writing
http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this
information useful.
Besides build failures, the -Wsizeof-pointer-memaccess
warning triggered in several packages that succeeded building,
but it would be nice if package maintainers actually checked those
and fixed up, most likely those are real package bugs. The list of such
packages is included in first attachment.
For the more aggresive loop optimizations if the loop contain undefined
behavior, while it caused build failures just for 12 packages during the
mass rebuild, supposedly more packages will be affected, just the problems
weren't triggered during package build. Usually such loops are either
turned into infinite loops that soon crash, or hang, or as can be seen
on the perl-PDL case loops can be turned into just conditional non-looping
code (e.g. when compiler assumes that it can validly loop just at most
once).
blktap-2.0.90-6.git20111216.62de90d.fc18.src.rpm
cdrkit-1.1.11-14.fc19.src.rpm
elfutils-0.155-1.fc19.src.rpm
isomd5sum-1.0.9-2.fc18.src.rpm
libopensync-plugin-opie-0.22-8.fc18.src.rpm
linphone-3.5.2-4.fc18.src.rpm
lldpad-0.9.45-3.fc19.src.rpm
openvas-libraries-5.0.4-1.fc19.src.rpm
pilot-link-0.12.5-13.fc18.src.rpm
sh-elf-binutils-2.21-5.fc19.src.rpm
packages built with -Werror, for which the new
-Wsizeof-pointer-memaccess warning included in -Wall warns
and -Werror makes a fatal error out of it
bamf-0.2.104-4.fc18.src.rpm
byzanz-0.3-0.5.fc17.src.rpm
fvkbd-0.2.2-6.fc18.src.rpm
gedit-collaboration-3.6.0-1.fc18.src.rpm
gtkimageview-1.6.4-6.fc18.src.rpm
gypsy-0.8-6.fc17.src.rpm
libindicator-0.4.94-3.fc18.src.rpm
ltrace-0.7.0-1.fc19.src.rpm
mail-notification-5.4-64.git.eab5c13.fc19.src.rpm
ModemManager-0.6.0.0-2.fc19.src.rpm
physfs-2.0.2-3.fc18.src.rpm
roboptim-core-0.5-6.fc18.src.rpm
v8-3.10.8-2.fc18.src.rpm
xen-4.2.0-6.fc19.src.rpm
packages built with -Werror, for which the new
-Wunused-local-typedefs warning included in -Wall warns
and -Werror makes a fatal error out of it
trafficserver-3.2.0-3.fc18.src.rpm
package built with -Werror, and -Wmaybe-uninitialized warns
about possibly uninitialized fields which are uninitialized
if inc_gmtime_r returns -1 (and ink_time_current_mdy doesn't
bother to check that return value)
armacycles-ad-0.2.8.3.2-3.fc18.src.rpm
irrlicht-1.8-1.fc19.src.rpm
kdevelop-4.4.1-2.fc19.src.rpm
kst-2.0.3-7.fc18.src.rpm
maildrop-2.5.0-17.fc18.src.rpm
megaglest-3.7.1-1.fc19.src.rpm
opal-3.10.9-2.fc19.src.rpm
oxygen-gtk2-1.3.1-1.fc19.src.rpm
oxygen-gtk3-1.1.1-2.fc19.src.rpm
supertuxkart-0.7.3-3.fc19.src.rpm
syncevolution-1.3.2-1.fc19.src.rpm
gcc bug - internal compiler error in inline_call,
fixed upstream already, see http://gcc.gnu.org/PR55683
pari-2.5.3-1.fc19.src.rpm
gcc bug - internal compiler error in LRA,
fixed upstream already, see http://gcc.gnu.org/PR55775
avrdude-5.11.1-2.fc18.src.rpm
gcc bug - internal compiler error in remove_redundant_iv_tests,
fixed upstream already, see http://gcc.gnu.org/PR55684
openttd-1.2.2-1.fc19.src.rpm
gcc bug - the package is built with LTO, and the problem
is extremely hard to reduce, just rebuild without --with-lto
for now
b43-openfwwf-5.2-8.fc18.src.rpm
ccache-3.1.8-1.fc18.src.rpm
openchange-1.0-12.fc19.src.rpm
openttd-opengfx-0.4.5-1.fc19.src.rpm
samba-4.0.0-171.fc19.rc6.src.rpm
/usr/include/stdc-predef.h issues
gcc preprocessor now in C/C++ modes automatically includes
<stdc-predef.h> header, packages which are using preprocessor
for non-C/C++ code or doing weird things with the preprocessor
might run into issues. For non-C/C++ code, it is always better
to preprocess as assembly instead of C
libxc-1.2.0-2.fc18.src.rpm
/usr/include/stdc-predef.h issues - using cpp -C -ansi to preprocess
Fortran sources is simply a very bad idea
adobe-source-libraries-1.0.43-13.fc19.src.rpm
asl-gcc.patch patch needs to be tweaked also for GCC 4.8
aws-2.11.0-11.fc19.src.rpm
gprbuild-2011-5.fc18.src.rpm
matreshka-0.3.0-2.fc19.src.rpm
needs dependencies rebuilt with GCC 4.8 gnat
cp2k-2.3-1.fc19.src.rpm
loop iterator passed as INTENT(INOUT) argument, see http://gcc.gnu.org/PR30146
dragonegg-3.1-18.fc19.src.rpm
needs to be ported to GCC 4.8+
flterm-1.0-1.rc3.fc18.2.src.rpm
gedit-code-assistance-0.1.5-1.fc18.src.rpm
hfsplus-tools-540.1.linux3-2.fc18.src.rpm
clang needs to be updated not to require libstdc++-devel 4.7
gambas3-3.3.4-2.fc19.src.rpm
gcc bug for --enable-checking=yes compiler only, see http://gcc.gnu.org/PR55878
distro compilers are always --enable-checking=release, so non-issue
except for the testing compiler
gccxml-0.9.0-0.13.20120309.fc19.src.rpm
supposedly needs to be ported for GCC 4.8, some tests failed
getdata-0.7.3-3.fc18.src.rpm
GCC is now more aggresive in turning loops that invoke undefined
behavior into endless loops. In test/get_uint32.c there is:
uint32_t data_data[128];
int fd, n, error, r = 0;
...
for (fd = 0; fd < 128; ++fd)
data_data[fd] = fd * (0x02000001);
When fd is 64 or above, fd * 0x02000001 overflows, which is invalid
in C/C++ for signed types (int here). To fix use
data_data[fd] = fd * 0x02000001U;
or
data_data[fd] = (uint32_t) fd * 0x02000001;
etc. instead.
sys_basher-1.1.24-3.fc18.src.rpm
similarly to getdata bug:
for(i=0;i<MAX_THREADS;i++)
{
csvt[i] = 0;
seed[i] = (i + 1LL) * 0x0123456789ABCDEFLL;
}
again, should have been 1ULL or 0x0123456789ABCDEFULL (or both)
ipv6calc-0.93.1-3.fc18.src.rpm
similarly to getdata bug:
for (i = 0; i < (int) (sizeof(newidentifier->in6_addr.s6_addr) / sizeof(newidentifier->in6_addr.s6_addr[0])); i++) {
/* copy into */
newidentifier->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i];
newtoken->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i + 8];
};
s6_addr array size is 16 (i.e. i < 16 is the loop condition), digest
array has size 16, but obviously for i 8 and above the [i + 8]
accesses are all out of bounds. No idea what the code meant to do.
mpir-2.6.0-2.fc19.src.rpm
similarly to getdata bug, another clear out of bounds access in a loop:
#define numberof(x) (sizeof (x) / sizeof ((x)[0]))
...
for (oindex = 0; oindex <= numberof (offset); oindex++)
{
o = offset[oindex];
...
}
hdf-4.2.8-1.fc19.src.rpm
similarly to getdata bug:
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
{
...
ui32[i][j] = (uint32) ((i * 400000000) + j); /* range: 0 ~ 4-billion */
}
...
}
skf-1.99.0-1.fc18.2.src.rpm
similar to getdata bug:
#define BIG5P_TBL_LEN 23940 /* BIG5-Plus 190 * 126 */
...
#define HKSCS_FA_LEN 1140 /* f940 - fefe */
...
unsigned short big5a_uni_byte[BIG5P_TBL_LEN];
skf_ucode big5uao_fa_uni_byte[HKSCS_FA_LEN] = { ... };
...
for (j=0;j<HKSCS_FA_LEN;j++) { /* fa00 - */
big5a_uni_byte[BIG5P_TBL_LEN+j-950] = big5uao_fa_uni_byte[j];
};
yap-6.2.2-4.fc18.src.rpm
similar to getdata bug:
LAST_FLAG = 23
...
#define NUMBER_OF_YAP_FLAGS LAST_FLAG
...
#define yap_flags Yap_heap_regs->yap_flags_field
...
Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
...
/* This must be done before initialising predicates */
for (i = 0; i <= LAST_FLAG; i++) {
yap_flags[i] = 0;
}
avr-gcc-4.7.2-1.fc19.src.rpm
gcc-4.7.2-9.fc19.src.rpm
mingw-gcc-4.7.2-6.fc19.src.rpm
msp430-gcc-4.6.3-2.fc19.src.rpm
another occurrences of similar issue, fixed upstream with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186590
when using older gcc codebases (4.6 and 4.7 based), this
needs to be backported.
perl-PDL-2.4.10-4.fc19.src.rpm
struct pdl_trans { ... pdl *pdls[1]; ... };
...
for(j=0; j<trans->vtable->nparents; j++) {
if(trans->vtable->per_pdl_flags[j] & 0x01) {
par_pvaf++;
if(!trans->pdls[j]) {return;}
pdl_make_physvaffine(trans->pdls[j]);
} else {
if(!trans->pdls[j]) {return;}
pdl_make_physical(trans->pdls[j]);
}
}
for(; j<trans->vtable->npdls; j++) {
...
}
From pdls[1] above the compiler figures out the first loop
iterates at most once (otherwise it would be an out of bounds
access). As the function is called with ->nparents ranging
from 0 to roughly 11 and ->npdls ranging from 1 to roughly 14
if it happened to "work" before, it was purely by luck.
glm-0.9.3.4-2.fc19.src.rpm
test/core/core_setup_message.cpp needs to be adjusted to grok GLM_COMPILER_GCC48
inkscape-0.48.3.1-4.fc19.src.rpm
qelectrotech-0.30-0.4.svn1844.fc18.src.rpm
texmaker-3.5-1.fc19.src.rpm
xmlcopyeditor-1.2.0.4-4.fc18.src.rpm
stray comma at the end of declaration, see http://gcc.gnu.org/PR55368
struct A { void *member,; }; used to be accepted, now is rejected as
invalid.
kdbg-2.5.1-2.fc18.src.rpm
lemonpos-0.9.4-5.fc19.src.rpm
libaccounts-qt-0.31-6.fc18.src.rpm
qgis-1.8.0-10.fc19.src.rpm
rosegarden4-12.04-3.fc18.src.rpm
scribus-1.4.1-3.fc19.src.rpm
sir-2.4-1.fc18.src.rpm
unixODBC-gui-qt-0-0.6.20120105svn98.fc18.src.rpm
gcc bug, fixed upstream by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194816
llvm-3.1-12.fc19.src.rpm
gcc bug, not fixed yet, see http://gcc.gnu.org/PR55875
openjpa-2.2.1-1.fc19.src.rpm
flaky (every time failed in a different spot) java issue, not clear
if in any way related to gcj/libgcj
python-webob1.2-1.2.1-8.fc19.src.rpm
flaky (every time failed in a different spot), doesn't contain any
non-python code, so I don't see how it could be related to gcc
snapper-0.1.0-1.20121026git1aaa372.fc19.src.rpm
includes <auto_ptr.h> which is declared to be a libstdc++ internal
header not supposed to be included directly, see http://gcc.gnu.org/PR55866
sunpinyin-2.0.4-0.4.fc18.src.rpm
seems to be flaky SConstruct, with scons -j16 install (or even -j4)
it usually fails to install, with -j1 or -j2 it always succeeds
zarafa-7.0.9-1.fc19.src.rpm
gcc bug, fixed upstream already, see http://gcc.gnu.org/PR55877
blender-2.64a-2.fc19.src.rpm
centerim-4.22.10-6.fc18.src.rpm
HippoDraw-1.21.3-6.fc19.src.rpm
meshlab-1.3.1-7.fc18.src.rpm
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character ('/builddir/build/BUILD/' vs '/usr/src/debug/')
See https://bugzilla.redhat.com/show_bug.cgi?id=304121 , avoid using
double slashes in path names and filenames.
E.g. for centerim it is in
AM_CPPFLAGS = -I$(top_srcdir)/kksystr/include -I$(top_srcdir)//kkstrtext
(note the useless // there, just making it / fixes this issue).
Jakub
10 years, 6 months
