Re: Unstable ==> Testing ==> Stable

[Sven Hartge]

John Hasler  wrote:
> Sven writes:

>> It is of note that "experimental" in itself is not a complete set of
>> packages like "unstable" is, it is intended as an addon to "unstable"
>> and has to be used in conjunction with it.

> It is also of note that Unstable is unstable in that it is constantly
> changing, not that it is full of buggy packages.  One of the ways in
> which it can be unstable is that new versions of packages can be
> uploaded to it with out regard to the presence or absence of
> dependencies. 

The latter part is mitigated a bit when source-only uploads are used, as
those greatly reduce the impact of an unclean build-environment on the
DDs side.

But during library transitions "unstable" gets hit with this with the
full force, doing "apt dist-upgrade" blindly will see you remove the
major parts of your system quite easily.

You have to use your brain a bit when using "unstable".

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Unstable ==> Testing ==> Stable

[John Hasler]

Sven writes:
> It is of note that "experimental" in itself is not a complete set of
> packages like "unstable" is, it is intended as an addon to "unstable"
> and has to be used in conjunction with it.

It is also of note that Unstable is unstable in that it is constantly
changing, not that it is full of buggy packages.  One of the ways in
which it can be unstable is that new versions of packages can be
uploaded to it with out regard to the presence or absence of
dependencies. 
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Unstable ==> Testing ==> Stable

[Sven Hartge]

Kushal Kumaran  wrote:

> There is an experimental "distribution" that is for trying all kinds of
> new and weird things.

It is of note that "experimental" in itself is not a complete set of
packages like "unstable" is, it is intended as an addon to "unstable"
and has to be used in conjunction with it.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Unstable ==> Testing ==> Stable

[Kushal Kumaran]

rhkra...@gmail.com writes:

