Updated lclint (2.5r)
I use this at times at work, school, and home. As such I've created some more up to date packages. 2.4b is the only available version in the archives, stable-unstable. 2.4b was released in Apr 98 and the last upload to the archives appears to be Feb 2000. I've emailed the maintainer ([EMAIL PROTECTED]) that I have these available and if he would care to look at them or put the package up for adoption, I would be interested in maintaining it. However, after a closer look at the developer's ref, (http://www.debian.org/doc/developers-reference/ch-archive-manip.en.html#s-adopting) it's plainly clear that lack of response from maintainer is no reason to try to adopt a package. So if anyone would like to review and/or provide this as an NMU, I'm making it available at: http://wolverine.cameron.edu/~gbsadler/debian Apt-gettable with: deb http://wovlerine.cameron.edu/~gbsadler/debian ./ deb-src http://wolverine.cameron.edu/~gbsadler/debian ./ -- Gordon Sadler
Re: how can Euro symbol be displayed under X [4.0.3]?
On Wed, May 09, 2001 at 02:09:57PM -0400, Alan Shutko wrote: John H. Robinson, IV [EMAIL PROTECTED] writes: it depends upon the font that you use. the latin-9 font contains the sideways quake two symbol, ยค, (some fonts will show that as a o with four little tick marks on it) Your Content-Type was Content-Type: text/plain; charset=iso-8859-1 so _everyone_ should be showing it as the o with four little tick marks. (What a weird character... it has to have a name, right?) Not everyone. It's a square here, on the console. Just like good ol' pong. Gordon Sadler
Re: Who uses ccmalloc?
On Sun, May 06, 2001 at 10:28:56PM +0200, J.H.M. Dassen (Ray) wrote: On Sun, May 06, 2001 at 19:31:43 +0200, Adrian Bunk wrote: J.H.M. Dassen (Ray) ([EMAIL PROTECTED]) ccmalloc To the best of my knowledge, there's no upstream for ccmalloc anymore. I'm not using it myself, and there are several (possibly better) alternatives available. I'm therefore pondering dropping it, unless someone can convince me it's still being used. It is maintained upstream, just moved a bit...: http://www.inf.ethz.ch/personal/biere/projects/ccmalloc Last change(webpage): 5 Feb 01 Version: 0.3.4 (dated 5 Mar 01) I still use it sparingly, I'm no expert with it. Think I use dmalloc the most, possible electric-fence as well. Gordon Sadler
Re: upgrading only urgency=high packages
On Tue, May 01, 2001 at 02:44:21PM -0400, Matt Zimmerman wrote: From: Matt Zimmerman [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: upgrading only urgency=high packages Mail-Followup-To: debian-devel@lists.debian.org On Tue, May 01, 2001 at 02:12:24PM -0400, Dan Christensen wrote: Is there a way to upgrade all currently installed packages which have had an urgency=high version uploaded to the archive since I last upgraded? (And any necessary dependencies, of course.) I'm thinking of this for the unstable distribution. The idea is to frequently do such upgrades to get any security fixes, and less frequently do an entire dist-upgrade. (I know about testing, but for the machine in question I like to stay current with unstable most of the time.) I'm guessing that the information about the urgency fields might not be available except in the changelog, so it might be necessary to download the package and have a script look through the changelog. Could apt-listchanges be hacked to do this? Or could apt's new pinning mechanism help? Is urgency information stored anywhere besides the changelog? How do the testing scripts do this? I had an idea (and a working script) to extract changelogs from source packages and insert them into a SQL database. My original intention was to allow apt-listchanges to display changelogs for packages before downloading them, but such a database would also allow for queries like this. It would also allow the CGI changelog viewer to work again. If the daily lintian runs start up again, this script could easily be run when a source package is unpacked, to keep the database up-to-date as new packages come into the archive. You might look at another idea. When katie/dinstall runs it has to parse the .changes file. This includes both the urgency info and the changelog relevant to the current upload. Gordon Sadler
Re: Base Bug Week, 30th April to 6th May
On Thu, Apr 26, 2001 at 02:52:11PM +1000, Brian May wrote: Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin Since the base system comprises our most important Martin packages, virtually all of which are installed on any Martin Debian system, your help is really needed! While Bug Martin Squashing Parties usually focus on Release Critical (RC) Martin bugs, we should also try to get the number of normal (or Martin even wishlist) bugs in the base as low as possible. This Martin involves writing patches or documentation -- everyone can Martin help with this; also non developers are encouraged to Martin participate. What is the easiest way to upgrade only base packages without upgrading anything else (unless required?). Ideally I would like to upgrade/install anything section==base or priority==required, but not anything else just yet (as I don't like upgrading to much stuff, partly because of the huge bandwidth required). Is this possible without manually copyingpasting from dselect? Just enter dselect, then on each category that you have packages installed, except for base/required, choose to hold them '='. Should be that simple, although I haven't run dselect in months. Gordon Sadler
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 07:33:50PM -0400, Daniel Jacobowitz wrote:
On Wed, Apr 25, 2001 at 06:07:50PM -0400, Josh Huber wrote:
Craig Sanders [EMAIL PROTECTED] writes:
i am, and always have been, talking about the bloated number of
kernel-{image,headers} packages.
I have to admit, I strongly disagree with having separate packages for
every flavor of i386 machines. What about the other architectures as
well? Should we have versions for every revision of the Alpha?
powerpc too? this seems like an incredible waste of mirror space
bandwidth, and it looks like virtually every Developer here thinks
this is a bad idea. I wonder why that is?
Actually, we do have equivalent kernel packages for most of the (e.g.)
PowerPC variants. There it is a little more necessary than here, since
the kernels only boot on one flavor. There'll be even more when I
start building kernel packages on a faster machine.
Alpha is, I believe, the same way. As is ARM, and possibly sparc...
FWIW, I do compile my own kernel. That said, here's some facts:
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-alpha/base/
shows 21! different v2.2.13 kernel-images.
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-arm/base/
shows 1 v2.2.10 kernel-image
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-i386/base/
shows 4 different v2.2.17 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-m68k/base/
show 6 different v2.2.10 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-powerpc/base/
show 3 different v2.2.15 kernel-images
ftp://ftp.us.debian.org/debian/dists/stable/main/binary-sparc/base/
show 5 different v2.2.17 kernel-images
I'm not sure why people are coming down on Herbert Xu here. If he
decides as the maintainer of the kernel-images to provide flavors for
various CPU types within the i386 family, that is his perogative, right?
Sounds like the main argument is mirror space. Now consider the 21
different v2.2.13 kernel-images available for alpha. If it were possible
to determine the percentage of people using debian on each of the 21
different flavors, then compare that to percentage of people using
different flavors of i386, then depending on the result there could be
an argument made for/against based on that kind of data.
Do alpha and the other architectures really have that many flavors of
CPU's? Are they all binary incompatible with each other, or do they have
a minimal compatibility standard (eg i386)?
Gordon Sadler
Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]
On Sun, Jan 07, 2001 at 01:14:40AM -0600, Nathan E Norman wrote: I apologize for prolonging this thread - it's quite annoying. However, after reading this enlightened response I wonder if it's possible for a user to close the (silly) bug he or she reported after he or she solves the problem. bugs.debian.org doesn't seem to indicate a way for a bug to be closed other than action by the maintainer. Actually under /usr/doc/debian the doc-debian package provides a number of files, including bug-main-mailcontrol.txt. A message to [EMAIL PROTECTED] of this format: close $(bugnumber) thanks will close a bug. Only submitters or maintainers should close a bug as noted in the docs.
Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]
On Sun, Jan 07, 2001 at 01:57:11AM -0600, Gordon Sadler wrote: Actually under /usr/doc/debian the doc-debian package provides a number of files, including bug-main-mailcontrol.txt. A message to [EMAIL PROTECTED] of this format: close $(bugnumber) thanks will close a bug. Only submitters or maintainers should close a bug as noted in the docs. Ugh late night. s;/usr/doc;/usr/share/doc s/bug-main-mailcontrol.txt/bug-maint-mailcontrol.txt
Re: lilo.conf
On Sat, Jan 06, 2001 at 12:04:52PM +, Lars Wirzenius wrote: Russell Coker [EMAIL PROTECTED]: I am working on the Debian package of lilo and am writing code for auto-generating lilo.conf files. Presumably, if there is a /etc/lilo.conf file already on the system, you will ask whether to keep that as it is or whether to create a new one? (I'd like confirmation about this, in light of the other lilo related thread.) Just FYI, as of now, the package available in sid/unstable does NOT ask to save your /etc/lilo.conf. If you install the current deb backup your lilo.conf file first.
find/locate both segfault after today's update [unstable]
I update most every day to current unstable. Something I just noticed today no matter what options or how I call them, both find and locate are producing: locate libc6 Segmentation fault find / -name etc Segmentation fault The only thing even close to relevant AFAICT today is ... libc6 Package: libc6 Version: 2.2-9 Now I also have libc6-i686, but til now have not had problems running it. Can anyone else confirm this? Gordon Sadler
Re: find/locate both segfault after today's update [unstable]
On Thu, Jan 04, 2001 at 11:38:56PM -0500, Ben Collins wrote: On Thu, Jan 04, 2001 at 09:35:28PM -0600, Gordon Sadler wrote: I update most every day to current unstable. Something I just noticed today no matter what options or how I call them, both find and locate are producing: locate libc6 Segmentation fault find / -name etc Segmentation fault The only thing even close to relevant AFAICT today is ... libc6 Package: libc6 Version: 2.2-9 Now I also have libc6-i686, but til now have not had problems running it. Have you tried removing libc6-i686 just to make sure it isn't causing this? Also, what kernel ar you running? BINGO removed libc6-i686 and all's well... that's kind of bothersome though isn't it? Sorry about kernel info uname -a Linux xxx 2.2.18pre24 #1 Wed Dec 6 21:30:42 CST 2000 i686 unknown I knew I should have tried removing libc6-i686 as soon as I remembered other problems reported with some packages and optimized libs. Thanks much, anything we can look into why/how this doesn't work with optimized libs?
Question/comment re:incoming.debian.org/REPORT
REPORT shows as of now, stamped 03-Jan-2001 14:58, the following: 1. dpkg_1.8.0_i386.changes BYHAND dpkg-1.8.0.tar.gz byhand dpkg_1.8.0_i386.deb to pool/main/d/dpkg/dpkg_1.8.0_i386.deb The above says to me I should be able to find that file at that location. However, a search of ftp.debian.org, http.us.debian.org, ftp.twtelecom.net (closer mirror) at that location shows: 257 /pub/mirrors/debian/pool/main/d/dpkg is current directory. ftp ls -rw-r--r-- 1 ftp ftp851612 Dec 11 00:00 dpkg_1.7.2_sparc.deb Would this be due to BYHAND, or possibly something with the package pools? the dpkg_1.8.0...deb files still appear in incoming regardless of the REPORT file. If it's a problem I hope I have alerted the correct people, if not sorry for your time. 2. gcc-2.97_2.97-001230_i386.changes NEW to experimental I know, I know it's experimental and the above is unstable neither are expected/suppose/guarnteed to work. However, I think this might actually be worth noting. The above related debs still appear in incoming as well and the appropriate directory and the same mirrors as above shows: 257 /pub/mirrors/debian/project/experimental is current directory. ftp ls Packages* -rw-r--r-- 1 ftp ftp127551 Dec 7 20:01 Packages -rw-r--r-- 1 ftp ftp 27252 Dec 7 20:01 Packages.gz ftp ls gcc* -rw-r--r-- 1 ftp ftp 30660 Dec 5 19:54 gcc-base-ss_2.97-0.001202_all.deb -rw-r--r-- 1 ftp ftp463352 Dec 5 19:54 gcc-doc-ss_2.97-0.001202_all.deb -rw-r--r-- 1 ftp ftp407502 Dec 5 19:54 gcc-snapshot_20001202-0.001202.diff.gz -rw-r--r-- 1 ftp ftp 1278 Dec 5 19:54 gcc-snapshot_20001202-0.001202.dsc -rw-r--r-- 1 ftp ftp 12499345 Dec 5 19:54 gcc-snapshot_20001202.orig.tar.gz -rw-r--r-- 1 ftp ftp 1611204 Dec 6 19:53 gcc-ss_2.97-0.001202_alpha.deb -rw-r--r-- 1 ftp ftp 1416836 Dec 5 19:54 gcc-ss_2.97-0.001202_i386.deb -rw-r--r-- 1 ftp ftp 1297818 Oct 25 18:52 gcc-ss_2.97-0.1_sparc.deb So, the REPORT says it is NEW to experimental and indicates it has been installed but it is not located there nor have the Packages files been regenerated since Dec 7. Again, it looked like someone might not be aware of this. If it's a non-issue, I apologize for taking your time. Thanks Gordon Sadler
Re: Question/comment re:incoming.debian.org/REPORT
Thanks for the info, I actually think I understand that file now much better. I was not reading all the way through and made some incorrect conclusions from my incomplete understanding. Gordon Sadler On Wed, Jan 03, 2001 at 11:08:00PM -0600, Adam Heath wrote: On Wed, 3 Jan 2001, Gordon Sadler wrote: REPORT shows as of now, stamped 03-Jan-2001 14:58, the following: 1. dpkg_1.8.0_i386.changes BYHAND dpkg-1.8.0.tar.gz byhand dpkg_1.8.0_i386.deb to pool/main/d/dpkg/dpkg_1.8.0_i386.deb [snip] gcc-2.97_2.97-001230_i386.changes NEW to experimental Unless you actually see an INSTALL, it hasn't been installed.
Possible problem about to occur in incoming?
If you look at incoming.debian.org/REPORT it will show the following: gcc_2.95.2-21_i386.changes SKIP (too new) Rejected: gcj_2.95.2-21_i386.deb Old version `1:2.95.3-2' = new version `1:2.95.2-21'. Rejected: gcj_2.95.2-21_i386.deb Old version `1:2.95.3-3' = new version `1:2.95.2-21'. Rejected: g77_2.95.2-21_i386.deb Old version `1:2.95.3-2' = new version `1:2.95.2-21'. Rejected: g77_2.95.2-21_i386.deb Old version `1:2.95.3-3' = new version `1:2.95.2-21'. Rejected: libstdc++2.10-glibc2.2_2.95.2-21_i386.deb Old version `1:2.95.3-2.001229' = new version `1:2.95.2-21'. Rejected: libstdc++2.10-glibc2.2_2.95.2-21_i386.deb Old version `1:2.95.3-2.001231' = new version `1:2.95.2-21'. SNIP lots of the same It looks like the new 'experimental' 2.95.3 will not allow the old 'stable' 2.95.2 to be updated? Sorry if I'm completely wrong, just thought it might be worth mentioning. Thanks Gordon Sadler
