Re: [gentoo-user] Ladspa plugins installed twice (multilib)

2018-04-19 Thread Lasse Pouru
Neil Bothwick <n...@digimed.co.uk> writes:

> On Thu, 19 Apr 2018 10:54:14 +0300, Lasse Pouru wrote:
>
>> I can't seem to get rid of the 32-bit versions of ladspa plugins. Even
>> with the -abi_x86_32 flag set for the packages in question (ladspa-cmt,
>> ladspa-sdk, swh-plugins, tap-plugins) both versions get installed (under
>> /usr/lib/ladspa and /usr/lib64/ladspa).
>
> /usr/lib is usually a symlink to /usr/lib/64 so you may have only one set
> of plugins but the software is seeing them twice. Can you change the
> patchs it look in? Or you could try the 17.1 profile, which removes this
> symlink - read the news item first.

Oh, I see. Switching to 17.1 seems like something I'd rather not do
right now. In Audacity it should be possible to manually disable all the
duplicates but for LMMS there doesn't seem to be such an option.



[gentoo-user] Ladspa plugins installed twice (multilib)

2018-04-19 Thread Lasse Pouru
I can't seem to get rid of the 32-bit versions of ladspa plugins. Even
with the -abi_x86_32 flag set for the packages in question (ladspa-cmt,
ladspa-sdk, swh-plugins, tap-plugins) both versions get installed (under
/usr/lib/ladspa and /usr/lib64/ladspa). This is an annoyance because
every plugins shows up twice in Audacity. I also have a similar issue
with LMMS, every instrument is listed twice. (I don't know which
package(s) these instruments come from.)

I have ABI_X86 set to "32 64" in make.conf, does this override the
-abi_x86_32 use flag?

- Lasse



Re: [gentoo-user] Brother Printer AMD64

2018-03-12 Thread Lasse Pouru
Mick  writes:

> On Monday, 12 March 2018 15:29:28 GMT Nils Freydank wrote:
>> Hi,
>> 
>> Am Montag, 12. März 2018, 13:54:18 CET schrieb siefke_lis...@web.de:
>> > Hello,
>> > 
>> > I have a short question. Is it true that Brother Printer Drivers need
>> > a multilib System?
>> 
>> unfortunately yes. Maybe specific drivers will work with no-multilib, but
>> most ones will compile and install and then silently fail due to some
>> missing 32bit userspace libs they need etc.
>> 
>> > https://github.com/stefan-langenmaier/brother-overlay
>> > 
>> > I found this overlay and it seem so that gcc without multilib not work.
>> > 
>> > Is there a way to build the printer system as 32 bit, or does the whole
>> > system have to be built accordingly?
>> 
>> You can try to setup a chroot or container (e.g. with LXC/LXD or systemd-
>> nspawn) for it, but I these would contain a small 32bit system, too.
>> 
>> > Thank you & Nice Day
>> > Silvio
>> 
>> I hope I could help a bit,
>> Nils
>
> I can confirm this.  When I tried to install net-print/brother-hl3140cw-bin 
> from the brother overlay on a amd64 no-multilib system it failed.
>
> I have not tried to install the same driver on a 32bit system, but could give 
> it a go one of these days if it helps.

I guess if you only need multilib for this one package it would be
possible to compile it and its dependencies with the abi_x86_32 USE flag
instead of setting the ABI_X86 variable for the whole system?

- Lasse



Re: [gentoo-user] [off-topic] Ripping "enhanced" CDs with abcde/cdparanoia

2018-03-04 Thread Lasse Pouru
Lasse Pouru <lasse.po...@edu.turkuamk.fi> writes:

> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at
> http://aka.ms/LearnAboutSpoofing]
>
> Floyd Anderson <f...@31c0.net> writes:
>
>> On Sun, 04 Mar 2018 14:01:00 +0200
>> Lasse Pouru <lasse.po...@edu.turkuamk.fi> wrote:
>>>You know, the ones with video or software tracks shoehorned into the
>>>end. Whenever I try to rip one with abcde I get the error "selected span
>>>contains non audio track at track X", even when I've chosen a range not
>>>containing track X (e.g. abcde 1-11, 12 being the non-audio track). Grip
>>>rips the same CDs just fine, but I'd prefer to use a command-line
>>>tool. I'm using cdparanoia with both abcde and grip, so is this a bug in
>>>abcde or am I doing something wrong?
>>>
>>
>> That error message seems to come from dev-libs/libcdio-paranoia [1],
>> so you have to ensure that abcde invokes cdparanoia (I assume it’s a
>> symlink to /usr/bin/libcdio-paranoia) with the intended track
>> range/span by looking at the forced debug or verbose output.
>>
>> Or maybe simpler, invoke cdparanoia directly to see which one of the
>> involved parts (wrapper/program) to blame – if your given range/span
>> really contains only audio tracks.
>>
>>
>> References:
>>   - [1] 
>> <https://github.com/rocky/libcdio-paranoia/blob/b63fec7/src/cd-paranoia.c#L1199>
>
> Same error when invoking cdparanoia directly. It seems grip includes its
> own version of cdparanoia since it has two cdparanoia options, "grip
> (cdparanoia)" and just "cdparanoia". The first on works, the latter
> doesn't.
>
> I'll try installing the unstable version of libcdio-paranoia in case
> this is a bug that has recently been fixed.

