LMDE BREAKAGES - tracking TESTING

Archived topics about LMDE 1
Forum rules
zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Sun Dec 02, 2012 8:10 am

fiver22 wrote:I should I bite the bullet and install ia32libs because more things will now be converted to multiarch -can do
hi :) what i was trying to say is that now the conversion to multiarch is imperative (we might not see the issues now if we don't do it but we will soon)

Code: Select all

~ $ dpkg --print-architecture
amd64
if outputs amd64 we are eligible to multiarch conversion

Code: Select all

~ $ dpkg --print-foreign-architectures
~ $ 
and before we start this command has to output nothing and return to the prompt again

Code: Select all

sudo dpkg --add-architecture i386

Code: Select all

sudo sed -i 's/deb\ /deb\ [arch=amd64,i386]\ /g' /etc/apt/sources.list

Code: Select all

sudo apt-get update

Code: Select all

~ $ dpkg --print-foreign-architectures
i386
now has to output i386
fiver22 wrote:should I change the pinning to all the same? 500, 500, 500 for example?
that option will give you less chances of troubles in the long run but be aware that if you decide to enable the experimental repo for example (that should have a priority of 1 in normal conditions thus never having nothing from there automatically installed) the 3rd rule is overwriting that and giving all the debian repos the same priority (meaning that you can end up with upgrades to experimental without realizing and that i can assure you is not a good thing :lol: )
Image

[ bliss of ignorance ]

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Sun Dec 02, 2012 8:32 am

as a side note just to give an idea of the multiarch impact:
this is a very very old system (probably fev 2011) it's a bit unmaintained now but until a few months ago was my main system; wasn't multiarch and today the first output of DU was

Code: Select all

301 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 441 MB of archives.
After this operation, 21.4 MB of additional disk space will be used.
Do you want to continue [Y/n]? n
now minutes after and with multiarch the output is

Code: Select all

302 upgraded, 153 newly installed, 3 to remove and 0 not upgraded.
Need to get 501 MB of archives.
After this operation, 83.5 MB of additional disk space will be used.
Image

[ bliss of ignorance ]

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Sun Dec 02, 2012 9:53 am

dpkg --print-architecture did output amd64
and dpkg --print-foreign-architectures output nothing, as expected
so I did sudo dpkg --add-architecture i386
and then sudo sed -i 's/deb\ /deb\ [arch=amd64,i386]\ /g' /etc/apt/sources.list -my bash skills aren't up to par but I see that that writes "[arch=amd64,i386]" to non 'deb-src' lines in sources.list, a la:

Code: Select all

deb [arch=amd64,i386] http://packages.linuxmint.com/ debian main upstream import
deb-src http://packages.linuxmint.com/ debian main upstream import
deb [arch=amd64,i386] http://ftp.us.debian.org/debian/ testing main contrib non$
deb [arch=amd64,i386] http://security.debian.org/ testing/updates main contrib $
deb [arch=amd64,i386] http://www.deb-multimedia.org testing main non-free
I've also changed my apt-pinning to 500, 500, 500.
sudo apt-get update, then dist-upgrade gives

Code: Select all

The following packages will be REMOVED:
  thunderbird
The following packages will be upgraded:
  banshee gtk2-engines-aurora hunspell-en-us xchat-common
4 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 6,099 kB of archives.
After this operation, 51.5 MB disk space will be freed.
Not much of a change -must be because I don't happen to use 32bit apps (as zerozero mentioned).
Thanks again for the advice -all appears well.

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Wed Jan 02, 2013 3:20 pm

Hello fellow followers of testing. I have a general question about tracking testing: Is there a time I should be watching out for when Testing becomes particularly dangerous, or conversely approaches stability (and so becomes stagnant)?
I've read over a few docs on stable and testing but to be honest with you, I find them a bit confusing. I get that testing eventually becomes the new stable, of course -but some of the details are a bit over my head.
So yeah, basically: is there a time I should be watching for when tracking testing enters a phase that is more dangerous to system stability than it is right now?
Many thanks, I enjoy following this slightly more 'on the edge' version of mint/debian-testing and enjoy learning when things go a little wrong. I back up the system with clonezilla in case of major problems.

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Wed Jan 02, 2013 3:40 pm

testing will become volatile a couple weeks after debian 7 goes gold (can happen next feb), until then (and since last june) with the deep-freeze not much is going on neither on testing nor in sid but there's a huge backlog of updates to catch-up (that are most of them "stored" in experimental) and when "they open the gates again" is when we can/will see issues :mrgreen:
Image

[ bliss of ignorance ]

cwwgateway
Level 5
Level 5
Posts: 839
Joined: Fri Nov 11, 2011 10:44 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by cwwgateway » Wed Jan 02, 2013 8:20 pm

zerozero is very correct. For about a year and a half, testing rolls normally, and for most of that time its stability is fairly consistent (whenever big new releases and package migrations happen, there can be problems, but there are consistently these problems :lol: ). I have heard that generally, after the release of squeeze the updates weren't too bad (although I don't think the people who were talking used gnome). However, there will be lots of leaps during this time period, so I would be very careful about upgrading. The linux kernel is due for an update (3.2 to whatever is in experimental - 3.6 or 3.7), and gnome will be updated to 3.6 (among many other updates). The gnome update will probably break cinnamon, so if you use that I would be careful. It's possible the cinnamon package from sid migrates to testing, and afterwards the maintainers rebuild this package for gnome 3.6, but I don't know if that will happen. Otherwise, testing is very stable towards the end of the freeze, because Debian is about to make a stable release, so none of the packages will have release critical bugs.

