lilo -R equivalent in grub?
by Warren Togami
I just learned about the awesome "lilo -R" command. The man page says:
-R command line
This option sets the default command for the boot loader the next
time it executes. The boot loader will then erase this line: this is
a once-only command. It is typically used in reboot scripts, just
before calling ‘shutdown -r’.
This allows you to test new kernels on remote servers, and it will
revert back to the lilo.conf default during the next boot. A regular
reboot, remote power cycle, or passing 'panic=10' kernel option which
reboots upon panic would fallback to the previous default.
Does GRUB have anything similar to lilo's -R? This is a totally useful
function and I would really like to avoid using lilo.
If this functionality is truly missing from GRUB then this is another
project for me.
Warren
20 years, 5 months
rebuild of redhat-artwork will fail because of the makefile of gdm doesn't want utf in combination with intltool
by lupus
I was wondering if it still is necessary with the latest intltool to set
LANG=en_US when building redhat-artwork
my lang:
LANG=nl_NL.UTF-8
I know there is a simple workaround :p but I was just wondering if the
protection in the make script was still necessary.
I noticed that only the gdm dir has this protection.
[root@d51528079 redhat-artwork-0.88]# grep -R en_US *
art/gdm/Bluecurve/Makefile.in: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
art/gdm/Bluecurve/Makefile.in: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
art/gdm/Bluecurve/Makefile.am: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
art/gdm/Bluecurve/Makefile.am: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
art/gdm/Bluecurve/Makefile: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
art/gdm/Bluecurve/Makefile: if locale | grep -q UTF; then echo
"intltool doesn't like UTF-8 locales. Try rerunning with eg:
LANG=en_US"; /bin/rm -f Bluecurve.xml GdmGreeterTheme.desktop; exit 1;
fi
error:
if locale | grep -q UTF; then echo "intltool doesn't like UTF-8
locales. Try rerunning with eg: LANG=en_US"; /bin/rm -f Bluecurve.xml
GdmGreeterTheme.desktop; exit 1; fi
intltool doesn't like UTF-8 locales. Try rerunning with eg: LANG=en_US
make[5]: *** [all-local] Fout 1
make[5]: Weggaan uit map
`/home/lupus/garnome-0.29.1/geektoys/redhat-artwork/work/main.d/redhat-artwork-0.88/art/gdm/Bluecurve'
make[4]: *** [all-recursive] Fout 1
make[4]: Weggaan uit map
`/home/lupus/garnome-0.29.1/geektoys/redhat-artwork/work/main.d/redhat-artwork-0.88/art/gdm'
make[3]: *** [all-recursive] Fout 1
make[3]: Weggaan uit map
`/home/lupus/garnome-0.29.1/geektoys/redhat-artwork/work/main.d/redhat-artwork-0.88/art'
make[2]: *** [all-recursive] Fout 1
make[2]: Weggaan uit map
`/home/lupus/garnome-0.29.1/geektoys/redhat-artwork/work/main.d/redhat-artwork-0.88'
make[1]: *** [all-recursive-am] Fout 2
make[1]: Weggaan uit map
`/home/lupus/garnome-0.29.1/geektoys/redhat-artwork/work/main.d/redhat-artwork-0.88'
make: *** [build-work/main.d/redhat-artwork-0.88/Makefile] Fout 2
[root@d51528079 redhat-artwork]# cd ..
20 years, 5 months
Clarification on kernel builds
by Stan Bubrouski
Hey Guys,
Quick question: Are the kernels that end up in the development tree the
same as the ones on arjan's pages? (I know arjan's are updated more
frequently, but I was wondering before I jump around between them).
-sb
20 years, 5 months
Essential Packages
by Casey James Price
I think it would be nice if the Core could be slimmed down to 2 cds
opposed to 3, just for convenience sake. It seems the main discussion here
has been about the Core size and whether or not anti-virus should be
included in the Core. I think that it would be nice to have the "core" of
the Core composed of the necessities required for the average user on the
first 2 cds, and on a 3 or 4 you could call that the "Core Extras Disk".
This disk would contain other handy utilities and packages that aren't
essential, but that would be nice such as anti-virus. I think what sv has
been trying to say is that this distro is not just a server os, its going
to be used on laptops, workstations, etc...and that AV isn't necessarily a
core component of an operating system. In reality, most os' don't ship
with any AV, thats the reason the AV companies make their money.
It would be very easy for Fedora Core to turn into a huge bloated
distribution, not that would be that bad...it would just be a pain
maintaining it and downloading everything needed to get up and running,
and would come with much more than someone needs. The user doesn't need
more options than they know what to do with. They need a functioning
distro that contains what they need and not a ton of extra things that
they will likely use. So in the big picture I think that a cd filled with
extra components would be the best option for everyone.
--
Casey Price
20 years, 5 months
Path for upgrading from Red Hat Linux 9 to Fedora Core 2?
by Keith Sharp
Hello,
Given that the dates for the FC 2 release and the EOL of RHL 9 are quite
close to each other, is the plan to allow the upgrade of RHL 9 systems
directly to FC 2?
Or will the recommended path be: RHL 9 -> FC 1 -> FC 2?
Thanks,
Keith.
20 years, 5 months
Installation and removal of GConf schemas via RPM
by Michel Alexandre Salim
Abstract
--------
Controlling installation and removal of GConf schemas from RPM spec
files
Introduction
------------
GConf-enabled applications present a unique challenge to packagers,
having to do with the nature of GConf itself. The most appropriate
comparison is with Windows' registry, with applications shipping with a
.schemas file (equivalent to .reg) listing GConf keypairs that have to
be installed into the system's GConf tree when the package is installed,
and uninstalled when the package is removed.
Current situation
-----------------
Vendor-supplied Makefiles call gconf-install-tool as part of the
'install' target, and the following line, put under the %install section
of the .spec file before 'make install' prevents this as schemas should
not be installed at this time:
export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
With some Makefiles GConf schema installation has to be disabled before
%build's make as well; YMMV.
Schemas are installed during %post, with a typical procedure as follows:
%post
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule \
%{_sysconfdir}/gconf/schemas/straw.schemas >/dev/null
Problem
-------
So far so good. It is uninstalling that packagers have, unfortunately,
tended to ignore, as I discovered when packaging my first GConf-enabled
app. Leaving GConf keys behind is messy and could pose potential
compatibility problems when newer versions of applications are
installed, and should be discouraged. The uninstall process itself is
happily quite easy to perform:
%preun
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-uninstall-rule \
%{_sysconfdir}/gconf/schemas/straw.schemas >/dev/null
This has to be done in %preun instead of %postun since at the latter
stage, the .schemas file would have been already erased.
Recommendations
---------------
1. Add GConf install/uninstall examples to Fedora's spectemplate.spec
https://bugzilla.fedora.us/show_bug.cgi?id=1178
2. Bugzilla the necessary packages
One could get the list of packages by rpm -qf'ing the .schemas files in
/etc/gconf/schemas/
Hopefully this could be sorted by the time FC2 ships.
Regards,
Michel
20 years, 5 months
Should there be BuildRequires for perl/libtool/auto*?
by Toshio Kuratomi
Hi, I'm fighting with BuildRequires here and was wondering about the
auto* family of tools. configure checks for them at build time and
during builds of some packages. Are these tools actually needed for
the package to build (ie: should they be a BuildRequire?)
A related question: If I change something up the tool chain (A
configure.in or Makefile.am) should I do my auto*'ing inside the .spec
or do it in my work area before hand and create a patch? The latter
will generate a bigger patch, but it seems cleaner....
-Toshio
--
Toshio <toshio(a)tiki-lounge.com>
20 years, 5 months
default yum configuration for Legacy
by Chuck Anderson
Should the yum service default to on or off?
Should the yum.conf exclude kernels by default?
I think auto updates should be off by default, and kernels should be
excluded by default, just as it is in up2date.
What are people's opinions on this?
20 years, 5 months
rawhide report: 20040106 changes
by Build System
New package libxfce4mcs
multi-channel settings management support for xfce
New package libxfcegui4
gtk widgets for xfce
Updated Packages:
alchemist-1.0.29-1
------------------
* Mon Jan 05 2004 Tim Waugh <twaugh(a)redhat.com> 1.0.29-1
- Own %{_sysconfdir}/alchemist (bug #74024, bug #112842).
- Build requires glib2-devel (bug #110780).
bash-2.05b-35
-------------
* Mon Jan 05 2004 Tim Waugh <twaugh(a)redhat.com> 2.05b-35
- Fix parameter expansion in multibyte locales (bug #112657).
- Run 'make check'.
* Tue Dec 09 2003 Tim Waugh <twaugh(a)redhat.com> 2.05b-34
- Build requires texinfo (bug #111171).
dhcp-3.0pl2-6.19
----------------
* Mon Jan 05 2004 Dan Walsh <dwalsh(a)redhat.com> 1:3.0pl2-6.18
- Close leaseFile before exec, to fix selinux error message
grep-2.5.1-24
-------------
* Mon Jan 05 2004 Tim Waugh <twaugh(a)redhat.com> 2.5.1-24
- Work around glibc bug #112869 (segfault in re_compile_pattern).
- Avoid patching Makefile.am, to avoid automake/autoconf weirdness.
kernel-2.6.0-1.24
-----------------
* Mon Jan 05 2004 Dave Jones <davej(a)redhat.com>
- Disable PNPBIOS
- Fix mremap security hole.
lapack-3.0-23
-------------
* Wed Dec 31 2003 Jeff Johnson <jbj(a)jbj.org> 3.0-23
- link -lg2c explicitly into liblapack and libblas (#109079).
nss_db-2.2-24
-------------
* Mon Jan 05 2004 Nalin Dahyabhai <nalin(a)redhat.com> 2.2-24
- disable use of RPM's internal dependency generator, which was preventing
the filtering out of glibc private dependencies (#112849)
policy-1.4.4-1
--------------
* Mon Jan 05 2004 Dan Walsh <dwalsh(a)redhat.com> 1.4.4-1
- Many changes added, access to random device
- add directories ownership
* Tue Dec 23 2003 Dan Walsh <dwalsh(a)redhat.com> 1.4.2-2
- Fix bluetooth
* Tue Dec 23 2003 Dan Walsh <dwalsh(a)redhat.com> 1.4.2-1
- Latest policy with Russel and My changes.
- Add Bluetooth and pam
rpmdb-fedora-1.90-0.20040106
----------------------------
rsync-2.6.0-0
-------------
* Mon Jan 05 2004 Jay Fenlason <fenlason(a)redhat.com> 2.6.0-0
- New upstream version, obsoletes the rsync-2.5.6-signal.patch
system-config-bind-2.0.2-2
--------------------------
* Mon Jan 05 2004 Dan Walsh <dwalsh(a)redhat.com> 2.0.1-2
- Default new slave zones to slave directory
20 years, 5 months
whois buglet in FC1
by Hugo van der Kooij
Hi,
There are some typos in /etc/jwhois.conf where whois is spelled as whios
instead.
$ whois 210.139.254.162
[Querying whios.nic.ad.jp]
[whios.nic.ad.jp: Name or service not known]
Hugo.
--
All email sent to me is bound to the rules described on my homepage.
hvdkooij(a)vanderkooij.org http://hvdkooij.xs4all.nl/
Don't meddle in the affairs of sysadmins,
for they are subtle and quick to anger.
20 years, 5 months