Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #160093 > unrolled thread

where does unstable appear from?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  where does unstable appear from? Andrey Rybak <rybak.andrey@yahoo.com> - 2015-11-02 11:30 +0100
    Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-02 11:40 +0100
      Re: where does unstable appear from? Andrey Rybak <rybak.andrey@yahoo.com> - 2015-11-02 12:10 +0100
        Re: where does unstable appear from? Brian <ad44@cityscape.co.uk> - 2015-11-02 12:40 +0100
        Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-02 12:50 +0100
          Re: where does unstable appear from? Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-03 05:20 +0100
            Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-03 10:10 +0100
              Re: where does unstable appear from? The Wanderer <wanderer@fastmail.fm> - 2015-11-03 15:10 +0100
                Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-03 15:50 +0100
                  Re: where does unstable appear from? The Wanderer <wanderer@fastmail.fm> - 2015-11-03 16:30 +0100
                    Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-03 17:00 +0100
                  Re: where does unstable appear from? Joe <joe@jretrading.com> - 2015-11-03 20:50 +0100
                    Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-03 21:10 +0100
                Re: where does unstable appear from? Sven Arvidsson <sa@whiz.se> - 2015-11-03 16:10 +0100
            Re: where does unstable appear from? Alex Moonshine <moonshine@openmailbox.org> - 2015-11-03 10:20 +0100
    Re: where does unstable appear from? Brad Rogers <brad@fineby.me.uk> - 2015-11-02 12:00 +0100

#160093 — where does unstable appear from?

[Multipart message — attachments visible in raw view] — view raw

Thats my sources list:
# less /etc/apt/sources.list
deb http://ftp.us.debian.org/debian testing main contrib non-free
deb-src http://ftp.us.debian.org/debian testing main contrib non-free
deb http://ftp.debian.org/debian/ testing-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ testing-updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free
deb http://debian-mirrors.sdinet.de/debian-multimedia stable main
deb-src http://debian-mirrors.sdinet.de/debian-multimedia stable mainAs we can see - i must have testing branch only
But:
# lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux testing/unstable
Release:    testing/unstableCodename:    n/awhere does unstable appear from?
And i have very strange situation - i can not install filezilla:#aptitude install filezilla
No candidate version found for filezilla 
No candidate version found for filezillaWhat is wrong with my sources.list?Thanks in advance.

[toc] | [next] | [standalone]

#160094