Otherwise, testing is fairly stable, but when a package breaks it can take a lot more time to fix than in sid. Packages migrate to testing from sid when they're 10 days old, have no known rc-critical bugs, have all of their dependencies satisfied, etc. If package foo 1.3.1 migrates to testing and a very big bug is found with it afterwards, the maintainer will fix this bug (or upstream will) and it will be updated in sid (let's say 1.3.2). However, someone could find a seperate rc-critical bug, which would cause the package to need to be updated again (now it might be 1.3.3). This means it would take at least 20 days, in addition to the time it takes for a dev to fix the bug, so lets say 30 days (5 days per bug, plus 20). However, what if sid has bar version 1.2, but testing has bar version 1.1. Package foo 1.3.3 depends on bar 1.2, but an rc-critical bug was found in bar 1.2. This could mean it would take a lot of time (2+ months) for foo to get updated in testing. If a big package has hundreds of dependencies, then you could imagine the possible problems.

You can kind of disregard the last paragraph, but I just figured that out after a while of thinking, so I wanted to write it down/share it :D . Anyways, welcome to testing, and may the odds be ever in your favor :mrgreen: .
Dell XPS 15 l502x - Debian Testing 64-bit NetInst Xfce, SolydX 64-bit Debian Testing, SolydK 64-bit SolydXK Testing
Old Gateway Pentium 4 Desktop - Arch Linux 64-bit Xfce and SolydX 32-bit Sid

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Wed Jan 02, 2013 8:50 pm

