On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault wrote:
>
> Hello,
>
> Answering separately since they are completely separate issues.
Thanks a lot for taking a look!
> That's odd indeed. Which gnumach kernel were you using? I noticed an FPU
> context switch bug in gnumach, possibly that was affe
On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault wrote:
> > I've verified that I see the same behavior on darnassus,
>
> I don't see it happen on darnassus.
Interesting: I've just checked and I no longer see it on darnassus
either! But I'm 100% positive I saw it there. Could it be that
darnassus h
On Fri, Oct 8, 2021 at 12:38 AM Samuel Thibault wrote:
> Please always check the latest version of the wiki pages on darnassus,
> there it was fixed:
>
> debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
> --extra-suites=unreleased sid chroot http://deb.debian.org/debian-
On Fri, Oct 8, 2021 at 12:56 PM Sergey Bugaev wrote:
>
> On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault wrote:
> >
> > Hello,
> >
> > Answering separately since they are completely separate issues.
>
> Thanks a lot for taking a look!
>
> > That's odd indeed. Which gnumach kernel were you using?
Sergey Bugaev, le ven. 08 oct. 2021 12:56:01 +0300, a ecrit:
> Or perhaps you happen to know of an apt flag/option to
> ignore sha512 and temporarily rely on other hashes?
You can as well just download the .deb files yourself and dpkg -i them.
> Was the FPU context bug introduced recently (as in,
Sergey Bugaev, le ven. 08 oct. 2021 13:14:04 +0300, a ecrit:
> ...but that doesn't seem to have helped much:
>
> # debootstrap --no-check-gpg --extra-suites=unreleased sid
> /mnt/subhurd/ http://deb.debian.org/debian-ports/
>
> dpkg: dependency problems prevent configuration of vim-tiny:
> vim-
On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault wrote:
> That's because vim is currently failing to build, and thus we get
> trapped again by the version difference between vim and vim-common.
>
> "Unstable" has its name for a reason :)
Even ignoring vim for a second (I could/should attempt to exc
Sergey Bugaev, le ven. 08 oct. 2021 14:25:38 +0300, a ecrit:
> On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault wrote:
> > That's because vim is currently failing to build, and thus we get
> > trapped again by the version difference between vim and vim-common.
> >
> > "Unstable" has its name for a r
Hello purchasing dept.,
Good day. How do you do?
This Villa from Kalis Electronics Ltd., our company is a professional
Electronics Parts exporter. So we want to avail ourselves of opportunity
establishing business relation with you.
Our advantage:
1. Do our best to Meet your TP
2. Shorter le
On 9/10/21 12:25 am, Sergey Bugaev wrote:
On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault wrote:
That's because vim is currently failing to build, and thus we get
trapped again by the version difference between vim and vim-common.
"Unstable" has its name for a reason :)
Even ignoring vim for
On Fri, Oct 08, 2021 at 01:09:38PM +0300, Sergey Bugaev wrote:
> On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault wrote:
> > > I've verified that I see the same behavior on darnassus,
> >
> > I don't see it happen on darnassus.
>
> Interesting: I've just checked and I no longer see it on darnassus
Ignoring both syslog and vim did the trick! The final command was:
# debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
--extra-suites=unreleased --exclude vim,vim-tiny,rsyslog sid
/tmp/subhurd/ http://deb.debian.org/debian-ports/
Now, I ran into another issue, which is th
Sergey Bugaev, le ven. 08 oct. 2021 19:17:33 +0300, a ecrit:
> A proper fix would be to extend
> device_get_status () to support sizes that don't fit into a single
> 32-bit int; perhaps by using a third int and a new "flavor".
That's the "Extend `device_read`/`device_write` into supporting > 2TiB
Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
> On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault wrote:
> > That's the "Extend `device_read`/`device_write` into supporting > 2TiB
> > disk sizes." item in the "small hack entries" list. There's indeed the
> > device_get_status() call th
On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault wrote:
> That's the "Extend `device_read`/`device_write` into supporting > 2TiB
> disk sizes." item in the "small hack entries" list. There's indeed the
> device_get_status() call that needs fixing, but device_read/write as
> well, they need to be ext
On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault wrote:
> Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
> > I wonder if it'd be possible to change device_{read,write} to use a
> > 64-bit integer without introducing separate new RPCs,
>
> No: RPC interfaces have fixed typing, expressed
Separate seems a cleaner solution.
We could deprecate it down the line.
On Fri, Oct 8, 2021, 22:15 Sergey Bugaev wrote:
> On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault
> wrote:
> > Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
> > > I wonder if it'd be possible to change device_
On Fri, Oct 8, 2021 at 9:57 PM Sergey Bugaev wrote:
> type recnum_t = uint64_t | array[*:2] of uint32_t;
Hm, no, that wouldn't actually work, it's still a type mismatch. And
'polymorphic' is not polymorphic enough. type recnum_t = array[*:2] of
uint32_t would work, but that changes libc *API*, at
18 matches
Mail list logo
