way.
>
>nvi adds to the subversive ones, with bash, etc.
What on earth do you mean by "subversive" here??
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
nothing to hid
;
>Not speaking for logtool obviously, but maintaining simple packages on salsa is
>just useless bureaucracy.
So that's OK for *you* only in this case. Now consioder for the
project as a whole. Every package that differs from the norm is more
effort for anybody else to maintain/bugfix/NMU/what
, I want to be able to
>point them at a documented decision and say "please report a bug to
>$TOOL" instead of taking a week off to port everything again to gpg.
>
>Thank you for all the work you've done on this over the years! I've
>appreciated it with grea
einstall the whole system?
>
>(maybe this should be in a bug against release-notes)
Maybe a wrapper script to just report likely problems would be a good
plan.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.
tainly hope so!
So I've just set up a ProtonMail test account to verify. Mailing to
myself, it already clearly knew about my PGP key (I've already had
lots of encrypted mails from ProtonMail users), but sending to a
different address that came through in plain text.
So *that* doesn't seem to be a wo
.org will encrypt the email that
>>is sent to the BTSe...which has the effect of making Debian development
>>veiled in plain sight rather than "in the open".
>
>Does it not encrypt email per-sender?
Ewww, I certainly hope so!
Do we have any examples of encrypted ma
work even if we don't have the library loader
>on the ABI-compliant path?
What exactly do you mean here? You know that even a statically linked
executable needs an interpreter defined in the ELF header?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< slad
Steve Langasek wrote:
>
>On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
>> >If the main reason is to support non-free binaries, at least to me
>> >that does not seem like a very compelling reason. And people can
>> >always use old chro
Andrew Cater wrote:
>On Fri, May 19, 2023 at 03:03:40PM +0100, Steve McIntyre wrote:
>>
>> I had been thinking about doing similar for installer images too, but
>> with other work going on too I think it got too late in the cycle to
>> make that change. My plan is there
,}chroot will cover the vast majority of
needs. That's how we've been building i386 software already for ages
in Debian already.
More complex things can be done if needed: loopback mount an image,
debootstrap, install a kernel, etc. I don't see this as something we
should be spending much e
Luca Boccassi wrote:
>On Fri, 19 May 2023 at 12:42, Steve McIntyre wrote:
>>
>> I'm planning on stopping publishing installer images for i386
>> soon. Why? We should be strongly encouraging users to move away from
>> it as a main architecture. If they're stil
on't
support those binaries. *But* I think we'll also need to keep the port
going with security fixes - it's still likely to be quite common and
we need to keep users safe.
People are even likely to want to keep old software running beyond
2038, in which case I envisage clock hacks coming to kee
Hey Johannes,
On Mon, May 15, 2023 at 06:48:04AM +0200, Johannes Schauer Marin Rodrigues
wrote:
>Quoting Steve McIntyre (2023-05-15 02:54:02)
>>
>> Pointing at gentoo or nixos as examples of projects that have decided
>> to break compatibility doesn't cut it, I'm afrai
Your apparent lack of care for agreed standards
here is horrifying.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
ing without significant
cross- and inter-project discussion.
Pointing at gentoo or nixos as examples of projects that have decided
to break compatibility doesn't cut it, I'm afraid. They're well known
for changing fundamental things around Linux and (basically) not
caring about interoperabil
On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote:
>>
>> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>> >>
On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
>>>
>>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>>> >
>&g
On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
>>
>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >
>> >The core issue as I see it is as follows:
>> >
>> >- Debian
ies.
WTF? *Nobody* has been talking about breaking ABI like this, that I've
seen. The interpreter must *not* be changed willy-nilly.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code
is in
hich makes it
hard to keep in step with security updates etc. I hope to find time
to rationalise things, following on from work that Colin was doing
earlier.
2. I'd like to simplify options more and reduce the number of packages
we ship here too. Let's see...
--
Steve McIntyre, Camb
f project
development. Should we therefore declare that "preferred form of
modification" could include all of the github or gitlab
infrastructure?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived
Hey again,
On Tue, Jan 31, 2023 at 03:36:53PM +, Steve McIntyre wrote:
>>
>>As you can see, this affects many teams:
>>* live-setup: a MR to generate all live images for Bookworm [A2]
So, after some delay from me and some further delays from various
Debian machines com
things in d-i to re-enable os-prober if
the system looks like it might have some other OS installed. Yes, I
realise that may sound odd(!), but I can see a number of users
complaining that their dual-boot system doesn't work any more... :-/
--
Steve McIntyre, Cambridge, UK.
debian.org/debian-devel-announce/2023/02/msg5.html
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
minor fix [A3]
No idea about that, leaving for somebody else.
>* live-installer: A better user experience after the installer is finished
>[A4]
Merred just now.
>* live-build: Various installer improvements, including off-line installation
>[A5]
Not sure who might review that, let's
nest, I've been horrified for years that we can still ask
the shadow question. I hadn't realised it might be relevant for
NIS. Even so, +1 from me. Let's get this done, I think...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?
s not great, no. Do you have a better suggestion for making sure
people update sources.list?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
>On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
>> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
>> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
>> >>
On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
>On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
>> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>> > What's the plan for upgraded systems with an existing
>>
On Sun, Oct 02, 2022 at 05:31:16PM +0200, Cyril Brulebois wrote:
>Steve McIntyre (2022-10-02):
>> * Extra d-i code to inform users about what firmware blobs have been
>> loaded and the matching non-free-firmware packages. Plus information
>> about the hardware involved. M
On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>
>Hi Steve,
>
>thanks for the update!
>
>Am 02.10.22 um 16:27 schrieb Steve McIntyre:
>
>> * Tweaks to add the non-free-firmware section in the apt-setup module
>>if desired/needed.
>
>...
se changes, that would be lovely too!
[1] https://lists.debian.org/debian-vote/2022/10/msg0.html
[2] https://lists.debian.org/debian-devel/2022/03/msg00251.html
--
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended
loaded
>which would be the one thing we could not easily toggle on/off from the
>initrd and/or d-i.)
Please go and *read* and *respond* in debian-vote. The discussion is
there, not here.
You've utterly missed Phil's point about people not seeing or hearing
boot options. Go and read my first
Hi all!
Sorry for the delay on this, I've been really really busy. :-(
I think it's time we started on the firmware GR, so I've mailed the
-vote list:
https://lists.debian.org/debian-vote/2022/08/msg1.html
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Roberto C. Sánchez wrote:
>On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote:
>>
>> Do you have a real use for this package?
>
>Why in the world is that even a relevant question? There are plenty of
>packages in the archive which are useful to essent
Edward wrote:
>Steve McIntyre wrote:
>>
>> Oh, not *another* package that tries to guess things from names.
>>
>> Do you have a real use for this package? There are a *lot* of issues
>> in this area, and mis-gendering people is not something to risk
>
hen
trying to make strawman arguments:
"We welcome contributions from everyone as long as they interact
constructively with our community."
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
e trying to say here.
Are you actually somehow claiming that Debian's core values include
bad treatment of Jews and those other groups? Seriously, WTF?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that manage
Marc Haber wrote:
>On Thu, 14 Jul 2022 12:54:52 +0100, Steve McIntyre
>wrote:
>>And I see you uploaded ~immediately - why even bother with an ITP?
>
>Is it proper procedure to upload without an ITP?
IMHO there are 2 points to an ITP:
* to save effort in case two peopl
Steve McIntyre wrote:
>edw...@4angle.com wrote:
>
>>Package: wnpp
>>Severity: wishlist
>>Owner: Edward Betts
>>X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
>>
>>* Package name: gender-guesser
>> Version
his package? There are a *lot* of issues
in this area, and mis-gendering people is not something to risk
lightly...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
o action on the bug reports.
Just to clarify: is this suggesting that packages from NEW would end
up in the archive even with serious bugs? If not, what's the point of
the "eventual removal" above? I'm not following you here...
--
Steve McIntyre, Cambridge, UK.st...@ein
hnical stuff, I've written a fair amount of
user-facing docs for UEFI, shim and secure boot over the last few
years. In the limited time I have available, I've tried to focus on
the common cases for people using an expected simple setup. I'd *love*
some help to cover more of the space.
--
Steve Mc
The Wanderer wrote:
>On 2022-04-26 at 10:14, Marc Haber wrote:
>
>> On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
>> wrote:
>
>>> Alternatively, people can build replacement shim-signed packages
>>> using their own root of trust if desired. If we
rub, Linux,
etc. too.
We need a reproducible build for shim so that we can check that the
shipped binary for signing matches what we can rebuild ourselves.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that
Marc Haber wrote:
>On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
>
>>Better than that, our shim-signed source package always double-checks
>>things here. At build time it removes the Microsoft signature and
>>compares that shim binary to the binary that we submitted
rt to draft a GR to formalise what the
project wants, feel free to add an option for that too but I
personally wouldn't expect it to gain much traction.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
hecks
things here. At build time it removes the Microsoft signature and
compares that shim binary to the binary that we submitted for
signing. We would spot immediately if there was any code added.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
ritten the scripts involved. This is actually another place
where we'd benefit from the new non-free-firmware component - we'd be
able to just consistently rely on *that* list of packages.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.
Russ Allbery wrote:
>Steve McIntyre writes:
>
>> Thanks! That's a really good question, and one that we should also
>> include on the GR. I'd split my option 5 into two:
>
>> 5. Include non-free firmware but do not enable it by default
>> 6. Include non-free
Hey Ansgar!
Ansgar wrote:
>On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote:
>> > Russ Allbery wrote:
>> > 1. Purely free installation.
>[ Other options ]
>> > 4. Enable non-free firmware and enable normal upgrades, [...]
>[...]
>> Now, the *defa
gt;> black magic "stuff" that they need to enable their devices.
>
>> I do not think that we should impose on our users to trust black magic
>> by default, though.
>
>I think this is a somewhat different question than whether we put the
>firmware on the default in
Paul Wise wrote:
>
>On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
>
>> There are a number of issues here that make developers and users unhappy:
>
>There are a couple more issues related to unredistributable firmware:
Oh, I'm quite sure there are more than
asily for our users. Devin's description of the
troubles they had are entirely on-topic and useful in the context of
that discussion. Castigating them here is *not* helpful.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We we
Jeremy Stanley wrote:
>On 2022-04-19 01:27:46 +0100 (+0100), Steve McIntyre wrote:
>[...]
>> Along with adding non-free firmware onto media, when the installer
>> (or live image) runs, we should make it clear exactly which
>> firmware packages have been used/insta
w...@debian.org wrote:
>
>Also, drivers and firmware are different things.
*Totally*. This is one of my pet peeves - many *many* people confuse
the two and talk about "non-free drivers" in Debian when they actually
mean firmware... ARGH.
--
Steve McIntyr
t
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
signature.asc
Description: PGP signature
just going
to confuse people. Unless you can explain a good reason to need this,
I'd argue strongly that the 3.0 native support is DTRT for the
principle of least surprise if nothing else!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical expert
with this.
It's maddening to see Google continue to f*ck up mail requirements for
everybody else. Of course, they continue to be (one of?) the biggest
sources of spam on the net and show no interest in doing anything
about it. "Don't be evil" indeed... :-(
--
Steve McIntyre, Cambridge,
on me
any more. If you can find other volunteers to pick this up, *please*
do.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait: https://www.debian.org/CD/free-linux-cd
Debian does NOT ship free CDs. Please do NOT contact the mailing
lists
seye release,
and I'm waiting for somebody to take over maintaining them.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
e you
>have a working proof of concept that some people have toyed with; we can
>discuss how the “alternative” part could be implemented (different
>images, or both partitioners ship together, with some option/selection —
>people might remember GRUB vs. LILO). I cannot guarantee a timely
For that reason, Rust uses the target names "aarch64-unknown-uefi",
>"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
>right names for these targets in other toolchains, as well.
Nod, agreed. I think that makes sense.
--
Steve McIntyre, Ca
id that we'd lose just about all the
reviews that currently happen. The whole point of sending ITPs to
d-devel is that they will be seen by a wider audience, but I can't see
many signing up for YA mailing list for them.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Hey Andreas!
On Tue, Mar 02, 2021 at 02:46:52PM +0100, Andreas Tille wrote:
>On Thu, Oct 08, 2020 at 10:23:19AM +0100, Steve McIntyre wrote:
>> Hey Andreas! I hope you're keeping well!
>>
>> On Tue, Oct 06, 2020 at 06:08:02PM +0200, Andreas Tille wrote:
>> >> (Ov
It asks for a disk with *firmware* on it, not
*drivers*. Please stop confusing the two.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
ke it'd be going too far (but then I also
>don't think apt should be "required").
>If there are specific examples where you think "important" would help
>I'd be interested; right now I'm sort of favouring "standard" as good
>enough.
Sounds like good logic to me.
Thanks for looking into this!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Bjørn wrote:
>Steve McIntyre writes:
>
>> Marc Haber wrote:
>>>
>>>I was not aware of that feature. It is good to have that, but I would
>>>be embarrassed to seriously suggest this way because we can't manage
>>>to get WLAN working in the install
Marc Haber wrote:
>On Mon, 18 Jan 2021 16:35:01 +0000, Steve McIntyre
>wrote:
>>Marc Haber wrote:
>>>I was not aware of that feature. It is good to have that, but I would
>>>be embarrassed to seriously suggest this way because we can't manage
>>>to get WLAN
t, but it's not something to do
lightly.
We *can* do a better job of pointing people at the media with non-free
firmware included. I've added a few more links in various places, but
IMHO we desperately need a better set of download (etc.) pages rather
than just bodging changes in to the existing inadeq
ftware goals as
"political reasons"? Should we just abandon them?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
package in the archive for this now:
https://tracker.debian.org/pkg/debian-crossgrader
It's targeted at systems exactly like yours, tbh. Maybe give it a try?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
of) the most common environments for driving
debconf, in package config and postinst scripts. I don't think that's
going to fly.
Oh, except... We'd only have to generate the json from shell, not
parse it. That may be more tractable. Thanks, that could be a good
suggestion!
>Otherwise, what wou
Thomas Goirand wrote:
>On 11/30/20 11:18 AM, Steve McIntyre wrote:
>> I'm envisaging treating the Choices *mostly* like in an existing
>> select/multiselect, but with extra decoration to indicate the position
>> in the tree for display. It would then be up to t
Timo wrote:
>-=-=-=-=-=-
>
>Hallo Steve McIntyre,
>
>30.11.20 16:36 Steve McIntyre:
>> I'll admit that I'm thinking of this *mostly* in terms of the needs of
>> tasksel so far, but I'd expect switching to a new template type is
>> likely to need a rethink to make
Colin Watson wrote:
>On Mon, Nov 30, 2020 at 10:24:56AM +0000, Steve McIntyre wrote:
>> Timo wrote:
>> >What are the proposed semantics of this multitreeselect?
>> >
>> >If we imagine something like:
>> >
>> >[ ] a
>> > [ ] a/
Colin Watson wrote:
>On Sun, Nov 29, 2020 at 07:21:54PM +0000, Steve McIntyre wrote:
>> On and off, I've been hacking on tasksel for quite a while to improve
>> the UI there and add better support for things like Blends. I've made
>> some progress in my hacking, but I think
Hi!
Timo wrote:
>29.11.20 20:21 Steve McIntyre:
>> On and off, I've been hacking on tasksel for quite a while to improve
>> the UI there and add better support for things like Blends. I've made
>> some progress in my hacking, but I think I've hit a brick wall and I
&
at *can* support it. So, I have a couple of
questions:
1. How flexible is Debconf at coping with a frontend not including
support for a type??
2. Is anybody actually ever using the more obscure (to me!) frontends
(e.g. kde, editor)? Is it worth spending time there?
--
Steve McIntyre, Cambridg
Hey Andreas! I hope you're keeping well!
On Tue, Oct 06, 2020 at 06:08:02PM +0200, Andreas Tille wrote:
>On Mon, Mar 23, 2020 at 07:16:11PM +0000, Steve McIntyre wrote:
>> >Not yet, I'm afraid. A little too swamped so far, but you're near the
>> >top of my TODO list. I'm ho
plain that. The
binary artifact has become the preferred form for modification once
you have it.
In some cases you won't be able to sensibly reproduce the artifact
that causes a problem, but you keep it around to ensure test
coverage. IMHO there is no issue here.
--
Steve McIntyre, Cambridge, U
On Mon, Jan 06, 2020 at 04:23:08PM +, Steve McIntyre wrote:
>Hey Andreas!
>
>On Wed, Dec 18, 2019 at 08:23:39AM +0100, Andreas Tille wrote:
>>
>>the first alpha of the installer of Debian 11 is out. As we talked at
>>DebConf about better Blends support: Is
On Mon, Feb 17, 2020 at 09:03:22AM +0100, Wouter Verhelst wrote:
>On Sat, Feb 15, 2020 at 11:41:32PM +0000, Steve McIntyre wrote:
>> Hey John,
>>
>> John Goarzen wrote:
>> >On Tue, Feb 04 2020, Steve McIntyre wrote:
>> >
>> >The thing that
ace.
>
>PS: Debian-devel is likely the wrong place to redesign C/POSIX functions.
+1000
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loya
Hey John,
John Goarzen wrote:
>On Tue, Feb 04 2020, Steve McIntyre wrote:
>
>The thing that we have to remember is that an operating system is a
>platform for running software. This problem is rather thorny, because:
>
>1) Some software is provided in only binary form and can
Adam Borowski wrote:
>On Wed, Feb 12, 2020 at 06:10:53PM +0000, Steve McIntyre wrote:
>>
>> /me ponders - this could be a fun task for a GSoC/outreachy student to
>> hack on, maybe?
>
>Prior art:
>
>* my unfinished https://github.com/kilobyte/crossgrade -
ases where nobody has tested
interop between 32 and 64 bit machines, though. :-/
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
ullseye, but that's clearly up to the
release team to make a call on. The longer we leave things, the harder
that target will be.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
Florian Weimer wrote:
>* Steve McIntyre:
>
>>>In addition if we are using a new multiarch triplet, and need to
>>>rebuild the world, are going to be ABI incompatible anyway, we might
>>>as well use a proper multiarch-qualified ld.so pathname that does
>>
Hey Simon,
Simon McVittie wrote:
>On Tue, 04 Feb 2020 at 13:14:10 +0000, Steve McIntyre wrote:
>> Arnd scanned the library packages in the Debian archive and identified
>> that about one third of our library packages would need rebuilding
>> (and tracking) to make a (
[ Skimming through this - Arnd already responded ... ]
Guillem Jover wrote:
>On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:
...
>> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
>> need to basically rebuild the world to be 2038-safe. Wh
Florian Weimer wrote:
>* Steve McIntyre:
>
>> The kernel is *basically* fixed now. Internally, data structures
>> should now be safe. There are a small number places where 32-bit time
>> is still a thing, but it's in hand. A number of syscalls, ioctls,
>> etc. ha
stack,
which makes it hard.
We *can* go the suffix route if preferred, but that's a *lot* of
effort - see proposal A...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
off the table without discussion or consideration doesn't
>seem like a good call.
As Arnd has mentioned, it seems the (upstream) glibc maintainers are
not keen to change soname. The last thing we want is to diverge from
them (and hence other distros), so it's a discussion we would need to
h
wzss...@gmail.com wrote:
>Steve McIntyre äº2020å¹´2æ4æ¥å¨äº ä¸å9:15åéï¼
...
>> A Follow a similar path to last time (rename library packages). This
>>will allow us to do partial upgrades, but the cost is that a vast
>>number of packages will need wor
Steve McIntyre wrote:
>Russ Allbery wrote:
>>
>>If we go down this path, can we make cross-grading a supported feature for
>>the next stable release? I'm sure I'm not the only one who is stuck with
>>continuously-upgraded i386 hosts who has been wanting to switch b
people asking for this over the last few
years. I've personally cross-graded a couple of systems (and my home
server has moved twice, i386->amd64->arm64), but it's not for the
faint-hearted.
/me ponders - this could be a fun task for a GSoC/outreachy student to
hack on, maybe?
--
Steve McI
a lot of them are using
Debian as a base already - see the Civil Infrastructure Platform as an
example: https://www.cip-project.org/
As these people are already engaging in ELTS work, I don't expect that
this setup is going to go away any time soon.
--
Steve McIntyre, Cambridge, UK.
Arg, typo in the list address. Sorry. :-(
On Sat, Feb 08, 2020 at 09:28:50PM +, Steve McIntyre wrote:
>Hey Michael!
>
>Sorry for leaving you hanging here. Really busy week...
>
>Michael Biebl wrote:
>>Am 01.02.20 um 14:36 schrieb Steve McIntyre:
>>> Michael Biebl
ut in expert mode, probably yes.
>
>It's not a question for debian-devel or the DPL anyway, please bring it
>to debian-boot.
+1. A reasonable patch to allow this kind of thing would of course be
considered. It could even be pre-seeded to allow for easy control of
it.
I *think* we sai
1 - 100 of 954 matches
Mail list logo
