Apologies for the awful formatting gmail inflicted on my previous mail...
Gstreamer info and dmesg below.
gstreamer1-1.10.4 framework for streaming media
gstreamer1-plugins-base-1.10.4 base elements for GStreamer
>> OpenBSD/amd64 BOOT 3.33
boot>
booting hd0a:/bsd: 6994272+2216968+259456+0+67
It appears that Gstreamer-1.0 can't access raw uaudio(4) devices (rsnd/n).
I'm struggling to debug further so wanted to ask if this is expected to
work or a known limitation of OpenBSD's sndio(7) implementation for
gstreamer?
This is where I've got to so far:
Gstreamer-1.0 works fine with uaud
Has anyone noticed problems with uvideo(4) in recent snapshots?
The issue I'm seeing is reproducible with video(1) - just run it and
wait. After some seconds or minutes no new frames arrive and video(1)
is waiting on poll(2). Larger frame sizes seem to decrease the time
needed to achieve this stat
I'd say twice per message processed is unnecessarily verbose but I
assume you want it that way for a reason.
It is a trivial niggle and probably irritates only me :-)
Thanks for looking Gilles.
Percy.
On 17 July 2012 19:04, Gilles Chehade wrote:
> mh, is it really that verbose ?
Any objections to making the scheduler a little less verbose?
Cheers,
Percy.
Index: scheduler.c
===
RCS file: /cvs/src/usr.sbin/smtpd/scheduler.c,v
retrieving revision 1.6
diff -u -p -r1.6 scheduler.c
--- scheduler.c 10 Jul 2012 11:1
Hi all.
Smtpd.conf(5) states that %a expands to the user before alias resolution
and %u after. Is it the other way round? I am probably missing something
but on the latest i386 snap it seems %a and %u do the opposite to what
smtpd.conf(5) claims?
Can anyone clarify?
Many thanks
Percy
http://www.sinet.bt.com/506v1p0.pdf
For the archives sake, we finally solved this. pppoe(4) never requests
an mru during lcp negotiation (and acks any reasonable mru offered).
In our case we were being offered an mru (1492) by the BT AC (BRAS)
which we ack'd. With the mru agreed at both ends of the link our auth
with the BT bras succ
On 30 December 2011 01:17, Stuart Henderson wrote:
> I haven't seen this with pppoe(4) and any of: zen fttc, demon adsl
> (ipstream), aaisp adsl (ipstream or 21cn), bogons adsl (ipstream).
OK thanks. That's a decent list of positives.
> Does your ISP have reachable technical people that might b
On 28 December 2011 21:36, percy piper wrote:
> pppoe(4) did not work. We need to authenticate with chap first, then
> pap. pppoe(4) forces the exclusive use of either one or the other.
Actually this is not true. Both use chap. There is no pap.
The first chap challenge succeeds (to the
Hi, we finally went live today so a small summary of how it went.
pppoe(4) did not work. We need to authenticate with chap first, then
pap. pppoe(4) forces the exclusive use of either one or the other.
This was an unexpected gotcha and I will look at the code to see what
can be done.
pppoe(8) wor
Hi Stuart and thank you for the excellent info.
It looks like we're good then, our install is due this coming Monday
so I will refer to your mail as we proceed through the initial setup.
Oh, and for the archives s/FTTC/FTTP.
Percy.
Is anyone using OpenBSD as the 'front-end' router on a UK fibre (FTTC)
broadband circuit?
We are due to start trialling a 100Mb FTTC broadband and hope to use
an OpenBSD box as the first stage router (i.e. to replace what the
Home Hub would normally do). We know the presentation (from BT) is
ether
>> There was a brief window in in late July/early August about a week
>> long where it would successfully suspend and resume, but the screen
>> would never turn back on. Anytime before or after that and it
>> would suspend fine, but when it resumes it's totally unresponsive
>> to anything except a
> Yes, this started to happen lately with current.
> It seems the guilty commit has been just backed out.
Thanks Luca, would you mind sending me a pcidump -v please?
>> It has an ATI Radeon Mobility X1400 btw.
> I have the same issue with resume.
Did either of you have working resume ever before?
Just wanted to mention my appreciation and admiration for those who
have the knowledge and ability and give it to us for free. But especially
krw@ who found and fixed what turned out to be (in my uneducated
opinion) an obscure bug buried deep in the SCSI code.
Thanks all, and thanks indeed Ken.
I'm having trouble with restore from SCSI tape with the June 6th i386 snapshot.
I have a few i386 boxes that dump ~200GB data to tape each night.
I updated one to the June 6th i386 snapshot and dump continues to work. e.g.:
sudo dump -a0 /dev/wd0a
DUMP: Date of this level 0 dump: Tue Jun 8 18:
18 matches
Mail list logo