Re: Debian on the Sharp Zaurus/SL-5xxx
On Sun, Jun 16, 2002 at 09:32:31PM +0200, Wichert Akkerman wrote: > Previously Matt Zimmerman wrote: > > I'd be interested to hear your opinions about whether they would indeed > > be useful, and how difficult they would be to implement. > > Replying to to a html file is very inconvenient so if you want proper > comments please post it as normal text to the debian-dpkg list. To save you the trouble of cutting and pasting: Exclude arbitrary filesets from being unpacked This is already planned for a future dpkg release. Ideally, it would be possible for binary packages themselves to specify some information about what can be safely excluded. Strip down status file Exclusion of Description, Priority, Section, and possibly others, would save a significant amount of space in the package database. Adam Heath: There are plans to do this. If you look at status, there are empty package paragraphs. dselect uses these, and they polute the dpkg runtime memory. We have plans to remove these entries. Optionally disable or compress available-old and status-old backups Disk space and speed savings Optionally unpack files in-place Dangerous, but would provide significant space savings for upgrades. Might it be better to remove (but not purge) and then install the new version? Doing this frequently could provoke lurking bugs in maintainer scripts. Exclusion of certain control files (?) md5sums and shlibs could be excluded in most environments. templates also tends to be quite large, but I don't know what can be done about that. Exclude certain translations? It might be more effective to use a filesystem which can effectively store many small files, as most of the cost seems to be from large block sizes.Probably done most effectively with a separate tool. Automated slicing of packages across different filesystems For example, allow the user to say "for package X, place hierarchy Y at location Z instead, and symlink Y -> Z". This would allow larger packages, which might not even be able to be unpacked in internal storage, to gracefully flow onto removable media. This probably belongs in a separate tool. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#150135: galeon-common: tries to open non-existant file
Quoting Erich Schubert ([EMAIL PROTECTED]): > reassign 150135 dpkg > thanks > > > Setting up galeon-common (1.2.5-1) ... > > Failed to open `/etc/gconf/schemas/galeon.schemas': No such file or > > directory > > dpkg: error processing galeon-common (--configure): > > subprocess post-installation script returned error exit status 1 > > I think dpkg is broken somehow: the file IS in the galeon-common-package. > > dpkg -c galeon-common_1.2.5-1_all.deb | grep schema > [...] ./etc/gconf/schemas/galeon.schemas > > I've seen this problem before, it must come from dpkg's conffile > mechanism. If you "dpkg --purge galeon galeon-common galeon-nautilus" > and then install galeon again it should work fine. > I don't know how to reproduce it. I didn't have galeon installed. After a purge of galeon-common galeon-nautilus and a reinstall it worked just fine. > (Note that the file was in the galeon package itself before, maybe > moving conffiles from one package to another doesn't work properly?) > > Do you know what the previous version of galeon was that you had > installed? The last one that was in unstable yesterday. Cheers Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#150135: galeon-common: tries to open non-existant file
Processing commands for [EMAIL PROTECTED]: > reassign 150135 dpkg Bug#150135: galeon-common: tries to open non-existant file Bug reassigned from package `galeon-common' to `dpkg'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#150156: dpkg: conffile diffs don't work
Package: dpkg Version: 1.9.21 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I choose to see a diff for a modified conffile, I get returned to the prompt immediately, no trace of any diff output. PS: Sorry if this has already been reported, I started skimming the list of bugs against this package but gave up after about a hundred... PPS: Kinda bad to have this bug in woody, isn't it? - -- System Information Debian Release: 3.0 Architecture: powerpc Kernel: Linux tibook 2.4.19-pre8-ben0-xfs-fblogo-lolat #12 Fri May 31 18:15:41 CEST 2002 ppc Locale: LANG=C, LC_CTYPE=de_CH Versions of packages dpkg depends on: ii libc62.2.5-6 GNU C Library: Shared libraries an ii libncurses5 5.2.20020112a-8 Shared libraries for terminal hand ii libstdc++2.10-glibc2.2 1:2.95.4-7 The GNU stdc++ library -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9DIhcWoGvjmrbsgARAjsEAKCJRgCjrBRpo7ZwuQJLqkpaVAtDWACdG8lU 4cC+I94VBgz5NcDg939jkGY= =fxdN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#147183: I suspect hardware problems
I've seen weird stuff happen on my system, and the stuff described here looks similar. (My problem was data errors due to insufficient power supply capacity. This usually caused segfaults. The solution was to lower the CPU clock frequency.) The problem seems to be that tar crashes or something when run from dpkg, unless tar's code is already in the disk cache. (This is the only difference that running tar a few times beforehand could cause, that I can think of.) If disk caching is making a difference, caching of the .deb might also be making a difference maybe relevant to the problems extracting control files). Kurt> Now that you mention it, the machine *is* acting somewhat strange; so far Kurt> it's frozen twice in the middle of reading man pages. Random hangs are very indicative of hardware problems. Pekka> Sounds to me like an eccentric kernel bug If so, it's probably in the ide or SCSI hardware driver Kurt is using. >> your system is fundamentally screwed up Kurt> Always a possibility. Any way for me to check this? Use very conservative settings to try to avoid hardware errors. Don't worry about performance for now. What you want to do is see if things change when you give the hardware a large margin of error. If that makes the problems go away, you can try to figure out what's going on so you can get decent performance without errors from your system. If you using an IDE system, try using hdparm to turn off some IDE features. For starters, try without DMA. You might also want to use ide-smart to ask your disk how it's feeling :) Your IO system might have occasional errors when reading and writing simultaneously. This is especially likely if you have disks on separate IDE channels. (However, I haven't heard of this kind of problem on SMP i686 chipsets. Crappy i4 and 586 and chipsets had these kinds of problems.) Try underclocking your CPU/RAM. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