Testing/unstable is just a common release name for testing AND unstable.
Your sources.list is fine. Filezilla package isn't present in 
testing/stretch (see https://packages.debian.org/wheezy/filezilla). In 
fact, if you were running sid, you'd be able to install it.

[toc] | [prev] | [next] | [standalone]

#160096

[Multipart message — attachments visible in raw view] — view raw

thanks for your answer.its very strange for me that it is not possible to use filezilla in testing. i was using testing brunch in several years and filezilla was presenting in there. am i right? is it ok if i will change "testing" to "stratch"?

      From: Alex Moonshine <moonshine@openmailbox.org>
 To: debian-user@lists.debian.org 
 Sent: Monday, November 2, 2015 12:37 PM
 Subject: Re: where does unstable appear from?
   
Testing/unstable is just a common release name for testing AND unstable.
Your sources.list is fine. Filezilla package isn't present in 
testing/stretch (see https://packages.debian.org/wheezy/filezilla). In 
fact, if you were running sid, you'd be able to install it.





   

[toc] | [prev] | [next] | [standalone]

#160099

On Mon 02 Nov 2015 at 10:58:15 +0000, Andrey Rybak wrote:

> thanks for your answer.its very strange for me that it is not possible
> to use filezilla in testing. i was using testing brunch in several
> years and filezilla was presenting in there. am i right? is it ok if i
> will change "testing" to "stratch"?

That's ok. At present tt won't alter the list of available packages or
what upgrade/dist-upgrade downloads.

[toc] | [prev] | [next] | [standalone]

#160100

[Multipart message — attachments visible in raw view] — view raw

On 11/02/2015 12:58 PM, Andrey Rybak wrote:
> thanks for your answer.
> its very strange for me that it is not possible to use filezilla in 
> testing. i was using testing brunch in several years and filezilla was 
> presenting in there. am i right? is it ok if i will change "testing" 
> to "stratch"?
>
No, testing and stretch is currently the same thing. Changing to 
unstable would let you install filezilla (I would actually recommend 
using sid over testing). It's actually very common that package fall in 
and out of testing, there's absolutely nothing strange about that. 
Packages get removed because of bugs, new versions take time to be 
pushed down from unstable. You were just lucky with filezilla, I guess.

Alternatively, adding it to your sources.list and installing it with 
"apt-get -t unstable install filezilla", then removing it from 
sources.list or giving it low priority in /etc/apt/preferences will do 
the trick (consult this: https://wiki.debian.org/AptPreferences).

Be careful, both of those actions that I suggested, performed without 
full awareness of what you are doing  might break your system pretty badly.

[toc] | [prev] | [next] | [standalone]

#160151

On Mon, Nov 02, 2015 at 01:46:35PM +0200, Alex Moonshine wrote:
> On 11/02/2015 12:58 PM, Andrey Rybak wrote:
> >thanks for your answer.
> >its very strange for me that it is not possible to use filezilla in
> >testing. i was using testing brunch in several years and filezilla was
> >presenting in there. am i right? is it ok if i will change "testing" to
> >"stratch"?
> >
> No, testing and stretch is currently the same thing. Changing to unstable
> would let you install filezilla (I would actually recommend using sid over
> testing). It's actually very common that package fall in and out of testing,
> there's absolutely nothing strange about that. Packages get removed because
> of bugs, new versions take time to be pushed down from unstable. You were
> just lucky with filezilla, I guess.
> 
> Alternatively, adding it to your sources.list and installing it with
> "apt-get -t unstable install filezilla", then removing it from sources.list
> or giving it low priority in /etc/apt/preferences will do the trick (consult
> this: https://wiki.debian.org/AptPreferences).
> 
> Be careful, both of those actions that I suggested, performed without full
> awareness of what you are doing  might break your system pretty badly.

You mean your suggestion to install Sid? I agree. Suggesting that
someone run sid just so that they can have the latest package, is IMHO,
very cruel.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

[toc] | [prev] | [next] | [standalone]

#160159

On 11/03/2015 06:15 AM, Chris Bannister wrote:
> You mean your suggestion to install Sid? I agree. Suggesting that 
> someone run sid just so that they can have the latest package, is 
> IMHO, very cruel. 

To someone who runs stable - sure. He's running testing, though, which 
is more troublesome, in my experience, then Sid. Even Debian 
documentation recommends unstable over testing:
https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html

[toc] | [prev] | [next] | [standalone]

#160169

[Multipart message — attachments visible in raw view] — view raw

On 2015-11-03 at 04:07, Alex Moonshine wrote:

> On 11/03/2015 06:15 AM, Chris Bannister wrote:
> 
>> You mean your suggestion to install Sid? I agree. Suggesting that
>> someone run sid just so that they can have the latest package, is
>> IMHO, very cruel.
> 
> To someone who runs stable - sure. He's running testing, though,
> which is more troublesome, in my experience, then Sid.

That does not match my experience, at all.

When I first installed Debian (I think with potato), I started out with
running stable; it wasn't long before I switched to tracking sid, for
various reasons including the awareness that unstable does no good if
people don't help test it.

This worked okay-ish for some while, but in the long run I definitely
had cause to regret it. I ended up with a computer in an inconsistent
and broken state, which it wasn't clear could practically be fixed even
by a lot of manual work - so when I built my next new computer, I
reinstalled. The first time, I still kept tracking sid.

Then the same thing happened again, only arguably worse, on _that_
computer. So when I built my _next_ new computer, I abandoned sid and
switched to tracking testing.

So far, the only structural problem I've had with testing has been in
the grub-related packages, in the form of longstanding open bugs
reported by people whose computers became unbootable after a grub
upgrade (which may have been related to the transition away from
grub-legacy); I've had those packages set on hold for what seems like
years now, ever since those bugs first appeared, to avoid the risk of
this computer getting into a similar state. Even this hasn't caused me
any practical problems, however.

(Well, aside from temporary breakage due to package transitions such as
the recent lib*v5 mess. That's just a matter of "wait a few weeks before
dist-upgrading", though, which isn't unreasonable; it seems unlikely
that most people will want to dist-upgrade multiple times a week the way
I usually do outside of a release freeze.)

> Even Debian documentation recommends unstable over testing:
> https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html

I think I can see what you're interpreting as "recommends unstable over
testing" in that document, but only barely. It's certainly not a bald or
unequivocal recommendation, unless I'm missing something.

I would certainly not recommend that _anyone_ run sid on their primary
computer, much less on their only computer. Installing a single package
as a one-off is one thing (and I occasionally do it myself), but - as
the name implies - sid is, and probably always will be, too unstable to
be safe for general use.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#160171

[Multipart message — attachments visible in raw view] — view raw

On 11/03/2015 04:06 PM, The Wanderer wrote:
>
> So far, the only structural problem I've had with testing has been in
> the grub-related packages, in the form of longstanding open bugs
> reported by people whose computers became unbootable after a grub
> upgrade (which may have been related to the transition away from
> grub-legacy); I've had those packages set on hold for what seems like
> years now, ever since those bugs first appeared, to avoid the risk of
> this computer getting into a similar state. Even this hasn't caused me
> any practical problems, however.

How about packages that are not in testing, because they or their 
dependencies have bugs that prevent pushing them down from unstable? 
You're lucky you're not using any. OP does (filezilla).
What do you recommend him to do? What if it isn't filezilla? What if it 
is xorg-server? It might happen. Testing isn't meant to always be 
usable. Well, unstable isn't as well, but it switches from unusable 
state to usable MUCH faster (days, as opposed to weeks).

>
> (Well, aside from temporary breakage due to package transitions such as
> the recent lib*v5 mess. That's just a matter of "wait a few weeks before
> dist-upgrading", though, which isn't unreasonable; it seems unlikely
> that most people will want to dist-upgrade multiple times a week the way
> I usually do outside of a release freeze.)

How about waiting a few weeks before dist-upgrading on sid? Solves all 
problems just as well.
There's an essential package called apt-listbugs that you HAVE TO use 
when running either sid or testing.

> I think I can see what you're interpreting as "recommends unstable over
> testing" in that document, but only barely. It's certainly not a bald or
> unequivocal recommendation, unless I'm missing something.

    3.1 Which Debian distribution (stable/testing/unstable) is better
    for me?

    If security or stability are at all important for you: install
    stable. period. This is the most preferred way.

    *If you are a new user installing to a desktop machine, start with
    stable.* Some of the software is quite old, but it's the least buggy
    environment to work in. You can easily switch to the more modern
    unstable (or testing) once you are a little more confident.

    *If you are a desktop user with a lot of experience in the operating
    system and does not mind facing the odd bug now and then, or even
    full system breakage, use unstable. * It has all the latest and
    greatest software, and bugs are usually fixed swiftly.

There's no advice to install testing at all, for any user (because of 
the same reason - the package that you need may just not be there).

I would also invoke the opinion of Raphael Herzog (the author of Debian 
Administrator Handbook) 
https://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/

You, of course, are entitled to have your own opinion, nothing wrong 
with that.

> I would certainly not recommend that _anyone_ run sid on their primary
> computer, much less on their only computer. Installing a single package
> as a one-off is one thing (and I occasionally do it myself), but - as
> the name implies - sid is, and probably always will be, too unstable to
> be safe for general use.
>
I've been running Sid as my main daily driver for >3 years with little 
to no issues.
Not saying that everyone can or should. AM saying that those who can't 
should run stable, NOT testing.
But, well, I guess different things work for different people. Some 
folks do use Arch, for example.

[toc] | [prev] | [next] | [standalone]

#160179

[Multipart message — attachments visible in raw view] — view raw

On 2015-11-03 at 09:40, Alex Moonshine wrote:

> On 11/03/2015 04:06 PM, The Wanderer wrote:
>> 
>> So far, the only structural problem I've had with testing has been
>> in the grub-related packages, in the form of longstanding open
>> bugs reported by people whose computers became unbootable after a
>> grub upgrade (which may have been related to the transition away
>> from grub-legacy); I've had those packages set on hold for what
>> seems like years now, ever since those bugs first appeared, to
>> avoid the risk of this computer getting into a similar state. Even
>> this hasn't caused me any practical problems, however.
> 
> How about packages that are not in testing, because they or their
> dependencies have bugs that prevent pushing them down from unstable?
> You're lucky you're not using any. OP does (filezilla). What do you
> recommend him to do?

Either install the version that's in stable (since there's zero harm in
tracking stable + testing, vs. tracking just testing), or - if that
would cause too many dependency problems - install it as a one-off
package from sid. As I said, installing a single package as a one-off is
one matter, but tracking sid as a whole is entirely another.

> What if it isn't filezilla? What if it is xorg-server? It might
> happen. Testing isn't meant to always be usable. Well, unstable isn't
> as well, but it switches from unusable state to usable MUCH faster
> (days, as opposed to weeks).

It switches from obviously unusable to not obviously unusable much
faster, perhaps, but its failure states are much sneakier and harder to
recover from.

>> (Well, aside from temporary breakage due to package transitions
>> such as the recent lib*v5 mess. That's just a matter of "wait a few
>> weeks before dist-upgrading", though, which isn't unreasonable; it
>> seems unlikely that most people will want to dist-upgrade multiple
>> times a week the way I usually do outside of a release freeze.)
> 
> How about waiting a few weeks before dist-upgrading on sid? Solves
> all problems just as well.

No, not really - because in those few weeks, the odds of something else
significant getting broken in sid are much higher than the odds of
another such transition happening in testing. Such transitions tend to
be fairly rare; I'd consider it odd for there to be even a handful of
them (large enough to be noticeable) in one year.

Not to mention that the odds of _not noticing_ that something got broken
are much higher in sid than in testing. "Package not installable" is
easy to spot, has no real negative repercussions on an upgrade (since
you can see it in advance and cancel / postpone the upgrade), can be
worked around manually with comparatively little difficulty, and tends
to be fixed in the course of routine operations; the problems in sid
tend to be more subtle, much harder to spot in advance, and much harder
to fix once they've gotten themselves in place.

When tracking testing, the biggest problems you're likely to encounter
can be fixed by simply waiting for new package versions to reach testing
(and/or possibly a bit of cleverness with the package manager). I have
encountered this several times, but it's never been critical or fatal,
and it's never lasted terribly long.

When tracking sid, the biggest problems you're likely to encounter
cannot easily be fixed in-place at all; you're likely to need to
reinstall Debian from scratch. I have encountered this twice, and that's
more than enough.

The latter is, IMO, by far the worse of the two possibilities.

> There's an essential package called apt-listbugs that you HAVE TO use
> when running either sid or testing.

Of course, and I do use it. (As well as apt-listchanges, because not all
changes which I might find objectionable would get classified as bugs.
Some are actively intentional, such as aspects of the systemd mess.)

>> I think I can see what you're interpreting as "recommends unstable over
>> testing" in that document, but only barely. It's certainly not a bald or
>> unequivocal recommendation, unless I'm missing something.
> 
>     3.1 Which Debian distribution (stable/testing/unstable) is better
>     for me?
> 
>     If security or stability are at all important for you: install
>     stable. period. This is the most preferred way.
> 
>     *If you are a new user installing to a desktop machine, start with
>     stable.* Some of the software is quite old, but it's the least buggy
>     environment to work in. You can easily switch to the more modern
>     unstable (or testing) once you are a little more confident.
> 
>     *If you are a desktop user with a lot of experience in the operating
>     system and does not mind facing the odd bug now and then, or even
>     full system breakage, use unstable. * It has all the latest and
>     greatest software, and bugs are usually fixed swiftly.
> 
> There's no advice to install testing at all, for any user (because of 
> the same reason - the package that you need may just not be there).

There's a _big_ gap between "new desktop user" and "desktop user with a
lot of experience in the operating system, who does not mind facing full
system breakage"...

> I would also invoke the opinion of Raphael Herzog (the author of
> Debian Administrator Handbook)
> https://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/
> 
> You, of course, are entitled to have your own opinion, nothing wrong 
> with that.

I tend to concur with the view expressed by the person posting as
"Seeker" in the comments on that post.

Yes, sid is usable, but it is not safe to use - period, full stop.

If you are tracking sid, things _will_ break occasionally, and have to
be fixed - not just in the repositories (e.g. package-dependency issues
such as the ones in the gcc5 transition), but on your computer, unless
you're lucky enough to have someone else trip over them and report the
bug before you install the broken version.

If you are tracking testing, things may break occasionally - but it's
far less likely that the breakage won't be noticed before making it to
your computer than would be the case in sid, simply because sid provides
an additional layer in which such breakage can be noticed and reported
before it ever has a chance to reach you.

>> I would certainly not recommend that _anyone_ run sid on their
>> primary computer, much less on their only computer. Installing a
>> single package as a one-off is one thing (and I occasionally do it
>> myself), but - as the name implies - sid is, and probably always
>> will be, too unstable to be safe for general use.
>> 
> I've been running Sid as my main daily driver for >3 years with
> little to no issues.

I suspect that either you really do have issues under the hood which you
just haven't noticed yet (I certainly did, after using it for a similar
time period), or you're much more knowledgeable and careful (and
micromanage-y) about your upgrades than most people. Or else you've just
been lucky.

