Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

[Josh Triplett]

James Addison wrote:
> Do we know how often the i386 installer is downloaded compared to
> amd64, and could/should we start with updated messaging where those
> are provided before removing users' ability to install on their
> systems?

How easily could we add 64-bit system detection to the i386 installer,
and a message saying something like:

"You're installing the i386 architecture on a 64-bit system. While this
will work, this is the last release it'll be supported. We recommend
installing the 64-bit amd64 architecture instead. On amd64 you can still
subsequently install i386 packages and run 32-bit binaries. Are you sure
you want to proceed with a 32-bit-only install?"

That might help reduce the number of actual installations of i386 by
people who don't realize they could be and should be using amd64.

(I realize that this is fairly late to be making *any* changes to the
installer, let alone changes that require translations. Also, if we
already have some detection like that, my apologies for missing it.)

- Josh Triplett

Re: i386 in the future

[Ansgar]

On Sat, 2023-05-20 at 04:25 +0100, Wookey wrote:
> On 2023-05-19 12:42 +0100, Steve McIntyre wrote:
> > If they're still running
> > i386 *hardware*, then they should be replacing that hardware with more
> > modern, more capable, more *efficient* stuff.
> 
> I'm still using an i386 early acer netbook. (I even just upgraded it 4
> releases from Wheezy to Bookworm to get a newer Alfa wifi card working
> with a mdern kernel). It's only used for ~1 month/year, primarily as a
> fancy long-range wifi router and it's reasonably low power. An rPI
> would not be a useful replacement as it's not the same form factor
> (robust clamshell, with screen/mouse).
[...]
> Removing the installer to stop supporting _new_ installs is probably
> fair enough but I don't think we can yet say there are no reasonable
> use cases for old i386 hardware.

I don't think that is a good use case to keep i386 installations on
i386 hardware alive beyond 2028 (which is what we are talking about):
just grab a slightly newer amd64 netbook out of the junk by the time
LTS support for Debian bookworm ends.

Ansgar

Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

[Simon Richter]

Hi,

On 20.05.23 16:15, Josh Triplett wrote:


That might help reduce the number of actual installations of i386 by
people who don't realize they could be and should be using amd64.


Crossgrades are probably broken with systemd, but it might be possible 
to hack something that diverts /sbin/init and performs the crossgrade 
after a reboot, that might also help a few people leave i386 behind.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Wookey]

On 2023-05-17 20:14 -0500, Richard Laager wrote:
> 
> They mention, "We likely have to complete Modern C porting first to remove
> any instances of -Wimplicit-function-declaration otherwise the redirects in
> glibc for e.g. time->time64 won't actually work."

> Has that issue been considered here? (I can't speak intelligently on it at
> this time. I just want to make sure it's on your radar.)

I was aware of it (the gentoo info is linked on the 64bit-time wiki
page), but had not yet looked into how significant an issue this actually
was, so had not documented it. (frankly, I was hoping we could avoid
tying yet another transition into this one). Thanks for the reminder.

So having re-read that, if I understand this correctly, we do need to
be mindful that software which looks up functions or function
parameters in unusual ways (e.g. cross-language Foreign Function
Interfaces, or using implicit declarations) is likely to get the
wrong-size definition (because glibc makes both versions available).

So we should enable -Wimplicit-function-declaration on libraries being
rebuilt because their ABIs changed. We don't need to enable/fix it for
everything though. A rebuild check of affected libraries to see how
much work this adds would be a good idea.

I'll add this info the the wiki and do some tests.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: #932957 Please migrate Release Notes to reStructuredText

[RL]

Holger Wansing  writes:

> However, I may have some objections against the migration at all:
> as far as I know, sphinx/reStructuredText is still lacking some functionality,
> which is heavily used in the release-notes.
> That is the use of substitutions within URLs.
> In docbook speach these were entities, and you could use them in URLs like 
> this:
>
> Please follow the instructions in the  
> url="https://www.debian.org/releases/&oldreleasename;/releasenotes";>Release
> Notes for &debian; &oldrelease; to upgrade to &debian;
> &oldrelease; first if needed.
>
> Please note the &oldreleasename; in the URL!
> I could not get this working with sphinx (if someone knows better, please
> contact me!)

No idea about sphinx, but we could we just run a simple sed script to update

i've submitted several patches to release notes, and found the use of
entities and XML more confusing than helpful (especially '&debian;' for
'Debian') - this is meant to be a document for people, and needs a
decent proof-read anyway.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Sat, 20 May 2023 at 09:39, Cyril Brulebois  wrote:>
> James Addison  (2023-05-20):
> > Replying individually, but may bring this back on-list depending on
> > what I learn:
> >
> > On Sat, 20 May 2023 at 06:00, Cyril Brulebois  wrote:
> > >
> > > If you're concerned about the impact of no longer producing installation
> > > images for this use case, you shouldn't. Building netinst, CD, DVD, BD,
> > > etc. images happens via debian-cd
>
> Stopping that is the plan.
>
> > > using artifacts produced by a src:debian-installer build, which are stored
> > > under installer-/ directories in the archive. Those wouldn't go away
> > > in this scenario.
> > >   http://ftp.debian.org/debian/dists/bookworm/main/installer-i386/
> >
> > I'm confused: I thought Steve's suggestion was exactly that these i386
> > installer builds would no longer occur after the bookworm release.
> >
> > Did I misunderstand the plan?
>
> I suppose so?

Ok, thanks.  I was uncertain what you were referring to with "Those
wouldn't go away" - and that potentially raised conflicts with my
reading of Steve's suggestion.

Updated understanding:

  * planned to go away: Debian-distributed images as built using
debian-cd for i386 (where the images include: debian-installer + a
subset of packages from a Debian mirror + supporting stuff to provide
a complete installation environment).
  * _not_ planned to go away: standalone binary package builds of the
i386 debian-installer package itself in the archives.

And so the result should be: it'd still be possible for people to
build-their-own i386 ISO images by using the debian-cd tooling; there
won't be officially-distributed images provided by Debian, though.

Re: What *is* the amd64 ABI

[Bastien Roucariès]

Le mardi 16 mai 2023, 04:45:51 UTC Michael Hudson-Doyle a écrit :
> On Tue, 16 May 2023, 15:42 Russ Allbery,  wrote:
> 
> > Sam Hartman  writes:
> >
> > > We've all been talking about the x86_64 ABI, and I'm realizing I'm never
> > > read it.
> > > Are we talking about
> > > https://refspecs.linuxbase.org
> > 
> 
> /elf/x86_64-abi-0.99.pdf
> > 
> >
> > That's the one that I was looking at, at least.  Specifically (for the
> > purposes of the current discussion) page 84.  I'm not sure if there's a
> > newer version, since that one is labeled draft.
> >
> 
> I think the current version lives at
> https://gitlab.com/x86-psABIs/x86-64-ABI

