Sound recordings fails - Debian

This is a discussion on Sound recordings fails - Debian ; 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. System: Debian Sarge stable Kernelversion 2.4 (This means with ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Sound recordings fails

  1. Sound recordings fails

    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.

    System:
    Debian Sarge stable
    Kernelversion 2.4 (This means with no native Alsa support)
    alsa-driver-1.0.2 compiled by myself
    Sound Blaster Audigy whith module emu10k1

    cat /proc/asound/devices
    0: [0- 0]: ctl
    4: [0- 0]: hardware dependent
    9: [0- 1]: raw midi
    8: [0- 0]: raw midi
    19: [0- 3]: digital audio playback
    26: [0- 2]: digital audio capture
    25: [0- 1]: digital audio capture
    16: [0- 0]: digital audio playback
    24: [0- 0]: digital audio capture
    1: : sequencer
    6: [0- 2]: hardware dependent
    10: [0- 2]: raw midi
    11: [0- 3]: raw midi
    33: : timer

    cat /proc/asound/cards
    0 [Audigy ]: Audigy - Sound Blaster Audigy
    Sound Blaster Audigy (rev.3) at 0xd400, irq 10

    Full duplex is active

    So in my opinion everything looks good. But the mixer Kmix seems to have a
    problem:
    First of all in the card "output" i got "Input" and "Input2". Input shows a
    green LED. According to a manual there has to be a red LED too. It doesn't
    show. With a right mouseclick I controlled whether all channels are
    checked. They are.
    Second: The card Input shows nothing. The right mousecklick offers no
    options for showing channels.

    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.

    Thanks in advance for any help or a proposal for a suitable newsgroup. Have
    a nice day.
    --
    Dirk Hartmann
    Remove _nospam from my mail adress because of spam protection

  2. Re: Sound recordings fails

    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/

  3. Re: Sound recordings fails

    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

  4. Re: Sound recordings fails

    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/

  5. Re: Sound recordings fails - solved

    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

  6. Re: Sound recordings fails - solved

    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.


  7. Re: Sound recordings fails - solved

    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

  8. apt and track pinning (was: Sound recordings fails - solved)

    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

  9. Re: apt and track pinning (was: Sound recordings fails - solved)

    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)

  10. Re: apt and track pinning (was: Sound recordings fails - solved)

    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

  11. Re: apt and track pinning (was: Sound recordings fails - solved)

    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. :-)



  12. Re: apt and track pinning (was: Sound recordings fails - solved)

    >>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

  13. Re: apt and track pinning (was: Sound recordings fails - solved)

    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

  14. Re: apt and track pinning (was: Sound recordings fails - solved)

    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.


  15. Re: apt and track pinning (was: Sound recordings fails - solved)

    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

+ Reply to Thread