Dear *,
could some kind soul point me to an example on how to make accessing the
typical serial lock files like /var/lock/LCK..ttyUSBx work for non root users?
polkit should fit the bill, but I cannot locate any good examples.
Background:
I'm packaging chan_dongle for Asterisk, that allows to use a usual USB dongle
for routing phone calls from/to it:
https://build.opensuse.org/package/show/home:frispete:telephony:asterisk/as…
but of course, nobody wants to run asterisk as root(!)
Thanks in advance,
Pete
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
I want to use find to locate files with a specific suffix. The thing
is that once I find a file with that suffix, I do not want to continue
in that directory or it's sub-directories - especially not any
sub-directories. But I do want the search to otherwise continue.
I have seen how to get find to stop after X matches. But that is not
what I need. The sub-directories contain 10s of thousands of images.
When run over a network, skipping these speed things tremendously.
Any ideas?
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
Anyone here using zeromq ?
I'm looking for a simple inter-system (ie. networked) message queueing
library. I only need push-pull, bidirectional. Sofar I've just used
my own, but now I need to control the length of a queue. I.e. "don't
push unless queuelen<N".
I've just now looked at zeromq and rabbitmq, but they both seem a bit
too much for what I need.
--
Per Jessen, Zürich (19.2°C)
http://www.hostsuisse.com/ - virtual servers, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
I'm rebuilding from some code I wrote in 2010 and compiled with gcc
4.2.1. Compiling now with gcc 7.3.1 I get e.g. this warning:
/usr/include/aio.h:149:12: note: expected ‘struct aiocb * const*
restrict’ but argument is of type ‘struct aiocb *’
afaict, this about what the compiler is allowed to optimize and what
not, can anyone elaborate ?
--
Per Jessen, Zürich (17.2°C)
http://www.dns24.ch/ - your free DNS host, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
Roger Oberholtzer wrote:
> On Mon, Jun 4, 2018 at 8:45 AM, Per Jessen <per(a)computer.org
> <mailto:per@computer.org>> wrote:
>
> I'm reviving some old code, dates back to 2010. In one place I see I
> have replaced use of pthread_mutexes with sem_wait() and sem_post()
> (posix semaphores). I just can't see why I did it. :-(
>
> The semantics are slightly different, but can anyone suggest why one
> should use one over the other? (or vice versa).
>
>
> They would act differently. The pthread_mutexes typically wait for
> access to a variable. They do not wait for the variable itself to
> change. The sem_wait(), well, waits for the semaphore to change. Is the
> semaphore value itself the one you are interested in? Or does it's
> change mean that some variable you are interested in has changed? IMHO,
> pthread_mutexes are safer because when you access the protected
> variable, it should not be in the process of changing.
Thanks for your input, Roger.
Here is what I wrote -
//pthread_mutex_lock( &mux );
while( EINTR==sem_wait( &mux ) );
do some queue manip.
//pthread_mutex_unlock( &mux );
sem_post( &mux );
mux is either a pthread_mutex_t or a sem_t.
The queue manipulation is key, the mux is uninteresting. The reason I am
looking at this is that a thread got hung up (over the weekend) - in the core
dump, a signal handler was called and tried to write to the queue whilst someone
was reading from the queue. It's possible that is why I had to move to using
semaphores - I wonder if pthread_mutex_lock is async-safe.
/Per
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
I'm reviving some old code, dates back to 2010. In one place I see I
have replaced use of pthread_mutexes with sem_wait() and sem_post()
(posix semaphores). I just can't see why I did it. :-(
The semantics are slightly different, but can anyone suggest why one
should use one over the other? (or vice versa).
--
Per Jessen, Zürich (18.9°C)
http://www.hostsuisse.com/ - dedicated server rental in Switzerland.
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
Hi,
I'm trying to compile the TDE text editor (http://adoxa.altervista.org/tde/),
a 32-bit application, on my OpenSuSE Leap 42.3 X86_64 system, but I'm
getting a prerequisite error:
~/Downloads/Packages/Non-RPMs/Linux/tde-5.1v
$ make
Compiling bj_ctype.c
In file included from /usr/include/features.h:389:0,
from /usr/include/stdio.h:27,
from tdestr.h:19,
from bj_ctype.c:20:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or
directory
# include <gnu/stubs-32.h>
^
compilation terminated.
makefile:102: recipe for target 'unix/bj_ctype.o' failed
make: *** [unix/bj_ctype.o] Error 1
I tried searching with zypper
$ zypper se --provides stubs-32.h
Retrieving repository 'devel:libraries:c_c++'
metadata .......................................................................
[done]
Building repository 'devel:libraries:c_c++'
cache ............................................................................
[done]
Retrieving repository 'devel:libraries:c_c++'
metadata .......................................................................
[done]
Building repository 'devel:libraries:c_c++'
cache ............................................................................
[done]
Retrieving repository 'Packman Repository'
metadata ..........................................................................
[done]
Building repository 'Packman Repository'
cache ...............................................................................
[done]
Loading repository data...
Reading installed packages...
No matching items found.
and
$ zypper se glibc-devel
Loading repository data...
Reading installed packages...
S | Name |
Summary | Type
---+-----------------------------+-------------------------------------------------------+-----------
i+ | glibc-devel | Include Files and Libraries Mandatory for
Development | package
| glibc-devel-32bit | Include Files and Libraries Mandatory for
Development | package
i+ | glibc-devel-debuginfo | Debug information for package
glibc-devel | package
| glibc-devel-debuginfo-32bit | Debug information for package
glibc-devel | package
| glibc-devel-static | C library static libraries for -static
linking | package
i+ | glibc-devel-static-32bit | C library static libraries for -static
linking | package
i+ | linux-glibc-devel | Linux headers for userspace
development | package
| linux-glibc-devel | Linux headers for userspace
development | srcpackage
but though glibc-devel-32bit is installed (which is where I would expect it to
be, gcc can't find it anywhere.
Can anyone tell me what provides gnu/stubs-32.h?
Leslie
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
libnsl (network services library), which used to be part of glibc, has
been moved to its own package (libnsl). I have linked with this
library since forever. On Tumbleweed, I just noticed it's absence. I
am guessing this is the result of some code rearrangement. But it's
not clear to me what is being accomplished by moving it to a new
package. As an example, gethostbyname is available via glibc
libraries, as well as via the separate libnsl. Or so it seems. Why
have functions like gethostbyname in two places? The only clue I have
seen is that libnsl supports IPV6. Does this mean that for these
functions glibc does not have this support?
I see that libnsl as a package has been built on OBS for a while. But,
unless I am mistaken, it is only very recently that /lib64/libnsl.so.1
is no longer in glibc. One must now install libnsl as well. Maybe I
don't need to link with libnsl anymore? We don't have IPv6 networks.
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
I am trying to link with a library (I do not have the source) that
uses ffmpeg. I have the various bits installed (I have tried both
openSUSE and Packman versions). When I do this:
gcc source.c -I /usr/include/ffmpeg -lsomelib -lavformat -lavcodec
-lavutil -lswscale
I get this:
/usr/lib/libsomelib.so: undefined reference to
`avformat_alloc_output_context2@LIBAVFORMAT_FFMPEG_56'
/usr/lib/libsomelib.so is a binary for which I do not have the source.
Others claim it should be usable in openSUSE. It is not really called
this.
I get this for a dozen or so functions in the various ffmpeg libs. The
library does contain avformat_alloc_output_context2. But what is the
@LIBAVFORMAT_FFMPEG_56 after the name?
The library is:
lrwxrwxrwx 1 root root 24 Sep 18 14:35 /usr/lib64/libavformat.so
-> libavformat.so.56.40.101
lrwxrwxrwx 1 root root 24 Dec 20 15:17
/usr/lib64/libavformat.so.56 -> libavformat.so.56.40.101
-rwxr-xr-x 1 root root 1896832 Dec 2 18:50 /usr/lib64/libavformat.so.56.40.101
Which seems correct.
I am obviously missing something.
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org
We are exploring the possibility of obtaining interrupts from various
GPIO lines on intel NUC computers. For example the NUC5i5MYBE. We are
expecting to write a kernel driver. But the kernel docs are not all
one needs for this.
Intel support for Linux on this hardware is less than usual. I think
part of the solution requires that the ACPI information in the BIOS
tells about such interrupts. I am not sure. Does anyone have any
experience with these computers and, more specifically, GPIO
interrupts? openSUSE Leap 42.3 installs and runs fine on this
hardware. We just want to use more of the available hardware.
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-programming+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-programming+owner(a)opensuse.org