> Not saying that everyone can or should. AM saying that those who
> can't should run stable, NOT testing.

I strongly disagree on that latter point. testing is much safer than
sid, in terms of the types of breakage it sees and how easy it is to
avoid such (or to fix them after the fact), while not being stuck on
potentially years-old outdated software as stable can be.

> But, well, I guess different things work for different people. Some 
> folks do use Arch, for example.

^_^

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#160181

On 11/03/2015 05:19 PM, The Wanderer wrote:
> When tracking sid, the biggest problems you're likely to encounter 
> cannot easily be fixed in-place at all; you're likely to need to 
> reinstall Debian from scratch. I have encountered this twice, and 
> that's more than enough. The latter is, IMO, by far the worse of the 
> two possibilities.
Luckily, in all my lifetime of using Linux, I personally have never 
encountered a problem with Linux, be it any version of Debian, 
Slackware, Mageia (the distros that I use constantly), or any other 
distributions that I briefly test out, which required full 
reinstallation. I hate reinstalling OS because of some problem, that's 
Windows way of doing things. I believe that short of rm -rf / everything 
that's done can be undone.

[toc] | [prev] | [next] | [standalone]

#160188

On Tue, 3 Nov 2015 16:40:01 +0200
Alex Moonshine <moonshine@openmailbox.org> wrote:


> 
> How about waiting a few weeks before dist-upgrading on sid? Solves
> all problems just as well.

No, it doesn't, sometimes a judicious bit of butchery is required to
clear a dependency jam. I waited for quite a while recently, when
apt-get wanted to rip out a fair number of packages which I use, and
aptitude just threw up its virtual hands and told me to do the job
myself.

Eventually I got bored with waiting, and went with apt-get, managing to
restore everything essential afterwards, because apt-get wasn't clever
enough to see the right upgrade path. Aptitude was clever enough but
not powerful enough to deal with the number of packages involved.

It turned out that all the packages were present and OK, but that the
sheer number of them which needed to be upgraded at the same time led
to some very difficult dependency webs.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#160189

On Tue, 3 Nov 2015 19:40:54 +0000
Joe <joe@jretrading.com> wrote:

> No, it doesn't, sometimes a judicious bit of butchery is required to
> clear a dependency jam. I waited for quite a while recently, when
> apt-get wanted to rip out a fair number of packages which I use, and
> aptitude just threw up its virtual hands and told me to do the job
> myself.
> 
> Eventually I got bored with waiting, and went with apt-get, managing
> to restore everything essential afterwards, because apt-get wasn't
> clever enough to see the right upgrade path. Aptitude was clever
> enough but not powerful enough to deal with the number of packages
> involved.

I virtually never do that. Just wait until it resolves itself. I'm not
in any hurry, mind you. If it takes a month, it takes a month.

-- 
Time is an illusion. Lunchtime doubly so.

Best wishes,
Alex S.

[toc] | [prev] | [next] | [standalone]

#160174

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2015-11-03 at 09:06 -0500, The Wanderer wrote:
> > To someone who runs stable - sure. He's running testing, though,
> > which is more troublesome, in my experience, then Sid.
> 
> That does not match my experience, at all.

Interesting, my own experience is pretty much the opposite. I have been
using unstable for something like ten years, and while breakage have
occurred I don't remember any really big issues. 

For myself, either I want a rock stable system I can pretty much forget
about, stable. Or something that is really bleeding edge, that is
unstable, and sometimes even unstable moves too slow.

Testing seems like the worst of both, not recent enough to be useful
for me, and not stable enough to just use unattended upgrades and
forget about it.

Of course, this is all subjective, and I wouldn't recommend or talk
inexperienced users into running unstable (or testing) but it works for
me! 

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5

[toc] | [prev] | [next] | [standalone]

#160160

Also, not installing the latest version - installing the package at all, 
as it is absent from testing entirely.

[toc] | [prev] | [next] | [standalone]

#160095

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2 Nov 2015 10:20:21 +0000 (UTC)
Andrey Rybak <rybak.andrey@yahoo.com> wrote:

Hello Andrey,

>Release:    testing/unstableCodename:    n/awhere does unstable appear

I've never been sure myself but, for as long as I've used testing,
testing systems have always been labelled that way.

>filezilla:#aptitude install filezilla No candidate version found for

Filezilla has been removed for testing.  AIUI, due to missing
dependencies.  Hopefully, this is temporary.  There are alternative ftp
programs, obviously.

>filezilla No candidate version found for filezillaWhat is wrong with my
>sources.list?

AFAICT, there's nothing wrong with your sources.list

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Junk floats on polluted water
Hong Kong Garden - Siouxsie & The Banshees

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web