Ok, upgrading libcdio-paranoia and libcdio to unstable versions solved
the problem. It's not even necessary to specify the range when running
abcde, the non-audio tracks are automatically left out.



Re: [gentoo-user] [off-topic] Ripping "enhanced" CDs with abcde/cdparanoia

2018-03-04 Thread Lasse Pouru
Floyd Anderson <f...@31c0.net> writes:

> On Sun, 04 Mar 2018 14:01:00 +0200
> Lasse Pouru <lasse.po...@edu.turkuamk.fi> wrote:
>>You know, the ones with video or software tracks shoehorned into the
>>end. Whenever I try to rip one with abcde I get the error "selected span
>>contains non audio track at track X", even when I've chosen a range not
>>containing track X (e.g. abcde 1-11, 12 being the non-audio track). Grip
>>rips the same CDs just fine, but I'd prefer to use a command-line
>>tool. I'm using cdparanoia with both abcde and grip, so is this a bug in
>>abcde or am I doing something wrong?
>>
>
> That error message seems to come from dev-libs/libcdio-paranoia [1],
> so you have to ensure that abcde invokes cdparanoia (I assume it’s a
> symlink to /usr/bin/libcdio-paranoia) with the intended track
> range/span by looking at the forced debug or verbose output.
>
> Or maybe simpler, invoke cdparanoia directly to see which one of the
> involved parts (wrapper/program) to blame – if your given range/span
> really contains only audio tracks.
>
>
> References:
>   - [1] 
> <https://github.com/rocky/libcdio-paranoia/blob/b63fec7/src/cd-paranoia.c#L1199>

Same error when invoking cdparanoia directly. It seems grip includes its
own version of cdparanoia since it has two cdparanoia options, "grip
(cdparanoia)" and just "cdparanoia". The first on works, the latter
doesn't.

I'll try installing the unstable version of libcdio-paranoia in case
this is a bug that has recently been fixed.




[gentoo-user] [off-topic] Ripping "enhanced" CDs with abcde/cdparanoia

2018-03-04 Thread Lasse Pouru
You know, the ones with video or software tracks shoehorned into the
end. Whenever I try to rip one with abcde I get the error "selected span
contains non audio track at track X", even when I've chosen a range not
containing track X (e.g. abcde 1-11, 12 being the non-audio track). Grip
rips the same CDs just fine, but I'd prefer to use a command-line
tool. I'm using cdparanoia with both abcde and grip, so is this a bug in
abcde or am I doing something wrong?



Re: [gentoo-user] Basic questions about Distcc

2017-11-03 Thread Lasse Pouru
Wol's lists <antli...@youngman.org.uk> writes:

> On 03/11/17 16:54, Lasse Pouru wrote:
>> I have a bunch of old laptops that large builds such as texlive and
>> ghc fail on, I'm assuming because of insufficient memory and disk
>> space. If I've understood correctly, with Distcc I could build
>> everything on my main desktop PC and have the binaries transferred
>> through network? How does this work, exactly, and is it a lot of
>> work to set up? I currently have no networking devices besides a
>> single modem/router, would something more be required?
>>
> No. What distcc does is spread compilation across multiple machines to
> save time, so if it blows up on those machine currently, there's no
> guarantee it won't blow up with distcc.
>
> What I do is make sure my flags and stuff match across all machines,
> then compile using the -bk flags (I can't remember which says "create
> binary if it doesn't exist" and which is "use binary if it
> exists"). That way, it builds on the machine that works, and uses the
> binary on the machines that don't.
>
> Oh - and it's definitely possible you've got dodgy ram. I gather it's
> not uncommon for ram to work perfectly until gcc stresses it on a big
> build at which point everything comes crashing down ...
>
> Cheers,
> Wol

So the flags would have to be the same on all machines? What about the
CPU architecture? Isn't there a way to cross-compile for a 32-bit
machine (with minimal flags) on a 64-bit machine, and specify which
machine to do the compiling on?



[gentoo-user] Basic questions about Distcc

2017-11-03 Thread Lasse Pouru
I have a bunch of old laptops that large builds such as texlive and ghc fail 
on, I'm assuming because of insufficient memory and disk space. If I've 
understood correctly, with Distcc I could build everything on my main desktop 
PC and have the binaries transferred through network? How does this work, 
exactly, and is it a lot of work to set up? I currently have no networking 
devices besides a single modem/router, would something more be required?

- Lasse



Re: [gentoo-user] Pure Data (Pd) can't access ALSA device

2017-09-22 Thread Lasse Pouru
I don't (and won't) use PulseAudio and haven't set up dmix or anything
like it. The weird thing is the simultaneous audio works with every
other program I use (Qutebrowser, mpd, Audacity etc.) -- it's only Pd
that gives the error.

