Government satellites recorded Dirk Hartmann saying:
> Hello,
>
> i want to record some old records but i don't get an input signal. With my
> Win98 partition sound recording works. Furthermore i can *play* any sound
> with Debian Linux.


>
> Kmix


Is aRTS and ALSA "running"? Kill aRTS and test.

>
> I gues the Alsa module causes the problem. But I couldn't find a hint in the
> man pages, e.g. for an option when compiling the module.

Change the[*] to [M] in the kernel. Be certain to unload your ALSA
stuff if local.rc, or whatever, is loading ALSA.

--
sk8r-365

http://goodbye-microsoft.com/

Hello and thanks a lot for your answer,

> Is aRTS and ALSA "running"? Kill aRTS and test.
I did. Both are running.

Output of "ps xa | grep arts": 0:04 artsd -F 10 -S 4096 -d -b 16 -s 60 -m
artsmessage -c drkonqi -l 3 -f

lsmod says that all alsa modules are loaded. More alsa stuff should't be
necessary, right?
snd-emu10k1 77284 1
snd-pcm 66852 0 [snd-emu10k1]
snd-timer 16100 0 [snd-pcm]
snd-rawmidi 14592 0 [snd-emu10k1]
snd-ac97-codec 49036 0 [snd-emu10k1]
snd-util-mem 1616 0 [snd-emu10k1]
snd-page-alloc 7252 0 [snd-emu10k1 snd-pcm]
snd-hwdep 5284 0 [snd-emu10k1]
snd-seq-device 4436 0 [snd-emu10k1 snd-rawmidi]
snd 35044 1 [snd-emu10k1 snd-pcm snd-timer snd-rawmidi
snd-ac97-codec snd-util-mem snd-hwdep snd-seq-device]
soundcore 4260 4 [snd]
emu10k1-gp 1416 0 (unused)

>> I gues the Alsa module causes the problem. But I couldn't find a hint in
>> the man pages, e.g. for an option when compiling the module.

> Change the[*] to [M] in the kernel. Be certain to unload your ALSA
> stuff if local.rc, or whatever, is loading ALSA.

As I wrote I use kernelversion 2.4 which offers no Alsa module, this
started with kernel 2.5.5. That's why I compiled the module. According to
cat /proc/asound/devices the neccessary devices have been created. And at
least playing sound works. The docs and manuals told me nothing about
additional flags which have to be set in order to record sound.

BTW: I first tried recording with gramofile. Because of the known problem I
used Krec. It's manuals stated that Arts Audio Manager has to show Krec:in
and Krecut as two necessary entries. It does.

Hope you got an inspiration. I ran out of ideas and manuals to read.

Best regards
--
Dirk Hartmann
Remove _nospam from my mail adress because of spam protection

Government satellites recorded Dirk Hartmann saying:
> Hello and thanks a lot for your answer,
>
>> Is aRTS and ALSA "running"? Kill aRTS and test.
> I did. Both are running.


Does this mean you turned off aRTS and tried it?

--
sk8r-365

http://goodbye-microsoft.com/

Problem solved. Kmix doesn't show the necessary mixer channel, don't know
why. Alsamixer does: I just had to turn on Capture-Analog Mix. Things can
be so easy sometimes. Hope this helps somebody who faces the same problem.
--
Dirk Hartmann
Remove _nospam from my mail adress because of spam protection

On Aug 25, 11:35 pm, Dirk Hartmann wrote:
> Problem solved. Kmix doesn't show the necessary mixer channel, don't know
> why. Alsamixer does: I just had to turn on Capture-Analog Mix. Things can
> be so easy sometimes. Hope this helps somebody who faces the same problem.

Good to here that you solved the problem, and that you reported back.

But do you really run Debian/Stable with Linux 2.4 kernel?
I though that Debain/Stable (Debian/Etch that is) don't supported
Linux 2.4 kernel any more, only 2.6.

AJackson wrote:

