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 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.
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://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
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
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
-- Those who don't understand recursion are doomed to repeat it
currently default error policy for printers in Fedora is "Stop printer" on
any error which is a really bad default. I have run across this issue LOTS
of times with regular Fedora desktop users who don't get why has their
printer stopped working, there is no UI queue to warn users, there is no
easy way to "Start printer" with one click after it has been stopped. It is
just a big mess.
Even worse, previous versions of Gnome control panel (if I remember
correctly) had option to change default error policy, now that option is
removed and you can get to it only by installing system-config-printers
tool, something regular users have no idea about even exists, and it is not
installed by default.
There are too many examples which are simple user errors but result in
priner going offline (stopped) and this is really bad, because after any
small error users can't print any more.
For example: user trying to print while he/she is not at home so his/hers
printer is not available, user trying to print but has forgot to connect
usb priner cable, user trying to print but haven't turned it on, user
printing to wifi printer but while connected to different wifi network...
Any of these actions is simple uses error but results in permanently
disabling of priner (Stops printer) and users can't print even when they
resolve issue that was stopping them from accessing the printer.
Now Fedora is what is stopping them from printing.
Who is responsible for user experience of Fedora desktop? To whom should I
point this issue to?
I'm sure those that need to know, know, but for those that haven't heard
Mozilla's official Firefox build will enforce addons to contain a Mozilla signature
without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla
signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1221923
about this too but thought it would be good to ask here.
F22 currently has llvm-3.5.0 (F23 is now on 3.6.0):
I believe there is a newer 3.5.2 bugfix release -
would it make sense to make a F22 update for that?
Is there any expected risk with doing that?
Anyway for F23 I probably have to make a llvm35 package
again for building ghc-7.10 on armv7 (and ideally aarch64).
3.5.0 has a critical bug that breaks ghc, so it would
be based on 3.5.2 anyway.
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?
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á