no :D cww, you are spot on in that analysis
the transition to gnome 3.2 well documented here took long months and ultimately delayed UP4 (because Clem didn't want to upgrade lmde to a half-backed gnome-shell3.0 and because the mint projects at the time <mgse> were GS3.2 compatible)

also this breakage nothing minor: just xorg, nvidia and ati :mrgreen: took also months because everytime the issue was about to be solved, a new version was uploaded to sid.
Image

[ bliss of ignorance ]

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Thu Jan 03, 2013 12:19 am

Thanks very much zerozero and cwwgateway -lots of good info. As for gnome updates... I installed last from 201204-XFCE, then switched sources

Code: Select all

####TRACK TESTING ADDED PAR MOI SET PINNING TO EQUAL###
deb [arch=amd64,i386] http://packages.linuxmint.com/ debian main upstream import
deb-src http://packages.linuxmint.com/ debian main upstream import
deb [arch=amd64,i386] http://ftp.ca.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.ca.debian.org/debian/ testing main contrib non-free
deb [arch=amd64,i386] http://security.debian.org/ testing/updates main contrib non-free
deb [arch=amd64,i386] http://www.deb-multimedia.org testing main non-free

####SIDUCTION FOR XFCE4####
deb http://packages.siduction.org/xfcenext unstable main
deb-src http://packages.siduction.org/xfcenext unstable main

####VirtualBox FOR WHEEZY####
deb http://download.virtualbox.org/virtualbox/debian wheezy contrib
...so aside from all the weird (well, I don't know what they're for so I call them weird;)) gnome dependencies it's pretty much just xfce for me.
The main things that 'break' for me is nvidia/xorg, and I don't know that I'd even call that a breakage -I just run smxi if x fails and reinstall the proprietary drivers.
To be honest, I kind of like it when little things break a bit because I usually learn something new.
Again, many thanks o/

User avatar
mockturtl
Level 4
Level 4
Posts: 452
Joined: Sat Oct 09, 2010 8:51 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by mockturtl » Thu Jan 03, 2013 1:12 am