>> > oldstable == previous release (currently sarge)
>> > stable == current release (currently etch)
>> > testing == next release (currently lenny)
>> > unstable == always unstable (always sid)
>>
>> > Packages are uploaded to unstable and, after a while, appear in
>> > testing, replacing older versions (subject to dependencies and security
>> > bugs). Security updates are done for oldstable (for a while), stable
>> > and testing.
>>
>> This answers my question. The difference between stable/testing/unstable
>> should be clear for any Debian user (mixing it causes trouble e.g. when
>> forcing apt-get -f). In my opinion Debian is build for easy
>> administration of the distribution.
>> Background: To have a clean Debian I use pinning (generally i use apt-get
>> -ut stable to install a new program). My sources list includes only sarge
>> repositories. And my /etc/apt/preferences is accommodated as follows
>>
>> Package: *
>> Pin: release a=stable
>> Pin-Priority: 500
>>
>> Package: *
>> Pin: release a=testing
>> Pin-Priority: 400
>>
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 50
>>
>> That's why I insisted on the definition. And old stable (sarge) vs stable
>> (etch) sounds reasonable. Also that one has to keep in mind in the moment
>> that the latest testing version ist sid (and sarge unstable is only for
>> strange experiments)
>
> Sorry, if you pin at stable, you use Etch now, mixed with old packages
> from Sarge.
> This is not a good situation(tm)
>
> There is only one Woddy, only one Sarge, only one Etch and only one
> Lenny. If you want to be in control when you go between them, you
> should pin at those names, not stable, testing or unstable. If you
> pin at stable, you will always get latest stable. So when they
> released Ech, you was starting to pull packages from Etch instead of
> Sarge.
>
> If those name confuse you, use debian version numbers instead.
> Testing and Unstable never have version numbers.
> So when Debian releases a new version, the old releases gets bumped
> off.
>
> So when Woddy was stabel, Sarge was testing.
> When Sarge went stabel, Etch was new testing. Woody's support was
> dropped after some months
> When Etch went stabel, Lenny is new testing. Sarge's support is
> beeing dropped in some months
>
> So. When a releas gets stabel, it will never change (except for
> security updates).
> So Sarge is no longer stabel, it's an old release that you can install
> if you feal like running old software. All distributions are
> archived, and need to be some 10 years, I think (some licensies demand
> this).

Hello,
at least this should be a new thread about managing distributions. My
opinion is:
I DON'T mix the distributions as mentioned before. In my sources list I only
have entries for sarge (e.g. deb-src http://ftp.de.debian.org/debian sarge
main). So any apt-get update only considers sarge. And my pinning
preferences guarantee that I am able to decide whether to install
stable/testing/unstable. So with apt-get -ut stable I get sarge stable.
1) Is this correct?
2) Is this a the best system management? Or am I totally wrong?

I assume the other policy would be as I read in a manual:
1) Changing the sources list entries from deb-src
http://ftp.de.debian.org/debian sarge main to deb-src
http://ftp.de.debian.org/debian *stable* main
This makes sure that any time a new distribution is released I get a up to
date stable release. This sounds good. But I preferred the recent years to
keep sarge stable because my computer is old and some features like the
graphical interface are optimized for faster machines (I know this from
friend with older machines which slowed down after upgrading).

To summarize: Is my procedure (the mix of sources list with entries only for
sarge and my pinning-preferences) OK for people who do not want to change a
successful running system?
Or does it contradict to debian philosophy and furthermore causes
conflicts? I didn't experience this and I still guess my way is the best
way for a home user who sees some advantages in using an older stable
version (in a LAN one should surely guarantee to use the latest stable).
But I'm really willing to learn.

Thanks for your patience and your helpful statements.

Best regards
--
Dirk Hartmann
Remove _nospam from my mail adress because of spam protection

Dirk Hartmann writes:
>AJackson wrote:
[Someone wrote:]
>>> Package: *
>>> Pin: release a=stable
>>> Pin-Priority: 500
>>>
>>> Package: *
>>> Pin: release a=testing
>>> Pin-Priority: 400
>>>
>>> Package: *
>>> Pin: release a=unstable
>>> Pin-Priority: 50
....
>> There is only one Woddy, only one Sarge, only one Etch and only one
>> Lenny. If you want to be in control when you go between them, you
>> should pin at those names, not stable, testing or unstable.

