Re: Bug#580088: jack-audio-connection-kit: FTBFS on armel ("cannot convert 'int' to 'va_list'")

[Adrian Knoth]

On Mon, May 03, 2010 at 04:00:14PM +0100, Adam D. Barratt wrote:

> ../common/JackAPI.cpp:303: error: cannot convert 'int' to 'va_list'
> for argument '4' to 'jack_client_t* jack_client_open_aux(const char*,
> jack_options_t, jack_status_t*, va_list)'

The code in question:

   jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL);

Obviously, arg4 is NULL, so the message means the compiler cannot
convert 0 to a va_list, which should be (more or less) a pointer. Or at
least was until some va_list mangling in gcc-4.4.

I don't have a clue: anybody more common with ARM specifics around?



TIA

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100503161300.gq12...@ltw.loris.tv

Re: Bug#580088: jack-audio-connection-kit: FTBFS on armel ("cannot convert 'int' to 'va_list'")

[Adrian Knoth]

On Mon, May 03, 2010 at 05:50:39PM +0100, Simon McVittie wrote:

> > The code in question:
> >
> >jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL);
> 
> Instead of trying to fake up an empty va_list, why not call the varargs
> version, with only the argument terminator in its varargs?
> 
> jack_client_open(client_name, (jack_options_t)options, NULL, NULL);

Absolutely. I've been blind. ;)


Thanks, this should work.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100503171003.gs12...@ltw.loris.tv

Bug#593734: ITP: a2jmidid -- daemon for exposing legacy ALSA MIDI in JACK MIDI systems

[Adrian Knoth]

Package: wnpp
Severity: wishlist
Owner: Adrian Knoth 

* Package name: a2jmidid
  Version : 6
  Upstream Author : Nedko Arnaudov
* URL : http://home.gna.org/a2jmidid/
* License : GPL
  Programming Lang: C
  Description : daemon for exposing legacy ALSA MIDI in JACK MIDI systems



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100820154307.16092.38784.report...@hex.inf-ra.uni-jena.de

Re: Bug#603699: ITP: celt051 -- The CELT codec v0.5.1

[Adrian Knoth]

On Tue, Nov 16, 2010 at 04:08:02PM +0100, Patrick Matthäi wrote:

Hi!

[CELT for spice]
> Yeah I am aware of the celt _madness_ - I am one of the mumble
> maintainers..
>
> spice then has to be adjusted to support celt 0.9.

I strongly support this demand. It was wrong to use CELT in the first
place, these guys clearly state that everything may change whenever they
want (before the 1.0 release), and especially the API is unstable.

We had the same thing in jackd, and it's as simple as that: either
prepare for a moving target or don't use it.

Ok, now spice has ignored all warnings and "decided" to go for
celt-0.5.1 (for whatever reason).

Please forgive my ignorance, but I don't see why this means they'll have
to stick to it til the end of time. I might have missed something, but I
don't know a single spice user, so which backward compatibility are we
talking about?

Anyway, there's

   http://www.spice-space.org/docs/spice_protocol.pdf

and it says it's a draft, so I guess it can still be reworked. But
still, if you see section 7 and 8, you'll notice two constants:

   RED_PLAYBACK_DATA_MODE_RAW= 1
   RED_PLAYBACK_DATA_MODE_CELT_0_5_1 = 2

And the mode constants are used in an uint32 (section 7.5).

So why on earth don't you simply define a
RED_PLAYBACK_DATA_MODE_CELT_0_9_whatever, make this number three and
that's it?

Ok, you'll lose backward compatibility to non-celt-0.9 installations
already deployed and not being able to update... but who's using them?
And who will be using them by 2011?

If there's such a legacy user base, then I suggest to embed your private
copy of celt-0.5.1 into the spice client source. For everyone else, it's
the wrong signal to expect any CELT version (below 1.0) to be widely
installed anywhere.

So strictly speaking: it's possible for spice to support more than one
celt version (as shown above) without ruining backward compatibility.
In Debian, only provide the newest celt version. If need be, embed
celt-0.5.1 into spice, but the other approach would be to entirely
ignore this 0.5.1 thing.