cwwgateway wrote:If package foo 1.3.1 migrates to testing and a very big bug is found with it afterwards, the maintainer will fix this bug (or upstream will) and it will be updated in sid (let's say 1.3.2). However, someone could find a seperate rc-critical bug, which would cause the package to need to be updated again (now it might be 1.3.3). This means it would take at least 20 days
RC fixes (in reportbug terms: "critical," "grave," "serious") can be fast-tracked, and avoid the 10-day migration period.
Image

GeneBenson
Level 4
Level 4
Posts: 342
Joined: Fri Sep 17, 2010 9:55 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by GeneBenson » Thu Jan 03, 2013 4:48 am

Hi fiver22,

In addition to the excellent info already given I have a tip for you. Have a look in the thread just above this one entitled: LMDE BREAKAGES - (Tracking SID!) - Jan 2, 2013.
There are a number of brave souls here tracking Sid. Any issues will usually be reported there first. Most of the time these issues will be fixed before the updates enter testing. Just nice to know what's going on.
The main things that 'break' for me is nvidia/xorg, and I don't know that I'd even call that a breakage -I just run smxi if x fails and reinstall the proprietary drivers.
Another tip for you. If you are using Nvidia proprietary drivers then you can do the following whenever a new kernel is installed. Make a note of the kernel version just installed. For example, the last kernel (64 bit) was 3.2.0-4-amd64. After smxi is finished with updates then choose "quit". Then simply issue this command at the prompt:

Code: Select all

sgfxi -K 3.2.0-4-amd64
This will install the latest Nvidia driver for your new kernel. When it's finished just reboot.

Hope this helps. :wink:

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Thu Jan 03, 2013 6:32 pm

Many thanks for the replies and suggestions, folks. Much appreciated. Merci bien.

timbo
Level 1
Level 1
Posts: 47
Joined: Sun Oct 09, 2011 5:06 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by timbo » Sun Jan 06, 2013 11:23 am

zerozero wrote:
fiver22 wrote:I should I bite the bullet and install ia32libs because more things will now be converted to multiarch -can do
hi :) what i was trying to say is that now the conversion to multiarch is imperative (we might not see the issues now if we don't do it but we will soon)

Code: Select all

~ $ dpkg --print-architecture
amd64
if outputs amd64 we are eligible to multiarch conversion

Code: Select all

~ $ dpkg --print-foreign-architectures
~ $ 
and before we start this command has to output nothing and return to the prompt again

Code: Select all

sudo dpkg --add-architecture i386

Code: Select all

sudo sed -i 's/deb\ /deb\ [arch=amd64,i386]\ /g' /etc/apt/sources.list

Code: Select all

sudo apt-get update

Code: Select all

~ $ dpkg --print-foreign-architectures
i386
now has to output i386
fiver22 wrote:should I change the pinning to all the same? 500, 500, 500 for example?
that option will give you less chances of troubles in the long run but be aware that if you decide to enable the experimental repo for example (that should have a priority of 1 in normal conditions thus never having nothing from there automatically installed) the 3rd rule is overwriting that and giving all the debian repos the same priority (meaning that you can end up with upgrades to experimental without realizing and that i can assure you is not a good thing :lol: )
Can I revert these changes? I'm not willing to risk nuclear meltdown on my system just for the sake of skype =)

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Sun Jan 06, 2013 11:45 am

timbo,
yeahh you can revert those changes

Code: Select all

dpkg --remove-architecture i386
should do it
test the result with

Code: Select all

dpkg --print-foreign-architectures
(should output nothing)

but the big question is that is not only skype, is google-earth, wine, acrobat reader, the next update of video4linux support libraries (and who knows exactly what else to come?)

so i would say that for sure going forward you'll have more problems if you skip multiarch than if you convert to it.
Image

[ bliss of ignorance ]

timbo
Level 1
Level 1
Posts: 47
Joined: Sun Oct 09, 2011 5:06 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by timbo » Sun Jan 06, 2013 12:23 pm

zerozero wrote:timbo,
yeahh you can revert those changes

Code: Select all

dpkg --remove-architecture i386
should do it
test the result with

Code: Select all

dpkg --print-foreign-architectures
(should output nothing)

but the big question is that is not only skype, is google-earth, wine, acrobat reader, the next update of video4linux support libraries (and who knows exactly what else to come?)

so i would say that for sure going forward you'll have more problems if you skip multiarch than if you convert to it.
Hey dude,

thanks for the swift response. You know, I had written my previous post after doing "dist-upgrade" and then checking which dependencies I'd have to install in order to use Skype.

Code: Select all

sudo aptitude install ia32-libs
The following NEW packages will be installed:
  esound-common{a} freeglut3:i386 gcc-4.7-base:i386{a} ia32-libs 
  ia32-libs-i386:i386 lesstif2:i386 libacl1:i386 libaio1:i386 
  libasound2:i386{a} libasyncns0:i386 libattr1:i386{a} libaudio2:i386 
  libaudiofile1:i386 libavahi-client3:i386 libavahi-common-data:i386{a} 
  libavahi-common3:i386{a} libbsd0:i386 libc6:i386{a} libc6-i686:i386{a} 
  libcaca0:i386{a} libcap2:i386 libcomerr2:i386 libcups2:i386 libcurl3:i386 
  libdb5.1:i386{a} libdbus-1-3:i386{a} libdirectfb-1.2-9:i386 
  libdrm-intel1:i386{a} libdrm-nouveau1a:i386{a} libdrm-radeon1:i386{a} 
  libdrm2:i386{a} libedit2:i386 libesd0:i386 libexif12:i386 
  libexpat1:i386{a} libffi5:i386{a} libflac8:i386 libfltk1.1:i386 
  libfontconfig1:i386{a} libfreetype6:i386{a} libgcc1:i386{a} 
  libgcrypt11:i386{a} libgd2-xpm:i386{a} libgdbm3:i386 
  libgl1-mesa-dri:i386{a} libgl1-mesa-glx:i386{a} libglapi-mesa:i386{a} 
  libglu1-mesa:i386 libgnutls26:i386{a} libgpg-error0:i386{a} 
  libgphoto2-2:i386 libgphoto2-port0:i386{a} libgpm2:i386{a} 
  libgssapi-krb5-2:i386{a} libice6:i386{a} libidn11:i386{a} 
  libieee1284-3:i386 libjack-jackd2-0:i386 libjbig0:i386 libjpeg62:i386 
  libjpeg8:i386{a} libjson0:i386{a} libk5crypto3:i386{a} 
  libkeyutils1:i386{a} libkrb5-3:i386{a} libkrb5support0:i386{a} 
  liblcms1:i386 libldap-2.4-2:i386{a} libltdl7:i386{a} liblzma5:i386{a} 
  liblzo2-2:i386 libmpg123-0:i386 libncursesw5:i386{a} libnspr4:i386 
  libnspr4-0d:i386 libnss3:i386 libnss3-1d:i386 libodbc1:i386 
  libogg0:i386{a} libopenal1:i386 libp11-kit0:i386{a} libpam0g:i386 
  libpciaccess0:i386{a} libpng12-0:i386{a} libpopt0:i386 libpulse0:i386{a} 
  librtmp0:i386{a} libsamplerate0:i386{a} libsane:i386 
  libsane-extras:i386{a} libsasl2-2:i386{a} libsasl2-modules:i386{a} 
  libsdl1.2debian:i386 libselinux1:i386 libsigc++-2.0-0c2a:i386 
  libslang2:i386{a} libsm6:i386{a} libsndfile1:i386{a} libsqlite3-0:i386{a} 
  libssh2-1:i386{a} libssl1.0.0:i386{a} libstdc++5:i386 libstdc++6:i386{a} 
  libsvga1:i386 libsysfs2:i386 libtasn1-3:i386{a} libtdb1:i386 
  libtiff4:i386{a} libtinfo5:i386{a} libts-0.0-0:i386{a} 
  libusb-0.1-4:i386{a} libuuid1:i386{a} libv4l-0:i386{a} 
  libv4lconvert0:i386{a} libvorbis0a:i386{a} libvorbisenc2:i386{a} 
  libvorbisfile3:i386 libwrap0:i386{a} libx11-6:i386{a} libx11-xcb1:i386{a} 
  libx86-1:i386{a} libxau6:i386{a} libxaw7:i386 libxcb-glx0:i386{a} 
  libxcb-render-util0:i386 libxcb-render0:i386{a} libxcb1:i386{a} 
  libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386{a} 
  libxdmcp6:i386{a} libxext6:i386{a} libxfixes3:i386{a} libxft2:i386{a} 
  libxi6:i386{a} libxinerama1:i386{a} libxml2:i386 libxmu6:i386{a} 
  libxmuu1:i386 libxp6:i386{a} libxpm4:i386{a} libxrandr2:i386 
  libxrender1:i386{a} libxslt1.1:i386 libxss1:i386 libxt6:i386{a} 
  libxtst6:i386{a} libxv1:i386 libxxf86vm1:i386{a} odbcinst{a} 
  odbcinst1debian2{a} odbcinst1debian2:i386 uuid-runtime{a} xaw3dg:i386 
  zlib1g:i386{a}
Will this list cause me any trouble or is it what I'll need for multiarch anyeways?

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Sun Jan 06, 2013 12:37 pm

it should be fine (meaning tis that i don't see in there nothing particularly strange)
1- enabling multiarch and then installing a 32bit app (like skype or wine) will always install a bunch of i386 libraries (that are duplications of the same amd64 lib that we already had in the system >> basically this exactly multiarch)
2- if it was me i would use apt instead of aptitude: there's several bug reports showing problems between aptitude and multiarch systems.
Image

[ bliss of ignorance ]

timbo
Level 1
Level 1
Posts: 47
Joined: Sun Oct 09, 2011 5:06 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by timbo » Sun Jan 06, 2013 2:07 pm

zerozero wrote:it should be fine (meaning tis that i don't see in there nothing particularly strange)
1- enabling multiarch and then installing a 32bit app (like skype or wine) will always install a bunch of i386 libraries (that are duplications of the same amd64 lib that we already had in the system >> basically this exactly multiarch)
2- if it was me i would use apt instead of aptitude: there's several bug reports showing problems between aptitude and multiarch systems.
alright that is what i thought. thank you for helping me out here and i'll definitely keep your advise concerning aptitude in mind from here onwards!

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Sun Jan 13, 2013 5:55 pm

Hallo, hallo.
Another question or two if someone has the time:
Today brings me

Code: Select all

accountsservice exim4-config gir1.2-accountsservice-1.0 gjs gnome-shell
  gnome-shell-common grub-common grub-pc grub-pc-bin grub2-common
  libaccountsservice0 libgjs0b libpython2.7 python2.7 python2.7-dev
  python2.7-minimal tar
I'm curious why it even wants gnome-shell and how I can stop it (if that's wise).

Second question is again regarding sources.list and the state of wheezy/testing:
I saw that 'widget', in another thread said [quote=widget](...)"When Wheezy is released, hopefully early next month, anyone using the term "testing" in the sources.list instead of "wheezy" will get a huge update/upgrade dumped on them with the change to Jessie. You may want to have an extra install to test that on to see if it breaks anything."[/quote]
For the sake of stability does that mean I want to replace each instance of the word 'testing' with 'wheezy' in

Code: Select all

deb [arch=amd64,i386] http://packages.linuxmint.com/ debian main upstream import
deb-src http://packages.linuxmint.com/ debian main upstream import
deb [arch=amd64,i386] http://ftp.ca.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.ca.debian.org/debian/ testing main contrib non-free
deb [arch=amd64,i386] http://security.debian.org/ testing/updates main contrib non-free
deb [arch=amd64,i386] http://www.deb-multimedia.org testing main non-free
just before the change to Jessie? so I avoid all the brand new testing changes? Or is even early/new testing fairly stable?
Thanks again for your time!
(edit: spelling)
Last edited by fiver22 on Sun Jan 13, 2013 7:01 pm, edited 1 time in total.

cwwgateway
Level 5
Level 5
Posts: 839
Joined: Fri Nov 11, 2011 10:44 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by cwwgateway » Sun Jan 13, 2013 6:56 pm

What packages are being upgraded? I'd assume one of them now depends on gnome-shell, and I don't know which one that would be.

As for the second question, switching from testing to wheezy would increase stability because wheezy would be "Stable." You could switch to wheezy and then switch back once testing calms down a little bit, but that could have varying success depending on how long you wait to upgrade (but it should be safe as long as you don't wait too long). I honestly don't know how rocky testing will be once wheezy is released (I didn't use linux when squeeze was released), but I'd imagine/hope that it won't be completely unstable - it won't be completely stable either, but it won't be so much worse than testing normally is when it isn't frozen.
Dell XPS 15 l502x - Debian Testing 64-bit NetInst Xfce, SolydX 64-bit Debian Testing, SolydK 64-bit SolydXK Testing
Old Gateway Pentium 4 Desktop - Arch Linux 64-bit Xfce and SolydX 32-bit Sid

User avatar
fiver22
Level 1
Level 1
Posts: 44
Joined: Wed Feb 01, 2012 8:08 am

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by fiver22 » Sun Jan 13, 2013 7:05 pm

cwwgateway wrote:What packages are being upgraded? I'd assume one of them now depends on gnome-shell, and I don't know which one that would be.
(...)
Just looked and they're actually all upgrades O.o 0 newly installed. Dunno how THAT happened. I'm running xfce4.10 -partly because I'm on old hardware :D I didn't realize I had so much gnome/gnome-shell.

zerozero
Level 16
Level 16
Posts: 6507
Joined: Tue Jul 07, 2009 2:29 pm

Re: LMDE BREAKAGES - tracking TESTING - updated 2 Dec

Post by zerozero » Sun Jan 13, 2013 7:31 pm

fiver,
i would start looking for the usual suspect

Code: Select all

dpkg -l | grep nautilus
in 2 xfce installs it reports

Code: Select all

zerozero@debian:~$ dpkg -l | grep nautilus
ii  libnautilus-extension1a                     3.4.2-1+build1                     amd64        libraries for nautilus components - runtime version

Code: Select all

zerozero@un-xfce:~$ dpkg -l | grep nautilus
ii  libnautilus-extension1a                3.4.2-1+build1                       amd64        libraries for nautilus components - runtime version
just that.
i bet that your list is bigger :shock:
Image

[ bliss of ignorance ]

Locked

Return to “LMDE 1 Archive”