And, yeah, there is a kind of catch-22 when you've got bugs in the bug-handling software.
]]>-- Oh, I forgot to add: I did a pacman -Syu today and the first thing it wanted to do was wipe out my spiffy new bash, so I told it no, added
IgnorePkg = bash
to /etc/pacman.conf and then ran it again. I assume that's the right way to go and I'll just remove it again when I actually want to upgrade?
Exactly! Quick learner.
As for getting a bug report account. Some time back there was an issue with the registration not working. Don't know why.
Are you using email response, or jabber? I am pretty sure that jabber doesn't work right.
Anyway, long story short, I had to email Judd and ask to be manually added to the bugtracker. funny story, someone said I should *ahem* file a bug about not being able to join the bugtracker..lol..I am sure it was said tongue in cheeck, but it was still pretty funny at the time.
As far as the alternate method, it does make more sense to pull the patch down directly - I saw the one patch in the ABS directory so I thought there must be a convention about having the patches locally. But I still don't know why it complained about the checksums - it *should* work either way. And, like I say, the checksum complaint didn't prevent the build or installation but does make it a 'bad' package, in a way.
Anyway - true, it does kind of have that feeling that once I really get it, I'll wonder how I didn't get it in the first place.
-- Oh, I forgot to add: I did a pacman -Syu today and the first thing it wanted to do was wipe out my spiffy new bash, so I told it no, added
IgnorePkg = bash
to /etc/pacman.conf and then ran it again. I assume that's the right way to go and I'll just remove it again when I actually want to upgrade?
pkgname=bash
pkgver=3.0
pkgrel=4-CSTM
pkgdesc="The GNU Bourne Again shell"
url="http://www.gnu.org/software/bash/bash.html"
backup=(etc/profile)
depends=('glibc' 'readline')
source=(ftp://ftp.cwru.edu/pub/bash/bash-$pkgver.tar.gz profile
bash-history.patch
ftp://ftp.cwru.edu/pub/bash/bash-3.0-patches/bash30-002)
md5sums=('26c4d642e29b3533d8d754995bc277b3'
'719b60711ee609850277bd0848516136'
'7108b64d6b21b74764a602e142ca6b2c'
'6F4CF2AA975A1FCC0CB43A406BD47CA5')
build() {
cd $startdir/src/$pkgname-$pkgver
patch -Np1 -i ../bash-history.patch || return 1
patch -Np1 -i ../bash30-002 || return 1
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
makepkg, and install the resulting tarball with pacman -U filename.tar.gz
and..i should clarify my earlier statement. Once you get used to it, it will be easy.
ps. i haven't tried the above, but in theory, it should work.
]]>[ j@alfredeneuman ][ Thu Jan 27 21:34:09 ]
[ ~ ] >> bash --version
GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
and it seems to work. However, I didn't know what to put for release version - it was 3 so is mine 4? I just put '1j'. And trying to set up a 'local repository' seemed confusing as hell and whatever I did was wrong. I actually got pissed and deleted bash and copied in mine manually, but then figured out I could do 'pacman -U bash-3.0-1j.pkg.tar.gz' directly. So I did that to re-overwrite stuff and get it in the package db.
What's wrong with this:
# $Id: PKGBUILD,v 1.30 2004/11/02 17:27:46 judd Exp $
# Maintainer: judd <jvinet@zeroflux.org>
pkgname=bash
pkgver=3.0
pkgrel=1j
pkgdesc="The GNU Bourne Again shell"
url="http://www.gnu.org/software/bash/bash.html"
backup=(etc/profile)
depends=('glibc' 'readline')
source=(ftp://ftp.cwru.edu/pub/bash/bash-$pkgver.tar.gz
profile
bash30-001
bash30-002
bash30-003
bash30-004
bash30-005
bash30-006
bash30-007
bash30-008
bash30-009
bash30-010
bash30-011
bash30-012
bash30-013
bash30-014
bash30-015
bash30-016)
md5sums=('26c4d642e29b3533d8d754995bc277b3'
'719b60711ee609850277bd0848516136'
'24a83f78a44a6029024371f02da174dd'
'6f4cf2aa975a1fcc0cb43a406bd47ca5'
'c8bf41e78cda16d391b9099eeba01386'
'c069dffbb3f442aac3660b883ddd97f5'
'ad06309c623ff8e1b9f039d3b7eb97c2'
'f162bf93a76759bab37b29509a4a6e20'
'89903d92ca620921aecb3f1f30c05ebe'
'9a295c02f46bc867fc096862c7380a88'
'786c7e2af1dca5104af92bbdc60f7474'
'f2d90d06ed445a285c8406016e9d9c13'
'9506c56968c58332489986633319a186'
'2753d4de0b57fc8890488463c5e86d3f'
'5de5be8289764c11a3206b06351d81a6'
'd4b531e02b6a0287cffdbf527134ca29'
'adc1ab952b42ed0c0f53d1c308a32101'
'a3bb09a185e4c6a813227f3e84e4f6e5')
build() {
cd $startdir/src/$pkgname-$pkgver
for patch in ../bash30* ; do
cat $patch | patch -p0
done
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
It gave checksum errors but seems to have gone ahead otherwise.
In my I-know-nothing-I-just-mess-around-here opinion, *all* patches released by a *maintainer* should be applied unless the maintainer describes specific instances where it might not be a good idea. There are *16* patches for bash, and I applied all of them. What's the logic of rel-3 having *one*?
And maybe having a single source of documentation that handles the ABS stuff in a linear step-by-step would be good. I think messing with the man pages and the Install Guide and some other stuff ended being more confusing that helpful.
But you helped a lot, cactus - thanks for pointing me in the right direction. And I'll definitely take that 'helping along' offer.
]]>for example...
build() {
cd $startdir/src/$pkgname-$pkgver
patch -Np1 -i ../bash-history.patch || return 1
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
The above is from the current bash pkgbuild. It should be a simple matter of adding an additional patch line after the existing one.
Still, if you are not comfortable with such things, then I am sure someone else would be easily convinced into helping you along.
Make sure you file a bug though..it is unlikely the maintainer will be reading the forums, and it might be the only way the issue "bubbles" up to those that need to be aware of it.
]]>Not important either way, though - but this terminal truncation is driving me batty. I could strip the newlines but I like having a short prompt at the actual command line but still having some information in it. And, in X I could put it in the xterm titlebar (usually do), but I also like separating my command/output with blank lines.
Ah well, on the bright side, my PC keys work without fiddling, which is nice.
]]>seems to do the trick..
]]>Incidentally, mc and vim came up in xterm in black&white and specifying 'xterm-color' in ~/.Xdefaults fixed that (after doing 'mc -c' for awhile) but I'm wondering if that was the right way and if there's some other problem. I mean, as I say, this happens on the console, too, so it's not an xterm thing, but I thought I'd mention it in case it was somehow relevant and if there is a better way to fix the colors.
-- Oh, missed that last question. I set it from .bashrc. I also tried put it in a separate file and sourcing it from .bashrc (not to fix this, but just as a separate experiment) and neither method made any difference.
]]>