Re: The future of the amd64 port
Well, I removed the old entries. The problem is clearly introduced by the new entries. Interestingly, although the packages provided by Sarge and Etch should theoretically be the same, they behave differently. I tried this with diff, which is one of the about 20 packages affected on my system: 1. ~# aptitude -t stable -syvDV install diff ... The following packages have been kept back: ... The following packages will be upgraded: diff [2.8.1-11 - 2.8.1-11] 1 packages upgraded, 0 newly installed, 0 to remove and 22 not upgraded. Need to get 0B/190kB of archives. After unpacking 0B will be used. Inst diff [2.8.1-11] (2.8.1-11 Debian AMD64 archive:3.1r0/stable) Conf diff (2.8.1-11 Debian AMD64 archive:3.1r0/stable) 2. ~# aptitude -t testing -syvDV install diff ... The following NEW packages will be automatically installed: tzdata [2006c-2] (D: libc6) The following packages will be automatically REMOVED: base-config [2.53.10-0.0.0.1.pure64] (C: locales) The following packages have been kept back: ... The following NEW packages will be installed: tzdata [2006c-2] The following packages will be REMOVED: base-config [2.53.10-0.0.0.1.pure64] The following packages will be upgraded: diff [2.8.1-11 - 2.8.1-11] libc6 [2.3.2.ds1-22 - 2.3.6-7] libc6-dev [2.3.2.ds1-22 - 2.3.6-7] locales [2.3.2.ds1-22 - 2.3.6-7] 4 packages upgraded, 1 newly installed, 1 to remove and 448 not upgraded. Need to get 10.6MB of archives. After unpacking 8086kB will be freed. Remv base-config (2.53.10-0.0.0.1.pure64 Debian AMD64 archive:3.1r0/stable) Inst tzdata (2006c-2 Debian:testing) Inst libc6-dev [2.3.2.ds1-22] (2.3.6-7 Debian:testing) [] Inst locales [2.3.2.ds1-22] (2.3.6-7 Debian:testing) [] Inst libc6 [2.3.2.ds1-22] (2.3.6-7 Debian:testing) Conf tzdata (2006c-2 Debian:testing) Conf libc6 (2.3.6-7 Debian:testing) Inst diff [2.8.1-11] (2.8.1-11 Debian:testing) Conf diff (2.8.1-11 Debian:testing) Conf libc6-dev (2.3.6-7 Debian:testing) Conf locales (2.3.6-7 Debian:testing) So, we have the same package with different dependencies when installed via Sarge and Etch? Regards, Clemens On Wednesday 26 April 2006 19:39, Goswin von Brederlow wrote: And don't forget to remove the obsolete entries from sources.list. MfG Goswin -- --- Clemens Bergmann Schwertlilienweg 14 68259 Mannheim [EMAIL PROTECTED] --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
[EMAIL PROTECTED] writes: Well, I removed the old entries. The problem is clearly introduced by the new entries. Interestingly, although the packages provided by Sarge and Etch should theoretically be the same, they behave differently. I tried this with diff, which is one of the about 20 packages affected on my system: 1. ~# aptitude -t stable -syvDV install diff ... The following packages have been kept back: ... The following packages will be upgraded: diff [2.8.1-11 - 2.8.1-11] 1 packages upgraded, 0 newly installed, 0 to remove and 22 not upgraded. Need to get 0B/190kB of archives. After unpacking 0B will be used. Inst diff [2.8.1-11] (2.8.1-11 Debian AMD64 archive:3.1r0/stable) Conf diff (2.8.1-11 Debian AMD64 archive:3.1r0/stable) Stable is one of the old entries. 2. ~# aptitude -t testing -syvDV install diff ... The following NEW packages will be automatically installed: tzdata [2006c-2] (D: libc6) The following packages will be automatically REMOVED: base-config [2.53.10-0.0.0.1.pure64] (C: locales) The following packages have been kept back: ... The following NEW packages will be installed: tzdata [2006c-2] The following packages will be REMOVED: base-config [2.53.10-0.0.0.1.pure64] The following packages will be upgraded: diff [2.8.1-11 - 2.8.1-11] libc6 [2.3.2.ds1-22 - 2.3.6-7] libc6-dev [2.3.2.ds1-22 - 2.3.6-7] locales [2.3.2.ds1-22 - 2.3.6-7] 4 packages upgraded, 1 newly installed, 1 to remove and 448 not upgraded. Need to get 10.6MB of archives. After unpacking 8086kB will be freed. Remv base-config (2.53.10-0.0.0.1.pure64 Debian AMD64 archive:3.1r0/stable) Inst tzdata (2006c-2 Debian:testing) Inst libc6-dev [2.3.2.ds1-22] (2.3.6-7 Debian:testing) [] Inst locales [2.3.2.ds1-22] (2.3.6-7 Debian:testing) [] Inst libc6 [2.3.2.ds1-22] (2.3.6-7 Debian:testing) Conf tzdata (2006c-2 Debian:testing) Conf libc6 (2.3.6-7 Debian:testing) Inst diff [2.8.1-11] (2.8.1-11 Debian:testing) Conf diff (2.8.1-11 Debian:testing) Conf libc6-dev (2.3.6-7 Debian:testing) Conf locales (2.3.6-7 Debian:testing) So, we have the same package with different dependencies when installed via Sarge and Etch? All packages were recompiled for debian, that includes versions that are the same in sarge. The reinstallation of packages with the same version is a side effect we have to live with. Regards, Clemens MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
I have server with etch debian. After I changed source list to debian.org many packages want upgrade to the same version. Is there any tricks to prevent this? -- Olleg Samoylov smime.p7s Description: S/MIME Cryptographic Signature
Re: The future of the amd64 port
Hi Olleg, I have just stumbled across a similar (the same?) problem. I am running Sarge with addition of some Etch packages. After switching sources.list from http://ftp.de.debian.org/debian-amd64/debian/ etch main contrib non-free to http://ftp.de.debian.org/debian/ etch main contrib non-free, aptitude wants to install about 20 packages from Sarge 3.1r0 again in the identical version to that already installed. Worst of all, after reinstalling these packages, aptitude keeps repeating the request to reinstall with every run! So, here seems to be a bug in package management. Interestingly, all packages affected have one thing in common: their versions are identical in Sarge/Stable and Etch/Testing. It looks like Aptitude is believing that these packages are installed from Etch and therefore tries to update them to the newest version (I use pinning to stay with Sarge except for those packages I added from Etch). However, as the packages installed from Etch are identical to those from Sarge, Aptitude goes through this process over and over. Regards Clemens On Wednesday 26 April 2006 10:41, Olleg Samoylov wrote: I have server with etch debian. After I changed source list to debian.org many packages want upgrade to the same version. Is there any tricks to prevent this? -- --- Clemens Bergmann Schwertlilienweg 14 68259 Mannheim [EMAIL PROTECTED] --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
I am running Sarge with addition of some Etch packages. After switching sources.list from http://ftp.de.debian.org/debian-amd64/debian/ etch main contrib non-free to http://ftp.de.debian.org/debian/ etch main contrib non-free, aptitude wants to install about 20 packages from Sarge 3.1r0 again in the identical version to that already installed. Worst of all, after reinstalling these packages, aptitude keeps repeating the request to reinstall with every run! OK, this is also my situation. I've been working on it with Goswin von Brederlow in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351056, but we haven't gotten to the bottom of it yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
On Wednesday 26 April 2006 09:40, [EMAIL PROTECTED] wrote: aptitude wants to install about 20 packages from Sarge 3.1r0 again in the identical version to that already installed. Worst of all, after reinstalling these packages, aptitude keeps repeating the request to reinstall with every run! I had the same problem try going into your /var/cache/apt/archvies directory and deleting those packages that are in the cache. Then when you allow them to upgrade the new packages should be downloaded and installed getting rid of the annoying behavior. Stephen -- GPG Pubic Key: http://users.eastlink.ca/~stephencormier/publickey.asc pgpCwoCbm45d3.pgp Description: PGP signature
Re: The future of the amd64 port
Andrew Schulman [EMAIL PROTECTED] writes: I am running Sarge with addition of some Etch packages. After switching sources.list from http://ftp.de.debian.org/debian-amd64/debian/ etch main contrib non-free to http://ftp.de.debian.org/debian/ etch main contrib non-free, aptitude wants to install about 20 packages from Sarge 3.1r0 again in the identical version to that already installed. Worst of all, after reinstalling these packages, aptitude keeps repeating the request to reinstall with every run! OK, this is also my situation. I've been working on it with Goswin von Brederlow in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351056, but we haven't gotten to the bottom of it yet. And don't forget to remove the obsolete entries from sources.list. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
Joey Hess [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Can we list the amd64.debian.net mirrors as sarge only and the debian mirrors as etch/sid? Not sure if the Master file had that info. The sarge installer contains a copy (or 2) of the mirror list, so changing Mirrors.masterlist for etch will not affect sarge, aside from needing to be careful that any new versions of the sarge packages avoid downloading the updated list. (Remember to cc me.) Unfortunately a lot of current amd64 hardware won't work with a 2.6.8 kernel. A lot of people have been forced to use the etch installer and then point it at sarge in choose-mirror. That is what we were refering too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
I should know this, but my choices for sources.list repositories have always been provided by the installation program. Now it seems that I'll have to change it, and I'm not sure what the exact change should be. I'm guessing something like: deb ftp://ftp.us.debian.org/amd64/ testing main contrib non-free deb-src ftp://ftp.us.debian.org/amd64/ testing main contrib non-free Would someone please clarify the exact syntax. -- View this message in context: http://www.nabble.com/The-future-of-the-amd64-port-t1421829.html#a3861420 Sent from the debian-amd64 forum at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
rickh [EMAIL PROTECTED] writes: I should know this, but my choices for sources.list repositories have always been provided by the installation program. Now it seems that I'll have to change it, and I'm not sure what the exact change should be. I'm guessing something like: deb ftp://ftp.us.debian.org/amd64/ testing main contrib non-free deb-src ftp://ftp.us.debian.org/amd64/ testing main contrib non-free deb ftp://ftp.us.debian.org/debian/ testing main contrib non-free deb-src ftp://ftp.us.debian.org/debian/ testing main contrib non-free like for any other official port. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
On Tue, Apr 11, 2006 at 06:19:51AM -0700, rickh wrote: I should know this, but my choices for sources.list repositories have always been provided by the installation program. Now it seems that I'll have to change it, and I'm not sure what the exact change should be. I'm guessing something like: deb ftp://ftp.us.debian.org/amd64/ testing main contrib non-free deb-src ftp://ftp.us.debian.org/amd64/ testing main contrib non-free ^ this part should read /debian/. And yes, it looks very reasonable. S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
rickh wrote: I should know this, but my choices for sources.list repositories have always been provided by the installation program. Now it seems that I'll have to change it, and I'm not sure what the exact change should be. I'm guessing something like: deb ftp://ftp.us.debian.org/amd64/ testing main contrib non-free deb-src ftp://ftp.us.debian.org/amd64/ testing main contrib non-free Would someone please clarify the exact syntax. I recommend using this in /tmp: netselect-apt unstable It will find you the fastest repository and create a version of sources.list you can copy selectively to /etc/apt/sources.list. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
On Sun, Apr 09, 2006 at 06:47:14PM -0400, Joey Hess wrote: (Please CC me, I forget if I'm subscribed.) At what point should Mirrors.masterlist be updated to remove the amd64.debian.net mirrors and stop listing all the main mirror network as !amd64? As used in the installer? I guess as long as it supports installing sarge. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
Kurt Roeckx [EMAIL PROTECTED] writes: On Sun, Apr 09, 2006 at 06:47:14PM -0400, Joey Hess wrote: (Please CC me, I forget if I'm subscribed.) At what point should Mirrors.masterlist be updated to remove the amd64.debian.net mirrors and stop listing all the main mirror network as !amd64? As used in the installer? I guess as long as it supports installing sarge. Kurt Can we list the amd64.debian.net mirrors as sarge only and the debian mirrors as etch/sid? Not sure if the Master file had that info. It would be nice to have both sarge and etch/sid installs working. If that can be done I think it should be done asap so the next choose-mirror upload gets the new list. If the list isn't detailed enough I'm not sure what I would prefer. Either sarge or etch/sid will be broken soon then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
Goswin von Brederlow wrote: Can we list the amd64.debian.net mirrors as sarge only and the debian mirrors as etch/sid? Not sure if the Master file had that info. The sarge installer contains a copy (or 2) of the mirror list, so changing Mirrors.masterlist for etch will not affect sarge, aside from needing to be careful that any new versions of the sarge packages avoid downloading the updated list. (Remember to cc me.) -- see shy jo signature.asc Description: Digital signature
The future of the amd64 port
Hi, as some of you already noticed amd64 is now included in Debian unstable and soon in testing also[1]. This renders parts of amd64.debian.net unnecessary now (but please read on, especially mirror admins the last paragraph, thanks). As inclusion of AMD64 in Debian is now at a point where unstable nearly has all packages built[2] we are at the point to move on with this archive. We therefore decided on the following plan, which should give the smoothest possible transition: 0. Users of stable: *NOTHING* changes for you. You can skip the rest. Sarge will always be on amd64.debian.net and its mirrors, security for it will always be on security.debian.org. You only need to change something if you upgrade to etch later, but if you stay with sarge you can skip the rest of this mail. 1. amd64.debian.net will stop its own buildd and import source and binaries from Debian. 2. This method will be used until Debian etch is synced so far that debian-installer can install an etch system only using debian mirrors (and the CD-guys can built etch images only using debian mirrors). 3. At the time point 2 happens we will stop updating the amd64.debian.net unstable/testing tree, 2 weeks later we will remove them. 4. Users of unstable are encouraged to change their /etc/apt/sources.list to point to a Debian mirror now. 5. Users of testing need to wait a bit more, until Debian testing includes enough amd64 packages. That should be soon.[3] Mirror Admins: Please do *not* delete amd64 out of your configs. We will delete the unstable and etch part only (and free some space on your machines with it), but keep sarge for its whole lifetime (which means as long as the security team supports it after etch is released). You dont need to do anything, we still need you. Footnotes: [1] Thanks to the hard work of the/our buildd admin(s). [2] Modulo those that are now RC-Buggy due to FTBFS and need a new upload and also modulo those that will get removed soon (like old python versions). [3] Well, if not you will notice the 404s you get back from the archive when we drop it, after having a period of no updates. :) -- bye Joerg Maulkin ie: are we getting a nice connection? :) * gwolf silently reads Maulkin's question stone-head netinstall over 56kbps modem stockholm Maulkin: yes, they hope to have drums installed at the hotel by then so they can communicate with them at 20bit/s gwolf stockholm: Make them _fast_ drums! stockholm ok, 40bit/s gwolf I still have to meet a drummer who can slap at 40hz pgpfnJHRdJQFz.pgp Description: PGP signature