Yes, that would be a good idea, and I would do it if it worked. But
in my experience it does not in preferences (and the failure is
silent, it just installs the packages from the wrong track:-(). It
does work in sources.list.

>Hello,
>at least this should be a new thread about managing distributions. My
>opinion is:
>I DON'T mix the distributions as mentioned before. In my sources list I only
>have entries for sarge (e.g. deb-src http://ftp.de.debian.org/debian sarge
>main). So any apt-get update only considers sarge. And my pinning
>preferences guarantee that I am able to decide whether to install
>stable/testing/unstable. So with apt-get -ut stable I get sarge stable.
>1) Is this correct?

No. If you only have sarge (now oldstable) on your sources.list, you
only get sarge no matter what your preferences say. So, if you only
want to install from one track, you can just put that track and no
other in the sources.list and you don't need preferences. Preferences
are for deciding between versions of the same package for different
tracks.

>I assume the other policy would be as I read in a manual:
>1) Changing the sources list entries from deb-src
>http://ftp.de.debian.org/debian sarge main to deb-src
>http://ftp.de.debian.org/debian *stable* main
>This makes sure that any time a new distribution is released I get a up to
>date stable release. This sounds good.

Only if you want the Debian release managers to determine when you
upgrade your machine.

>To summarize: Is my procedure (the mix of sources list with entries only for
>sarge and my pinning-preferences) OK for people who do not want to change a
>successful running system?

Yes. Note that Sarge security upgrades will cease at some time, and
the download sites for it will go away at some time.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

On Sun, 14 Oct 2007 13:10:49 +0000, Anton Ertl wrote:

> Dirk Hartmann writes:
>>AJackson wrote:
> [Someone wrote:]
>>>> Package: *
>>>> Pin: release a=stable
>>>> Pin-Priority: 500
>>>>
>>>> Package: *
>>>> Pin: release a=testing
>>>> Pin-Priority: 400
>>>>
>>>> Package: *
>>>> Pin: release a=unstable
>>>> Pin-Priority: 50
> ...
>>> There is only one Woddy, only one Sarge, only one Etch and only one
>>> Lenny. If you want to be in control when you go between them, you
>>> should pin at those names, not stable, testing or unstable.
>
> Yes, that would be a good idea, and I would do it if it worked. But in
> my experience it does not in preferences (and the failure is silent, it
> just installs the packages from the wrong track:-(). It does work in
> sources.list.
>
>

Anton, in the preferences file, instead of using a=foo, have you tried
using v=foo? The version number rather than the archive name. Example for
the case currently being discussed in which the desired version is sarge,
v=3.1

Package: *
Pin: release v=3.1
Pin-Priority: (whatever priority you want to assign)

Rodney writes:
>On Sun, 14 Oct 2007 13:10:49 +0000, Anton Ertl wrote:
>
>> Dirk Hartmann writes:
>>>AJackson wrote:
>>>> There is only one Woddy, only one Sarge, only one Etch and only one
>>>> Lenny. If you want to be in control when you go between them, you
>>>> should pin at those names, not stable, testing or unstable.
>>
>> Yes, that would be a good idea, and I would do it if it worked. But in
>> my experience it does not in preferences (and the failure is silent, it
>> just installs the packages from the wrong track:-(). It does work in
>> sources.list.
>>
>>
>
>Anton, in the preferences file, instead of using a=foo, have you tried
>using v=foo?

Now I have.

> The version number rather than the archive name. Example for
>the case currently being discussed in which the desired version is sarge,
>v=3.1
>
>Package: *
>Pin: release v=3.1
>Pin-Priority: (whatever priority you want to assign)

I have tried this on one machine, but this time all of the following
produced the same results:

Pin: release v=4.0
Pin: release a=stable
Pin: release a=etch

In the case that I mentioned above, the second variant worked
correctly, but the third variant did work differently and not as I
expected (without warning).

Anyway, thanks for the pointer.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

On Mon, 15 Oct 2007 19:50:43 +0000, Anton Ertl wrote:

> Rodney writes:
>>On Sun, 14 Oct 2007 13:10:49 +0000, Anton Ertl wrote:
>>
>>> Dirk Hartmann writes:
>>>>AJackson wrote:
>>>>> There is only one Woddy, only one Sarge, only one Etch and only one
>>>>> Lenny. If you want to be in control when you go between them, you
>>>>> should pin at those names, not stable, testing or unstable.
>>>
>>> Yes, that would be a good idea, and I would do it if it worked. But in
>>> my experience it does not in preferences (and the failure is silent, it
>>> just installs the packages from the wrong track:-(). It does work in
>>> sources.list.
>>>
>>>
>>>
>>Anton, in the preferences file, instead of using a=foo, have you tried
>>using v=foo?
>
> Now I have.
>
>> The version number rather than the archive name. Example for
>>the case currently being discussed in which the desired version is sarge,
>>v=3.1
>>
>>Package: *
>>Pin: release v=3.1
>>Pin-Priority: (whatever priority you want to assign)
>
> I have tried this on one machine, but this time all of the following
> produced the same results:
>
> Pin: release v=4.0
> Pin: release a=stable
> Pin: release a=etch
>
> In the case that I mentioned above, the second variant worked correctly,
> but the third variant did work differently and not as I expected (without
> warning).
>

Well, sarge is the release we were talking about, yet you tested with
etch. My experience with sarge is also what you described, the third
variant did not give expected results but the first did. From your
current test, my guess would be that it has been corrected in etch.
Debian keeps getting better all the time. :-)

>>I DON'T mix the distributions as mentioned before. In my sources list I
>>only have entries for sarge (e.g. deb-src http://ftp.de.debian.org/debian
>>sarge main). So any apt-get update only considers sarge. And my pinning
>>preferences guarantee that I am able to decide whether to install
>>stable/testing/unstable. So with apt-get -ut stable I get sarge stable.
>>1) Is this correct?
Anton Ertl wrote:
>
> No. If you only have sarge (now oldstable) on your sources.list, you
> only get sarge no matter what your preferences say. So, if you only
> want to install from one track, you can just put that track and no
> other in the sources.list and you don't need preferences. Preferences
> are for deciding between versions of the same package for different
> tracks.
>
>>I assume the other policy would be as I read in a manual:
>>1) Changing the sources list entries from deb-src
>>http://ftp.de.debian.org/debian sarge main to deb-src
>>http://ftp.de.debian.org/debian *stable* main
>>This makes sure that any time a new distribution is released I get a up to
>>date stable release. This sounds good.
>
> Only if you want the Debian release managers to determine when you
> upgrade your machine.
>
>>To summarize: Is my procedure (the mix of sources list with entries only
>>for sarge and my pinning-preferences) OK for people who do not want to
>>change a successful running system?
>
> Yes. Note that Sarge security upgrades will cease at some time, and
> the download sites for it will go away at some time.
>
> - anton
Hello,

