Yuri [EMAIL PROTECTED] writes:
But is there any workaround in 6.3? I need to port one package that
needs to lookup file names by FDs to the current FreeBSD and need some
solution now.
You can not reliably obtain a file name from a file descriptor. The
best you can hope for is to find a file
On 14:20:51 Nov 14, Daniel O'Connor wrote:
Couldn't you just run N copies of X (one for each head) and tell them
which mouse keyboard device to use in each config file?
ie don't use sysmouse or kbdmux.
Try it. If it works let us know. :)
Very unlikely.
Nowadays all X display managers
Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs
to lookup file names by FDs to the current FreeBSD and need some solution
now.
If the port
On Wednesday 14 November 2007, Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that
needs to lookup file names by FDs to the current FreeBSD and need
some
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs to
lookup file names by FDs to the current FreeBSD and need some solution now.
If the port uses a script to extract the
On Wed, 14 Nov 2007, Girish Venkatachalam wrote:
On 14:20:51 Nov 14, Daniel O'Connor wrote:
Couldn't you just run N copies of X (one for each head) and tell
them which mouse keyboard device to use in each config file?
ie don't use sysmouse or kbdmux.
Try it. If it works let us know. :)
On Wed, 14 Nov 2007, Skip Ford wrote:
Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs
to lookup file names by FDs to the current FreeBSD and need
On 2007-11-14 17:48, Daniel O'Connor [EMAIL PROTECTED] wrote:
I've been using a 'converted' tree for almost a year and a half now,
to keep a local mirror of the src repository at `/ws/freebsd/head' on
my laptop. The first clean import of the current tree I am using was
done during last
On 2007-11-14 15:31, OutbackDingo [EMAIL PROTECTED] wrote:
All ive seen in FreeBSD hg branches is a current and a releng_6 Id
like to see a complete tree converted if there is one out there. I do
have some bandwidth to potentially host such a conversion for others.
question is does one exist ?
Robert Watson wrote:
On Wed, 14 Nov 2007, Skip Ford wrote:
Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that
needs to lookup file names by FDs to the
On 22:41:28 Nov 14, Daniel O'Connor wrote:
Why?
No specific reason. linux worked hard to get multiseat working.
Can we have a free ride? I doubt very much.
Keyboard data would not be MUX'd if you didn't use kbdmux. Unless you
use moused mouse events wouldn't be MUX'd.
I haven't
Girish Venkatachalam [EMAIL PROTECTED] writes:
On 22:41:28 Nov 14, Daniel O'Connor wrote:
Why?
No specific reason. linux worked hard to get multiseat working.
Can we have a free ride? I doubt very much.
Just because Linux sucks, FreeBSD necessarily sucks too?
It should work out of the box
Someone I can't stand said this about FreeBSD. Though I know C, I don't
know anything about this and would love to respond. My first thought was
'contigmalloc' but I'm not sure it's equivalent.
[QUOTE]The kernel is really lacking some features. They need a method to
set precise type of memory
[cc cleaned, dropped -current]
Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to Subversion first, and then use the tags/branches
and changesets of Subversion
I suppose you know about fromcvs. I also guess you know that I suggest
using git instead of hg. Doesn't produce nasty large index files either :)
cheers
simon
So would you think cvs - git - hg might be easier to accomplish ??
Since one of my goals is to update projects Ive done based
OutbackDingo wrote:
I suppose you know about fromcvs. I also guess you know that I suggest
using git instead of hg. Doesn't produce nasty large index files either :)
So would you think cvs - git - hg might be easier to accomplish ??
Since one of my goals is to update projects Ive done based
On 2007-11-14 19:08, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote:
[cc cleaned, dropped -current]
Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to
On Wednesday 14 November 2007 11:11:41 am Rob Belics wrote:
Someone I can't stand said this about FreeBSD. Though I know C, I don't
know anything about this and would love to respond. My first thought was
'contigmalloc' but I'm not sure it's equivalent.
[QUOTE]The kernel is really lacking
Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to Subversion first, and then use the tags/branches
and changesets of Subversion to populate an Hg tree.
That
On Wednesday 14 November 2007 11:11:41 am Rob Belics wrote:
Someone I can't stand said this about FreeBSD. Though I know C, I
don't
know anything about this and would love to respond. My first
thought was
'contigmalloc' but I'm not sure it's equivalent.
[QUOTE]The kernel is really
Hello folks,
I am maintaining for net-p2p/linuxdcpp, I noticed that in pkgsrc has a
patch for linuxdcpp to make the characters less than 14 in sem_open() to
fix bug. I am wondering how I can reproduce this problem? I run linuxdcpp
pretty often and I don't see any problem. It makes me
On 15/11/2007, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote:
This is due to the fact that CVS doesn't have changesets. It is too
late now and it is also quite complicated to explain, but it boils down
to the fact that aggregating changesets will remove information, namely
the single
22 matches
Mail list logo
