IRC channel logs

<youpi>etno: https://buildd.debian.org/vim will show you how well it passed on the buildds. Possibly you have an additional packages that enables some feature in vim that triggers bugs. You'd have to build in a clean chroot to reproduce the buildd build situation

<etno>youpi: makes sense. gdb at least is one example, as it enables termdebug

<damo22>youpi: if the default will be to read xattr translator records, should the order of priority of the records be swapped when you change the option?

<damo22>currently, the code always prefers to read legacy translator records

<damo22>ie, if you add a xattr record it will remove the legacy one and write a new one, but if you dont use xattr, it will always try the legacy one first, fail, and then read the new one

<youpi>it does not really matter if we clear one when writing the other

<damo22>ok

<damo22>If xattr is supported by this filesystem, check for new translator record regardless of flag to use it or not (?)

<youpi>yes

<youpi>so the migration is soft

<youpi>otherwise there's a flag day, nobody wants a flag day

<damo22>ok

<damo22>ive made a small change and tested it

<damo22>i changed default to use xattr and added --no-xattr-translator-records

<damo22>which gives old behaviour

<damo22>and checked with debugfs

<Pellescours>why not do dual write for migration ? wrtiting the old os field AND the xattt gnu.translator at the same time during the migration period ? like this whenever user disable xattr, the old attr is still existing

<youpi>it's usually a bad thing to duplicate information

<damo22>maybe we can soft launch, and if nothing goes wrong, in the next release we can ship a script that renews all of the translator entries?

<damo22>like a post hook or something

<damo22>Pellescours: the code is already set up to deduplicate them

<damo22>once irqhelp gets merged, i can deduplicate the code in pci-userspace / ddekit

<damo22>youpi: bus_addr_t is unsigned long in rump api, does that work on PAE / 64 bit?

<damo22>i think some address is being truncated to 32 bits in rump when it tries to map some memory

<damo22>testing a change i made locally

<damo22>damn i broke it

<youpi>damo22: there's a patch in the debian package to fix that

<damo22>youpi: "PAE" ?

<youpi>yes

<damo22>im not sure that fixes it entirely

<youpi>possibly

<youpi>I just know it does work for 64bit

<damo22>ok

<youpi>but for 32bit we are not supposed to use >4G physical pages, drivers won't support that

<damo22>is there any harm using a non-PAE gnumach with rumpdisk + PAE

<youpi>none

<damo22>somehow the AHCI probe is failing on my amd box with i386 and PAE patch, it fails at pci_mapreg_map()

<damo22>rumpcomp_pci_map(unsigned long addr, unsigned long len) <--- is addr always <4G for pci space on i386?

<youpi>most probably

<gnucode>howdy@

<gnucode>howdy!

IRC channel logs

2024-03-03.log