This way, there'll be support for newest celt with the fallback to raw
audio transfer (DATA_MODE_RAW).



Just my €0.02

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101116211103.gy14...@ltw.loris.tv

Bug#604728: general: Cannot play anything in totem or gnome-mplayer while a flash movie is running in iceweasel

[Adrian Knoth]

On Tue, Nov 23, 2010 at 10:19:05PM +0100, marcin wrote:

[No other audio app starts when there's already one running]
> I'm sorry but I cannot tell which package exactly is the source of the
> problem so I put it in 'general' section.

Well, looks like a classic: on some (most?) audio cards, ALSA only
supports a single stream. So if you start your flash playback, the audio
device is occupied and hence blocked for other apps.

The solution is to multiplex/mix in software, most commonly done with
pulseaudio these days.

Don't you have pulseaudio installed?

Also, make sure to redirect all ALSA output to pulseaudio. Either in
/etc/asound.conf or in ~/.asoundrc:

--- asound.conf ---
pcm.pulse {
type pulse
}

ctl.pulse {
type pulse
}

pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
--- end of asound.conf ---


HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101124083652.gt14...@ltw.loris.tv

Re: Qt3 removal rational

[Adrian Knoth]

On Tue, Feb 08, 2011 at 12:42:38PM +0100, Bastien ROUCARIES wrote:

> In the scientific field a lot of software depend of qt3. And a lot of

Same for kpicosim, but I'm pretty confident that I can run qt3to4 on it
and simply link with qt4's qt3 support library.

Last time I tried, the whole process was pretty straight forward and
took less than 15mins.


Just in case you're looking for a quick workaround.

HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110208120800.gd15...@ltw.loris.tv

Re: realtime kernel for Debian

[Adrian Knoth]

On Wed, Mar 25, 2009 at 12:37:37PM +0100, Grammostola Rosea wrote:

> > >> Why only in 64studio and not in plain Debian?
> > What's good for Debian is good for us :-) but the Debian project may 
> > not want to tweak the kernel or the FireWire stack just for the 
> > benefit of FFADO users. In the 64 Studio project we have more 
> > flexibility to do things like that.
> > Some background info here:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463 
> What is true about this? Shouldn't plain Debian also support those Pro 
> audio Firewire devices, the ones the FFADO team are making drivers for?


It's easy:

http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Module_auto-loading


Compile both modules and blacklist the new Juju modules. That's the
current upstream recommendation.

Even if the default will change around 2.6.30 (or later, I don't know
the exact schedule), the FFADO users could still enable the old ieee1394
modules.

We already have libraw1394-v2 in sid, but as outlined, FFADO currently
only works with the old stack. This might also change in the future,
especially if the Google Summer of Code project succeeds. (in-kernel
alsa driver module for firewire audio)


IOW: ship both stacks, decide for one and blacklist the other. FFADO
users will then select the appropriate one. And of course, I'll continue
looking into the FFADO-on-Juju issue.


HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Please Improve Debian for Multimedia Production

[Adrian Knoth]

On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote:

> The problem is an realtime kernel and a proper configuration for music 
> production. Without that, you better stay away from music production 

Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks,
ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running
on a dualcore amd64 laptop.

It's an outdated myth that you need RT kernels for audio production,
though it helps with very low latencies. (let's say buffer sizes below
10ms and high CPU loads)


Nevertheless, for those with highest constraints or older hardware, a RT
kernel is beneficial.


HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#522151: ITP: calf -- High quality open source audio plugins for musicians

[Adrian Knoth]

Package: wnpp
Severity: wishlist
Owner: Adrian Knoth 


* Package name: calf
  Version : 0.0.18.3
* URL : http://calf.sf.net/
* License : GPL
  Programming Lang: C++
  Description : High quality open source audio plugins for musicians

(Include the long description here.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.28.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Two years later and still no netatalk3 in jessie?

[Adrian Knoth]

On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote:

> - jessie freeze happens in 2 months

Happened in the meantime :-/

> 2014/8/4 - Adrian updated the package to 3.1.3
> adi's package (currently @ 3.1.3):
> https://github.com/adiknoth/netatalk-debian

JFTR, I'm at 3.1.6.


The whole situation reminds me of wine, where Debian shipped the same
outdated version for multiple releases.

Even downstream distributions are suffering:

 
http://raspberrypi.stackexchange.com/questions/23985/why-is-netatalk-not-updated


I'd say get some devs behind this, call the package netatalk3 and ship
it in parallel. I had it running for months, upstream had worked on it
for years, it's not that this is bleeding edge or untested.

jessie without netatalk3 would be embarrassing at best, but more
importantly, it would be frustrating for everyone who wants to use their
Linux file servers as a time machine backup.

CC debian-devel for additional momentum. Please stop CCing this bug in
case this turns into another bike shedding discussions on the ML.


Cheers

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141109094858.ga8...@ltw.loris.tv

Re: Two years later and still no netatalk3 in jessie?

[Adrian Knoth]

On Sun, Nov 09, 2014 at 12:55:03PM +0100, Bálint Réczey wrote:

> >> 2014/8/4 - Adrian updated the package to 3.1.3
> >> adi's package (currently @ 3.1.3):
> >> https://github.com/adiknoth/netatalk-debian
[..]
> > I'd say get some devs behind this, call the package netatalk3 and ship
> > it in parallel. I had it running for months, upstream had worked on it
> > for years, it's not that this is bleeding edge or untested.
> IMHO the proper way of putting this package into focus is asking the
> maintainers to file an RFH bug if you don't want help yourself.
> Helping yourself can be submitting patches through BTS,

You surely have noticed that I actually provided proper Debian packaging
in January 2014, right? And proper means 3.0/quilt workflow with signed
tags, pristine-tar and everything.

I've pinged the maintainers/bug:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690227#65

I've updated the package in early August, pinged the bug plus the team
mailinglist:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690227#81


I've updated it a second time to 3.1.6 in late September. I think it's
only fair to say that *I* actually did help.


Read this timeline:


   From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685878#16

2012/7/9 - netatalk 3.0 released upstream

2012/10/11 - Hideki started working on a 3.0.1 package using dh style
instead of cdbs, but it was declined because of Jonas' wish to stick
with cdbs

2013/3/18 - Igor posted a 3.0.1 cdbs package

2013/4/12 - Martin updated the cdbs package to 3.0.3

2014/1/11 - Tony built a 3.0.6 deb

2014/1/11 - Tony articulated the need for 3.0.6 due to problems w. time
machine

2014/1/11 - Jonas stated intent to upgrade to 3.x but cited lack of time

2014/1/14 - Adrian cleaned up tony's 3.0.6 package and posted it

2014/2/10 - Jonas stated intent to continue to maintain the netatalk
package & opened a mailing list on alioth

2014/4/18 - Brian cleaned up & updated Adrian's package to 3.1.1

2014/4/19 - Chris suggested to get netatalk 3.x into experimental asap
to get it ready for jessie

2014/4/20 - Chris, Brian & Jonas collaborated & pushed 2.2.5

2014/8/4 - Adrian updated the package to 3.1.3

2014/8/27 - HAT reported that 3.1.6 is available

2014/9/29 - Adrian updated the package to 3.1.6



Add at least three wishlist bugs asking for netatalk 3.x, some as early
as 2012.  Two years of absolutely no progress, despite at least six
people helping.


I'm only a DM, I cannot upload foreign packages. And if it wasn't for
the two friends who needed netatalk3, I wouldn't even care at all.

But maybe, just maybe, at some point the maintainers should actually
upload stuff?



> Most probably Jessie will not contain netatalk 3, but having it in
> jessie-backports would be almost as good as having it in jessie.

I agree. So is there a DD who actually cares about netatalk? If so,
clone my git repo and upload to experimental as suggested seven months
ago. The usual git-buildpackage workflow.

Or call it netatalk3 and upload it to sid, totally up to you.

Or file a RFH bug on behalf of the netatalk maintainers that can be
ignored for another two years. ;)



Cheers

PS: Just in case it wasn't obvious, I have absolutely no interest in
maintaining netatalk. Not my package.


-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141109162042.gi11...@ltw.loris.tv

Re: RFC: OpenRC as Init System for Debian

[Adrian Knoth]

On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:

> I believe Debian still supports running locally compiled kernels which 
> do not depend on udev, and that some setups do not require udev either 
> (not everyone use fibre channel).

Speaking of which: there was a somewhat related comment from GregkH
yesterday:

   https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s


Money quote:

   'I seriously wonder how much longer a "general" distribution such as
Gentoo or Debian can keep up the charade of trying to provide all
options for all users.'


   'I strongly recommend tightly-coupled distros for desktops for
anyone (like Fedora or openSUSE or Ubuntu), and Debian or Gentoo only
for servers or embedded systems"'


And then, there is this statement about the core distro:

   "There are a number of folk in the Linux ecosystem pushing for a
small core of tightly coupled components to make the core of a modern
linux distro. The idea is that this “core distro” can evolve in sync
with the kernel, and generally move fast. This is both good for the
overall platform and very hard to implement for the “universal”
distros."



I thought I'd pass it along, since it mentions "Debian" multiple times.


Cheers

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120427064924.gy6...@ltw.loris.tv

Re: Node.js and it's future in debian

[Adrian Knoth]

On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote:

[nodejs's vs. hamradio's /usr/bin/node]
> In an ideal world, *neither* application would be using "node", since it's
> a very generic name

You could rename the binary in both packages and then ask the user via
debconf and/or alternatives whether to set a symlink to "node" and if
so, to which one (node-js or node-hamradio).

Within Debian, nothing should reference /usr/bin/node, but node-js or
node-hamradio. The symlink is then only required for 3rd party code.

Granted, this can still break for those who have 3rd party hamradio
scripts and 3rd party node-js stuff both referring to "node", but
that's exactly the problem you have right now.


Just my €0.02

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120428092523.gl6...@ltw.loris.tv

Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB

[Adrian Knoth]

On Wed, Jun 27, 2012 at 05:33:41PM +, The Fungi wrote:

> > what??? -v please.
> Presumably a reference to http://bugs.debian.org/674634 .

Speaking of which, I also had to disable CELT support in jackd1 and
jackd2, since none of the upstreams has opus code ready.

That said, there was this bug report saying "We'll RM celt anytime soon,
so don't use it anymore" and that's it.

We can live without it in jackd1 and jackd2, and maybe some day,
somebody will port it to opus to regain the missing functionality.

I wasn't involved in the mumble discussion, but got some complaints from
users saying they can no longer join conference calls.


Long story short: this was no transition, it was "EOL in 3, 2, 1, now".

I wasn't exactly happy about it, but at least it wasn't crucial for
jackd1/2. If there is consensus that CELT *will* be in wheezy, I'd use
the remaining time and re-enable it in jackd1/jackd2 again.


Adr"no strong feelings either way"ian

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120627180513.gt6...@ltw.loris.tv

Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB

[Adrian Knoth]

On Wed, Jun 27, 2012 at 07:47:43PM +0100, Ben Hutchings wrote:

> > That said, there was this bug report saying "We'll RM celt anytime soon,
> > so don't use it anymore" and that's it.
> Surely you were aware that CELT was experimental and this was due
> to happen?

Yep. And upstream code is cluttered with

#if CELT_0_5
#elif CELT_0_7
#else
#endif

so I appreciate the arrival of opus.

> CELT never had a stable bitstream format, so this sort of codec
> compatibility issue could occur even if all parties had some version
> of it.
> 
> It's now dead upstream, and support for any version of CELT would have
> become less and less useful during the lifetime of wheezy.

Nothing to argue with that, that's why I dropped CELT support
immediately.


Cheers

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120627185729.gw6...@ltw.loris.tv

Re: segfault error 4 in libpthread-2.13.so X86_64

[Adrian Knoth]

On 10/29/11 21:34, Dallas Clement wrote:

> Hi All,

Hi!

> I've got a multi-threaded C++ program that has been working for years
> that is segfaulting in the pthread library at exit after upgrading to

The "at exit" bit reminds me of a bug the FFADO team has been hunting
for months.

Feel free to have a rather lengthy read of

   http://subversion.ffado.org/ticket/329

If you're using custom exit functions, this might give you some
directions.

> squeeze.  It litters my kernel log with the following message:
> 
> segfault at 67eaf9d0 ip 7f4568e87d7c sp 7fff4571fe00 error 4
> in libpthread-2.13.so[7f4568e8+17000
> 
> I can produce a core file, but unfortunately I can't see the symbols
> inside the pthread lib to determine where it is crashing.

I don't think it's really something in the pthread library, but this
mailing list clearly is the wrong place to discuss.

> Is there a pthread library source package or debug version of libc /
> pthreads that I can try?

libc6-dbg?


HTH


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eac57c8.30...@drcomp.erfurt.thur.de

Re: Increasing minimum 'i386' processor

[Adrian Knoth]

On Sun, Nov 20, 2011 at 08:40:47AM +0100, Raphael Hertzog wrote:

Hi!

> > 6. DM&P/SiS Vortex86 and Vortex86SX.  These supposedly have all
> >586-class features except an FPU, and we could probably keep FPU
> >emulation for them.
> 
> FWIW, I do run Debian on such systems albeit with a custom kernel.
> Given those CPU tend to be used in an "embedded" context I guess
> it's ok if the official kernel does not support them. But it would be
> nice if Debian's userspace could be kept compatible.

On behalf of the multimedia camp, I'd like to point out that we'd love
to see SSE as the lowest common denominator on the x86 platform.

I'm fully aware that we can't, not even with i586 being the baseline.
Since many multimedia applications don't do runtime CPU detection, only
amd64 generally provides decent SIMD support to Debian users on x86
these days.


Long story short: userspace i386 compatibility would suck for
multimedia. ;)


Just my €0.02

PS: That's basically why we have packages like ardour-i686.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2020115655.gq10...@ltw.loris.tv

RFC: Realtime system (audio) group

[Adrian Knoth]

Hi!

[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]

As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.

We can call this group "rtaudio", but maybe somebody prefers a more
generic name, e.g., "realtime". Maybe there is already such a group.


WDYT?


Cheers


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1fda28.9020...@drcomp.erfurt.thur.de

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:44 PM, Bastian Blank wrote:


On Wed, Jan 25, 2012 at 11:38:18AM +, Simon McVittie wrote:

rtkit (packaged in Debian) seems a safer way to do this than
group-based privileges + setuid root.


Why does it use setuid


It doesn't use setuid root. Simon has wrongly assumed this.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1fec99.4060...@drcomp.erfurt.thur.de

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:43 PM, Bastian Blank wrote:


[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]


Why does jackd not grant _itself_ RT priority? It can grant itself
CAP_SYS_NICE, which allows arbitrary mangling of priorities.


   # setcap cap_sys_nice,cap_ipc_lock+eip /usr/bin/jackd

Works, but is hardly an improvement. It's either a stability risk (if
not limited) or:


