openSUSE Programming

programming@lists.opensuse.org

1032 discussions

[opensuse-programming] non root permission for /var/lock/LCK..ttyUSBx (polkit?)

by Hans-Peter Jansen

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

2 years, 10 months

[opensuse-programming] find stop search criteria

by Roger Oberholtzer

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

3 years, 1 month

[opensuse-programming] inter-system message queueing ?

by Per Jessen

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

3 years, 3 months

[opensuse-programming] struct aiocb * const* restrict

by Per Jessen

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

3 years, 4 months

Re: [opensuse-programming] pthread_mutex vs semaphore.h ?

by Per Jessen

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

3 years, 4 months

[opensuse-programming] pthread_mutex vs semaphore.h ?

by Per Jessen

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

3 years, 4 months

[opensuse-programming] Having trouble compiling TDE

by Leslie Turriff

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

3 years, 4 months

[opensuse-programming] libnsl no longer needed?

by Roger Oberholtzer

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

3 years, 7 months

[opensuse-programming] Linking with ffmpeg.

by Roger Oberholtzer

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

3 years, 10 months

[opensuse-programming] GPIO interrupts on intel NUC computers

by Roger Oberholtzer

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

4 years

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

openSUSE Programming