ABI are documented on the wiki

https://wiki.debian.org/ArchitectureSpecificsMemo#amd64

Thanks

Bastien
> 
> Cheers,
> mwh
> 
> > Russ Allbery (r...@debian.org)  
> >
> >
> 

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Andreas Metzler]

On 2023-05-20 Wookey  wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."

>> Has that issue been considered here? (I can't speak intelligently on it at
>> this time. I just want to make sure it's on your radar.)

> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.
[...]

Hello,

There is an ongoing Fedora project by Florian Weimer which includes this
issue.

https://fedoraproject.org/wiki/Changes/PortingToModernC

Not sure whether there is a similar effort for Debian but it should help
a lot, everything with active upstream that is packaged by Fedora will
be fixed.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

[Adam Borowski]

On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote:
> How easily could we add 64-bit system detection to the i386 installer,
> and a message saying something like:
> 
> "You're installing the i386 architecture on a 64-bit system. While this
> will work, this is the last release it'll be supported. We recommend
> installing the 64-bit amd64 architecture instead.

This is not a valid use for i386.  Running the i386 kernel on _modern_
hardware is insecure, slower (esp. if you have a non-tiny amount of
memory), etc.  We should put a big fat warnings for _that_.

On the other hand, it's okayish to run 32-bit userland -- in fact, in
some cases it might be quite a bit faster¹, as long as you use the
appropriate kernel.  Which is 32-bit for ancient hardware (including
some first 64-bit-capable models), and 64-bit today.


Meow!

[¹]. Sometimes amd64 wins by a lot due to more wider registers and SSE,
sometimes i386 win hugely due to halved pointers and better code density,
which allows using a higher-tier cache.  We could have been using x32
to get both, but oh well...
-- 
⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from
⣾⠁⢠⠒⠀⣿⡁ the Y292B problem.  So let's move the Epoch by 43545140006400
⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it
⠈⠳⣄ unsigned -- that'll almost double the range.

Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier

[Peter Wienemann]

Dear Jim,

On 10.05.23 17:01, Jim Anderson wrote:

I realize that auto logout is a general security feature, but in my
case, I have a secrure environment where only my wife and I have access to
my computer. I strong prefer to NOT have my computer auto logout for 10 hours,
allowing me to leave my computer in the evening and return to it in the
morning without haveing to log on.

I have the enrivonment variables TMOUT and autologout both set to 36000,
or 10 hours, but these are not honored by the system.


from what does your computer log you out when it logs you out: A 
graphical user session or a shell session? TMOUT only controls the 
time-out of shell sessions.


Best regards,

Peter

Debian Med video conference tomorrow Sunday 2023-05-20 18:00 UTC

[Andreas Tille]

Hi,

this is the call for the next video conference of the Debian Med team
that are an established means to organise the tasks inside our team.

Meetings usually take us only 15-20min depending what we are talking
about and how many people are joining.  The next meeting is tomorrow
   
 https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230520T18

The meeting is on the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

These video meetings were started in the Debian Med Biohackathon.
The topic is what contributors have done in the past period and to
coordinate the work until the next meeting.

For those who are interested in hot topics we want to tackle, here
are some items:

  - Some remaining RC bugs
  - Packaging new stuff

Newcomers are always welcome.

Lets keep on the great work and see you on Sunday
 
   Andreas.

-- 
http://fam-tille.de

Re: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

RL  wrote (Sat, 20 May 2023 12:52:25 
+0100):
> Holger Wansing  writes:
> 
> > However, I may have some objections against the migration at all:
> > as far as I know, sphinx/reStructuredText is still lacking some 
> > functionality,
> > which is heavily used in the release-notes.
> > That is the use of substitutions within URLs.
> > In docbook speach these were entities, and you could use them in URLs like 
> > this:
> >
> > Please follow the instructions in the  > 
> > url="https://www.debian.org/releases/&oldreleasename;/releasenotes";>Release
> > Notes for &debian; &oldrelease; to upgrade to &debian;
> > &oldrelease; first if needed.
> >
> > Please note the &oldreleasename; in the URL!
> > I could not get this working with sphinx (if someone knows better, please
> > contact me!)
> 
> No idea about sphinx, but we could we just run a simple sed script to update

That will not work. 
You cannot replace all 'bullseye' by 'bookworm' for example. 
There are places, where the 'bullseye' needs to stay. 
So that needs to be done selective one-by-one.

> i've submitted several patches to release notes, and found the use of
> entities and XML more confusing than helpful (especially '&debian;' for
> 'Debian') - this is meant to be a document for people, and needs a
> decent proof-read anyway.

I dropped that &debian; entity already in Sphinx for the release-notes :-)


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
>
> On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> > Do we know how often the i386 installer is downloaded compared to
> > amd64, and could/should we start with updated messaging where those
> > are provided before removing users' ability to install on their
> > systems?
> >
> > (i386 remains the second-most-popular architecture behind amd64 today
> > going by popcon[1] stats - perhaps a lot of that is people using i386
> > as a compatibility architecture only, but it'd be nice to be
> > reasonably confident about that)
>
> One of the problems with popcon is that it draws too much attention to
> old releases which isn't really interesting when talking about future
> developments.  If one looks at arch usage per release (as reported to
> popcon) one gets this table:
>
> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
> |++-++--+--|
> | alpha  |  1 | ||  |4 |
> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
> | arm64  ||   1 | 93 |  937 |  203 |
> | armel  | 21 |  47 | 67 |   68 |   10 |
> | armhf  |  7 |  18 |216 |  429 |   49 |
> | hppa   || ||  |8 |
> | hurd-i386  || ||4 |6 |
> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
> | ia64   || ||  |3 |
> | kfreebsd-amd64 |  2 | ||  |  |
> | m68k   ||   1 ||  |4 |
> | mips   |  2 | |  6 |  |  |
> | mips64el   || |  6 |4 |  |
> | mipsel |  2 |   1 |  7 |  |  |
> | powerpc| 13 |   1 |  1 |1 |   18 |
> | ppc64  || ||1 |   28 |
> | ppc64el||   5 | 16 |  |   12 |
> | riscv64|| ||  |   15 |
> | s390x  || ||8 |3 |
> | sh4|| ||  |1 |
> | sparc64|| ||  |   11 |
> | x32|| ||  |2 |
> |++-++--+--|
> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
> #+TBLFM: @>$2..@>$>=vsum(@I..II)
>
> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
> Also interesting is that arm64 has taken over i386 on bookwork/sid.
>
> We don't know how many people downloaded i386 instead of amd64 as they
> have an Intel CPU.
>
> What is also not clear is the bias of systems having popcon enabled at
> all (it seems to be mostly desktop systems) and how it looks on the
> total population.

Thanks, those are better statistics (and good notes about their limitations).

I may be playing devil's advocate, but I do also read from those that
the i386 install-base, even dwindled as it has to ~1%, remains more
popular than many other architectures (within whatever dimension of
users enable popcon) where we do provide install images, and then that
those users tend to upgrade to the latest i386 release of Debian that
they can -- and/or that despite the percentage-of-total trend
reducing, the absolute population of those i386 users is growing (I
guess the former is the larger contributing factor, but it's hard to
determine from the numbers only).

Meanwhile my understanding is that most of the i386 installer package
-- although I referred to it as a binary package in another thread,
using the source/binary package naming terminology -- is mostly shell
scripting and architecture-independent logic.

So I guess I will ask: is there a technical reason we want to drop d-i
images on i386, or is it primarily about trying to reduce our
anticipated support burden for one architecture?

(and if people clamoured for an i386 installer to download, would we
reverse the decision?)