> Aside: for my own self respect, I want to make some sort of disclaimer here 
> (with maybe several points):  I'm sure that sometimes I post things that do 
> any of (1) make other people cringe (for one reason or another), (2) make me 
> look uninformed (or worse), and (3) other causes for embarrassment (to myself 
> of others).
>
> I finally realized that the "normal" progression / hierarchy of the Debian 
> releases is from Unstable to Testing to Stable.
>
> I never looked it up -- I assume that, like most people, we don't look up 
> everything but make assumptions based on past experience.  I expected that 
> the 
> normal progression for Debian releases would be from Testing (trying all / 
> any 
> kind of new, possibly weird things), to Unstable (concentrating on things 
> that 
> survived some initial testing and now maybe being released to a select group 
> for some real pounding en route to Stable.
>

There is an experimental "distribution" that is for trying all kinds of
new and weird things.

> (I've never used anything other than stable releases, so my misunderstanding 
> hasn't had any real world effect on my systems, but I have been confused at 
> times, and suspect that maybe one other person out there may have similarly 
> been confused.)

You might find
https://debian-handbook.info/browse/stable/sect.release-lifecycle.html
informative.

-- 
regards,
kushal

Re: Unstable ==> Testing ==> Stable

[steef]

Hi there,
youre are far from an idiot. All this stuff like stable etc/ etc. rests on conventions. You wrote you never insxtalled something other than 
stable. So: do not worry why should you worry about this shit. In a philosophical way your point of view if you have any developed now on 
this topic can be argumented as well I think.

have a nice sunday,
steef


rhkra...@gmail.com schreef op 13-04-20 om 15:29:

Aside: for my own self respect, I want to make some sort of disclaimer here
(with maybe several points):  I'm sure that sometimes I post things that do
any of (1) make other people cringe (for one reason or another), (2) make me
look uninformed (or worse), and (3) other causes for embarrassment (to myself
of others).

I finally realized that the "normal" progression / hierarchy of the Debian
releases is from Unstable to Testing to Stable.

I never looked it up -- I assume that, like most people, we don't look up
everything but make assumptions based on past experience.  I expected that the
normal progression for Debian releases would be from Testing (trying all / any
kind of new, possibly weird things), to Unstable (concentrating on things that
survived some initial testing and now maybe being released to a select group
for some real pounding en route to Stable.

(I've never used anything other than stable releases, so my misunderstanding
hasn't had any real world effect on my systems, but I have been confused at
times, and suspect that maybe one other person out there may have similarly
been confused.)

Re: Unstable ==> Testing ==> Stable

[Andrei POPESCU]

On Lu, 13 apr 20, 09:29:50, rhkra...@gmail.com wrote:
> Aside: for my own self respect, I want to make some sort of disclaimer here 
> (with maybe several points):  I'm sure that sometimes I post things that do 
> any of (1) make other people cringe (for one reason or another), (2) make me 
> look uninformed (or worse), and (3) other causes for embarrassment (to myself 
> of others).
> 
> I finally realized that the "normal" progression / hierarchy of the Debian 
> releases is from Unstable to Testing to Stable.

Correct. If you were to examine the archive with an ftp client you could 
notice that oldstable is actually a symlink to stretch, stable is a 
symlink to buster and testing is a symlink to bullseye (the codename for 
the next release).

Unstable always points to sid.

> I never looked it up -- I assume that, like most people, we don't look up 
> everything but make assumptions based on past experience.  I expected that 
> the 
> normal progression for Debian releases would be from Testing (trying 
> all / any kind of new, possibly weird things),

That would be experimental (also known as rc-buggy).

> to Unstable (concentrating on things that survived some initial 
> testing and now maybe being released to a select group for some real 
> pounding en route to Stable.

Trivia: Long ago Debian only had stable and unstable, testing was 
introduced later.

Basically packages that are meant for the next stable release are 
uploaded to unstable. If they satisfy certain criteria established by 
the Release Team (no new RC bugs, tests and/or age in unstable, etc.) 
they migrate to testing automatically.

In order to prepare for release, testing is "frozen", i.e. the automatic 
migration is disabled and only targeted fixes for RC bugs are manually 
approved by the Release Team[1].

When the Release Team considers everything is "ready"[2] the release 
happens.

The next release starts as copy of stable and automatic migration from 
unstable is enabled again.

[1] This is a simplification, in practice the freeze has different 
stages with different rules.
[2] RC bug count is low enough, the distribution overall is consistent, 
etc.

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Unstable ==> Testing ==> Stable

[rhkramer]

Aside: for my own self respect, I want to make some sort of disclaimer here 
(with maybe several points):  I'm sure that sometimes I post things that do 
any of (1) make other people cringe (for one reason or another), (2) make me 
look uninformed (or worse), and (3) other causes for embarrassment (to myself 
of others).

I finally realized that the "normal" progression / hierarchy of the Debian 
releases is from Unstable to Testing to Stable.

I never looked it up -- I assume that, like most people, we don't look up 
everything but make assumptions based on past experience.  I expected that the 
normal progression for Debian releases would be from Testing (trying all / any 
kind of new, possibly weird things), to Unstable (concentrating on things that 
survived some initial testing and now maybe being released to a select group 
for some real pounding en route to Stable.

(I've never used anything other than stable releases, so my misunderstanding 
hasn't had any real world effect on my systems, but I have been confused at 
times, and suspect that maybe one other person out there may have similarly 
been confused.)

Re: mise à jour testing+stable

[Pierre Crescenzo]

Bonjour,

Je m'y suis mis sérieusement hier et, au prix de l'abandon (temporaire :-))
de quelques paquets importants pas encore prêts ("gnome" mais seulement le
métapaquet, "filezilla"...), ça passe désormais bien. J'ai agis peu à peu
avec synaptic, en lisant bien la liste de ce qu'il enlevait.

Amitiés,

Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Le 10 septembre 2015 11:35, Pierre Crescenzo  a
écrit :

> Bonjour,
>
> Merci pour cette information. Mais je vois bien la version 5 de
> LibreOffice et mes "blocages" (plus de 600) ne sont pas limités à lui. Je
> tente de faire quelques mises à jour sélectives de temps en temps pour
> converger mais c'est un travail de Sisyphe pour le moment...
>
> Amitiés,
>
> Pierre Crescenzo
>   mailto:pie...@crescenzo.nom.fr
>   http://www.crescenzo.nom.fr/
>
> Le 9 septembre 2015 15:35, kevin  a écrit :
>
>> Bonjour,
>>
>> Si ça peut aider...
>>
>> ces jours-ci, sur des machines installées en stretch, j'avais un
>> problème avec LibreOffice base avec un fichier qui pourtant fonctionnait
>> bien jusqu'à récemment --- quand exactement ? --- : lorsque je tentais
>> d'ouvrir le formulaire, j'avais un message d'erreur :
>> 
>>
>> aucun pilote SDBC n'a été trouvé pour
>> l'URL 'sdbc:embedded:hsqldb'
>> --
>>
>>
>> Réinstaller le paquet « libreoffice-sdbc-hsqldb » n'a pas corrigé le
>> problème.
>>
>>
>> D'autre part, je voyais sur www que la version LibreOffice pour stretch
>> est actuellement la 5, alors que mes machines sous stretch utilisaient
>> toujours la 4 ; et une mise à jour classique (aptitude update /
>> safe-upgrade) n'installait pas la 5.
>>
>> J'ai désinstallé le méta-paquet « libreoffice », puis je l'ai réinstallé
>> (après avoir lancé un clean), et la réinstallation lance en réalité
>> l'installation de la version 5 ; phénomène un peu curieux, que je
>> suppose être lié à cette période de transition dont parle le post
>> précédent.
>>
>> => et l'installation de la version 5 corrige mon problème d'accès à la
>> bdd.
>>
>> Après la « réinstallation » du paquet libreoffice, un nouvel
>> update/upgrade met à jour d'autres paquets (plutôt curieux aussi,
>> puisque juste avant de désinstaller LO, j'avais lancé un update/upgrade).
>>
>>
>>
>>
>>
>>
>>
>

Re: mise à jour testing+stable

[Alain Rpnpif]

Le  9 septembre 2015, kevin a écrit :

> D'autre part, je voyais sur www que la version LibreOffice pour stretch
> est actuellement la 5, alors que mes machines sous stretch utilisaient
> toujours la 4 ; et une mise à jour classique (aptitude update /
> safe-upgrade) n'installait pas la 5.
> 
> J'ai désinstallé le méta-paquet « libreoffice », puis je l'ai réinstallé
> (après avoir lancé un clean), et la réinstallation lance en réalité
> l'installation de la version 5 ; phénomène un peu curieux, que je
> suppose être lié à cette période de transition dont parle le post précédent.
> 
> => et l'installation de la version 5 corrige mon problème d'accès à la bdd.
> 
> Après la « réinstallation » du paquet libreoffice, un nouvel
> update/upgrade met à jour d'autres paquets (plutôt curieux aussi,
> puisque juste avant de désinstaller LO, j'avais lancé un update/upgrade).

À propos de libreoffice 5, il vient aussi d'apparaître dans
jessie-backports. Méfiez-vous il est bogué au niveau de certaines
fonctions CALC de calcul de date, surtout si vous l'utilisez en
français.

Pour quelques jours ou semaines, je conseille aux francophones de
rester sur Libreoffice 4.4.x.

-- 
Alain Rpnpif

Re: mise à jour testing+stable

[Pierre Crescenzo]

Bonjour,

Merci pour cette information. Mais je vois bien la version 5 de LibreOffice
et mes "blocages" (plus de 600) ne sont pas limités à lui. Je tente de
faire quelques mises à jour sélectives de temps en temps pour converger
mais c'est un travail de Sisyphe pour le moment...

Amitiés,

Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Le 9 septembre 2015 15:35, kevin  a écrit :

> Bonjour,
>
> Si ça peut aider...
>
> ces jours-ci, sur des machines installées en stretch, j'avais un
> problème avec LibreOffice base avec un fichier qui pourtant fonctionnait
> bien jusqu'à récemment --- quand exactement ? --- : lorsque je tentais
> d'ouvrir le formulaire, j'avais un message d'erreur :
> 
>
> aucun pilote SDBC n'a été trouvé pour
> l'URL 'sdbc:embedded:hsqldb'
> --
>
>
> Réinstaller le paquet « libreoffice-sdbc-hsqldb » n'a pas corrigé le
> problème.
>
>
> D'autre part, je voyais sur www que la version LibreOffice pour stretch
> est actuellement la 5, alors que mes machines sous stretch utilisaient
> toujours la 4 ; et une mise à jour classique (aptitude update /
> safe-upgrade) n'installait pas la 5.
>
> J'ai désinstallé le méta-paquet « libreoffice », puis je l'ai réinstallé
> (après avoir lancé un clean), et la réinstallation lance en réalité
> l'installation de la version 5 ; phénomène un peu curieux, que je
> suppose être lié à cette période de transition dont parle le post
> précédent.
>
> => et l'installation de la version 5 corrige mon problème d'accès à la bdd.
>
> Après la « réinstallation » du paquet libreoffice, un nouvel
> update/upgrade met à jour d'autres paquets (plutôt curieux aussi,
> puisque juste avant de désinstaller LO, j'avais lancé un update/upgrade).
>
>
>
>
>
>
>

Re: mise à jour testing+stable

[Pierre Crescenzo]

ReBonjour,

J'ai l'impression que les principaux paquets bloquants sont gnome et
gome-core.

Amitiés,

Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Le 10 septembre 2015 11:35, Pierre Crescenzo  a
écrit :

> Bonjour,
>
> Merci pour cette information. Mais je vois bien la version 5 de
> LibreOffice et mes "blocages" (plus de 600) ne sont pas limités à lui. Je
> tente de faire quelques mises à jour sélectives de temps en temps pour
> converger mais c'est un travail de Sisyphe pour le moment...
>
> Amitiés,
>
> Pierre Crescenzo
>   mailto:pie...@crescenzo.nom.fr
>   http://www.crescenzo.nom.fr/
>
> Le 9 septembre 2015 15:35, kevin  a écrit :
>
>> Bonjour,
>>
>> Si ça peut aider...
>>
>> ces jours-ci, sur des machines installées en stretch, j'avais un
>> problème avec LibreOffice base avec un fichier qui pourtant fonctionnait
>> bien jusqu'à récemment --- quand exactement ? --- : lorsque je tentais
>> d'ouvrir le formulaire, j'avais un message d'erreur :
>> 
>>
>> aucun pilote SDBC n'a été trouvé pour
>> l'URL 'sdbc:embedded:hsqldb'
>> --
>>
>>
>> Réinstaller le paquet « libreoffice-sdbc-hsqldb » n'a pas corrigé le
>> problème.
>>
>>
>> D'autre part, je voyais sur www que la version LibreOffice pour stretch
>> est actuellement la 5, alors que mes machines sous stretch utilisaient
>> toujours la 4 ; et une mise à jour classique (aptitude update /
>> safe-upgrade) n'installait pas la 5.
>>
>> J'ai désinstallé le méta-paquet « libreoffice », puis je l'ai réinstallé
>> (après avoir lancé un clean), et la réinstallation lance en réalité
>> l'installation de la version 5 ; phénomène un peu curieux, que je
>> suppose être lié à cette période de transition dont parle le post
>> précédent.
>>
>> => et l'installation de la version 5 corrige mon problème d'accès à la
>> bdd.
>>
>> Après la « réinstallation » du paquet libreoffice, un nouvel
>> update/upgrade met à jour d'autres paquets (plutôt curieux aussi,
>> puisque juste avant de désinstaller LO, j'avais lancé un update/upgrade).
>>
>>
>>
>>
>>
>>
>>
>

Re: mise à jour testing+stable

[kevin]

Bonjour,

Si ça peut aider...

ces jours-ci, sur des machines installées en stretch, j'avais un
problème avec LibreOffice base avec un fichier qui pourtant fonctionnait
bien jusqu'à récemment --- quand exactement ? --- : lorsque je tentais
d'ouvrir le formulaire, j'avais un message d'erreur :


aucun pilote SDBC n'a été trouvé pour
l'URL 'sdbc:embedded:hsqldb'
--


Réinstaller le paquet « libreoffice-sdbc-hsqldb » n'a pas corrigé le
problème.


D'autre part, je voyais sur www que la version LibreOffice pour stretch
est actuellement la 5, alors que mes machines sous stretch utilisaient
toujours la 4 ; et une mise à jour classique (aptitude update /
safe-upgrade) n'installait pas la 5.

J'ai désinstallé le méta-paquet « libreoffice », puis je l'ai réinstallé
(après avoir lancé un clean), et la réinstallation lance en réalité
l'installation de la version 5 ; phénomène un peu curieux, que je
suppose être lié à cette période de transition dont parle le post précédent.

=> et l'installation de la version 5 corrige mon problème d'accès à la bdd.

Après la « réinstallation » du paquet libreoffice, un nouvel
update/upgrade met à jour d'autres paquets (plutôt curieux aussi,
puisque juste avant de désinstaller LO, j'avais lancé un update/upgrade).

mise à jour testing+stable

[Pierre Crescenzo]

Bonjour,

J'ai une Debian testing+stable. Aujourd'hui, quasiment impossible de faire
les mises-à-jour (nombreuses proposées, avec synaptic) car la plupart
propose de désinstaller une (grande) partie des paquets. Avez-vous
expérimenté quelque chose de similaire, ou entendu/vu quelque chose à ce
propos ? Merci.

Amitiés,

Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Re: mise à jour testing+stable

[Pierre Crescenzo]

Bonjour,

Merci pour cette information. C'est en effet une cause plausible et
importante. :-)

Amitiés,

Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Le 7 septembre 2015 11:47, Erwan David <er...@rail.eu.org> a écrit :

> On Mon, Sep 07, 2015 at 11:40:01AM CEST, Pierre Crescenzo <
> pie...@crescenzo.nom.fr> said:
> > Bonjour,
> >
> > J'ai une Debian testing+stable. Aujourd'hui, quasiment impossible de
> faire les
> > mises-à-jour (nombreuses proposées, avec synaptic) car la plupart
> propose de
> > désinstaller une (grande) partie des paquets. Avez-vous expérimenté
> quelque
> > chose de similaire, ou entendu/vu quelque chose à ce propos ? Merci.
> >
> > Amitiés,
>
> gcc 5 arrive dans testing, avec tous les paquets qui en dépendaient et
> étaient bloqués (par exemple libreoffice 5). Il faut s'attendre à un
> peu de flottement pendant quelques jours. Personnellement dans cette
> situation je ne fais pour l'instant que les mises à jour tagguées
> sécurité et j'attends un peu que les choses se statbilisent.
>
>

Re: mise à jour testing+stable

[Erwan David]

On Mon, Sep 07, 2015 at 11:40:01AM CEST, Pierre Crescenzo 
<pie...@crescenzo.nom.fr> said:
> Bonjour,
> 
> J'ai une Debian testing+stable. Aujourd'hui, quasiment impossible de faire les
> mises-à-jour (nombreuses proposées, avec synaptic) car la plupart propose de
> désinstaller une (grande) partie des paquets. Avez-vous expérimenté quelque
> chose de similaire, ou entendu/vu quelque chose à ce propos ? Merci.
> 
> Amitiés,

gcc 5 arrive dans testing, avec tous les paquets qui en dépendaient et
étaient bloqués (par exemple libreoffice 5). Il faut s'attendre à un
peu de flottement pendant quelques jours. Personnellement dans cette
situation je ne fais pour l'instant que les mises à jour tagguées
sécurité et j'attends un peu que les choses se statbilisent.

Re: Sources: testing - stable

[Maciej Delmanowski]

Witam.

On kwi 10, Krzysztof Jastrzębski wrote:
 Mniej więcej w połowie życia wydanie stable robi się lekko stare a
 testing wychodzi z problemów życia młodzieńczego.
 Dobry moment by w sources zamienić stable na testing i cieszyć się w
 miarę nowymi wersjami przy niewielkiej ilości problemów.
 Przy Sarge tak właśnie zrobiłem (przynajmniej na desktopach bo na
 serwerach został stable) i było O.K.
 Jeśli dobrze rozumiem proces wydawniczy to w chwili nowego wydania w
 stable powinny być prawie te same pakiety co w testingu (który może
 zacząć mieć złe dni) i wydaje się to dobry moment na odwrotną zmianę w
 souces: z testing na stable.
 A za pół roku abarot...

W takich wypadkach przydaje się wiedza o budowie repozytoriów Debiana.
Poszczególne dystrybucje są zapisywane w katalogach o nazwach takich, jak
nazwy kodowe: woody, sarge, etch, lenny, sid. Natomiast smaki (stable,
testing, unstable) to tylko dowiązania symboliczne, które podczas wydania
nowej dystrybucji stabilnej są lekko modyfikowane. Ma to na celu
zmniejszenie obciążenia serwerów lustrzanych, w innym wypadku w dniu wydania
ogromne ilości danych musiałyby być przeniesione między poszczególnymi
katalogami. Dla przykładu, przed wydaniem Etcha symlinki były następujące:

oldstable - woody
stable - sarge
testing - etch
unstable - sid

Natomiast po wydaniu Etcha, dowiązania zostały zmienione na takie:

oldstable - sarge
stable - etch
testing - lenny

Woody został kilka miesięcy temu przeniesiony do archiwum
(http://archive.debian.org/) i jest stamtąd nadal dostępny, gdyby ktoś go
potrzebował.

Z tego wniosek, że podczas życia dystrybucji na serwerach warto używać
repozytoria oznaczając je nazwami kodowymi zamiast smakami. W Twoim
przykładzie mógłbyś zamienić wpisy w /etc/apt/sources.list z stable na etch.
Wtedy w dniu wydania nowej dystrybucji stabilnej automatycznie miałbyś na
swoich serwerach stabilną dystrybucję Debiana bez przejmowania się
o stabilność pakietów. Po jakimś czasie, powiedzmy 9 miesięcy, możesz zamienić
wpisy z etch na lenny i znowu w dniu wydania dystrybucji spać spokojnie, kiedy
inni kombinują czy lepiej wybrać 'testing' czy 'stable'. :)

Smaki natomiast przydają się właśnie na desktopach, kiedy zamiast
konkretnych dystrybucji warto trzymać się dystrybucji testowej, chociaż
zapewne duża ilość użytkowników na wpisane repozytoria unstable/sid. Jeżeli
używasz 'testing', wtedy po wydaniu nowego Debiana automatycznie zaczniesz
używać kolejnej dystrybucji testowej, bez potrzeby zmiany repozytoriów.

Pozdrawiam,
Maciej Delmanowski

-- 
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
| Maciej Delmanowski  /  http://linux.net.pl/~harnir/  /  GnuPG: 48B03AFE |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

Sources: testing - stable

[Krzysztof Jastrzębski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mniej więcej w połowie życia wydanie stable robi się lekko stare a
testing wychodzi z problemów życia młodzieńczego.
Dobry moment by w sources zamienić stable na testing i cieszyć się w
miarę nowymi wersjami przy niewielkiej ilości problemów.
Przy Sarge tak właśnie zrobiłem (przynajmniej na desktopach bo na
serwerach został stable) i było O.K.
Jeśli dobrze rozumiem proces wydawniczy to w chwili nowego wydania w
stable powinny być prawie te same pakiety co w testingu (który może
zacząć mieć złe dni) i wydaje się to dobry moment na odwrotną zmianę w
souces: z testing na stable.
A za pół roku abarot...
NIE chodzi mi o mieszanie repozytoriów tylko raz na pół roku a
porządnie: ten albo ten.
Czy ktoś z Was tak żonglował wpisami i z jakim efektem ?
W górę chodzi spokojnie bo sprawdziłem ale czy przy zmianie w dół ma
prawo się coś powalić... ?

- --
Pozdrawiam Krzysztof Jastrzębski 
Jotka Usługi Informatyczne
jotka[at]jastrzebscy[dot]pl http://jotka.jastrzebscy.pl/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGG8++gzQmZ4O8YgkRAialAKC7GWWZi0GmWotOjCWPAcESlfhL8gCgp6TK
qHBJ3P1BRNjnWbZxOoi8LpY=
=GyrE
-END PGP SIGNATURE-


--
Byłeś agentem? Sprawdź!
http://link.interia.pl/f1a46


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Sources: testing - stable

[Paweł Krzywicki]

kiedyś miałem zainstalowanego etch na swoim komputerku i niestety było tam 
także  mysql-server-5.0 z paczki w celach cwiczebnych zainstalowane no i to 
mi się całkowicie zwaliło. Powiem tyle namieszałem, naplątałem i 
zainstalowałem odnowa :\  
mam nadzieje że tobie się nic takowego nie porobi...
pozdrawiam

 Mniej więcej w połowie życia wydanie stable robi się lekko stare a
 testing wychodzi z problemów życia młodzieńczego.
 Dobry moment by w sources zamienić stable na testing i cieszyć się w
 miarę nowymi wersjami przy niewielkiej ilości problemów.
 Przy Sarge tak właśnie zrobiłem (przynajmniej na desktopach bo na
 serwerach został stable) i było O.K.
 Jeśli dobrze rozumiem proces wydawniczy to w chwili nowego wydania w
 stable powinny być prawie te same pakiety co w testingu (który może
 zacząć mieć złe dni) i wydaje się to dobry moment na odwrotną zmianę w
 souces: z testing na stable.
 A za pół roku abarot...
 NIE chodzi mi o mieszanie repozytoriów tylko raz na pół roku a
 porządnie: ten albo ten.
 Czy ktoś z Was tak żonglował wpisami i z jakim efektem ?
 W górę chodzi spokojnie bo sprawdziłem ale czy przy zmianie w dół ma
 prawo się coś powalić... ?


-- 
Etch Debian User: PawelatWartandotorg
kadu:3735326 Registered Linux User : 406139 |PLUG :1966491030
GnuPG | pub 1024D/2AAB159B
Home Page: http://www.wartan.org

Re: Sources: testing - stable

[Wojciech Ziniewicz]

10-04-07, Krzysztof Jastrzębski [EMAIL PROTECTED] napisał(a):


A za pół roku abarot...
NIE chodzi mi o mieszanie repozytoriów tylko raz na pół roku a
porządnie: ten albo ten.
Czy ktoś z Was tak żonglował wpisami i z jakim efektem ?
W górę chodzi spokojnie bo sprawdziłem ale czy przy zmianie w dół ma
prawo się coś powalić... ?


Uzywam debiana od wersji potato - w sumie nie było nigdy problemów
natury coś się powaliło , raczej po prostu zależności siadają a
doklaniej pakiety nie chcą się instalować a jesli coś usuwasz to
czasem z resztą systemu... to wszystko..

--
Wojciech Ziniewicz
Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;fl
ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
ct;umount;makeclean; zip;split;done;exit:xargs!!;)}

testing stable: vanished packages?

[furufuru]

Hi all,

I'm wondering why some packages aren't available for
the testing distribution.  For example, I wanted to
install apcalc (in the math section) but learned that
it's available only for the unstable and stable
distributions, not for the testing. (I searched
at http://www.debian.org .)

When sarge became the stable distribution, I read
that initially the stable and testing distributions
are the same but that packages in the testing keep
upgraded, if I remember correctly.  If that's so,
some packages in the testing will get frequently
upgraded and others will get upgraded less frequent
or not at all, but there's no reason why a package
must be removed, is there?  (unless there's a security
problem or some such serious problem.)

I downloaded .deb files in the stable distribution
of apcalc and installed them using dpkg -i.
I'm not very unhappy with that.  But, I remain
puzzled.

Cheers,
Ryo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: testing stable: vanished packages?

[Joseph Haig]

--- [EMAIL PROTECTED] wrote:

 Hi all,
 
 I'm wondering why some packages aren't available for
 the testing distribution.  For example, I wanted to
 install apcalc (in the math section) but learned that
 it's available only for the unstable and stable
 distributions, not for the testing. (I searched
 at http://www.debian.org .)
 

I was just starting to wonder the same thing.  After trying
unsucessfully to install 'testing' from scratch I found that the only
reliable way is to install 'stable' first and then upgrade.  More
recently I found, like you, that some packages are not available in
'testing' and I suspect that this is why some of my installs didn't
work.  For the sake of getting things to work I have started including
both 'stable' and 'testing' in my /etc/apt/sources.list file, but I'm
sure this isn't the right thing to do.




___ 
To help you stay safe and secure online, we've developed the all new Yahoo! 
Security Centre. http://uk.security.yahoo.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: testing stable: vanished packages?

[Carl Fink]

On Thu, Sep 29, 2005 at 02:14:16AM -0700, [EMAIL PROTECTED] wrote:

 When sarge became the stable distribution, I read
 that initially the stable and testing distributions
 are the same but that packages in the testing keep
 upgraded, if I remember correctly.  If that's so,
 some packages in the testing will get frequently
 upgraded and others will get upgraded less frequent
 or not at all, but there's no reason why a package
 must be removed, is there?  (unless there's a security
 problem or some such serious problem.)

Sure, there is.  For instance, what if package foo depends on package bar,
and bar has a release-critical bug and won't ever be included in Testing
until the bug is fixed?

Including packages from Stable will eventually stop working, I suspect.  All
it takes is one major change in an important library.
-- 
Carl Fink [EMAIL PROTECTED]
If you attempt to fix something that isn't broken, it will be.
-Bruce Tognazzini


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: testing stable: vanished packages?

[furufuru]

Antony Gelberg wrote:
[...]
 apcalc isn't in testing as it has an RC bug (read: serious problem).

 http://bjorn.haxx.se/debian/testing.pl?package=apcalc

Thanks for the info!  This webpage
(entitled Why is package X not in testing yet?)
seems very useful.

But, why then isn't the older package (which is part of the stable
distribution) kept for the testing distribution?  As I said,
it _appears_ to be working on my etch box.  Is it known to be seriously
broken on the etch platform?  Or, does this phrase in the webpage above

apcalc has no old version in testing (trying to add, not update)

mean that the package maintainer intends to re-introduce the older
package while the bug in the newer is being fixed?

It seems that I don't quite understand the process in which packages
are updated.

Regards,
Ryo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: sarge testing-stable and USB mouse issue

[Jon Dowland]

Jon Dowland wrote:


On 6/9/05, Jon Dowland [EMAIL PROTECTED] wrote:
 



Right - well indeed when I got in my PS2 mouse wasn't working in X. No
events on /dev/input/mice. psmouse module loaded, '0' modules
depending on it. rmmod psmouse; modprobe psmouse resulted in the
following on dmesg:

input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1

This line did occur in dmesg prior to the modprobe, i.e. as part of
the boot-up. It occurs after a similar message for the keyboard (which
works fine); but before the USB stuff loads. I have an 'aiptek
hyperpen' clone graphics tablet (USB) which does work.

Booting my machine _without_ the tablet plugged in prevents this issue. 
This isn't a relevant fix for my work computer, but luckily that one has 
stopped complaining as of late. I will investigate further at a later time.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

sarge testing-stable and USB mouse issue

[Jon Dowland]

Hi all - it seems a lot of people are having trouble with their mice 
after the sarge move from testing to stable. I am also having a problem 
which seems to be different from those who have already posted on d-u 
and I can't find any relevant bugs against xserver-xfree86.


When I get into work in the morning, my mouse does not appear to be 
working. Sometimes I have an X session open which I was using the 
previous day, mouse and all; other times I am logging in afresh from 
gdm. I cannot find any messages hinting at the cause in /var/log/* or 
dmesg. Removing the mouse and plugging it in again causes the hotplug 
system to register the mouse afresh:


usb 4-1: USB disconnect, address 5
usb 4-2: new low speed USB device using uhci_hcd and address 6
input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on 
usb-:00:1d.3-2


X is configured to use /dev/input/mice. I am using a 2.6.11 kernel.

When I come in tomorrow, assuming my mouse isn't working in the morning, 
I will confirm


a) that the no-mouse-in-X problem is in fact no-events-from-mouse by 
hexdumping /dev/input/m*
b) that there is a mouse entry (still) in the /proc/bus/usb listings 
(since the dmesg output indicates that a disconnect was registered, that 
sort-of suggests to me the mouse is still present as far as the kernel 
is concerned)


[Footnote: I may be having the same problem at home, too (similarly 
sarge 2.6.11, albeit PS2 mouse this time). However I can't  confirm 
that, I haven't used that machine much recently and I think the mouse 
actually was physically unplugged at one point.]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: sarge testing-stable and USB mouse issue

[Jon Dowland]

On 6/9/05, Jon Dowland [EMAIL PROTECTED] wrote:
 [Footnote: I may be having the same problem at home, too (similarly
 sarge 2.6.11, albeit PS2 mouse this time). However I can't  confirm
 that, I haven't used that machine much recently and I think the mouse
 actually was physically unplugged at one point.]

Right - well indeed when I got in my PS2 mouse wasn't working in X. No
events on /dev/input/mice. psmouse module loaded, '0' modules
depending on it. rmmod psmouse; modprobe psmouse resulted in the
following on dmesg:

input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1

This line did occur in dmesg prior to the modprobe, i.e. as part of
the boot-up. It occurs after a similar message for the keyboard (which
works fine); but before the USB stuff loads. I have an 'aiptek
hyperpen' clone graphics tablet (USB) which does work.

This is a 2.6.11 kernel. Any tips/advice would be greatly appreciated.

-- 
Jon Dowland
http://jon.dowland.name/

help in sarge testing-stable

[Alberto Bert]

Hi,

I'm running sarge, but I would like to keep using the testing distribution,
also after the release. Do you think there will be any kind of
problem in the transition between sarge and the new testing? I mean,
should I just upgrade my system and everything should work, or there are
some important changes I have to deal with?

sorry if the question was stupid.
thanks
Alberto


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: help in sarge testing-stable

[Clive Menzies]

On (18/05/05 10:33), Alberto Bert wrote:
 I'm running sarge, but I would like to keep using the testing distribution,
 also after the release. Do you think there will be any kind of
 problem in the transition between sarge and the new testing? I mean,
 should I just upgrade my system and everything should work, or there are
 some important changes I have to deal with?

As long as you have 'testing' instead of 'sarge' in your sources.list
everything should work fine.  I suspect that since sarge is now frozen,
there will be a build up of packages in 'sid' awaiting transition to
testing once 'etch' become testing.  So immediately after sarge goes
stable you will experience a large upgrade of packages.  I suggest you
have 'apt-listbugs' installed prior to that so that you can make sure
that nothing vital is going to break.

Regards

Clive

-- 
www.clivemenzies.co.uk ...
...strategies for business



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: help in sarge testing-stable

[Kamaraju Kusumanchi]

Alberto Bert wrote:
Hi,
I'm running sarge, but I would like to keep using the testing distribution,
also after the release. Do you think there will be any kind of
problem in the transition between sarge and the new testing? I mean,
should I just upgrade my system and everything should work, or there are
some important changes I have to deal with?
sorry if the question was stupid.
thanks
Alberto

The question is very common and there is nothing stupid about it. May I 
point you to the FAQ I have written in the past and hosted at

http://www.people.cornell.edu/pages/kk288/debian_choosing_distribution.html
In particular you might be interested in
Q13 - What happens when a new release is made?
Q15 - I am currently tracking testing (sarge). What happens when a 
release is made? Will I still be tracking testing or will my machine be 
running the new stable distribution?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

apt-get testing stable questions

[James W. Thompson, II]

I have what might be a stupid question...

can I get only certain packages from testing while leaving the rest of
my system on the stable chain without messing too much stuff up and do
it automatically through apt-get?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Testing-Stable?

[Colin Watson]

On Fri, May 07, 2004 at 02:00:05PM -0700, Justin Souter, InkNoise wrote:
 Is there any information on when the current testing release will become the
 stable release?

Follow the debian-devel-announce mailing list for relevant
announcements.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Testing-Stable?

[Roberto Sanchez]

Colin Watson wrote:
On Fri, May 07, 2004 at 02:00:05PM -0700, Justin Souter, InkNoise wrote:

Is there any information on when the current testing release will become the
stable release?


Follow the debian-devel-announce mailing list for relevant
announcements.
Naturally, there is the classic response: When it's ready.
One of the truly nice things about Debian.  A release won't
be rushed out the door to satisfy some political or financial
demand.
-Roberto Sanchez



signature.asc
Description: OpenPGP digital signature

Testing-Stable?

[Justin Souter, InkNoise]

Is there any information on when the current testing release will become the
stable release? I'm just looking for when PHP 4.3.x will be available in a
stable release. Thanks.

- - - - - - - - - -
Justin Souter
InkNoise
Personal Web Publishing
818-784-8778
http://www.inknoise.com



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Testing-Stable?

[Silvan]

On Friday 07 May 2004 05:00 pm, Justin Souter, InkNoise wrote:

 Is there any information on when the current testing release will become
 the stable release? I'm just looking for when PHP 4.3.x will be available
 in a stable release. Thanks.

When it's ready.  Hopefully sometime before never.

-- 
Michael McIntyre     Silvan [EMAIL PROTECTED]
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Testing-Stable?

[Brian Nelson]

Justin Souter, InkNoise [EMAIL PROTECTED] writes:

 Is there any information on when the current testing release will become the
 stable release? I'm just looking for when PHP 4.3.x will be available in a
 stable release. Thanks.

Some time this summer, most likely...

-- 
You win again, gravity!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Migration d'un serveur testing - stable

[Nicolas Rueff]

Le mer 27/08/2003 à 11:19, Yann Autissier a écrit :
 Bonjour nicolas,
 merci pour ta réponse, mais le probleme avait l'air plus complexe :
 
 j'ai desactiver le mdp root, permuter les disques, et la, impossible de 
 se logguer en root !
 vite google donne moi la solution ;)
 je redemarre le serveur sql sans charger les tables de privileges 
 (--skip-grant-tables), j'accede a ma base, je met un nouveau pass a mon 
 root, je relance toujours pas droit a mon root :-\
 au final , il m a fallu créer un nouvel utilisateur a la main, puis lui 
 changer son passwd avec phpmyadmin (a la main, ca ne passait pas)
 c'est bien la fonction PASSWORD a utiliser, je suis pas fou !
 bref je n'ai toujours pas compris l'origine de mon probleme
 si qqn a une idee...
 
 --
 /Y\

Et finalement, tes deux hash des password root sont-ils différents ?

/N 
__

Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
Real programmers don't comment their code. It was hard to write, it
should be hard to understand.
__




signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Migration d'un serveur testing - stable

[Yann Autissier]

Bonjour nicolas,
merci pour ta réponse, mais le probleme avait l'air plus complexe :

j'ai desactiver le mdp root, permuter les disques, et la, impossible de 
se logguer en root !

vite google donne moi la solution ;)
je redemarre le serveur sql sans charger les tables de privileges 
(--skip-grant-tables), j'accede a ma base, je met un nouveau pass a mon 
root, je relance toujours pas droit a mon root :-\
au final , il m a fallu créer un nouvel utilisateur a la main, puis lui 
changer son passwd avec phpmyadmin (a la main, ca ne passait pas)

c'est bien la fonction PASSWORD a utiliser, je suis pas fou !
bref je n'ai toujours pas compris l'origine de mon probleme
si qqn a une idee...

--
/Y\

Le mer 20/08/2003 à 12:32, Yann Autissier a écrit :


Bonjour la liste,
Je dispose chez moi d'un serveur debian sur lequel j'héberge qqs sites + 
bdd.
Ce serveur, de production, s'est progressivement retrouvé en version 
_unstable_, va savoir pourquoi 
Pour corriger cela, j'ai installé une woody toute fraiche sur un nouveau 
disque, et je vais garder l'ancien comme serveur de test_ing.


Le problème se pose quand je veux récupérer les données d'un serveur à 
l'autre.
Après avoir récupérer les fichiers de config sur mon serveur stable, 
j'ai fait un premier test, violent:

monter la partition /var/ de mon ancien serveur sur le nouveau.
Tous mes services redémarrent, j'accède à toutes mes données, je croie 
la partie gagnée..!

et beh non garry : au passage, j'ai perdu le password root de mysql !
La base mysql démarre, tous mes sites fonctionnent (ils accèdent à la 
bdd), mais il m'est impossible de me logguer en root sur la bdd 
J'ai perdu mon password mysql...? 
Je vérifie en redémarrant sur l'ancien disque : tout fonctionne 
normalement, mon password root mysql également.


Alors ou se cache-t-il ? ce password root mysql !
 



Seul le hash de ton pass est stocké dans mysl: base mysql, table user.
Je me suis pas spécialiste de mySQL, mais s'est possible que le hash
dépende de la version de mysql (v3 différent de v4 ?). Ça paraitrait
bizarre somme toute, because ça impliquerait de changer tous les pass
des utilisateurs de mysql au passage en v4.

Un remède éventuel: note le contenu du champ password originel,
désactive le mot de passe root de mysql, permute test disques, tente de
te logguer, et si ça marche mets en place le nouveau pass root (le même
que l'ancien), relève le contenu du champ password, et s'ils sont
différents, tu sauras d'ou viens ton pb.




Au passage, j'ai auusi monté 3 disques *neufs* (maxtor 120Go 8Mo cache) 
en raid 5 logiciel, et pendant que je copiai tranquilement mes données, 
j'ai eu droit à ces jolis messages d'erreurs :


hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide3: reset: success

c grave docteur ?? (la derniere fois que g vu ce genre de message, 
c'était sur un vieux disque qui m'a laché qqs temps après)
 



Tente un chtit coup de badbocks sur tes disques: en sortie d'usine il
peut y avoir des serveurs défectueux.

Ceci dit, as-tu rodé tes disques ? Quand tu les as formaté, as-tu
vérifié les secteurs défectueux ?

/N 
__


Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
Windoze CEMeNT: Now with CrackGuard(TM)! Never worry about
unsightly cracks in Windoze CEMeNT again! CrackGuard(TM) is
so powerful that the entire thing will crumble before it will
crack. Order your $200 upgrade version today!
__

Migration d'un serveur testing - stable

[Yann Autissier]

Bonjour la liste,
Je dispose chez moi d'un serveur debian sur lequel j'héberge qqs sites + 
bdd.
Ce serveur, de production, s'est progressivement retrouvé en version 
_unstable_, va savoir pourquoi ;)
Pour corriger cela, j'ai installé une woody toute fraiche sur un nouveau 
disque, et je vais garder l'ancien comme serveur de test_ing.


Le problème se pose quand je veux récupérer les données d'un serveur à 
l'autre.
Après avoir récupérer les fichiers de config sur mon serveur stable, 
j'ai fait un premier test, violent:

monter la partition /var/ de mon ancien serveur sur le nouveau.
Tous mes services redémarrent, j'accède à toutes mes données, je croie 
la partie gagnée..!

et beh non garry : au passage, j'ai perdu le password root de mysql !
La base mysql démarre, tous mes sites fonctionnent (ils accèdent à la 
bdd), mais il m'est impossible de me logguer en root sur la bdd =-O

J'ai perdu mon password mysql...? :-[
Je vérifie en redémarrant sur l'ancien disque : tout fonctionne 
normalement, mon password root mysql également.


Alors ou se cache-t-il ? ce password root mysql !


Au passage, j'ai auusi monté 3 disques *neufs* (maxtor 120Go 8Mo cache) 
en raid 5 logiciel, et pendant que je copiai tranquilement mes données, 
j'ai eu droit à ces jolis messages d'erreurs :


hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide3: reset: success

c grave docteur ?? (la derniere fois que g vu ce genre de message, 
c'était sur un vieux disque qui m'a laché qqs temps après)


Merci de vos réponses !

--
AyA

Re: Migration d'un serveur testing - stable

[Nicolas Rueff]

Le mer 20/08/2003 à 12:32, Yann Autissier a écrit :
 Bonjour la liste,
 Je dispose chez moi d'un serveur debian sur lequel j'héberge qqs sites + 
 bdd.
 Ce serveur, de production, s'est progressivement retrouvé en version 
 _unstable_, va savoir pourquoi ;)
 Pour corriger cela, j'ai installé une woody toute fraiche sur un nouveau 
 disque, et je vais garder l'ancien comme serveur de test_ing.
 
 Le problème se pose quand je veux récupérer les données d'un serveur à 
 l'autre.
 Après avoir récupérer les fichiers de config sur mon serveur stable, 
 j'ai fait un premier test, violent:
 monter la partition /var/ de mon ancien serveur sur le nouveau.
 Tous mes services redémarrent, j'accède à toutes mes données, je croie 
 la partie gagnée..!
 et beh non garry : au passage, j'ai perdu le password root de mysql !
 La base mysql démarre, tous mes sites fonctionnent (ils accèdent à la 
 bdd), mais il m'est impossible de me logguer en root sur la bdd =-O
 J'ai perdu mon password mysql...? :-[
 Je vérifie en redémarrant sur l'ancien disque : tout fonctionne 
 normalement, mon password root mysql également.
 
 Alors ou se cache-t-il ? ce password root mysql !

Seul le hash de ton pass est stocké dans mysl: base mysql, table user.
Je me suis pas spécialiste de mySQL, mais s'est possible que le hash
dépende de la version de mysql (v3 différent de v4 ?). Ça paraitrait
bizarre somme toute, because ça impliquerait de changer tous les pass
des utilisateurs de mysql au passage en v4.

Un remède éventuel: note le contenu du champ password originel,
désactive le mot de passe root de mysql, permute test disques, tente de
te logguer, et si ça marche mets en place le nouveau pass root (le même
que l'ancien), relève le contenu du champ password, et s'ils sont
différents, tu sauras d'ou viens ton pb.

 
 Au passage, j'ai auusi monté 3 disques *neufs* (maxtor 120Go 8Mo cache) 
 en raid 5 logiciel, et pendant que je copiai tranquilement mes données, 
 j'ai eu droit à ces jolis messages d'erreurs :
 
 hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
 hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
 ide3: reset: success
 
 c grave docteur ?? (la derniere fois que g vu ce genre de message, 
 c'était sur un vieux disque qui m'a laché qqs temps après)

Tente un chtit coup de badbocks sur tes disques: en sortie d'usine il
peut y avoir des serveurs défectueux.

Ceci dit, as-tu rodé tes disques ? Quand tu les as formaté, as-tu
vérifié les secteurs défectueux ?

/N 
__

Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
Windoze CEMeNT: Now with CrackGuard(TM)! Never worry about
unsightly cracks in Windoze CEMeNT again! CrackGuard(TM) is
so powerful that the entire thing will crumble before it will
crack. Order your $200 upgrade version today!
__



signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Backport de Xfree-4.2.1 (testing -- stable)

[Etienne]

On Sat, 3 May 2003 14:48:33 +0200 [EMAIL PROTECTED] wrote:

  Voilà, j'utilise une woody à laquelle je voudrais bien rajouter le
  support de l'accélération matérielle dans XFree. Malheureusement,
  pour ma carte (ATI RagePro), celui-ci est encore en développement.
  L'obtenir
 
 La rage pro est bien supporte dans XFree 4.1, mais j'imagine que tu
 veut dire l'acceleration OpenGL/mesa/DRI ? 
 
 Dans ce cas, il est plus facile d'utiliser les backport woody des
 packages 4.3.0 de daniel stone.
[...]
 http://www.linuxcompatible.org/story17614.html

Merci Sven, à part de petites erreurs dans la ligne à rajouter à mon
sources.list, ces packages sont impeccables (Pour mon architecture
x86), la branche mach64-0-0-6 du CVS DRI (accessible via
http://www.retinalburn.net/linux) s'y applique comme un charme, et tout
ce petit monde ronronne comme un chat.

-- 
Tinou

Re: Backport de Xfree-4.2.1 (testing -- stable)

[Sven Luther]

On Sun, May 04, 2003 at 11:40:38PM +0200, Etienne wrote:
 On Sat, 3 May 2003 14:48:33 +0200 [EMAIL PROTECTED] wrote:
 
   Voilà, j'utilise une woody à laquelle je voudrais bien rajouter le
   support de l'accélération matérielle dans XFree. Malheureusement,
   pour ma carte (ATI RagePro), celui-ci est encore en développement.
   L'obtenir
  
  La rage pro est bien supporte dans XFree 4.1, mais j'imagine que tu
  veut dire l'acceleration OpenGL/mesa/DRI ? 
  
  Dans ce cas, il est plus facile d'utiliser les backport woody des
  packages 4.3.0 de daniel stone.
 [...]
  http://www.linuxcompatible.org/story17614.html
 
 Merci Sven, à part de petites erreurs dans la ligne à rajouter à mon
 sources.list, ces packages sont impeccables (Pour mon architecture
 x86), la branche mach64-0-0-6 du CVS DRI (accessible via
 http://www.retinalburn.net/linux) s'y applique comme un charme, et tout
 ce petit monde ronronne comme un chat.

Tu est au courrant des packages DRI de Michel Daenzer ? Cela devrait
t'eviter a les compiler toi meme, je pense, ou du moins de ne pas mettre
des trucs partout sans etre gerer par dpkg.

Amicalement,

Sven Luther

Re: Backport de Xfree-4.2.1 (testing -- stable)

[Etienne]

On Sun, 4 May 2003 23:46:33 +0200 [EMAIL PROTECTED] wrote:

   Dans ce cas, il est plus facile d'utiliser les backport woody des
   packages 4.3.0 de daniel stone.
  [...]
   http://www.linuxcompatible.org/story17614.html
  
  Merci Sven, à part de petites erreurs dans la ligne à rajouter à mon
  sources.list, ces packages sont impeccables (Pour mon architecture
  x86), la branche mach64-0-0-6 du CVS DRI (accessible via
  http://www.retinalburn.net/linux) s'y applique comme un charme, et
  tout ce petit monde ronronne comme un chat.
 
 Tu est au courrant des packages DRI de Michel Daenzer ?

Non.

 Cela devrait t'eviter a les compiler toi meme, je pense, ou du moins
 de ne pas mettre des trucs partout sans etre gerer par dpkg.

Trop tard ! ... Il va falloir que je visite http://people.debian.org de
fond en comble, avant la prochaine manip. :-)

-- 
Tinou

Backport de Xfree-4.2.1 (testing -- stable)

[Etienne]

Bonjour à tous !

Voilà, j'utilise une woody à laquelle je voudrais bien rajouter le
support de l'accélération matérielle dans XFree. Malheureusement, pour
ma carte (ATI RagePro), celui-ci est encore en développement. L'obtenir
par CVS et le recompiler ne me pose pas de problème, mais je rencontre
des soucis pour recompiler la version de XFree avec laquelle il a été
développé. En effet, j'ai rapatrié le package source xfree-4.2.1-3, ses
dépendances, et ai lancé le dpkg-buildpackage kivabien. 2 heures plus
tard, la compilation s'arrête par un No space left on device, le
processus m'a bouffé 1,3 Go d'espace disque. Ca ne me semble pas normal,
la doc de X dit qu'il en faut beaucoup moins (~300 Mo). Toutefois, lors
de la compilation, j'ai vu passer des flags -DDEBUG qui m'ont fait
penser que dpkg-buildpackage créait une version avec le code de
déboggage, ce qui doit prendre beaucoup plus de place. J'ai bien essayé
de chercher dans le debian/rules quelles sont les DEB_BUILD_OPTIONS
qu'il faut lui passer pour éviter cela, mais je n'ai pas trouvé. Le
guide du nouveau mainteneur Debian ne m'a pas plus aidé.

Quelqu'un sait-il où sont listées les options que je peux passer à dpkg
pour construire le package à mon goût ? Quelqu'un sait-il où je peux
trouver la bonne doc ? Quelqu'un voit-il une erreur qui m'a échappé ?

Merci de votre intêret pour ma question.

-- 
Tinou

Re: Backport de Xfree-4.2.1 (testing -- stable)

[Sven Luther]

On Sat, May 03, 2003 at 02:10:52PM +0200, Etienne wrote:
 Bonjour à tous !
 
 Voilà, j'utilise une woody à laquelle je voudrais bien rajouter le
 support de l'accélération matérielle dans XFree. Malheureusement, pour
 ma carte (ATI RagePro), celui-ci est encore en développement. L'obtenir

La rage pro est bien supporte dans XFree 4.1, mais j'imagine que tu veut
dire l'acceleration OpenGL/mesa/DRI ? 

Dans ce cas, il est plus facile d'utiliser les backport woody des
packages 4.3.0 de daniel stone.

 par CVS et le recompiler ne me pose pas de problème, mais je rencontre
 des soucis pour recompiler la version de XFree avec laquelle il a été
 développé. En effet, j'ai rapatrié le package source xfree-4.2.1-3, ses
 dépendances, et ai lancé le dpkg-buildpackage kivabien. 2 heures plus
 tard, la compilation s'arrête par un No space left on device, le
 processus m'a bouffé 1,3 Go d'espace disque. Ca ne me semble pas normal,
 la doc de X dit qu'il en faut beaucoup moins (~300 Mo). Toutefois, lors

Compiler le package debian xfree86 necessite environ 4 Go, compiler
4.3.0 depuis les codes sources upstream necessite bien moins. Il te
suffit d'appliquer le patch attache pour ne pas ecraser ton install
courrante.

 de la compilation, j'ai vu passer des flags -DDEBUG qui m'ont fait
 penser que dpkg-buildpackage créait une version avec le code de
 déboggage, ce qui doit prendre beaucoup plus de place. J'ai bien essayé

Oui, c'est pour le package xfree86-dbg.

 de chercher dans le debian/rules quelles sont les DEB_BUILD_OPTIONS
 qu'il faut lui passer pour éviter cela, mais je n'ai pas trouvé. Le
 guide du nouveau mainteneur Debian ne m'a pas plus aidé.
 
 Quelqu'un sait-il où sont listées les options que je peux passer à dpkg
 pour construire le package à mon goût ? Quelqu'un sait-il où je peux
 trouver la bonne doc ? Quelqu'un voit-il une erreur qui m'a échappé ?

Non, c'est pas possible de faire comme cela. XFree86 est un trop gros
package avec un build systeme trop complexe pour faire ce que tu veut.
Essaye les backport woody des packages 4.3.0. Tu trouver comment faire
sous :

http://www.linuxcompatible.org/story17614.html

Amicalement,

Sven Luther

Re: Backport de Xfree-4.2.1 (testing -- stable)

[Etienne]

On Sat, 3 May 2003 14:48:33 +0200 [EMAIL PROTECTED] wrote:

  Voilà, j'utilise une woody à laquelle je voudrais bien rajouter le
  support de l'accélération matérielle dans XFree. Malheureusement,
  pour ma carte (ATI RagePro), celui-ci est encore en développement.
  L'obtenir
 
 La rage pro est bien supporte dans XFree 4.1, mais j'imagine que tu
 veut dire l'acceleration OpenGL/mesa/DRI ? 

Oui.
 
 Compiler le package debian xfree86 necessite environ 4 Go,

?!?!! Nom de ... ! Mazette, va falloir que je change de HDD, moi. Blague
à part, tu saurais me dire pourquoi ?

 compiler 4.3.0 depuis les codes sources upstream necessite bien moins.
 Il te suffit d'appliquer le patch attache pour ne pas ecraser ton
 install courrante.

Euh ... quel patch ??

 Non, c'est pas possible de faire comme cela. XFree86 est un trop gros
 package avec un build systeme trop complexe pour faire ce que tu veut.
 Essaye les backport woody des packages 4.3.0. Tu trouver comment faire
 sous :
 
 http://www.linuxcompatible.org/story17614.html

Dommage, moi qui cherchais un moyen un peu plus officiel :-) ...

Merci pour les infos ! Je vais essayer.

-- 
Tinou

testing -- stable

[Jean-Paul Lacharme]

Utiliser la version testing ne devrait pas poser de probleme pour un serveur
en exploitation, testing ne devant pas etre loin de stable a de tres petits
details pres a priori sans importance.
En fait, s'il apparait qu'il n'en est rien et que des bugs genants peuvent
rester sans solution pendant un temps incompatible avec une exploitation, la
question de revenir dans le cadre stricte de la distribution normale se pose.
Mais est-ce possible de repasser de testing a stable  ? quelqu'un l'a-t-il
deja fait sans problemes majeurs ? 
--
Jean-Paul LACHARME. Administrateur Reseau. 
GREQAM (UMR6579 CNRS, EHESS, Universites d'Aix-Marseille II et III)
Centre de la Vieille Charite. 2, rue de la Charite. 13002 MARSEILLE. 
Tel.: 04.91.14.07.68. Fax : 04.91.90.02.27. (collectif labo)
http://durandal.cnrs-mrs.fr/PP/lacharme/index.html
--

Re: testing -- stable

[Pierre Machard]

Le lundi 28 avril 2003 à 14:17 +0200, Jean-Paul Lacharme a écrit :
[...]
 question de revenir dans le cadre stricte de la distribution normale se pose.
 Mais est-ce possible de repasser de testing a stable  ? quelqu'un l'a-t-il
 deja fait sans problemes majeurs ? 
 

Le site debianplanet.org a publié un article à ce sujet en Décembre
dernier :

http://www.debianplanet.org/node.php?id=880


a+
-- 
Pierre Machard
[EMAIL PROTECTED]  TuxFamily.org
[EMAIL PROTECTED] techmag.info
+33(0)668 178 365http://migus.tuxfamily.org/gpg.txt
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87


pgpC0PU977lyn.pgp
Description: PGP signature

Re: Postfix prolem (Is it ok to mix testing/stable apt sources?)

[The Nose Who Knows]

 I have both testing and stable sources in my sources.list. I think I
 saw once on this list that it is OK and such mix is supported.

I would hope it is, since testing does not yet seem to contain a
complete distribution and having both stable and testing
simultaneously seems to be the only way to get a testing box working
well.

 I've just run dselect and it upgraded postfix with package from
 stable. However it doesn't want to install properly - on installation
 it runs newaliases which dies with:
 
postalias: fatal: open database /etc/aliases.db: Invalid argument
  
I've had this problem too, the version that apt-get upgrade fetched
for me was 0.0.19991231pl11-1, dated 1-Dec-2000.  Why such an old
package has only now made it into testing I'm not sure.

In a google search I just did, the error message quoted above crops up
quite often on postfix-related lists, suggesting it's a common problem.
The solution cited always seems to be to run newaliases, which doesn't
help us here because that command just gives the above error again.  I
haven't seen an explanation for *why* the message appears, nor why
running newaliases should fix it.

The following changelog.Debian.gz entry seems the only one related to
this problem:

=
postfix (0.0.19991231pl11-1) stable; urgency=high
  * Upstream fixes (see /usr/share/doc/postfix/RELEASE_NOTES),
  * including:
- Postfix must no longer use DB 1.85 compatibility mode, because that
  mode loses the file lock while building a table, so that table
  lookups fail and MAIL IS LOST.  Closes: #78812.
[...]
 -- LaMont Jones [EMAIL PROTECTED]  Fri,  1 Dec 2000 08:48:13 -0700
=

This in turn is referring to this entry from the changelog.gz:

=
20001026

Horror:  postmap and postalias (newaliases) silently lose
the file lock while building a lookup table with Berkeley
DB 2.x and later on Solaris, HP-UX, IRIX, and UNIXWARE.
The result is that table lookups fail while the table is
being built, so that mail is lost.  In order to avoid this
misbehavior one has to use an undocumented feature that is
NOT available with the DB1.85 compatibility interface.
Therefore, Postfix now supports three Berkeley DB programming
interfaces of increasing complexity. File: util/dict_db.c.

=

Would the lack of DB 1.85 compatibility be a problem on machines that
use DB 2.x, and more recently DB 3.x, as the testing tree now seems to
do?  Could it be that the recent addition of DB 3.x to the mix (my box
now has libdb2 2.7.7-7 and libdb3 3.2.9-5) is combining here to cause
this problem?  Any help on this confusing state of affairs is
appreciated.

Please Bcc: me on replies as my subscription to the list doesn't seem to
be working.

-- 
 \
  `\
_o__) BIGNOSE

Postfix prolem (Is it ok to mix testing/stable apt sources?)

[Ilya Martynov]

Hi,

I have both testing and stable sources in my sources.list. I think I
saw once on this list that it is OK and such mix is supported.

I've just run dselect and it upgraded postfix with package from
stable. However it doesn't want to install properly - on installation
it runs newaliases which dies with:

   postalias: fatal: open database /etc/aliases.db: Invalid argument

Downgrading to testing version of postfix seems to fix problem. So
should I post bug report against postfix or I should not bother to do
it because mix of stable/testing is not supported?

-- 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/)|
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80  E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/)  |
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-