I already use JACK when recording but it would be more convenient for me
to use ALSA when I'm just quickly trying out stuff. (I've set up JACK to
use an audio interface I don't have plugged in most of the time.)

- Lasse

Daniel Sonck <dan...@sonck.nl> writes:

> This sounds pretty normal to me. ALSA isn't really suited for simultaneous 
> audio access. In general with ALSA you have only one program that can use 
> audio at a time, or you use the mixer module from ALSA. I assume a program 
> running on the background has claimed ALSA already for certain reasons. 
>
> If you run PulseAudio (which is pretty standard on a regular desktop), this 
> one will be the cullprit. Usually the jack tools are smart enough to suspend 
> pulseaudio. You can in fact run puredata through the pasuspend script which 
> suspends pulseaudio so ALSA is free again.
>
> What I recommend (which you already tried) is using JACK. JACK will take 
> ownership of your ALSA device, and gives you a capable routing system 
> allowing 
> you to hook up more than just PureData to your audio card. Optionally routing 
> it to other software. In addition, it's possible to compile pulseaudio with 
> jack support which means you can in fact have regular (non-audio) apps work 
> together with jack, which is what I sometimes use: Set up my audio studio 
> setup, while still having pulseaudio around for stuff like browsers and video 
> players. If I suddenly have a creative spark, I have my studio ready to play 
> with. When I'm done, browsers still work with sound
>
> Daniel
>
> On vrijdag 22 september 2017 18:23:10 CEST Lasse Pouru wrote:
>> I can't get Pure Data to work with ALSA. It detects my sound card, but
>> whenever I try to turn on the audio I get the error:
>> 
>> ALSA output error (snd_pcm_open): Device or resource busy.
>> 
>> I've tried both using the ebuild from the audio-overlay and compiling
>> from the source on the Pd website, both behave the same. I've read that
>> Pd deals with ALSA differently than most other programs, but haven't
>> found an explanation how. I did get it to work with JACK.
>> 
>> - Lasse



[gentoo-user] Pure Data (Pd) can't access ALSA device

2017-09-22 Thread Lasse Pouru
I can't get Pure Data to work with ALSA. It detects my sound card, but
whenever I try to turn on the audio I get the error:

ALSA output error (snd_pcm_open): Device or resource busy.

I've tried both using the ebuild from the audio-overlay and compiling
from the source on the Pd website, both behave the same. I've read that
Pd deals with ALSA differently than most other programs, but haven't
found an explanation how. I did get it to work with JACK.

- Lasse



[gentoo-user] texlive-core dependency conflict

2017-06-17 Thread Lasse Pouru
Any way to get around this? I've already tried removing both the cjk and
xetex USE flags, running emerge -c, unmerging and remerging texlive-core
etc. I do actually want both the cjk and the xetex packages installed,
and this seems to be mostly an aesthetic issue since the version of
texlive-core I have installed is the latest (2016-r5).

I guess I'm really just wondering if my LaTeX installation is messed up
somehow and if there's something I could do to prevent errors like this
in the future.

Here's the error message:

WARNING: One or more updates/rebuilds have been skipped due to a
dependency conflict:

app-text/texlive-core:0

  (app-text/texlive-core-2016-r5:0/0::gentoo, ebuild scheduled for
  merge) conflicts with   
>=app-text/texlive-core-2010[cjk] required by
 ^^^ 
  (dev-texlive/texlive-langcjk-2016:0/0::gentoo, installed)
  
>=app-text/texlive-core-2010[xetex] required by
 ^
  (dev-texlive/texlive-xetex-2016:0/0::gentoo, installed)

- Lasse