IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>youpi: i plan to revert that patch
<damo22>it actually does nothing
<damo22>the cdrom one
<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> <--- afaik this is the upstream
<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>the maintainer will
<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>for debian main, not really
<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>we dont want that in there
<damo22>can we just assume we are the arbiter if we connect first?
<youpi>what do you mean by "if we connect first"?
<damo22>i need to read it again
<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
<damo22>no, "create" calls that anyway
<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>git quiltimport ???
<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>but i built a deb
<damo22>do you want me to email you the tarball of debian/
<youpi>damo22: for instance yes
<AlmuHS>I'm trying to enter in savannah, but It feels to be down
<AlmuHS>this even don't reply to ping
<AlmuHS>do you have the same problem?
<AlmuHS>damo22 youpi
<AlmuHS>savannah seems 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