now everything is clear. I misunderstood pinning: I thought it is helpful to
manage stable/testing/unstable/within a distribution. I was wrong. So for
my update policy it is reasonable:
1) I forget about pinning. After I did my update to etch in the next days I
probably won't need testing/unstable stuff from lenny (I guess this is more
interesting if one needs special applications or libraries). So pinning is
unnecessary and too complicated for my needs.
2) I keep my sources list as before. So my next one will only contain etch
repositories. And apt-get install will always install etch stable as it
should.

Thanks for enlighten me :-)
--
Dirk Hartmann
Remove _nospam from my mail adress because of spam protection

Rodney writes:
>On Mon, 15 Oct 2007 19:50:43 +0000, Anton Ertl wrote:
>
>> Rodney writes:
>>>Anton, in the preferences file, instead of using a=foo, have you tried
>>>using v=foo?
>>
>> Now I have.
>>
>>> The version number rather than the archive name. Example for
>>>the case currently being discussed in which the desired version is sarge,
>>>v=3.1
>>>
>>>Package: *
>>>Pin: release v=3.1
>>>Pin-Priority: (whatever priority you want to assign)
>>
>> I have tried this on one machine, but this time all of the following
>> produced the same results:
>>
>> Pin: release v=4.0
>> Pin: release a=stable
>> Pin: release a=etch
>>
>> In the case that I mentioned above, the second variant worked correctly,
>> but the third variant did work differently and not as I expected (without
>> warning).
>>
>
>Well, sarge is the release we were talking about, yet you tested with
>etch. My experience with sarge is also what you described, the third
>variant did not give expected results but the first did. From your
>current test, my guess would be that it has been corrected in etch.
>Debian keeps getting better all the time. :-)

