Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
amd64 as default architecture
56 views
Skip to first unread message
Ben Hutchings
May 19, 2012, 10:20:01 PM5/19/12
to
Most new PCs have an Intel or AMD 64-bit processor, and
popcon.debian.org shows amd64 numbers almost matching i386.
For some time we have also provided the amd64 kernel for i386, identical
in all but the package metadata. This has not always been perfectly
compatible with i386 userland, but split 32/64-bit installations are
increasingly used and I think most bugs have been flushed out by now.
Thanks to multi-arch you can now add amd64 as a secondary architecture
and install the kernel package from amd64, and if your system is running
such a kernel then it can also support userland packages from amd64.
So in wheezy I would like to see:
1. Default architecture (top of the list for installation media/manual)
being amd64 ('64-bit PC').
2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
a secondary architecture (debconf note?).
Then in wheezy+1:
3. amd64 kernel flavour for i386 dropped.
4. Kernel and common libraries for amd64 included in i386 installation
media; kernel included on low-number disc.
5. Installer for i386 prefers amd64 kernel on any capable machine
(that's a one-line change!) and adds amd64 as secondary architecture if
this is selected.
Eventually (wheezy+2? +3?) we would stop building a kernel package for
i386.
Does anyone see a problem with the above, in particular points 1 and 2?
(Also, much of the above applies to s390x vs s390. And please let's
have ppc64 and sparc64 soon!)
Ben.
--
Ben Hutchings
All extremists should be taken out and shot.
popcon.debian.org shows amd64 numbers almost matching i386.
For some time we have also provided the amd64 kernel for i386, identical
in all but the package metadata. This has not always been perfectly
compatible with i386 userland, but split 32/64-bit installations are
increasingly used and I think most bugs have been flushed out by now.
Thanks to multi-arch you can now add amd64 as a secondary architecture
and install the kernel package from amd64, and if your system is running
such a kernel then it can also support userland packages from amd64.
So in wheezy I would like to see:
1. Default architecture (top of the list for installation media/manual)
being amd64 ('64-bit PC').
2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
a secondary architecture (debconf note?).
Then in wheezy+1:
3. amd64 kernel flavour for i386 dropped.
4. Kernel and common libraries for amd64 included in i386 installation
media; kernel included on low-number disc.
5. Installer for i386 prefers amd64 kernel on any capable machine
(that's a one-line change!) and adds amd64 as secondary architecture if
this is selected.
Eventually (wheezy+2? +3?) we would stop building a kernel package for
i386.
Does anyone see a problem with the above, in particular points 1 and 2?
(Also, much of the above applies to s390x vs s390. And please let's
have ppc64 and sparc64 soon!)
Ben.
--
Ben Hutchings
All extremists should be taken out and shot.
Steve Langasek
May 19, 2012, 11:00:02 PM5/19/12
to
Hi Ben,
On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
switching to amd64 as a default for 12.04 - namely, that even though almost
all new hardware coming out would benefit from a 64-bit OS, there's a
sizeable fraction of users for whom a 64-bit CD would be nothing more than a
coaster.
https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035088.html
Now perhaps it's easier for Debian to switch this default than it is for
Ubuntu, since Debian's choice of default arch doesn't have quite the same
"all or nothing" impact on pressed CDs and the like. But IMHO it's better
for our users to choose a default that's safe, at the cost of some users not
getting the most out of their hardware if they use the default.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
> So in wheezy I would like to see:
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').
> 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> a secondary architecture (debconf note?).
My biggest concern with this is the same that prevented Ubuntu from
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').
> 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> a secondary architecture (debconf note?).
switching to amd64 as a default for 12.04 - namely, that even though almost
all new hardware coming out would benefit from a 64-bit OS, there's a
sizeable fraction of users for whom a 64-bit CD would be nothing more than a
coaster.
https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035088.html
Now perhaps it's easier for Debian to switch this default than it is for
Ubuntu, since Debian's choice of default arch doesn't have quite the same
"all or nothing" impact on pressed CDs and the like. But IMHO it's better
for our users to choose a default that's safe, at the cost of some users not
getting the most out of their hardware if they use the default.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Ben Hutchings
May 19, 2012, 11:20:02 PM5/19/12
to
On Sat, 2012-05-19 at 19:44 -0700, Steve Langasek wrote:
> Hi Ben,
>
> On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
>
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
> > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > a secondary architecture (debconf note?).
>
> My biggest concern with this is the same that prevented Ubuntu from
> switching to amd64 as a default for 12.04 - namely, that even though almost
> all new hardware coming out would benefit from a 64-bit OS, there's a
> sizeable fraction of users for whom a 64-bit CD would be nothing more than a
> coaster.
I certainly don't propose to have any pages where amd64 is the only
> Hi Ben,
>
> On Sun, May 20, 2012 at 03:16:15AM +0100, Ben Hutchings wrote:
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
>
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
> > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > a secondary architecture (debconf note?).
>
> My biggest concern with this is the same that prevented Ubuntu from
> switching to amd64 as a default for 12.04 - namely, that even though almost
> all new hardware coming out would benefit from a 64-bit OS, there's a
> sizeable fraction of users for whom a 64-bit CD would be nothing more than a
> coaster.
option. But where we have lists of multiple architectures, I would like
to see '64-bit PC' first.
Quite a few such lists sorted alphabetically by Debian architecture
name, which means that 'amd64' comes first. However, 'amd64' confuses
many people, and sorting by descriptive name puts '32-bit PC' first.
> https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035088.html
>
> Now perhaps it's easier for Debian to switch this default than it is for
> Ubuntu, since Debian's choice of default arch doesn't have quite the same
> "all or nothing" impact on pressed CDs and the like. But IMHO it's better
> for our users to choose a default that's safe, at the cost of some users not
> getting the most out of their hardware if they use the default.
linked from the front of www.debian.org - is an amd64/i386 netinst
image, which encourages use of amd64 while still being 'safe'.
Marco d'Itri
May 20, 2012, 12:20:02 AM5/20/12
to
On May 20, Ben Hutchings <b...@decadent.org.uk> wrote:
> Then in wheezy+1:
> 3. amd64 kernel flavour for i386 dropped.
Why can't we use the multiarch package in wheezy?
> Then in wheezy+1:
> 3. amd64 kernel flavour for i386 dropped.
--
ciao,
Marco
Marc Haber
May 20, 2012, 4:10:01 AM5/20/12
to
target freeze date are a bad idea and should be done right after a
release so that the change get maximum exposure before it is
considered for a stable release?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/E1SW0Ev-...@swivel.zugschlus.de
Goswin von Brederlow
May 20, 2012, 5:30:01 AM5/20/12
to
Ben Hutchings <b...@decadent.org.uk> writes:
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
>
> For some time we have also provided the amd64 kernel for i386, identical
> in all but the package metadata. This has not always been perfectly
> compatible with i386 userland, but split 32/64-bit installations are
> increasingly used and I think most bugs have been flushed out by now.
> Thanks to multi-arch you can now add amd64 as a secondary architecture
> and install the kernel package from amd64, and if your system is running
> such a kernel then it can also support userland packages from amd64.
>
> So in wheezy I would like to see:
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').
Default image could be multiple archs. We had i386/amd64/ppc DVD images
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
>
> For some time we have also provided the amd64 kernel for i386, identical
> in all but the package metadata. This has not always been perfectly
> compatible with i386 userland, but split 32/64-bit installations are
> increasingly used and I think most bugs have been flushed out by now.
> Thanks to multi-arch you can now add amd64 as a secondary architecture
> and install the kernel package from amd64, and if your system is running
> such a kernel then it can also support userland packages from amd64.
>
> So in wheezy I would like to see:
> 1. Default architecture (top of the list for installation media/manual)
> being amd64 ('64-bit PC').
in the past and that seems like the best default. It simply works (near
enough) everywhere. Doesn't work for all image types but where it does ...
> 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> a secondary architecture (debconf note?).
installed the amd64 kernel image but also i386 on amd64.
Slightly OT but I wanted to mention it for its similarity:
One thing that should be tested and then documented prominently as yay
or nay in the wheezy upgrade notes is wether one can cross-grade from
i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
then migrate to a 64bit userspace.
> Then in wheezy+1:
> 3. amd64 kernel flavour for i386 dropped.
> 4. Kernel and common libraries for amd64 included in i386 installation
> media; kernel included on low-number disc.
> 5. Installer for i386 prefers amd64 kernel on any capable machine
> (that's a one-line change!) and adds amd64 as secondary architecture if
> this is selected.
Otherwise it won't see the amd64 kernel in the first place.
> Eventually (wheezy+2? +3?) we would stop building a kernel package for
> i386.
> Does anyone see a problem with the above, in particular points 1 and 2?
> (Also, much of the above applies to s390x vs s390. And please let's
> have ppc64 and sparc64 soon!)
>
> Ben.
Goswin
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87mx53i...@frosties.localnet
Thomas Goirand
May 20, 2012, 7:20:01 AM5/20/12
to
On 05/20/2012 10:16 AM, Ben Hutchings wrote:
> Does anyone see a problem with the above, in particular points 1 and 2?
>
I agree with all you said (you know better than I), but what
> Does anyone see a problem with the above, in particular points 1 and 2?
>
I would really love to see would be the installer warning
people when they try to install the i386 version on a 64 bits
capable machine.
Yes, it's a bit stupid, but some users still don't understand
that amd64 arch also works on Intel! A very simple debconf menu
in the installer, explaining what's going on, would solve the issue.
Just my 2 cents,
Thomas
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Joachim
May 20, 2012, 7:20:02 AM5/20/12
to
On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
> Slightly OT but I wanted to mention it for its similarity:
>
> One thing that should be tested and then documented prominently as yay
> or nay in the wheezy upgrade notes is wether one can cross-grade from
> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> then migrate to a 64bit userspace.
Won't work in wheezy, apt does not support crossgradesน. Making it a
> Slightly OT but I wanted to mention it for its similarity:
>
> One thing that should be tested and then documented prominently as yay
> or nay in the wheezy upgrade notes is wether one can cross-grade from
> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> then migrate to a 64bit userspace.
release goal for wheezy+1 seems to be a good idea, but it's a long way
to get there.
Cheers,
Sven
น Replacing foo:i386 with foo:amd64 is done by removing foo:i386 and
then installing foo:amd64, which does not work for Essential packages.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87aa133...@turtle.gmx.de
David Kalnischkies
May 20, 2012, 8:30:02 AM5/20/12
to
On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
> On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>
>> Slightly OT but I wanted to mention it for its similarity:
>>
>> One thing that should be tested and then documented prominently as yay
>> or nay in the wheezy upgrade notes is wether one can cross-grade from
>> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> then migrate to a 64bit userspace.
>
> Won't work in wheezy, apt does not support crossgradesน.
There is no real reason to require apt to do the heavy lifting here.
> On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>
>> Slightly OT but I wanted to mention it for its similarity:
>>
>> One thing that should be tested and then documented prominently as yay
>> or nay in the wheezy upgrade notes is wether one can cross-grade from
>> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> then migrate to a 64bit userspace.
>
> Won't work in wheezy, apt does not support crossgradesน.
It would be nice, but it is a one-time action, so a specialized tool wouldn't
hurt muscle memory too much. Install essentials and apt and you should
be good to go to proceed as usual, just with a different architecture…
Even most essentials are easy to crossgrade, the only really difficult one
is dpkg and it's dependencies as you have to take care of not breaking it
while it crossgrades itself.
(I think it is unlikely that apt will get support for that soon, if at all,
given that it quiet easily becomes a quiet complicated situation in
general in a codearea which isn't short on complexity already.
And that just for the "once in a blue moon" encounter of a crossgrade?)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
May 20, 2012, 9:10:02 AM5/20/12
to
On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> Ben Hutchings <b...@decadent.org.uk> writes:
>
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
> >
> > For some time we have also provided the amd64 kernel for i386, identical
> > in all but the package metadata. This has not always been perfectly
> > compatible with i386 userland, but split 32/64-bit installations are
> > increasingly used and I think most bugs have been flushed out by now.
> > Thanks to multi-arch you can now add amd64 as a secondary architecture
> > and install the kernel package from amd64, and if your system is running
> > such a kernel then it can also support userland packages from amd64.
> >
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
>
> Default image could be multiple archs. We had i386/amd64/ppc DVD images
> in the past and that seems like the best default. It simply works (near
> enough) everywhere. Doesn't work for all image types but where it does ...
The default image *is* i386/amd64 netinst.
> Ben Hutchings <b...@decadent.org.uk> writes:
>
> > Most new PCs have an Intel or AMD 64-bit processor, and
> > popcon.debian.org shows amd64 numbers almost matching i386.
> >
> > For some time we have also provided the amd64 kernel for i386, identical
> > in all but the package metadata. This has not always been perfectly
> > compatible with i386 userland, but split 32/64-bit installations are
> > increasingly used and I think most bugs have been flushed out by now.
> > Thanks to multi-arch you can now add amd64 as a secondary architecture
> > and install the kernel package from amd64, and if your system is running
> > such a kernel then it can also support userland packages from amd64.
> >
> > So in wheezy I would like to see:
> > 1. Default architecture (top of the list for installation media/manual)
> > being amd64 ('64-bit PC').
>
> Default image could be multiple archs. We had i386/amd64/ppc DVD images
> in the past and that seems like the best default. It simply works (near
> enough) everywhere. Doesn't work for all image types but where it does ...
> > 2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
> > a secondary architecture (debconf note?).
>
> 2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
> installed the amd64 kernel image but also i386 on amd64.
> Slightly OT but I wanted to mention it for its similarity:
>
> One thing that should be tested and then documented prominently as yay
> or nay in the wheezy upgrade notes is wether one can cross-grade from
> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> then migrate to a 64bit userspace.
difficulty, even before multi-arch.)
> > Then in wheezy+1:
> > 3. amd64 kernel flavour for i386 dropped.
> > 4. Kernel and common libraries for amd64 included in i386 installation
> > media; kernel included on low-number disc.
> > 5. Installer for i386 prefers amd64 kernel on any capable machine
> > (that's a one-line change!) and adds amd64 as secondary architecture if
> > this is selected.
>
> D-I (libdebian-installer) must be multiarch aware for that then.
> Otherwise it won't see the amd64 kernel in the first place.
> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > i386.
>
> As in drop the i386 arch?
that to a 'partial architecture' that has only libraries (similar to
ia32-libs today, only cleaner).
Ben.
> > Does anyone see a problem with the above, in particular points 1 and 2?
>
> No problem as such, just more ideas.
>
> > (Also, much of the above applies to s390x vs s390. And please let's
> > have ppc64 and sparc64 soon!)
> >
> > Ben.
Marco d'Itri
May 20, 2012, 10:50:02 AM5/20/12
to
> No, keep i386 userland only. Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
Don't you believe in x32?
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
--
ciao,
Marco
Ben Hutchings
May 20, 2012, 11:00:02 AM5/20/12
to
to be somewhat more efficient than either i386 or amd64. I doubt it's
worth adding to the Debian archive, but if we did then I imagine it
would also be as a partial architecture.
Marco d'Itri
May 20, 2012, 11:10:01 AM5/20/12
to
On May 20, Ben Hutchings <b...@decadent.org.uk> wrote:
> > > No, keep i386 userland only. Though we might consider reducing even
> > > that to a 'partial architecture' that has only libraries (similar to
> > > ia32-libs today, only cleaner).
> > Don't you believe in x32?
> What do you mean, 'believe'? I'm aware it may allow some applications
> to be somewhat more efficient than either i386 or amd64. I doubt it's
> worth adding to the Debian archive, but if we did then I imagine it
> would also be as a partial architecture.
I cannot see any use case, except supporting proprietary software,
> > > No, keep i386 userland only. Though we might consider reducing even
> > > that to a 'partial architecture' that has only libraries (similar to
> > > ia32-libs today, only cleaner).
> > Don't you believe in x32?
> What do you mean, 'believe'? I'm aware it may allow some applications
> to be somewhat more efficient than either i386 or amd64. I doubt it's
> worth adding to the Debian archive, but if we did then I imagine it
> would also be as a partial architecture.
where a i386 userland-only port would be more useful of a x32 port
(which would be userland-only by definition).
I think that we should be seriouly investigating the merits of a x32
port once we are done with multiarch.
--
ciao,
Marco
Andreas Barth
May 20, 2012, 11:40:02 AM5/20/12
to
* Marco d'Itri (m...@Linux.IT) [120520 17:31]:
1. Migration of existing systems is easier.
2. There are still machines bought new which aren't ready for x32.
Andi
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> On May 20, Ben Hutchings <b...@decadent.org.uk> wrote:
>
> > > > No, keep i386 userland only. Though we might consider reducing even
> > > > that to a 'partial architecture' that has only libraries (similar to
> > > > ia32-libs today, only cleaner).
> > > Don't you believe in x32?
> > What do you mean, 'believe'? I'm aware it may allow some applications
> > to be somewhat more efficient than either i386 or amd64. I doubt it's
> > worth adding to the Debian archive, but if we did then I imagine it
> > would also be as a partial architecture.
> I cannot see any use case, except supporting proprietary software,
> where a i386 userland-only port would be more useful of a x32 port
> (which would be userland-only by definition).
Two issues:
>
> > > > No, keep i386 userland only. Though we might consider reducing even
> > > > that to a 'partial architecture' that has only libraries (similar to
> > > > ia32-libs today, only cleaner).
> > > Don't you believe in x32?
> > What do you mean, 'believe'? I'm aware it may allow some applications
> > to be somewhat more efficient than either i386 or amd64. I doubt it's
> > worth adding to the Debian archive, but if we did then I imagine it
> > would also be as a partial architecture.
> I cannot see any use case, except supporting proprietary software,
> where a i386 userland-only port would be more useful of a x32 port
> (which would be userland-only by definition).
1. Migration of existing systems is easier.
2. There are still machines bought new which aren't ready for x32.
Andi
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052015...@mails.so.argh.org
Mike Hommey
May 20, 2012, 12:30:03 PM5/20/12
to
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052016...@glandium.org
Andrey Rahmatullin
May 20, 2012, 12:40:03 PM5/20/12
to
On Sun, May 20, 2012 at 06:24:23PM +0200, Mike Hommey wrote:
> > > > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > > > i386.
> > >
> > > As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
>
> How would plain x86 systems be supposed to boot, then?
Using wheezy+1 (+2?).
> > > > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > > > i386.
> > >
> > > As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
>
> How would plain x86 systems be supposed to boot, then?
--
WBR, wRAR
Russ Allbery
May 20, 2012, 1:50:01 PM5/20/12
to
Ben Hutchings <b...@decadent.org.uk> writes:
> If by 'plain x86' you mean PCs with 32-bit processors, we would no
> longer support them - *eventually*.
Excactly like how we no longer support pure i386 systems (as opposed to
> If by 'plain x86' you mean PCs with 32-bit processors, we would no
> longer support them - *eventually*.
i486 or later). And with the same sort of criteria, I suspect. Note that
Ben is talking about 3-5 years into the future, if not more.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
May 20, 2012, 3:40:02 PM5/20/12
to
>> No, keep i386 userland only. Though we might consider reducing even
>> that to a 'partial architecture' that has only libraries (similar to
>> ia32-libs today, only cleaner).
>> that to a 'partial architecture' that has only libraries (similar to
>> ia32-libs today, only cleaner).
>Don't you believe in x32?
Puke. Please, no. If it had happened back when amd64 was starting up,
it might have looked useful. Now it's a joke and a waste of time.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/E1SWBsa-...@mail.einval.com
Josh Triplett
May 20, 2012, 5:10:02 PM5/20/12
to
Ben Hutchings wrote:
>On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>>> Eventually (wheezy+2? +3?) we would stop building a kernel package
>>> for i386.
>>
>> As in drop the i386 arch?
>
> No, keep i386 userland only. Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
I'd love to see that happen someday, but at the moment, new x86 systems
>On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>>> Eventually (wheezy+2? +3?) we would stop building a kernel package
>>> for i386.
>>
>> As in drop the i386 arch?
>
> No, keep i386 userland only. Though we might consider reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
still get sold that don't support 64-bit. Notably, many low-power Atom
processors still don't support 64-bit. If at some point 64-bit becomes
a required feature on all new x86 processors, with a definite indication
that no new 32-bit-only processors will ever show up, then a few years
after that this change could become reasonable.
The rest of your plan, namely migrating the 64-bit kernel to a multiarch
package instead of an i386 package, seems appropriate as soon as testing
shows that multiarch can smoothly handle it (which probably means after
the wheezy release, for safety). And automatically enabling multiarch
based on processor capabilities seems like a good plan as well;
eventually, that'll start becoming necessary for manageability, once new
partial architectures start showing up for more fine-grained processor
features.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
May 20, 2012, 7:40:02 PM5/20/12
to
On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
> Ben Hutchings wrote:
> >On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings <b...@decadent.org.uk> writes:
> >>> Eventually (wheezy+2? +3?) we would stop building a kernel package
> >>> for i386.
> >>
> >> As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
>
> I'd love to see that happen someday, but at the moment, new x86 systems
> still get sold that don't support 64-bit. Notably, many low-power Atom
> processors still don't support 64-bit.
Right, though I think these are going into phones now, not netbooks.
> Ben Hutchings wrote:
> >On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings <b...@decadent.org.uk> writes:
> >>> Eventually (wheezy+2? +3?) we would stop building a kernel package
> >>> for i386.
> >>
> >> As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
>
> I'd love to see that happen someday, but at the moment, new x86 systems
> still get sold that don't support 64-bit. Notably, many low-power Atom
> processors still don't support 64-bit.
> If at some point 64-bit becomes
> a required feature on all new x86 processors, with a definite indication
> that no new 32-bit-only processors will ever show up, then a few years
> after that this change could become reasonable.
So about 2030 then? I don't believe we need to wait that long - for
example, we dropped support for 386-class processors in 2004 even though
Intel was still selling them (finally EOL'd in 9/2007, apparently). But
certainly we should consider just how many systems might be affected by
changes in minimum specs.
(Should we consider gathering selected hardware specs in popcon?)
Ben.
--
Ben Hutchings
You can't have everything. Where would you put it?
Steve Langasek
May 20, 2012, 8:20:01 PM5/20/12
to
On Sun, May 20, 2012 at 05:39:06PM +0200, Andreas Barth wrote:
> > > > > No, keep i386 userland only. Though we might consider reducing even
> > > > > that to a 'partial architecture' that has only libraries (similar to
> > > > > ia32-libs today, only cleaner).
> > > > Don't you believe in x32?
> > > What do you mean, 'believe'? I'm aware it may allow some applications
> > > to be somewhat more efficient than either i386 or amd64. I doubt it's
> > > worth adding to the Debian archive, but if we did then I imagine it
> > > would also be as a partial architecture.
> > I cannot see any use case, except supporting proprietary software,
> > where a i386 userland-only port would be more useful of a x32 port
> > (which would be userland-only by definition).
> > > > > No, keep i386 userland only. Though we might consider reducing even
> > > > > that to a 'partial architecture' that has only libraries (similar to
> > > > > ia32-libs today, only cleaner).
> > > > Don't you believe in x32?
> > > What do you mean, 'believe'? I'm aware it may allow some applications
> > > to be somewhat more efficient than either i386 or amd64. I doubt it's
> > > worth adding to the Debian archive, but if we did then I imagine it
> > > would also be as a partial architecture.
> > I cannot see any use case, except supporting proprietary software,
> > where a i386 userland-only port would be more useful of a x32 port
> > (which would be userland-only by definition).
> 1. Migration of existing systems is easier.
> 2. There are still machines bought new which aren't ready for x32.
Any such machine would also need a 32-bit kernel, so doesn't seem to be what
> 2. There are still machines bought new which aren't ready for x32.
we're talking about here.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052100...@virgil.dodds.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
May 20, 2012, 8:50:01 PM5/20/12
to
Le Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings a écrit :
> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
> >
> > I'd love to see that happen someday, but at the moment, new x86 systems
> > still get sold that don't support 64-bit. Notably, many low-power Atom
> > processors still don't support 64-bit.
>
> Right, though I think these are going into phones now, not netbooks.
Fit-PC sells an excellent fanless mini-PC with an Atom Z510 that does not
> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
> >
> > I'd love to see that happen someday, but at the moment, new x86 systems
> > still get sold that don't support 64-bit. Notably, many low-power Atom
> > processors still don't support 64-bit.
>
> Right, though I think these are going into phones now, not netbooks.
support 64-bit instructions. It consumes 8 W according to the manufacturer,
which is less than some Arm-based plug computers. I am the happy owner of one
of them and would be quite sad to have to replace it in two years in order to
keep on using Debian Stable on my personal server.
By the way, are there plans to drop the support of the i386 architecture with
kFreeBSD as well ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wookey
May 20, 2012, 8:50:02 PM5/20/12
to
+++ Ben Hutchings [2012-05-21 00:30 +0100]:
to guess how many people we are cutting off when minimum support is
moved forward.
Wookey
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120521002...@stoneboat.aleph1.co.uk
>
> (Should we consider gathering selected hardware specs in popcon?)
Yes please. This would really help arm people too. We currently have
> (Should we consider gathering selected hardware specs in popcon?)
to guess how many people we are cutting off when minimum support is
moved forward.
Wookey
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Henrique de Moraes Holschuh
May 20, 2012, 10:00:02 PM5/20/12
to
On Sun, 20 May 2012, Russ Allbery wrote:
> Ben Hutchings <b...@decadent.org.uk> writes:
> > If by 'plain x86' you mean PCs with 32-bit processors, we would no
> > longer support them - *eventually*.
>
> Excactly like how we no longer support pure i386 systems (as opposed to
> i486 or later). And with the same sort of criteria, I suspect. Note that
> Ben is talking about 3-5 years into the future, if not more.
Try 10 years, if not 15. We'll be able to support just i686 3 years from
> Ben Hutchings <b...@decadent.org.uk> writes:
> > If by 'plain x86' you mean PCs with 32-bit processors, we would no
> > longer support them - *eventually*.
>
> Excactly like how we no longer support pure i386 systems (as opposed to
> i486 or later). And with the same sort of criteria, I suspect. Note that
> Ben is talking about 3-5 years into the future, if not more.
now, I suppose, but even that is not certain.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
May 21, 2012, 1:20:02 AM5/21/12
to
On Mon, May 21, 2012 at 8:25 AM, Wookey wrote:
> +++ Ben Hutchings [2012-05-21 00:30 +0100]:
>>
>> (Should we consider gathering selected hardware specs in popcon?)
>
> Yes please. This would really help arm people too. We currently have
> to guess how many people we are cutting off when minimum support is
> moved forward.
There is smolt for that, but folks haven't packaged it for Debian yet:
> +++ Ben Hutchings [2012-05-21 00:30 +0100]:
>>
>> (Should we consider gathering selected hardware specs in popcon?)
>
> Yes please. This would really help arm people too. We currently have
> to guess how many people we are cutting off when minimum support is
> moved forward.
https://fedorahosted.org/smolt/
http://bugs.debian.org/435058
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miles Bader
May 21, 2012, 1:50:02 AM5/21/12
to
Paul Wise <pa...@debian.org> writes:
> There is smolt for that, but folks haven't packaged it for Debian yet:
>
> https://fedorahosted.org/smolt/
> http://bugs.debian.org/435058
Hmm... from "http://smolts.org/static/stats/stats.html":
> There is smolt for that, but folks haven't packaged it for Debian yet:
>
> https://fedorahosted.org/smolt/
> http://bugs.debian.org/435058
The statistics script is no longer running and creating new
data. We're in the process of decomissioning smolt. Please take a
look at the census project if you'd like to help out with the
replacement for smolt.
-miles
--
Quack, n. A murderer without a license.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
May 21, 2012, 2:00:02 AM5/21/12
to
On Mon, May 21, 2012 at 1:42 PM, Miles Bader wrote:
> Paul Wise <pa...@debian.org> writes:
>> There is smolt for that, but folks haven't packaged it for Debian yet:
>>
>> https://fedorahosted.org/smolt/
>> http://bugs.debian.org/435058
>
> Hmm... from "http://smolts.org/static/stats/stats.html":
>
> The statistics script is no longer running and creating new
> data. We're in the process of decomissioning smolt. Please take a
> look at the census project if you'd like to help out with the
> replacement for smolt.
Doesn't look like the replacement is useful yet:
> Paul Wise <pa...@debian.org> writes:
>> There is smolt for that, but folks haven't packaged it for Debian yet:
>>
>> https://fedorahosted.org/smolt/
>> http://bugs.debian.org/435058
>
> Hmm... from "http://smolts.org/static/stats/stats.html":
>
> The statistics script is no longer running and creating new
> data. We're in the process of decomissioning smolt. Please take a
> look at the census project if you'd like to help out with the
> replacement for smolt.
https://fedorahosted.org/census/log/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6E393TPWtjit13eMGCR...@mail.gmail.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aníbal Monsalve Salazar
May 21, 2012, 2:10:02 AM5/21/12
to
On Mon, May 21, 2012 at 01:11:21PM +0800, Paul Wise wrote:
>On Mon, May 21, 2012 at 8:25 AM, Wookey wrote:
>On Mon, May 21, 2012 at 8:25 AM, Wookey wrote:
>>On Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings wrote:
>>>
>>>(Should we consider gathering selected hardware specs in popcon?)
>>
>>Yes please. This would really help arm people too. We currently have
>>to guess how many people we are cutting off when minimum support is
>>moved forward.
>
>There is smolt for that, but folks haven't packaged it for Debian yet:
>
>https://fedorahosted.org/smolt/
>http://bugs.debian.org/435058
kmuto had/has a webpage about hardware used on machines running Debian.
>>>
>>>(Should we consider gathering selected hardware specs in popcon?)
>>
>>Yes please. This would really help arm people too. We currently have
>>to guess how many people we are cutting off when minimum support is
>>moved forward.
>
>There is smolt for that, but folks haven't packaged it for Debian yet:
>
>https://fedorahosted.org/smolt/
>http://bugs.debian.org/435058
I cannot recall its address at the moment.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chow Loong Jin
May 21, 2012, 2:20:01 AM5/21/12
to
On 21/05/2012 08:45, Charles Plessy wrote:
> Le Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings a écrit :
>> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
>>>
>>> I'd love to see that happen someday, but at the moment, new x86 systems
>>> still get sold that don't support 64-bit. Notably, many low-power Atom
>>> processors still don't support 64-bit.
>>
>> Right, though I think these are going into phones now, not netbooks.
>
> Fit-PC sells an excellent fanless mini-PC with an Atom Z510 that does not
> support 64-bit instructions. It consumes 8 W according to the manufacturer,
> which is less than some Arm-based plug computers. I am the happy owner of one
> of them and would be quite sad to have to replace it in two years in order to
> keep on using Debian Stable on my personal server.
>
> By the way, are there plans to drop the support of the i386 architecture with
> kFreeBSD as well ?
I thought we were discussing amd64 being the default architecture for new
> Le Mon, May 21, 2012 at 12:30:11AM +0100, Ben Hutchings a écrit :
>> On Sun, 2012-05-20 at 14:02 -0700, Josh Triplett wrote:
>>>
>>> I'd love to see that happen someday, but at the moment, new x86 systems
>>> still get sold that don't support 64-bit. Notably, many low-power Atom
>>> processors still don't support 64-bit.
>>
>> Right, though I think these are going into phones now, not netbooks.
>
> Fit-PC sells an excellent fanless mini-PC with an Atom Z510 that does not
> support 64-bit instructions. It consumes 8 W according to the manufacturer,
> which is less than some Arm-based plug computers. I am the happy owner of one
> of them and would be quite sad to have to replace it in two years in order to
> keep on using Debian Stable on my personal server.
>
> By the way, are there plans to drop the support of the i386 architecture with
> kFreeBSD as well ?
installations, rather than the removal of the i386 architecture.
--
Kind regards,
Loong Jin
Andrey Rahmatullin
May 21, 2012, 3:10:01 AM5/21/12
to
On Mon, May 21, 2012 at 02:19:09PM +0800, Chow Loong Jin wrote:
> > By the way, are there plans to drop the support of the i386 architecture with
> > kFreeBSD as well ?
> I thought we were discussing amd64 being the default architecture for new
> installations, rather than the removal of the i386 architecture.
Both.
> > By the way, are there plans to drop the support of the i386 architecture with
> > kFreeBSD as well ?
> I thought we were discussing amd64 being the default architecture for new
> installations, rather than the removal of the i386 architecture.
--
WBR, wRAR
Thorsten Glaser
May 22, 2012, 9:40:02 AM5/22/12
to
Ben Hutchings dixit:
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
>No, keep i386 userland only.
Oh, definitely not! Please keep this runnable on at least
machines such as Soekris (486-compatible), Pentium-M, etc.
>> > have ppc64 and sparc64 soon!)
For sparc64, I heard the sparc kernel has been sparc64-only
since past etch, already. (Too bad, otherwise I could have
run Debian on one of my six SPARCstations at home.)
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
>No, keep i386 userland only.
machines such as Soekris (486-compatible), Pentium-M, etc.
>> > have ppc64 and sparc64 soon!)
since past etch, already. (Too bad, otherwise I could have
run Debian on one of my six SPARCstations at home.)
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
May 22, 2012, 11:10:02 AM5/22/12
to
On Tue, May 22, 2012 at 01:25:21PM +0000, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> >> > i386.
> >>
> >> As in drop the i386 arch?
> >
> >No, keep i386 userland only.
>
> Oh, definitely not! Please keep this runnable on at least
> machines such as Soekris (486-compatible), Pentium-M, etc.
For ever and ever and ever?
> Ben Hutchings dixit:
>
> >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> >> > i386.
> >>
> >> As in drop the i386 arch?
> >
> >No, keep i386 userland only.
>
> Oh, definitely not! Please keep this runnable on at least
> machines such as Soekris (486-compatible), Pentium-M, etc.
> >> > have ppc64 and sparc64 soon!)
>
> For sparc64, I heard the sparc kernel has been sparc64-only
> since past etch, already. (Too bad, otherwise I could have
> run Debian on one of my six SPARCstations at home.)
I think sparc32 is in better shape now but it seems pointless to bring
them back.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052215...@decadent.org.uk
Jakub Wilk
May 22, 2012, 1:30:02 PM5/22/12
to
* Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
(worse!) some maintainers claiming it's not a bug.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
>5. Installer for i386 prefers amd64 kernel on any capable machine
>(that's a one-line change!) and adds amd64 as secondary architecture if
>this is selected.
We have still some software that doesn't work with 64-bit kernel, and
>(that's a one-line change!) and adds amd64 as secondary architecture if
>this is selected.
(worse!) some maintainers claiming it's not a bug.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052217...@jwilk.net
Ben Hutchings
May 22, 2012, 2:10:01 PM5/22/12
to
On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
> * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
> >5. Installer for i386 prefers amd64 kernel on any capable machine
> >(that's a one-line change!) and adds amd64 as secondary
> >architecture if this is selected.
>
> We have still some software that doesn't work with 64-bit kernel,
> and (worse!) some maintainers claiming it's not a bug.
Are you thinking of build systems using 'uname -m' to detect the
> * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
> >5. Installer for i386 prefers amd64 kernel on any capable machine
> >(that's a one-line change!) and adds amd64 as secondary
> >architecture if this is selected.
>
> We have still some software that doesn't work with 64-bit kernel,
> and (worse!) some maintainers claiming it's not a bug.
target architecture? It is possible to work around those using
setarch. But how do they build on sparc or s390 now?
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052218...@decadent.org.uk
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Joachim
May 22, 2012, 2:30:01 PM5/22/12
to
On 2012-05-22 20:03 +0200, Ben Hutchings wrote:
> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
>> * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
>> >5. Installer for i386 prefers amd64 kernel on any capable machine
>> >(that's a one-line change!) and adds amd64 as secondary
>> >architecture if this is selected.
>>
>> We have still some software that doesn't work with 64-bit kernel,
>> and (worse!) some maintainers claiming it's not a bug.
>
> Are you thinking of build systems using 'uname -m' to detect the
> target architecture?
I don't think so, although those have been quite annoying for me.
> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
>> * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
>> >5. Installer for i386 prefers amd64 kernel on any capable machine
>> >(that's a one-line change!) and adds amd64 as secondary
>> >architecture if this is selected.
>>
>> We have still some software that doesn't work with 64-bit kernel,
>> and (worse!) some maintainers claiming it's not a bug.
>
> Are you thinking of build systems using 'uname -m' to detect the
> target architecture?
The most prominent example is probably virtualbox (#456391), and
anything that uses libx86 won't work either (#492470).
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
May 22, 2012, 2:50:01 PM5/22/12
to
On 22/05/12 19:24, Sven Joachim wrote:
>> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
>>> We have still some software that doesn't work with 64-bit kernel,
>>> and (worse!) some maintainers claiming it's not a bug.
>> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
>>> We have still some software that doesn't work with 64-bit kernel,
>>> and (worse!) some maintainers claiming it's not a bug.
> The most prominent example is probably virtualbox (#456391)
That bug seems to be that the userland and kernel parts of virtualbox
must have the same "width" to work correctly.
In a multiarch world, that at least has a workaround: if your kernel is
amd64 but your default architecture is i386, replace virtualbox/i386
with virtualbox/amd64 and it should be happy again.
> and anything that uses libx86 won't work either (#492470).
Information, he's running libx86/i386 on one of the i386 kernel
flavours, and I don't see any indication that amd64 is involved at all.
S
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Joachim
May 22, 2012, 3:20:03 PM5/22/12
to
On 2012-05-22 20:40 +0200, Simon McVittie wrote:
> On 22/05/12 19:24, Sven Joachim wrote:
>
>> and anything that uses libx86 won't work either (#492470).
>
> Is this the right bug? According to the reporter's reportbug System
> Information, he's running libx86/i386 on one of the i386 kernel
> flavours,
Oh, indeed.
> On 22/05/12 19:24, Sven Joachim wrote:
>
>> and anything that uses libx86 won't work either (#492470).
>
> Is this the right bug? According to the reporter's reportbug System
> Information, he's running libx86/i386 on one of the i386 kernel
> flavours,
> and I don't see any indication that amd64 is involved at all.
kernel.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Guillem Jover
May 22, 2012, 3:50:02 PM5/22/12
to
On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
> There is no real reason to require apt to do the heavy lifting here.
> It would be nice, but it is a one-time action, so a specialized tool wouldn't
> hurt muscle memory too much. Install essentials and apt and you should
> be good to go to proceed as usual, just with a different architecture…
I disagree that this is a one-time action, people might want to
cross-grade specific packages back and forth, not just the entire
installation. Also unsafe cross-grade does not only affect the
Essential set, it also affects anything involved in the boot process,
if for whatever reason the system crashes and apt would have removed
such package the system would be rendered unbootable.
> Even most essentials are easy to crossgrade, the only really difficult one
> is dpkg and it's dependencies as you have to take care of not breaking it
> while it crossgrades itself.
I guess I don't see the additional complexity in the dpkg specific
case, it just needs the shared libraries to be installed which should
be co-installable anyway, and the rest being M-A:foreign.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120522194...@gaara.hadrons.org
> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
> > > Slightly OT but I wanted to mention it for its similarity:
> > >
> > > One thing that should be tested and then documented prominently as yay
> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> > > then migrate to a 64bit userspace.
> >
> > Won't work in wheezy, apt does not support crossgradesน.
> > > Slightly OT but I wanted to mention it for its similarity:
> > >
> > > One thing that should be tested and then documented prominently as yay
> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
> > > then migrate to a 64bit userspace.
> >
> There is no real reason to require apt to do the heavy lifting here.
> It would be nice, but it is a one-time action, so a specialized tool wouldn't
> hurt muscle memory too much. Install essentials and apt and you should
> be good to go to proceed as usual, just with a different architecture…
I disagree that this is a one-time action, people might want to
cross-grade specific packages back and forth, not just the entire
installation. Also unsafe cross-grade does not only affect the
Essential set, it also affects anything involved in the boot process,
if for whatever reason the system crashes and apt would have removed
such package the system would be rendered unbootable.
> Even most essentials are easy to crossgrade, the only really difficult one
> is dpkg and it's dependencies as you have to take care of not breaking it
> while it crossgrades itself.
I guess I don't see the additional complexity in the dpkg specific
case, it just needs the shared libraries to be installed which should
be co-installable anyway, and the rest being M-A:foreign.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
May 22, 2012, 4:00:02 PM5/22/12
to
On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote:
> On 2012-05-22 20:40 +0200, Simon McVittie wrote:
>
> > On 22/05/12 19:24, Sven Joachim wrote:
> >
> >> and anything that uses libx86 won't work either (#492470).
> >
> > Is this the right bug? According to the reporter's reportbug System
> > Information, he's running libx86/i386 on one of the i386 kernel
> > flavours,
>
> Oh, indeed.
>
> > and I don't see any indication that amd64 is involved at all.
>
> The lrmi backend uses vm86 mode which is not supported under an x86_64
> kernel.
So the x86emu backend should be built too if there are any 64-bit
> On 2012-05-22 20:40 +0200, Simon McVittie wrote:
>
> > On 22/05/12 19:24, Sven Joachim wrote:
> >
> >> and anything that uses libx86 won't work either (#492470).
> >
> > Is this the right bug? According to the reporter's reportbug System
> > Information, he's running libx86/i386 on one of the i386 kernel
> > flavours,
>
> Oh, indeed.
>
> > and I don't see any indication that amd64 is involved at all.
>
> The lrmi backend uses vm86 mode which is not supported under an x86_64
> kernel.
systems that need libx86 - and maybe for other reasons as well.
That's not a big deal, though, surely?
By the way, lack of VM86 mode under Long Mode is a restriction of the
AMD64 architecture definition and not a kernel limitation.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012052219...@decadent.org.uk
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 22, 2012, 4:20:02 PM5/22/12
to
Ben Hutchings dixit:
>> >> As in drop the i386 arch?
>> >
>> >No, keep i386 userland only.
>>
>> Oh, definitely not! Please keep this runnable on at least
>> machines such as Soekris (486-compatible), Pentium-M, etc.
>
>For ever and ever and ever?
Hm, 2035 or thereabounds sounds good. ;-) Then let’s talk again.
>Right, sparc32 kernel builds were more-or-less broken for a long time.
Ah, okay.
>I think sparc32 is in better shape now but it seems pointless to bring
>them back.
Probably yes; it’s been broken on Linux for so long I believe every
remaining user switched to MirBSD/NetBSD/OpenBSD in the meantime or
picked up something like SunOS 4 from some archive. And those are,
unlike i386, no longer built any more either. (Still usable though.)
bye,
//mirabilos
--
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
⎜ System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;) 08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.1...@herc.mirbsd.org
>> >> As in drop the i386 arch?
>> >
>> >No, keep i386 userland only.
>>
>> Oh, definitely not! Please keep this runnable on at least
>> machines such as Soekris (486-compatible), Pentium-M, etc.
>
>For ever and ever and ever?
>Right, sparc32 kernel builds were more-or-less broken for a long time.
>I think sparc32 is in better shape now but it seems pointless to bring
>them back.
remaining user switched to MirBSD/NetBSD/OpenBSD in the meantime or
picked up something like SunOS 4 from some archive. And those are,
unlike i386, no longer built any more either. (Still usable though.)
bye,
//mirabilos
--
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
⎜ System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;) 08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
May 22, 2012, 5:30:02 PM5/22/12
to
On Tue, May 22, 2012 at 08:08:29PM +0000, Thorsten Glaser wrote:
> Hm, 2035 or thereabounds sounds good. ;-) Then let’s talk again.
Are you volunteering to maintain the i386 architecture until 2035, or
> Hm, 2035 or thereabounds sounds good. ;-) Then let’s talk again.
volunteering Ben to do it? ☺
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120522212839.GC22383@debian
Jonathan McDowell
May 22, 2012, 5:40:01 PM5/22/12
to
On Tue, May 22, 2012 at 08:51:17PM +0100, Ben Hutchings wrote:
> On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote:
> > On 2012-05-22 20:40 +0200, Simon McVittie wrote:
> > > On 22/05/12 19:24, Sven Joachim wrote:
> > >
> > >> and anything that uses libx86 won't work either (#492470).
...
> On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote:
> > On 2012-05-22 20:40 +0200, Simon McVittie wrote:
> > > On 22/05/12 19:24, Sven Joachim wrote:
> > >
> > >> and anything that uses libx86 won't work either (#492470).
> > The lrmi backend uses vm86 mode which is not supported under an x86_64
> > kernel.
>
> So the x86emu backend should be built too if there are any 64-bit
> systems that need libx86 - and maybe for other reasons as well.
> That's not a big deal, though, surely?
Which backend to use is a compile time option, so this would be
> > kernel.
>
> So the x86emu backend should be built too if there are any 64-bit
> systems that need libx86 - and maybe for other reasons as well.
> That's not a big deal, though, surely?
switching to always use the x86emu backend. Not a big issue if we're
going to drop 32 bit kernels entirely, a performance impact on those
machines if we're not.
J.
--
Web [ Keyboard: Used for entering errors into a system. ]
site: http:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
May 22, 2012, 7:20:02 PM5/22/12
to
Le Tue, May 22, 2012 at 04:01:29PM +0100, Ben Hutchings a écrit :
> On Tue, May 22, 2012 at 01:25:21PM +0000, Thorsten Glaser wrote:
> > Ben Hutchings dixit:
> >
> > >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > >> > i386.
> > >>
> > >> As in drop the i386 arch?
> > >
> > >No, keep i386 userland only.
> >
> > Oh, definitely not! Please keep this runnable on at least
> > machines such as Soekris (486-compatible), Pentium-M, etc.
>
> For ever and ever and ever?
Obviously, if there are no skilled volunteers to maintain the current i386
> On Tue, May 22, 2012 at 01:25:21PM +0000, Thorsten Glaser wrote:
> > Ben Hutchings dixit:
> >
> > >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> > >> > i386.
> > >>
> > >> As in drop the i386 arch?
> > >
> > >No, keep i386 userland only.
> >
> > Oh, definitely not! Please keep this runnable on at least
> > machines such as Soekris (486-compatible), Pentium-M, etc.
>
> For ever and ever and ever?
kernel, there is no way to support it. But in case the user base is too large
compared to the developer base, perhaps users can self-organise and gather
donations to pay for the work ? I would definitely prefer to spend the price
of a new hardware as ~5 years of donations instead of replacing it as long as
it is performant enough for its task (I bought mine a few months ago). What do
you think would be the cost to keep a good-shaped i386 kernel package in
wheezy+2 ?
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120522231...@falafel.plessy.net
Julien Cristau
May 23, 2012, 5:30:02 AM5/23/12
to
On Tue, May 22, 2012 at 14:34:34 -0700, Jonathan McDowell wrote:
> On Tue, May 22, 2012 at 08:51:17PM +0100, Ben Hutchings wrote:
> > On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote:
> > > On 2012-05-22 20:40 +0200, Simon McVittie wrote:
> > > > On 22/05/12 19:24, Sven Joachim wrote:
> > > >
> > > >> and anything that uses libx86 won't work either (#492470).
> ...
> > > The lrmi backend uses vm86 mode which is not supported under an x86_64
> > > kernel.
> >
> > So the x86emu backend should be built too if there are any 64-bit
> > systems that need libx86 - and maybe for other reasons as well.
> > That's not a big deal, though, surely?
>
> Which backend to use is a compile time option, so this would be
> switching to always use the x86emu backend. Not a big issue if we're
> going to drop 32 bit kernels entirely, a performance impact on those
> machines if we're not.
>
When is vm86 mode ever a fast path?
> On Tue, May 22, 2012 at 08:51:17PM +0100, Ben Hutchings wrote:
> > On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote:
> > > On 2012-05-22 20:40 +0200, Simon McVittie wrote:
> > > > On 22/05/12 19:24, Sven Joachim wrote:
> > > >
> > > >> and anything that uses libx86 won't work either (#492470).
> ...
> > > The lrmi backend uses vm86 mode which is not supported under an x86_64
> > > kernel.
> >
> > So the x86emu backend should be built too if there are any 64-bit
> > systems that need libx86 - and maybe for other reasons as well.
> > That's not a big deal, though, surely?
>
> Which backend to use is a compile time option, so this would be
> switching to always use the x86emu backend. Not a big issue if we're
> going to drop 32 bit kernels entirely, a performance impact on those
> machines if we're not.
>
FWIW X used to have a way to build both vm86 and x86emu backends, and
fall back to x86emu if it got -ENOSYS. Now it just uses x86emu.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Philipp Kern
May 23, 2012, 6:00:01 AM5/23/12
to
On Tue, May 22, 2012 at 07:03:53PM +0100, Ben Hutchings wrote:
> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
> > * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
> > >5. Installer for i386 prefers amd64 kernel on any capable machine
> > >(that's a one-line change!) and adds amd64 as secondary
> > >architecture if this is selected.
> > We have still some software that doesn't work with 64-bit kernel,
> > and (worse!) some maintainers claiming it's not a bug.
> Are you thinking of build systems using 'uname -m' to detect the
> target architecture? It is possible to work around those using
> setarch. But how do they build on sparc or s390 now?
We're building with linux32 on those architectures. If some chroot (or
> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote:
> > * Ben Hutchings <b...@decadent.org.uk>, 2012-05-20, 03:16:
> > >5. Installer for i386 prefers amd64 kernel on any capable machine
> > >(that's a one-line change!) and adds amd64 as secondary
> > >architecture if this is selected.
> > We have still some software that doesn't work with 64-bit kernel,
> > and (worse!) some maintainers claiming it's not a bug.
> Are you thinking of build systems using 'uname -m' to detect the
> target architecture? It is possible to work around those using
> setarch. But how do they build on sparc or s390 now?
buildd/arch) is missing the correct setup, please drop us a mail.
Kind regards
Philipp Kern, with a wb-team hat
Goswin von Brederlow
Jun 1, 2012, 6:00:03 AM6/1/12
to
Guillem Jover <gui...@debian.org> writes:
> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>> > > Slightly OT but I wanted to mention it for its similarity:
>> > >
>> > > One thing that should be tested and then documented prominently as yay
>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> > > then migrate to a 64bit userspace.
>> >
>> > Won't work in wheezy, apt does not support crossgradesน.
Why? What breaks? Any bugs filed yet?
> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>> > > Slightly OT but I wanted to mention it for its similarity:
>> > >
>> > > One thing that should be tested and then documented prominently as yay
>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> > > then migrate to a 64bit userspace.
>> >
>> > Won't work in wheezy, apt does not support crossgradesน.
I'm sure you are right that it currently doesn't work out of the box. I
don't agree with killing this for wheezy without having some idea of how
much breakage is involed though. I've seen reports from other people
that have done crossgrades in the past with some handholding so it isn't
impossible.
Testing (see below) shows that there is one big issue, namely that
crossgrading wants to remove the package before installing the new
one. Everything else seems to be minor and package specific issues (like
dash trying to overwrite its diversion). But testing on a minimal chroot
is hardly conclusive so if you know other issues then feel free to speak
up.
>> There is no real reason to require apt to do the heavy lifting here.
>> It would be nice, but it is a one-time action, so a specialized tool wouldn't
>> hurt muscle memory too much. Install essentials and apt and you should
>> be good to go to proceed as usual, just with a different architecture…
>
> I disagree that this is a one-time action, people might want to
> cross-grade specific packages back and forth, not just the entire
> installation. Also unsafe cross-grade does not only affect the
> Essential set, it also affects anything involved in the boot process,
> if for whatever reason the system crashes and apt would have removed
> such package the system would be rendered unbootable.
multiarch stuff. As long as the dependencies are resolved, which
multiarch does, there should be no problem. All assuming the package
doesn't have architecture specific data that will break (like git-svn).
Except with the essential set you don't always have dependencies. But
I'm not concerned there. You always have depends on libraries through
the shlibs/symbols files and everything else is (or should be)
Multi-Arch: foreign and work in any arch.
>> Even most essentials are easy to crossgrade, the only really difficult one
>> is dpkg and it's dependencies as you have to take care of not breaking it
>> while it crossgrades itself.
>
> I guess I don't see the additional complexity in the dpkg specific
> case, it just needs the shared libraries to be installed which should
> be co-installable anyway, and the rest being M-A:foreign.
apt/dpkg the notion of native and foreign architecture switches and that
impacts /var/lib/dpkg/info/ and the handling of Arch:all packages.
So lets test this:
cdebootstrap -v sid sid http://ftp.debian.org/
# dpkg --add-architecture i386
# apt-get update
# apt-get install apt:i386 dpkg:i386
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
apt:i386 : Depends: debian-archive-keyring:i386 but it is not installable
E: Unable to correct problems, you have held broken packages.
Doh, debian-archive-keyring isn't Multi-Arch: foreign (yet). Lets fix
that and try again:
# apt-get install apt:i386 dpkg:i386
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386 libc6:i386
libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386 zlib1g:i386
Suggested packages:
aptitude:i386 synaptic:i386 wajig:i386 dpkg-dev:i386 apt-doc:i386
python-apt:i386 glibc-doc:i386 locales:i386
The following packages will be REMOVED:
apt dpkg
The following NEW packages will be installed:
apt:i386 dpkg:i386 gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386
libc6:i386 libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386
zlib1g:i386
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt dpkg
0 upgraded, 11 newly installed, 2 to remove and 0 not upgraded.
Need to get 10.3 MB of archives.
After this operation, 16.1 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
Get:1 http://ftp.debian.org/debian/ sid/main gcc-4.7-base i386 4.7.0-11 [140 kB]
Get:2 http://ftp.debian.org/debian/ sid/main libgcc1 i386 1:4.7.0-11 [53.3 kB]
Get:3 http://ftp.debian.org/debian/ sid/main libc6 i386 2.13-32 [3920 kB]
Get:4 http://ftp.debian.org/debian/ sid/main libbz2-1.0 i386 1.0.6-1 [45.8 kB]
Get:5 http://ftp.debian.org/debian/ sid/main libselinux1 i386 2.1.9-4 [90.4 kB]
Get:6 http://ftp.debian.org/debian/ sid/main zlib1g i386 1:1.2.7.dfsg-11 [90.9 kB]
Get:7 http://ftp.debian.org/debian/ sid/main dpkg i386 1.16.3 [2340 kB]
Get:8 http://ftp.debian.org/debian/ sid/main libstdc++6 i386 4.7.0-11 [347 kB]
Get:9 http://ftp.debian.org/debian/ sid/main libapt-pkg4.12 i386 0.9.5.1 [882 kB]
Get:10 http://ftp.debian.org/debian/ sid/main libc6-i686 i386 2.13-32 [1242 kB]
Get:11 http://ftp.debian.org/debian/ sid/main apt i386 0.9.5.1 [1119 kB]
Fetched 10.3 MB in 6s (1553 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Can not write log, openpty() failed (/dev/pts not mounted?)
(Reading database ... 6615 files and directories currently installed.)
Removing apt ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Selecting previously unselected package gcc-4.7-base:i386.
(Reading database ... 6464 files and directories currently installed.)
Unpacking gcc-4.7-base:i386 (from .../gcc-4.7-base_4.7.0-11_i386.deb) ...
Selecting previously unselected package libgcc1:i386.
Unpacking libgcc1:i386 (from .../libgcc1_1%3a4.7.0-11_i386.deb) ...
Selecting previously unselected package libc6:i386.
Unpacking libc6:i386 (from .../libc6_2.13-32_i386.deb) ...
Selecting previously unselected package libbz2-1.0:i386.
Unpacking libbz2-1.0:i386 (from .../libbz2-1.0_1.0.6-1_i386.deb) ...
Selecting previously unselected package libselinux1:i386.
Unpacking libselinux1:i386 (from .../libselinux1_2.1.9-4_i386.deb) ...
Selecting previously unselected package zlib1g:i386.
Unpacking zlib1g:i386 (from .../zlib1g_1%3a1.2.7.dfsg-11_i386.deb) ...
Can not write log, openpty() failed (/dev/pts not mounted?)
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: warning: overriding problem because --force enabled:
This is an essential package - it should not be removed.
dpkg: dpkg: dependency problems, but removing anyway as you requested:
readline-common depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
util-linux depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
gzip depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
findutils depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
grep depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
gnupg depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
sed depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
diffutils depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
perl-base depends on dpkg (>= 1.14.20).
coreutils depends on dpkg (>= 1.15.4) | install-info; however:
Package dpkg is to be removed.
Package install-info is not installed.
dash depends on dpkg (>= 1.15.0).
(Reading database ... 6773 files and directories currently installed.)
Removing dpkg ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Could not exec dpkg!
E: Sub-process /usr/bin/dpkg returned an error code (100)
Yeah, removing dpkg, even temporary, is not a good idea. A crossgrade of
essential packages has to work without removing them.
# Unpack the new dpkg by hand.
# dpkg --configure -a
# dpkg -i /var/cache/apt/archives/dpkg_1.16.3_i386.deb
# dpkg -i /var/cache/apt/archives/libapt-pkg4.12_0.9.5.1_i386.deb /var/cache/apt/archives/libstdc++6_4.7.0-11_i386.deb /var/cache/apt/archives/apt_0.9.5.1_i386.deb
# apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following extra packages will be installed:
insserv libdb5.1 liblocale-gettext-perl libpam-modules libpam0g
libtext-charwidth-perl libtext-iconv-perl perl-base sysvinit-utils
Suggested packages:
bootchart2 libpam-doc perl sash
The following packages will be REMOVED:
e2fsprogs:amd64 initscripts:amd64 insserv:amd64 liblocale-gettext-perl:amd64
libtext-charwidth-perl:amd64 libtext-iconv-perl:amd64 perl-base:amd64
sysvinit:amd64 sysvinit-utils:amd64 util-linux:amd64
The following NEW packages will be installed:
insserv libdb5.1 liblocale-gettext-perl libpam-modules libpam0g
libtext-charwidth-perl libtext-iconv-perl perl-base sysvinit-utils
0 upgraded, 9 newly installed, 10 to remove and 0 not upgraded.
Need to get 2926 kB of archives.
After this operation, 1794 kB disk space will be freed.
Do you want to continue [Y/n]?
# apt-get install e2fsprogs initscripts insserv liblocale-gettext-perl libtext-charwidth-perl libtext-iconv-perl perl-base sysvinit sysvinit-utils util-linux
...
# apt-get install bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
base-files bash-completion dash
Suggested packages:
bash-doc
The following packages will be REMOVED:
dash:amd64
The following NEW packages will be installed:
base-files bash bash-completion dash
0 upgraded, 4 newly installed, 1 to remove and 0 not upgraded.
Interestingly enough apt has no problem with removing an essential
package from a foreign architecture. In this case though it breaks
because the diversion handling in bash/dash is broken for crossgrades:
Removing dash ...
Removing 'diversion of /bin/sh to /bin/sh.distrib by dash'
dpkg-divert: error: rename involves overwriting `/bin/sh' with
different file `/bin/sh.distrib', not allowed
dpkg: error processing dash (--remove):
subprocess installed pre-removal script returned error exit status 2
Overall the one MAJOR showstopped seems to be that apt/dpkg can't
crossgrade a package without removing it. At least for packages with
Multi-Arch: foreign (only dpkg has that) a crossgrade should work
without removing the other package.
So the problem lies somewhere other than expected.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin von Brederlow
Jun 1, 2012, 6:10:01 AM6/1/12
to
Ben Hutchings <b...@decadent.org.uk> writes:
> On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
>
> Ben.
Which basically means i386 is droped but we still support 32bit stuff
for amd64.
Isn't there still a large demand for i386 in the industry/embedded
sector?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87396fn...@frosties.localnet
> On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
> No, keep i386 userland only. Though we might consider reducing even
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
>
> Ben.
Which basically means i386 is droped but we still support 32bit stuff
for amd64.
Isn't there still a large demand for i386 in the industry/embedded
sector?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
Jun 1, 2012, 8:40:01 AM6/1/12
to
On Fri, 2012-06-01 at 11:59 +0200, Goswin von Brederlow wrote:
> Ben Hutchings <b...@decadent.org.uk> writes:
>
> > On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings <b...@decadent.org.uk> writes:
> >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> >> > i386.
> >>
> >> As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> >
> > Ben.
>
> Which basically means i386 is droped but we still support 32bit stuff
> for amd64.
>
> Isn't there still a large demand for i386 in the industry/embedded
> sector?
I don't know; nor whether they use Debian much. But those are two
> Ben Hutchings <b...@decadent.org.uk> writes:
>
> > On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings <b...@decadent.org.uk> writes:
> >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> >> > i386.
> >>
> >> As in drop the i386 arch?
> >
> > No, keep i386 userland only. Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> >
> > Ben.
>
> Which basically means i386 is droped but we still support 32bit stuff
> for amd64.
>
> Isn't there still a large demand for i386 in the industry/embedded
> sector?
sectors not well known for keeping their software updated, i.e. they
might not care about a lack of future releases..
I'm not suggesting there's any need to decide a timescale for this,
anyway. I'm just proposing that we plan to have that transitional
stage for some time before actually removing i386.
Ben.
--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates
Sven Joachim
Jun 2, 2012, 2:40:01 PM6/2/12
to
On 2012-06-01 11:54 +0200, Goswin von Brederlow wrote:
> Guillem Jover <gui...@debian.org> writes:
>
>> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
>>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
>>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>>> > > Slightly OT but I wanted to mention it for its similarity:
>>> > >
>>> > > One thing that should be tested and then documented prominently as yay
>>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
>>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>>> > > then migrate to a 64bit userspace.
>>> >
>>> > Won't work in wheezy, apt does not support crossgradesน.
> Guillem Jover <gui...@debian.org> writes:
>
>> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
>>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim <sven...@gmx.de> wrote:
>>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>>> > > Slightly OT but I wanted to mention it for its similarity:
>>> > >
>>> > > One thing that should be tested and then documented prominently as yay
>>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
>>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>>> > > then migrate to a 64bit userspace.
>>> >
>
> Why? What breaks?
You give the answer yourself:
> Testing (see below) shows that there is one big issue, namely that
> crossgrading wants to remove the package before installing the new
> one.
without apt's help. While this should not pose insurmountable
difficulties, it is probably not something to be recommended to the
average user.
> Interestingly enough apt has no problem with removing an essential
> package from a foreign architecture. In this case though it breaks
> because the diversion handling in bash/dash is broken for crossgrades:
>
> Removing dash ...
> Removing 'diversion of /bin/sh to /bin/sh.distrib by dash'
> dpkg-divert: error: rename involves overwriting `/bin/sh' with
> different file `/bin/sh.distrib', not allowed
> dpkg: error processing dash (--remove):
> subprocess installed pre-removal script returned error exit status 2
removing dash has probably not been tested so well.
> Overall the one MAJOR showstopped seems to be that apt/dpkg can't
> crossgrade a package without removing it.
dpkg alone you may be left with lots of unfulfilled dependencies after
the crossgrade, see #20471¹.
Cheers,
Sven
¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=20471
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages