Bonjour à tous,
Est-ce que quelqu’un a déjà connu çà :
202 paquets mis à jour, 5 nouvellement installés, 4 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 1 246 Mo d’archives. Après dépaquetage, 1 381 Mo seront utilisés.
Peut-être est-ce la berlue ?
Cela dépend de la date de la dernière mise à jour?
Salut,
Quelle branche ? Quelle fréquence de mise à jour ?
Sur une testing CUT, mise à jour au changement de snapshot…
Salut,
Non, pas chez moi, mise à part le passage de Lenny à Squeeze … 
Récemment ?
Modification du sources ? preferences ? paquets dé-pinnés ?
re,
Sid amd64
Je fais l’upgrade tous les deux ou trois jours habituellement.
La machine étant tombée en panne d’alimentation, la dernière mise à jour remonte peut-être à une semaine, dix jours maxi.
Aucune modif n’a été faite sur les sources ni ailleurs (pas de dépôt expérimental).
Ce qui m’épate c’est la taille du téléchargement pour 202 paquets et l’utilisation sur le disque : 1381 Mo.( même taille en safe ou full-upgrade )
Pour le moment je n’ai pas lancé l’affaire, en attente de comprendre s’il y a quelque chose à comprendre.
J’ajoute la liste des paquets de l’update, je me demande ce qui peut rameuter un tel chargement !
Les NOUVEAUX paquets suivants vont être installés :
gir1.2-gnomekeyring-1.0{a} libgmime2.6-cil{a} libsox2{a}
libtokyocabinet9{a} libtracker-sparql-0.14-0{a}
Les paquets suivants seront ENLEVÉS :
libgmime2.4-cil{u} libsox1b{u} libtokyocabinet8{u}
libtracker-sparql-0.12-0{u}
Les paquets suivants seront mis à jour :
anacron apache2.2-bin baobab brasero brasero-cdrkit brasero-common
browser-plugin-gnash browser-plugin-lightspark coreutils cpp-4.4 cups
cups-bsd cups-client cups-common cups-dbg cups-filters cups-ppdc debconf
debconf-i18n debhelper debootstrap dnet-common exiftran fuse gcc-4.4
gcc-4.4-base gcj-4.4-base gcj-4.4-jre gcj-4.4-jre-headless
gcj-4.4-jre-lib gimp gimp-dbg gir1.2-brasero-3.0 gir1.2-gucharmap-2.90
gir1.2-peas-1.0 gir1.2-rb-3.0 gir1.2-totem-1.0 gir1.2-vte-2.90 gnash
gnash-common gnome-dictionary gnome-font-viewer gnome-pkg-tools
gnome-screenshot gnome-search-tool gnome-system-log gnome-utils-common
gnupg gnupg-curl gpgv graphviz grilo-plugins-0.1 gucharmap hfsprogs
iceweasel iceweasel-l10n-fr isc-dhcp-client isc-dhcp-common kdelibs-bin
kdelibs5-data kdelibs5-plugins kdoctools kmod libbrasero-media3-1
libbrasero-media3-dev libbrlapi0.5 libcdt4 libcgraph5 libcups2
libcupscgi1 libcupsdriver1 libcupsfilters1 libcupsimage2 libcupsmime1
libcupsppdc1 libdc1394-22 libdnet libemail-valid-perl libfltk1.1 libfuse2
libgcj10 libgcj10-awt libgdata-common libgdata13 libgdict-1.0-6
libgimp2.0 libgimp2.0-dev libgmime-2.6-0 libgnutls26 libgraph4
libgrilo-0.1-0 libgucharmap-2-90-7 libgvc5 libgvpr1 libgweather-3-0
libgweather-common libicu48 libidn11 libkcmutils4 libkde3support4
libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4 libkemoticons4
libkfile4 libkhtml5 libkidletime4 libkio5 libkjsapi4 libkjsembed4
libkmediaplayer4 libkmod2 libknewstuff3-4 libknotifyconfig4 libkntlm4
libkparts4 libkprintutils4 libkpty4 libkrosscore4 libktexteditor4
libkutils4 libmozjs10d libnautilus-extension1a libnepomuk4
libnepomukquery4a libnepomukutils4 libopenraw1 libp11-kit0
libpackagekit-glib2-14 libpathplan4 libpeas-1.0-0 libpeas-common
libplasma3 librhythmbox-core5 libsamplerate0 libslang2 libsolid4
libsox-fmt-alsa libsox-fmt-base libssl1.0.0 libthreadweaver4 libtotem0
libvte-2.90-9 libvte-2.90-common libwpd-0.9-9 libxcb-composite0
libxcb-dri2-0 libxcb-randr0 libxcb-render0 libxcb-render0-dev
libxcb-shape0 libxcb-shm0 libxcb-shm0-dev libxcb-xfixes0 libxcb-xinerama0
libxcb-xtest0 libxcb-xv0 libxcb1 libxcb1-dev libxdot4 libzvbi-common
libzvbi0 lightspark-common lintian linux-image-3.2.0-2-amd64
linux-libc-dev lsb-base lsb-release luckybackup luckybackup-data
module-init-tools mozilla-plugin-gnash mpd mplayer mutt nautilus
nautilus-data openclipart openclipart-libreoffice openclipart-png
openclipart-svg openssl os-prober packagekit packagekit-backend-aptcc
packagekit-bash-completion python-brlapi python-gobject-2
python-gtk-gnash python-opengl python-packagekit rhythmbox rhythmbox-data
rhythmbox-plugin-cdrecorder rhythmbox-plugins rsyslog sox synaptic tomboy
totem totem-common totem-mozilla totem-plugins xulrunner-10.0
Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés :
svn-buildpackage
206 paquets mis à jour, 5 nouvellement installés, 4 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 1 247 Mo d’archives. Après dépaquetage, 1 381 Mo seront utilisés.
[quote=“eggregor”]re,
Sid amd64
Je fais l’upgrade tous les deux ou trois jours habituellement.
La machine étant tombée en panne d’alimentation, la dernière mise à jour remonte peut-être à une semaine, dix jours maxi.
Aucune modif n’a été faite sur les sources ni ailleurs (pas de dépôt expérimental).
Ce qui m’épate c’est la taille du téléchargement pour 202 paquets et l’utilisation sur le disque : 1381 Mo.
Pour le moment je n’ai pas lancé l’affaire, en attente de comprendre s’il y a quelque chose? à comprendre[/quote]
La liste des paquets peut-être ?
Un souci avec le journal ? 
@ lol,
J’y avais songé pendant que tu écrivais, j’éditais donc, maintenant c’est parti, qu’en penses-tu ?
@loreil
le journal justement:
Enregistrement terminé.
Aptitude 0.6.5: journal
ven., mars 16 2012 11:29:22 +0100
IMPORTANT : ce journal ne contient que les actions demandées ; certaines actions qui
échouent à cause d’erreurs de dpkg peuvent donc ne pas être réalisées.
1 paquets vont être installés, et 0 retirés.
1 514 ko d’espace disque vont être utilisés
Tout foire dans les chiffres.
Pour ma part ça n’a vraiment rien d’étonnant en ce sens où c’est une Sid, qui est donc amenée à bouger constamment. Elle est justement faite pour ça.
@loreleil, pardon d’avoir faute de frappé ton pseudo,
en fait le journal annonce un paquet mais développe bien une liste convergente avec celle figurant dans l’update, normal de ce point de vue.
Je pense que je vais lancer l’upgrade, si çà annonce deux heures de téléchargement j’interromprai.
@cluster,
quand même, une telle mise à jour ! même en sid.
il y a une coquille par ailleurs c’est certain.
Edit : Bon pas deux mais 57 minutes !
Je préfère attendre vos avis, çà me paraît suspect.
Des sauvegardes avant, nan ? si ce n’est pas déjà fait …
Re,
C’est openclipart et sa bande le grassouillet…
apt-get install openclipart
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
fonts-sil-gentium fonts-sil-gentium-basic libreoffice libreoffice-filter-mobiledev libreoffice-report-builder-bin librsvg2-bin
openclipart-libreoffice openclipart-png openclipart-svg ttf-sil-gentium-basic
Paquets suggérés :
unixodbc libreoffice-gnome libreoffice-kde libreoffice-officebean ksvg gimp-svg sodipodi sketch
Les NOUVEAUX paquets suivants seront installés :
fonts-sil-gentium fonts-sil-gentium-basic libreoffice libreoffice-filter-mobiledev libreoffice-report-builder-bin librsvg2-bin
openclipart openclipart-libreoffice openclipart-png openclipart-svg ttf-sil-gentium-basic
0 mis à jour, 11 nouvellement installés, 0 à enlever et 27 non mis à jour.
Il est nécessaire de prendre 1 016 Mo dans les archives.
Après cette opération, 1 798 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?
Fait le reste et openclipart quand tu auras le temps…
Pour voir d’où vient toute cette différence :
[code]# aptitude --schedule-only upgrade
La seule chose qui nous intéresse c’est la sortie de aptitude search.
La première ligne permet à la deuxième d’afficher la différence de taille pour chaque paquet sans pour autant déclencher l’upgrade (vive l’option --schedule-only 
), et la troisième ligne remet tout en place pour éviter les bêtises. 
Edit : oups, lol a été plus rapide que moi.
Bravo, deux coups de cuiller à pot dit-on dans nos campagnes et dans l’Isalo.
Mais pourquoi ai-je openclipart dans mes valises ?
Parce que je ne clip’ pas beaucoup que je sache. Comment fait-on pour “retirer un paquet de la liste”, je ne me suis jamais posé la question jusqu’ici.
Je vais de ce pas tester de suite le shedule de syam.
Merci les gars.
Vu qu’il est déjà dans tes valises, il suffit de le désinstaller.
Éventuellement s’il réapparaît quand même lors de l’upgrade (mais j’en doute), appelle aptitude --without-recommends upgrade
Re,
Oui, ou le mettre en hold:
Je tente le passage en hold de openclipart, je relance l’upgrade et voilà le résultat.
Y aurait-il un autre grassouillet dans la besace ?
Je regarde tout ce qui touche à libreoffice.
205 paquets mis à jour, 5 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de télécharger 1 247 Mo/1 247 Mo d’archives. Après dépaquetage, 1 384 Mo seront utilisés.
Les paquets suivants ont des dépendances non satisfaites :
openclipart: Dépend: openclipart-libreoffice (= 0.18+dfsg-12) mais 2.0-1 doit être installé.
Les actions suivantes permettront de résoudre ces dépendances :
Conserver les paquets suivants dans leur version actuelle :
openclipart-libreoffice [0.18+dfsg-12 (now, testing)]
openclipart-png [0.18+dfsg-12 (now, testing)
@ syam
J’ai tenté ta formule mais elle ne rend pas le retour escompté
Mais idée ! après vérif je n’ai aucun paquet shedule, lequel dois-je choisir ?
[quote=“eggregor”]@ syam
J’ai tenté ta formule mais elle ne rend pas le retour escompté
Mais idée ! après vérif je n’ai aucun paquet shedule, lequel dois-je choisir ?[/quote]
Il n’est pas question d’un paquet “schedule” mais de l’option --schedule-only qui dit à aptitude de mettre les actions demandées en file d’attente sans les réaliser pour autant.
Normalement en faisant les 3 lignes que je t’ai données ça devrait te retourner quelque chose du genre :
[code]# aptitude --schedule-only upgrade
kde-l10n-fr – 4:4.6.5-1 => 4:4.7.4-2 – Libérera 833 ko d’espace
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 7 non mis à jour.
Il est nécessaire de télécharger 0 o d’archives. Après dépaquetage, 0 o seront utilisés.[/code]
Si ça n’est pas le cas, dis-moi quelle version d’aptitude tu as (aptitude --version) car il a parfois des comportements bizarres d’une version à l’autre avec certains filtres de recherche.
Je songeais à un paquet parce que j’ai un retour comme çà :
debian:/home/eggregor# aptitude --schedule-only upgrade
Résolution des dépendances…
debian:/home/eggregor# aptitude search ~U -F ‘%p – %V => %V – %u’ | cat
anacron – 2.3-16 => 2.3-16 – Utilisera 916 Mo d’espac
apache2.2-bin – 2.2.22-2 => 2.2.22-2 – Utilisera 916 Mo d’espac
baobab – 3.2.1-3 => 3.2.1-3 – Utilisera 916 Mo d’espac
brasero – 3.2.0-4 => 3.2.0-4 – Utilisera 916 Mo d’espac
brasero-cdrkit – 3.2.0-4 => 3.2.0-4 – Utilisera 916 Mo d’espac
brasero-common – 3.2.0-4 => 3.2.0-4 – Utilisera 916 Mo d’espac
browser-plugin-gnash – 0.8.10-5 => 0.8.10-5 – Utilisera 916 Mo d’espac
Pour avoir essayé trois fois, je précise que “l’utilisera” par ligne est passé de 1381 Mo 1ère réponse, 2848 ko et des brouettes, second tentative et 916 Mo dans celle-ci.
J’ai beau lire et relire je recopie bien ce que tu as transmis ?
Ok ok il semblerait que tu aies toujours aptitude 0.6.4 (tous les 0.6.x ont des bugs dans les filtres de recherche, pas forcément les mêmes d’une version à l’autre 
).
Ceci devrait être bon normalement :
aptitude search '!~aupgrade' -F '%p -- %V => %V -- %u' | catEdit : ah ben non en fait t’as bien la 0.6.5 comme moi d’après ton fichier de log /var/log/aptitude… Mystère… M’enfin la commande ci-dessus devrait fonctionner quand même (elle marche chez moi avec la 0.6.5 et marchait déjà avec les 0.6.4 et 0.6.3)