Bug filing advice needed: package uninstallable on amd64 only
Abiword is uninstallable on AMD64. It appears that the library package libenchant1c2 has been replaced by the package libenchant1c2a. This new package is available for AMD64; but the AMD64 Abiword port, and *only* the AMD64 port of Abiword, still has a dependency on the older libenchat1c2, which is no longer available. I'm curious what the proper way to proceed with this is. File a bug against Abiword with an AMD64 tag? Something else? Is it OK for us to file non-wishlist bugs of this sort, given that we're not yet an official port? Thanks, -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Confirm needed: python2.3 (thus lots of other stuff) uninstallable from etch?
Simo Kauppi wrote: On Sun, Feb 05, 2006 at 06:12:51AM +, [EMAIL PROTECTED] wrote: Can anyone else confirm this: } stax:/etc/apt# apt-get install python2.3 } Reading package lists... Done } Building dependency tree... Done } Package python2.3 is not available, but is referred to by another package. } This may mean that the package is missing, has been obsoleted, or } is only available from another source } However the following packages replace it: } python } E: Package python2.3 has no installation candidate } } The following packages have unmet dependencies. } python: Depends: python2.3 (= 2.3.5-1) but it is not installable } E: Broken packages Because of this, tons of stuff, from reportbug to GNOME, is uninstallable for me. My sources.list mirrors are: } deb http://debian.csail.mit.edu/debian-amd64/debian/ etch main contrib } deb-src http://debian.csail.mit.edu/debian-amd64/debian/ etch main contrib } } deb http://mirror.espri.arizona.edu/debian-amd64/debian/ etch main contrib } deb-src http://mirror.espri.arizona.edu/debian-amd64/debian/ etch main contrib Can anyone else confirm this? Yes, the 'Packages' of your mirror doesn't seem to have 'python2.3' and 'python' depends on that. It seems to be one those old version doesn't exist anymore, but the new version has not entered testing (or your mirror) yet situations. The actual file (both old and new) seem to be in the pool, so maybe the Packages file of your mirror is out of date: http://debian.csail.mit.edu/debian-amd64/debian/pool/main/p/python2.3/python2.3_2.3.5-8_amd64.deb http://debian.csail.mit.edu/debian-amd64/debian/pool/main/p/python2.3/python2.3_2.3.5-9_amd64.deb My mirror has the newer version, so you might want to try a different mirror, or wait until it gets into your mirror. Hmm, well, I just tried a whole bunch of mirrors -- specifically, I've tried debian.csail.mit.edu, mirror.espri.arizona.edu, ftp.de.debian.org, debian.inode.at, and ftp.jp.debian.org. All five of them had this problem; so it seems pretty widespread. I hadn't considered fetching the package directly, though; I went and looked on the mirror I normally use and it was indeed there, as you suggest above. Thanks. I use ftp://ftp.nl.debian.org/debian-amd64/debian/ apt-get updating from here gives: Failed to fetch ftp://ftp.nl.debian.org/debian-amd64/debian/dists/etch/main/source/Sources.gz MD5Sum mismatch Failed to fetch ftp://ftp.nl.debian.org/debian-amd64/debian/dists/etch/contrib/source/Sources.gz MD5Sum mismatch which is a bit worrisome! -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DMA missing after install -- rebuild initrd? HOWTO?
Sorry for the delay in responding; work kept me offline for a while. Lennart Sorensen wrote: On Wed, Feb 01, 2006 at 02:26:59AM +, [EMAIL PROTECTED] wrote: [ snip ] I've never built or rebuilt an initrd, or monkeyed with the contents of one. When I haven't been able to use a Debian install kernel, I've always just built my own and compiled the drive controller/ filesystem modules into the kernel, so there's no issue. I could do that again here, and I plan to eventually; but I'd like to have the installation kernel working well first so I can use it as a base from which to start (these are my first steps with 2.6.x as well). So I'm wondering if someone can point me at good docs/a howto for building/rebuilding the Debian install initrd? I have a vague memory of people commenting that mkinitrd is now deprecated in favor of yaird -- that correct? Well which kernel version do you use Right now, just as noted, the etch install kernel, which is 2.6.12-1-amd64-generic; I'll switch to 2.6.12-1-amd64-k8 right away, though, so that's fine too. and do you use mkinitrd, yaird or initramfs-tools? None of the above -- I use nothing, since I've never monkeyed around with initrds before. But I had a vague memory of people here discussing mkinitrd being deprecated in favor of yaird, but yaird having some problem on amd64 at the moment. Am I remembering correctly? -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
AMD64 Install (failure) report
Processor/Mobo: Athlon64 3800 Venice; ASUS A8N-SLI Premium IDE0 -- LiteOn DVD-ROM, WD 1200JB 120GB IDE1 -- WD 1200JB 120GB, WD 800JB 80GB SATA0 -- WD 2500KS 250GB PCI-E: nVidia 6800GS 256MB PCI: Creative SB Live 5.1 Install source: Etch Netinstall CD image dated 2006/01/11. A few weeks old, but I've successfully used it several times to install on this same machine, with the same hardware, as practice / just screwing around. First half of the install went fine. Problem #1 came on the reboot -- the Grub menu came up fine, but booting the kernel failed with an error 17. This I had to solve by going to the Grub command line. The problem ended up being that when menu.lst was written and Grub was installed, the SATA drive (on which the operating system was installed) was identified as (hd3) (the three IDE drives got (hd0) through (hd2)), so the root line in Grub's menu.lst identified the root partition as (hd3,0). However, when actually run during the reboot, the SATA drive got associated with (hd0), with the IDE drives going to (hd1) through (hd3). So I had to specify root, kernel and initrd by hand from the command line. Booting then worked. Problem #2 was a showstopper: during the second half of the install, after using what looks like the current incarnation of tasksel to pick stuff to install, I got configuration questions about those packages (e.g. exim configuration stuff). Then, at the point where it'd presumably start installing and configuring all the packages it had fetched, my screen flooded with a zillion instances of: /bin/sh: /usr/sbin/termwrap: No such file or directory /bin/sh: line 0: exec: /usr/sbin/termwrap: cannot execute: No such file or directory followed by one instance of: INIT: Id 1 respawning too fast: disabled for 5 minutes. after which the console just sat there. From inspecting my mirror (debian.csail.mit.edu), the package base-config appears to have gone weird around January 1. There are two versions on the mirror; 2.73 has a 251k .deb file which includes /usr/sbin/termwrap, while 2.76 has a 41k .deb which does not (and which is also missing lots of other stuff in the 2.73 file). So maybe after rebooting into the system to finish the install, updated versions of packages installed from the netinstall CD are fetched, and that one is broken? But then how was I able to install successfully previous times since January 11? Maybe some other package's install script calls termwrap, and isn't supposed to anymore? Advice on how to proceed with install much appreciated. -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DMA missing after install -- rebuild initrd? HOWTO?
Hi, After playing around for a while, I decided to go ahead and do my AMD64 Etch install for real. At the end of it, though, I got a surprise -- no DMA on any IDE devices. The drives are capable, the BIOS recognizes them as UDMA5, I tried a bunch of different 80-connector cables, and hdparm shows them as udma5 too. But still, attempts to turn on DMA got the well-known DIO_SET_DMA failed: Operation not permitted error. While googling like crazy for ideas, I came upon this thread from this mailing list: http://lists.debian.org/debian-amd64/2005/08/msg00309.html which suggests the problem may be loading ide-generic before my chipset-specific module, and that the solution would be to rebuild my initrd. Since my symptoms look similar to those described in this thread, I'll give it a shot. I've never built or rebuilt an initrd, or monkeyed with the contents of one. When I haven't been able to use a Debian install kernel, I've always just built my own and compiled the drive controller/ filesystem modules into the kernel, so there's no issue. I could do that again here, and I plan to eventually; but I'd like to have the installation kernel working well first so I can use it as a base from which to start (these are my first steps with 2.6.x as well). So I'm wondering if someone can point me at good docs/a howto for building/rebuilding the Debian install initrd? I have a vague memory of people commenting that mkinitrd is now deprecated in favor of yaird -- that correct? Thanks for any info. -c P.S. What's odd about this is that at one point in my playing around, I *did* have DMA access. I added some drives and did my install, and presto, no DMA anymore. So if it is the ide-generic loaded before chipset-specific issue, the loading sequence apparently can vary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How big will the 32-bit chroot end up being? What goes in these days?
Gilles wrote: - cdrecord/cdrdao plus whatever front end you're using to call them These and k3b all work on amd64. Thanks for the info. I'd seen a few webpages (such as http://desktux.xs4all.nl/tips/amd64.php ) that indicated there were serious bugs in the AMD64 version that hadn't yet been patched in etch. Perhaps they're out of date. -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How big will the 32-bit chroot end up being? What goes in these days?
mtms wrote: On 23 Jan 2006, 05:34, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - cdrecord/cdrdao plus whatever front end you're using to call them Huh? I'm using them every day on my amd64 system. And xcdroast too :) Thanks. I'd read elsewhere that the AMD64 cdrdao was buggy, and the patch to fix the bugs wasn't in either Sarge or Etch yet. I guess that's out-of-date info. -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How big will the 32-bit chroot end up being? What goes in these days?
Hi; thanks for your reply. No need to cc me; I read the list. Lennart Sorensen wrote: On Mon, Jan 23, 2006 at 05:34:13AM +, [EMAIL PROTECTED] wrote: So, as I understand it, the following stuff would need to go into the 32-bit chroot (assuming one wants/needs these things): - Sun's J2RE There is 64bit java as far as I know. Not sure about browser plugins. Heh. I had assumed that Sun didn't have an AMD64 version out; but I just went and looked, and there it is. Thanks for the tip. - cdrecord/cdrdao plus whatever front end you're using to call them No reason. Those work fine on amd64. Thanks. As I mentioned in other replies, I'd read on a few pages that cdrdao had significant bugs under AMD64, that a patch existed to fix those bugs, but that the Sarge and Etch versions hadn't yet been patched. Presumably, re: Etch, that info is just out of date? How much space would all that take? Assuming one were to put the chroot in its own partition, how much space should be allocated to that partition? If you're using an AMD64 desktop, how much space are you using in the chroot? chroot can just be a directory. No need for a partition. Sure is simpler. Yeah; but then the question becomes where to put it (i.e. in what existing partition to include it). The HOWTO suggests /var; but /var on this box could fluctuate strongly in disk space used. I want to avoid any issues if /var fills up. And at any rate, even if I do just put it in a subdir rather than its own full-fledged partition, I still need a vague idea of how much space the stuff in the chroot will take up, so that I can allocate enough space to the larger partition (that the chroot subdir will end up a part of) for both the chroot and its other contents. Cheers, -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge AMD64 installation won't boot
Robert Isaac wrote: Upgrading past 2.6.12 requires getting yaird or initramfstools installed on sarge somehow. It can be done however. Yaird is not too hard to backport. You could even save yourself some effort and install Yaird from backports.org :) OK, I have a dumbass question: why is yaird necessary at all? Or more accurately, why is an initrd necessary at all? Is it something about 2.6.x kernels? Back when I built 2.4.x kernels for my Athlon XP machine, I follwed the script of http://newbiedoc.sourceforge.net/system/kernel-pkg.html and I never messed with an initrd. My understanding is that the purpose of an initrd is to provide an image of a RAMdisk containing the modules the kernel needs to access the root file system; but if the hardware and filesystem support needed is compiled into the kernel, why even bother with an initrd? -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How big will the 32-bit chroot end up being? What goes in these days?
So, as I understand it, the following stuff would need to go into the 32-bit chroot (assuming one wants/needs these things): - Sun's J2RE - OpenOffice - Flash - RealPlayer/Helix/whatever - win32codecs + other misc A/V codecs one might scrounge up elsewhere - Any web browser that you want to be able to use Java/Flash/embedded AV stuff in - the Acrobat Reader - cdrecord/cdrdao plus whatever front end you're using to call them Is that correct? Anything I'm missing? How much space would all that take? Assuming one were to put the chroot in its own partition, how much space should be allocated to that partition? If you're using an AMD64 desktop, how much space are you using in the chroot? Cheers, -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
Am following the discussion of jigdo with interest -- but in the meantime, no need to cc: me directly on all the posts; I'm subscribed to the list. Thanks! -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Anyone willing to seed sarge amd64 isos?
Hi. Is there anyone (hopefully, more than one person) who's willing to seed sarge amd64 dvd ISOs for bittorrent for a while? I've been stuck at 39% and 24% for quite a while. Edit: well, it looks like someone has ESP, in that someone just started seeding within the last 30 minutes. Still, if more people could jump in that'd be very very helpful (especially since I dunno how long that person will be around). Thanks. -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
I just started them, and someone started downloading them at 700 KB/s Probably me. Thanks muchly. Why didn't you just download them from one of the mirrors anyway? Honestly? I figured the AMD64 ISOs would be reasonably popular, so bt would go quickly; and at the same time, I've always tried to avoid downloading ISOs directly from mirrors, just to be kind to mirror bandwidth and demand. If I stayed stuck for too long, I probably would have just gone with jigdo. Thanks again. At 77%/82% now. I'll definitely seed for a good while after I'm done. -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