It could still limit the usage for users with the audio group and just
drop the capability of the user is not in this group.


Which would still require the user to be part of a special group. The
audio group can't be used for this, as it would again combine "access to
sound card" and "have realtime permissions" as described in #656910.

So we're back at how to name this group. ;)


Cheers


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1ff2ea.8090...@drcomp.erfurt.thur.de

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:38 PM, Simon McVittie wrote:


As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.

rtkit (packaged in Debian) seems a safer way to do this than group-based
privileges + setuid root.


As already pointed out, there is no setuid binary.


it also has a watchdog thread with a higher priority than the rt
application itself, so it can carry out an emergency de-prioritization
on the rt application to get control back to your shell/UI if the system
becomes unresponsive.


RT CPU bandwidth is limited to 95% these days. No need for a watchdog
anymore.


If you have PolicyKit, rtkit defaults to letting you have rt priorities
if and only if you are logged in locally (gdm, kdm, getty etc., but not


Is there something like

   "If you're logged in locally, I'll grant you RT prios"?

that does not require the application to use dbus? So to say, "@local"
PAM magic or inherited from gdm/kdm/getty?

Can policykit do this? This would be a good compromise between "make it
work for the local user without messing with groups", but still leaving
enough freedom for the experienced if ssh is required.

Note that this would change the default ulimits if logged in locally.
We'd end up with every local user having RT priorities and more or less
unlimited memory locking. AFAIK, it's what OSX does, but it might
require some discussion if it's desired to have the same in Debian.



Cheers


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1ff63a.1000...@drcomp.erfurt.thur.de

Bug#623339: ITP: ardour3 -- Digital Audio Workstation

[Adrian Knoth]

Package: wnpp
Severity: wishlist
Owner: Adrian Knoth 


* Package name: ardour3
  Version : 3.0.0
  Upstream Author : Paul Davis et al. 
* URL : http://www.ardour.org/
* License : GPL
  Programming Lang: C++
  Description : Digital Audio Workstation

That's version 3.0.0 of the well-known and already packaged ardour, now 
featuring MIDI integration.

Its current release is alpha4, we're going to upload to experimental, 
first. ardour3 can be installed side-by-side with ardour, which makes 
sense given that it's not stable enough for everyday use. Hence the 
separate source package and this ITP.


-- System Information:
Debian Release: 5.0.6
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110419132214.515.47799.report...@ltw.loris.tv

Re: mplayer2 is a very poor fork name used to confuse users.

[Adrian Knoth]

On 08/19/11 05:56, compn wrote:

> mplayer2 is a very poor fork name used to confuse users.
[..]
> debian and uoti are setting themselves (and us) up for explaining to
> users which version is better.

While this is always the problem with forks, be assured you are not
alone.

There are jackd1 and jackd2, and these are just two independent
implementations of the jack API. Users think because two is lager than
one, jackd2 must be the successor of jackd1, which is wrong.

We have a FAQ on that (), maybe you want
one, too. ;)