Yes, I tested this on an Etch machine yesterday (I did not remember on
which machine I had noticed the problem). I have now also tried it on
a Sarge machine. There using the third variant did not work as
expected, but neither did the following:

Package: *
Pin: release v=3.1
Pin-Priority: 500

Package: *
Pin: release v=4.0
Pin-Priority: 100

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: *
Pin: release a=experimental
Pin-Priority: 49

However, once I changed the 4.0 into 4.0r1, it worked as expected.
So, v=... is not really the permanent solution, either:-( Thanks
anyway.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

On Tue, 16 Oct 2007 18:55:53 +0000, Anton Ertl wrote:

> Rodney writes:
>>On Mon, 15 Oct 2007 19:50:43 +0000, Anton Ertl wrote:
>>
>>> Rodney writes:
>>>>Anton, in the preferences file, instead of using a=foo, have you tried
>>>>using v=foo?
>>>
>>> Now I have.
>>>
>>>> The version number rather than the archive name. Example for
>>>>the case currently being discussed in which the desired version is
>>>>sarge, v=3.1
>>>>
>>>>Package: *
>>>>Pin: release v=3.1
>>>>Pin-Priority: (whatever priority you want to assign)
>>>
>>> I have tried this on one machine, but this time all of the following
>>> produced the same results:
>>>
>>> Pin: release v=4.0
>>> Pin: release a=stable
>>> Pin: release a=etch
>>>
>>> In the case that I mentioned above, the second variant worked
>>> correctly, but the third variant did work differently and not as I
>>> expected (without warning).
>>>
>>>
>>Well, sarge is the release we were talking about, yet you tested with
>>etch. My experience with sarge is also what you described, the third
>>variant did not give expected results but the first did. From your
>>current test, my guess would be that it has been corrected in etch.
>>Debian keeps getting better all the time. :-)
>
> Yes, I tested this on an Etch machine yesterday (I did not remember on
> which machine I had noticed the problem). I have now also tried it on a
> Sarge machine. There using the third variant did not work as expected,
> but neither did the following:
>
> Package: *
> Pin: release v=3.1
> Pin-Priority: 500
>
> Package: *
> Pin: release v=4.0
> Pin-Priority: 100
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 50
>
> Package: *
> Pin: release a=experimental
> Pin-Priority: 49
>
> However, once I changed the 4.0 into 4.0r1, it worked as expected. So,
> v=... is not really the permanent solution, either:-( Thanks anyway.
>
> - anton

Huh? You say you did this on a sarge machine? ...and changing to 4.0rc1
worked? Sarge is 3.1, so I'm not sure what you are trying to test or what
method you've used. If you use the correct priority (for the release you
desire, perhaps higher than 500) and correct v, it does work on sarge when
you also have etch repositories in the sources list. However sarge is the
next release to be archived and lose support so most people will be
upgrading, not much need to follow up on this. Whatever works for you,
that's enough for this topic.

Rodney writes:
>On Tue, 16 Oct 2007 18:55:53 +0000, Anton Ertl wrote:
>> Yes, I tested this on an Etch machine yesterday (I did not remember on
>> which machine I had noticed the problem). I have now also tried it on a
>> Sarge machine. There using the third variant did not work as expected,
>> but neither did the following:
>>
>> Package: *
>> Pin: release v=3.1
>> Pin-Priority: 500
>>
>> Package: *
>> Pin: release v=4.0
>> Pin-Priority: 100
>>
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 50
>>
>> Package: *
>> Pin: release a=experimental
>> Pin-Priority: 49
>>
>> However, once I changed the 4.0 into 4.0r1, it worked as expected. So,
>> v=... is not really the permanent solution, either:-( Thanks anyway.
>>
>> - anton
>
>Huh? You say you did this on a sarge machine? ...and changing to 4.0rc1
>worked? Sarge is 3.1, so I'm not sure what you are trying to test or what
>method you've used.

The preferences file shown above did not work as expected, but the
preferences file shown below did:

Package: *
Pin: release v=3.1
Pin-Priority: 500

Package: *
Pin: release v=4.0r1
Pin-Priority: 100

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: *
Pin: release a=experimental
Pin-Priority: 49

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html