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
I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://email@example.com/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
the current xine-lib maintainer speaking. :-)
The Xine project:
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
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
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:
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
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.)
I've been asked by Luya Tshimbalanga <luya(a)fedoraproject.org> to
maintain the gimp-separate+ package for official Fedora project so that
it can be included in Design Suite Livemedia.
Having read some introductory information, I would now like to introduce
myself with few short facts:
- I'm using Linux (at start Red Hat, later Fedora) since roughly 1997.
- To ease the maintenance of my systems, I'm creating RPM packages "just
for myself" since 1998 - this one seems to be the oldest one:
- I'm supporter of Free and Open Source Software and small-scale
contributor, more recently broadening it with participation in Open Data
- Now, Luya's invite finally pushed me to come closer to the Fedora project.
- I'm earning a living by doing software development and related
- I'm married with two children.
I'm looking forward for future cooperation. And I would also like to
thank in advance to all which will help me to get through initial stages
of first package submission
Peter Hanecak <hany(a)hany.sk>
although package Docky was lot of work for me (licensing patching etc) I
am no longer using it and last two releases were very unstable. There
are couple of bugzillas reported mainly because of gconf migration.
Docky is an advanced shortcut bar that sits at the edges of your screen.
It provides easy access to some of the files, folders and applications
on your computer, displays which applications are currently running,
holds windows in their minimized state and more.
Docky is written in mono.
Please ping me if you are interested to maintain the package.
Lukas "lzap" Zapletal
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
I'm using appliance-creator, in case that's doing anything silly.
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
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?
the Samba Team has announced  that it will remove SWAT from the Samba
Suite. SWAT is unmaintained and has the most security bugs.
I plan to remove the samba-swat subpackage in Fedora 18, 19 and rawhide as
soon as it gets removed from the current Samba development tree.
Andreas Schneider GPG-ID: 8B7EB4B8
Red Hat asn(a)redhat.com
Samba Team asn(a)samba.org