I always say "Think of 'number two', not 'version two'. It's just an
arbitrary enumeration."


HTH


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e4e2406.2020...@drcomp.erfurt.thur.de

Re: [Pkg-netatalk-devel] Bug#685878: Another year has passed, still no netatalk3

[Adrian Knoth]

On Sun, Oct 25, 2015 at 05:33:19PM +0100, Jonas Smedegaard wrote:

[Context: http://bugs.debian.org/685878]
> > We're now more than three years behind upstream (3.0 released 
> > 2012-07-09).
> > My github repo is still waiting to be integrated with Debian.
> And my point is still that there's an RC bug not yet fixed upstream 
> which could use some help getting solved!

We need to escalate this. Apparently, none of us has time to work on it,
so external help is the only way forward I see.

Looks like we're talking about ~10 FIXMEs in debian/copyrights. This is
http://bugs.debian.org/751121.

Any takers?


Thanks.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

Bug#827840: ITP: qstopmotion -- qStopMotion is a free application for creating stop-motion animation movies

[Adrian Knoth]

Package: wnpp
Severity: wishlist
Owner: Adrian Knoth 

* Package name: qstopmotion
  Version : newer than 2.2.0
  Upstream Author : Ralf Lange 
* URL : http://www.qstopmotion.org/
* License : GPL
  Programming Lang: C++
  Description : qStopMotion is a free application for creating stop-motion 
animation movies

Copy&paste from the website:

"qStopMotion is a free application for creating stop-motion animation movies.
The users will be able to create stop-motions from pictures imported from a
camera or from the harddrive and export the animation to different video
formats such as mpeg or avi."

We're going to maintain this inside pkg-multimedia-maintainers.

qStopMotion-2.2.0 (newest as of 2016-06-21) is still based on gstreamer0.10, but
upstream has indicated to get rid of it until August. We'll hold off packaging
anything until then.

Other technology involved:
  * Qt5
  * V4L (Video4Linux)
  * cmake