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
2011-06-23 : FTBFS not responded to
2010-06-30 : -static packaging bug not responded to
Plus, release 0.89 from 20-May-2011 is available whereas Fedora contains
0.84 from 2010 ( http://sourceforge.net/projects/courier/files/cone/ ).
This looks like somebody with interest in Cone should sign up as
co-maintainer and find out what's up with the current maintainer.
Fedora release 16 (Verne) - Linux 3.1.1-2.fc16.x86_64
loadavg: 0.82 1.09 0.87
I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
With Best Regards,
CSM-BIOS boot notes:
Apple hardware tested:
mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT.
mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M.
All notes based on booting with the Apple-EFI option-key startup menu to choose how to boot, not rEFIt.
1. After default install using any installation type, and reboot, neither model loads GRUB2 (and thus does not boot) by default. Pre or post-install work is needed.
2. Both models CAN boot and startup Fedora to a GUI login with pre- or post-install work.
a. 'nogpt' kernel parameter for Fedora only installs produces a bootable system without post-install work.
b. In dual-boot (Mac OS + Fedora) anaconda isn't creating a hybrid MBR post-install, therefore Apple's EFI startup disk menu doesn't see the F16 installation. Further, creating the hybrid MBR in advance is useless as parted wipes out the hybrid MBR in favor of a protective MBR just prior to installation. (See 3 below for additional fallout of this behavior.)
c. Triple boot (Mac OS, Fedora, Windows) is possible, but there are more ways this won't work, than will work. And more ways that will work, but aren't good partition schemes (invitations for data loss) since there really isn't such a thing as a safe hybrid MBR + GPT. I have found one or two that I think are about as "safe" as they can get, and it means that the user needs to install Mac OS, Windows, Fedora, in that order, but located on the disk in order: Mac OS, Fedora, Windows.
3. Anaconda + parted consistently remove pre-existing hybrid MBRs, replacing them with protective MBRs. The hybrid MBR will exist in a case where Windows has already been installed (using Apple's Bootcamp application). If removed in favor of a protective MBR, Windows is no longer bootable. So not only is Fedora not bootable, a previously bootable Windows is no longer bootable. This happens with either EFI or BIOS mode installs of Fedora.
So either anaconda needs to proceed no further upon discovery of a hybrid MBR, or it needs to become pretty good at sorting out hybrid MBR and GPT schemes that are "safe".
4. gptsycnc: I don't think gptsync has such a sophisticated heuristic for creating such hybrid MBRs - I regularly see it produce very linear MBRs while suggesting huge percentages of the disk are empty. Any MBR only aware tool would see these areas as fair game - what I call an invitation for data loss and probably not a good idea.
5. If all requirements are met, Apple's startup disk menu (option-key at startup chime) will present a single "Windows" disk icon which if selected will load GRUB2 and its menu. That "Windows" label is apparently hard coded in Apple's EFI for any foreign OS requiring legacy CSM-BIOS booting.
Additional EFI boot notes:
1. By default EFI//EFI/redhat/grub.efi isn't found by Apple's EFI and install a choosable option. If it and the .conf are moved to EFI//EFI/BOOT/BOOTX64.efi and .conf, both models have an "EFI Boot" labeled disk icon in the option-key startup menu. I'm guessing like the "Windows" equivalent, that "EFI Boot" is hardwired.
This is being addressed by this:
2. GRUB-EFI (legacy) regularly just hangs are loading the kernel and initramfs, on mbp41. I don't have this problem with GRUB2-EFI but I still have other problems mentioned in the previous email.
Just a friendly reminder: If you are a Fedora account system account
holder, and haven't changed your password and uploaded a new ssh key
since we announced the mandatory change, you best do so NOW. The
deadline is 2011-11-30 (only 2 days away).
If you don't, you may no longer have access to groups you currently do
(like packager, or sysadmin or ambassador).
Go take a few minutes, read the announcement and security information
linked to it, and change your password and upload a new ssh public key.
If you aren't a Fedora contributor, the information linked in our
announcement is still a great read and may just help you be more secure
on your machines. :)
devel-announce mailing list
Any reasons on why libgbm isn't being built and packaged in the
current mesa SPEC file? libgbm is a dependency for wayland-demos.
The --enable-gbm configure option depends on --enable-shared-glapi. Is
there any constraint?
The way we currently install Eclipse plugins in Fedora is incorrect and
RPM places all the plugin artifacts in the proper directories. However
that does not update the eclipse metadata. This means that until the
next time eclipse starts it is unaware of the newly installed plugins.
Because the user would normally run Eclipse not as root Eclipse does not
have permission to write to the meta data files located in the
installation directory. It therefore creates a parallel version in the
user's home directory ~/.eclipse. This creates a fragile installation
and leads to a whole host of problems.
To improve this I have written apatch which runs the Eclipse reconciler
during rpm installation. The Eclipse reconciler is an Eclipse
application which goes through and checks the installation directories
and updates the eclipse metadata with any newly installed plugins.
To add support for this in your eclipse package you have to add the
following line to your rpm spec file:
%_eclipse_pkg [package name]
Here is an example from the eclipse-rse spec file for the
The above macro expands to the following:
if [ $1 == 0 ]; then
I apologize if you have experienced instability in Eclipse installations
on rawhide, it is probably due to these changes. Please let me know if
you have any comments questions or suggestions.
I will be filing a request to update the Eclipse packaging guidelines.
If you are interested in the details of the work, here is a summary in
the form of a patch: http://fpaste.org/pPEC/