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
kernel/accounting question ...
by William W. Austin
(I know that this question might be more reasonable on a kernel list,
but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both
ac_io and ac_rw for bytes transferred and blocks read or written,
respectively. Fair and good - works (on paper) similarly to unix,
solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
(blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do
extensive performance analysis on several platforms and have written a
fairly compresive accounting package (as a wraparound for psacct or as
a standalone) including both an improved acctcom and a built-in
reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data?
(Overhead comes to mind.) Not that it makes a huge differnce for my
purposes (I had to write some wraparound code to make a
"best-guestimate" about the data I'm missing), but curiosity is bugging
me now. When I compile my program on other OS's I get useful data for
char and block i/o and I'd like to find out whether there is something
obvious that I'm just totally missing here...).
Thanks
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 9 months
acctcom for linux
by William W. Austin
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
info.
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
appreciate it.
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
respectively.
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
Thanks
- Bill
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 9 months
ctrlproxy-3.0.6
by Bernie Innocenti
Ciao,
I updated ctrlproxy to 3.0.6, and the resulting packages are here:
http://www.codewiz.org/pub/fedora/pkgs/
Patch follows. Can I commit it to CVS?
diff -u -p -r1.15 ctrlproxy.spec
--- ctrlproxy.spec 19 Feb 2008 07:31:45 -0000 1.15
+++ ctrlproxy.spec 25 May 2008 14:25:14 -0000
@@ -1,12 +1,18 @@
+%define ctrlproxy_homedir %{_var}/lib/ctrlproxy
+%define ctrlproxy_logdir %{_var}/log/irc
+%define ctrlproxy_service ctrlproxy
+%define ctrlproxy_user ctrlproxy
+
Summary: ctrlproxy
Name: ctrlproxy
-Version: 3.0.5
-Release: 2%{?dist}
+Version: 3.0.6
+Release: 1%{?dist}
License: GPLv2+
Group: Applications/Internet
Source: http://jelmer.vernstok.nl/releases/ctrlproxy-%{version}.tar.gz
Url: http://jelmer.vernstok.nl/ctrlproxy/
-Patch0: ctrlproxy-fix-ansi-build.patch
+Source100: ctrlproxy.init
+Source101: ctrlproxy.config
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: glib2-devel, popt, gnutls-devel
@@ -31,7 +37,6 @@ ctrlproxy development headers
%prep
%setup -q
-%patch0 -p1
%build
%configure
@@ -45,6 +50,23 @@ mkdir $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
make DESTDIR=$RPM_BUILD_ROOT -C doc install
chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/ctrlproxy/motd
+install -D -m 0755 %{SOURCE100} $RPM_BUILD_ROOT/%{_sysconfdir}/init.d/ctrlproxy
+install -D -m 0640 %{SOURCE101} $RPM_BUILD_ROOT/%{ctrlproxy_homedir}/config
+install -D -d -m 0750 $RPM_BUILD_ROOT/%{ctrlproxy_logdir}
+
+
+%pre
+/usr/sbin/useradd -s /sbin/nologin -M -r -d %{ctrlproxy_homedir} \
+ -c "ctrlproxy IRC daemon" %{ctrlproxy_user} &>/dev/null || :
+
+%post
+/sbin/chkconfig --add %{ctrlproxy_service}
+
+%preun
+if [ $1 = 0 ]; then
+ /sbin/service %{ctrlproxy_service} stop > /dev/null 2>&1 || :
+ /sbin/chkconfig --del %{ctrlproxy_service}
+fi
%clean
[ -d "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
@@ -59,12 +81,24 @@ chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/
%dir %{_docdir}/ctrlproxy
%{_docdir}/ctrlproxy/*
+%{_sysconfdir}/init.d/ctrlproxy
+%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_logdir}
+%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_homedir}
+%attr(0750, ctrlproxy, ctrlproxy) %config(noreplace) %{ctrlproxy_homedir}/config
+
+
%files devel
%defattr(-,root,root)
%{_includedir}/ctrlproxy-3.0/*
%{_libdir}/pkgconfig/ctrlproxy.pc
%changelog
+* Sun May 25 2008 Bernardo Innocenti <bernie(a)codewiz.org> 3.0.6-1
+- Update to latest upstream
+- Drop ctrlproxy-fix-irssi-log.patch
+- Add initscript
+- Create a ctrlproxy user to run ctrlproxy as a daemon
+
* Tue Feb 19 2008 Fedora Release Engineering <rel-eng(a)fedoraproject.org> - 3.0.5-2
- Autorebuild for GCC 4.3
--
\___/
_| X | Bernie Innocenti - http://www.codewiz.org/
\|_O_| "It's an education project, not a laptop project!"
14 years, 3 months
Maintainer Responsibility Policy
by Brian Pepple
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer
Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
not mandatory.
* http://www.redhat.com/mailman/listinfo/fedora-devel-announce
* http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
* http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
=== Maintain stability for users ===
* Package maintainers should limit updates within a single Fedora
release to those which do not require special user action. Many
users update automatically, and if their applications stop
working from no action of their own then they will be upset.
This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
following information:
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
change.
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
packages.
* F(current-1) -> F(current) -> Rawhide
* Packages should be pushed to the Rawhide branch first. If it
builds and works fine for a few days, then it can be pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of being in
F(current).
---
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
14 years, 4 months
mock 0.8.9 will not build anything
by Frank Büttner
Hello,
when I try to build an package mock will fail with:
ERROR: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for
output.
At the root.log:
2008-01-18 09:48:01,860 - DEBUG trace_decorator.py, Line: 20: ENTER:
doChroot((<mock.backend.Root object at 0xb7dc8e8c>, '/usr/sbin/grou
padd -g 102 mockbuild', ''), {})
2008-01-18 09:48:01,861 - DEBUG trace_decorator.py, Line: 20: ENTER:
do(('/usr/sbin/groupadd -g 102 mockbuild', '/var/lib/mock/fedora-de
velopment-i386/root', 0, True, 0, None, None, None, None), {})
2008-01-18 09:48:01,862 - DEBUG util.py, Line: 212: Run cmd:
/usr/sbin/groupadd -g 102 mockbuild
2008-01-18 09:48:01,862 - DEBUG util.py, Line: 218: Executing
timeout(0): /usr/sbin/groupadd -g 102 mockbuild
2008-01-18 09:48:01,866 - DEBUG trace_decorator.py, Line: 20: ENTER:
condPersonality((None,), {})
2008-01-18 09:48:01,869 - DEBUG trace_decorator.py, Line: 30: LEAVE
condPersonality --> None
2008-01-18 09:48:01,870 - DEBUG trace_decorator.py, Line: 20: ENTER:
condChroot(('/var/lib/mock/fedora-development-i386/root', None), {}
)
2008-01-18 09:48:01,871 - DEBUG trace_decorator.py, Line: 30: LEAVE
condChroot --> None
2008-01-18 03:48:01,872 - DEBUG trace_decorator.py, Line: 20: ENTER:
condDropPrivs((None, None, None), {})
2008-01-18 03:48:01,873 - DEBUG trace_decorator.py, Line: 30: LEAVE
condDropPrivs --> None
2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name
mockbuild is not unique
2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27:
EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f
or output.
Any ideas, what goes wrong??
Frank
14 years, 9 months
file system mount
by Amitakhya Phukan
hi all!
i have a system with fedora 7 and rhel 5 installed. recently, i changed
the f7 to rawhide. now whenever i boot up, it mounts all the file
systems related to rhel5 along with it and displays on the desktop.
dmesg says /dev/sda1 mounted on /media/_1 and so on. I want to disable
this feature. i don't know if this is anything useful ?? i even don't
know if its a feature or a bug... can any one please help me out with
this thing ? i understand hal is doing this (??), but why ? and even
when i unmount it, the same can still be found in /media. right clicking
on those partitions give me the option of mounting/unmounting them. but
i don't want to let them appear in my rawhide systems totally. anyone
else has this experience on rawhide??how do i disable it ??
thanks in advance.
with regards,
amitakhya phukan.
15 years, 1 month
RFC: FEver and RPath checks in Koji
by Debarshi Ray
I have a couple of proposals which I wanted to sound out.
+ Would it be possible to run FEver
(http://fedoraproject.org/wiki/PackageMaintainers/FEver) on a regular
basis? Currently I get the feeling that it is run manually at
irregular intervals, and since I depend heavily on it for tracking
upstream releases this often means that a release is missed
occasionally.
+ Would it be a good idea to have rpath related checks in Koji? Although I use
"%__arch_install_post /usr/lib/rpm/check-rpaths
/usr/lib/rpm/check-buildroot"
in my ~/.rpmmacros, some rpath issues are only detected on x86_64
systems? Although I have a x86_64 desktop, it can be a bit problematic
when a x86_64 system is not available. Such issues do not get detected
during the Koji build resulting in violation of the packaging
guidelines.
Comments?
Cheers,
Debarshi
--
Free software for the Indian community:
* ftp://fedora.glug-nith.org/
* http://fedora.glug-nith.org/
* http://gnu.glug-nith.org/
* http://mirror.wbut.ac.in/
15 years, 1 month
ext4dev oddity
by Trever L. Adams
I am having some pretty good success on some different machines with
ext4.
However, I am getting this message:
EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 717:
23410 blocks in bitmap, 23411 in gd
EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 721:
19309 blocks in bitmap, 19333 in gd
What do I need to do to help debug this, if anything, and how do I find
out which files or directories are affected?
Thank you,
Trever Adams
--
"Yesterday is gone. Tomorrow is too far for me. Today is what I have,
and what I fight for." -- Unknown
15 years, 1 month
