***Server sets mode: +nt
<damo22>youpi: i plan to revert that patch <damo22>youpi: for libpciaccess can you be more specific on which to base my 0.16 patch? <damo22>ie, should it apply cleanly on top of existing debian 0.14-1+hurd.3 patches? <damo22>or should i replace the 99- ones with mine? <damo22>i think jlledom[m] is confused about where is "upstream" for libpciaccess <damo22>i was the one who got this merged here <damo22>if we want to add changes on top of that, we should review what is in there, do the changes and then create a patch for debian <damo22>ok so jlledom[m]'s patch *is* for 0.16 == upstream , but we have different code in debian <damo22>youpi: how do we bump the version from 0.14 to 0.16 in debian? <youpi>however the maintainer is the Xorg team, which doesn't have many members atm, and who are already very busy <damo22>is there something i can provide that will help? <youpi>so we can't expect things to happen quickly <youpi>but for unreleased, if you can provide an updated debian/ directory for 0.16, I can easily upload that to unreleased <damo22>im still not sure how to fix the weak symbol <damo22>can we just assume we are the arbiter if we connect first? <youpi>what do you mean by "if we connect first"? <damo22>why not just remove the netfs_server_name lookup and make it always open x86 first, it should fail if the ports are locked <damo22>otherwise it will use hurdish method <damo22>and if the locking doesnt work for some reason, it will just not use pci-arbiter until we fix the lock <damo22>maybe we need to call x86_enable_io() after running pci_system_x86_create() ? <damo22>actually we need to request ioperm just on the conf ports <damo22>but it should still work with all of them <jrtc27>why can you not just add a flag to the API somehow so pci-arbiter can say "I expect you to use the x86 method"? <damo22>because we are the only use case, it would be annoying for everyone if we changed the api <jrtc27>the existing API would stay as the normal way to do things <jrtc27>you just add an extra special feature for the hurd <jrtc27>because our way of doing things *is* special <jrtc27>rather than trying to use heuristics in the library to guess at what the right behaviour is <youpi>damo22: trying x86 first won't work <youpi>because you can't be sure that it's pci-arbiter which will start first <jrtc27>it also completely decouples libpciaccess from knowing that pci-arbiter is special <youpi>unless we have another way to enforce that <damo22>then jrtc27's idea makes a lot of sense <jrtc27>this way, *any* translator that decides it wants to take ownership can (provided nobody else has already) <jrtc27>yeah that will break things if it's not well behaved, but so what <damo22>youpi: i did a clean import of all patches from 0.14 to 0.16 in a debian tree and then git merged the branch into debian-unstable branch, fixed the changelog and exported the debian/ dir to a tarball, there are no patches applied <damo22>im not sure what patches we want on top of 0.16 <damo22>do you want me to email you the tarball of debian/ <AlmuHS>I'm trying to enter in savannah, but It feels to be down <youpi>I have seen it have issues these days, yes <youpi>I guess the admins are aware <AlmuHS>ok, It's not problem of my computer or location ***Emulatorman____ is now known as Emulatorman