LMDE BREAKAGES - (Tracking SID!) -{CLOSED}

[GregE]

all the problems with ia32 and multiarch, along with Gnome imploding make me glad I am using i386 and KDE.

Fully upgraded sid using daily apt-get dist-upgrade, no problems here. With 1933 installed packages.

I think it is hard to argue against using 32bit Debian with a PAE kernel. It would certainly make for an easier computing life. That is what I do on my notebook and multi-media computer because I do not want to waste time maintaining three computers the hard way. With a fast processor and a big bunch of ram the extra speed of 64bit computing is negligible.

Anyway I am nearly fixed with my 64bit multi-arch. A problem with libsasl is blocking Wine, but the rest is working. The worst part is that I do not really need Wine, it just irks me that it is broken. I will look in Debian bugs and try and solve the Sasl issues.

EDIT: there is a bug in libsasl, I think it will all resolve in a day or two.
EDIT2: By not installing Wine LDAP everything works and Wine is back functioning - except of course for programs requiring LDAP. That should resolve with the libsasl stuff. That was a waste of several hours.

My system is back and running as it should.

[Brian49]

With 1933 installed packages.

That's a lot of packages. Only 703 here.

[jackmetal]

With 1933 installed packages.

That's a lot of packages. Only 703 here.

I'm running with 2988 packages. Of course, I have not only full gnome-shell installed, but also kde, fluxbox and xfce as backups. Sometimes I like to switch out desktops I'm using to keep things fresh. LOL

[ericcc65]

ericcc65 - I noticed something similar when an update to xfce4-mixer came through recently. My preference is to pin such auxiliary packages and keep Xfce 4.10, at least until the developers of the auxiliary packages catch up with the latest Xfce.

Sorry for the dumb question here. I've searched a bunch on pinning packages. It seems that it is used to get packages from a different branch, which is what I did to get Xfce 4.10 from experimental. I'm not seeing how that would help me with all of these xfce-*-panel packages that want to upgrade to a minor release but won't let me with Xfce 4.10. Care to shed light? Or is there anyone else running Xfce 4.10 from experimental? I suspect since these are minor updates that I should be able to force an upgrade, but I'm not sure what that would do after that when next versions of the packages come along and to my dependency checking.

[GregE]

ericcc65 - I noticed something similar when an update to xfce4-mixer came through recently. My preference is to pin such auxiliary packages and keep Xfce 4.10, at least until the developers of the auxiliary packages catch up with the latest Xfce.

Sorry for the dumb question here. I've searched a bunch on pinning packages. It seems that it is used to get packages from a different branch, which is what I did to get Xfce 4.10 from experimental. I'm not seeing how that would help me with all of these xfce-*-panel packages that want to upgrade to a minor release but won't let me with Xfce 4.10. Care to shed light? Or is there anyone else running Xfce 4.10 from experimental? I suspect since these are minor updates that I should be able to force an upgrade, but I'm not sure what that would do after that when next versions of the packages come along and to my dependency checking.

The problem is that by installing Xfce 4.10, you get xfce-panel 4.10. None of the apps that sit on that panel have been updated to run on the 4.10 panel. Even in Experimental. The updates that you see held back are only updates to the 4.8 packages.

So, you are stuck until they are updated. My xfce setup is in the same boat. I have considered removing 4.10 and going back to 4.8, and waiting a few weeks, but then I can just do without the panel packages.

[ericcc65]

The problem is that by installing Xfce 4.10, you get xfce-panel 4.10. None of the apps that sit on that panel have been updated to run on the 4.10 panel. Even in Experimental. The updates that you see held back are only updates to the 4.8 packages.

So, you are stuck until they are updated. My xfce setup is in the same boat. I have considered removing 4.10 and going back to 4.8, and waiting a few weeks, but then I can just do without the panel packages.

Thanks. It's a bit confusing though because these updates are just that...updates. The old versions of these packages are working fine with 4.10. The updates seem very minor too (not even minor number versions, just a +b1 at the end. For example, xfce-mixer from 4.8.0-3 to 4.8.0-3+b1). I would be very surprised if these new packages truly didn't work with the current panel even though the old ones did.

[GregE]

Thanks. It's a bit confusing though because these updates are just that...updates. The old versions of these packages are working fine with 4.10. The updates seem very minor too (not even minor number versions, just a +b1 at the end. For example, xfce-mixer from 4.8.0-3 to 4.8.0-3+b1). I would be very surprised if these new packages truly didn't work with the current panel even though the old ones did.

Only some of the packages work. On mine if I try and add the weather app it just says it will not run. Several of the others are the same. I did consider trying to grab Ubuntu debs for panel apps from the 4.10 PPA, but mixing Ubuntu packages with Debian is generally not a great move.

EDIT: I just tried the Ubuntu weather app and it will not install, apparently Ubuntu is using a libc newer that the one in Sid.

[zerozero]

apparently Ubuntu is using a libc newer that the one in Sid.

saw that minutes ago http://forums.linuxmint.com/viewtopic.p ... 16#p611079

firefox-trunk: Depends: libc6 (> = 2.15) but is to be installed 2.13-27

[Brian49]

Sorry for the dumb question here. I've searched a bunch on pinning packages.

"Pinning" a package means locking it in its present installed version, so that you don't get alerts about newer versions. If you have some panel-related packages already installed which are working fine in their present versions, you have the option of pinning them.

If you mainly use Synaptic for updating your system, select one of those panel-related packages from the list, then go the Package menu and click on Lock Version.

If you mainly use the terminal for updating, then you need to edit the file /etc/apt/preferences as root, and add pinning entries like this:

Code: Select all

Package: xfce4-mixer
Pin: release a=unstable
Pin-Priority: -1

You can reverse these steps whenever it suits you. By the way, if you go down the second route, the packages will be pinned in Synaptic as well as in the terminal.

[GeneC]

...................The problem is that by installing Xfce 4.10, you get xfce-panel 4.10. None of the apps that sit on that panel have been updated to run on the 4.10 panel. Even in Experimental. The updates that you see held back are only updates to the 4.8 packages.

So, you are stuck until they are updated. My xfce setup is in the same boat. I have considered removing 4.10 and going back to 4.8, and waiting a few weeks, but then I can just do without the panel packages.

I've upgraded to Xfce 4.10 on 2 separate occasions only to run into this same problem.
I have decied to revert back to 4.8 and patiently.. wait for the rest of 4.10 to catch up.
It does seem to be taking longer than expected, but 4.8 is so solid its not a big issue.

[ericcc65]

I've upgraded to Xfce 4.10 on 2 separate occasions only to run into this same problem.
I have decied to revert back to 4.8 and patiently.. wait for the rest of 4.10 to catch up.
It does seem to be taking longer than expected, but 4.8 is so solid its not a big issue.

I really like Xfce but I find the "Multiple Rows" feature of 4.10 quite useful. It's how I have my panel set up now.

"Pinning" a package means locking it in its present installed version, so that you don't get alerts about newer versions. If you have some panel-related packages already installed which are working fine in their present versions, you have the option of pinning them.

If you mainly use Synaptic for updating your system, select one of those panel-related packages from the list, then go the Package menu and click on Lock Version.

If you mainly use the terminal for updating, then you need to edit the file /etc/apt/preferences as root, and add pinning entries like this:

Code: Select all

Package: xfce4-mixer
Pin: release a=unstable
Pin-Priority: -1

You can reverse these steps whenever it suits you. By the way, if you go down the second route, the packages will be pinned in Synaptic as well as in the terminal.

So imagine you just periodically remove the pinning and see if the new updates happen to be working correctly finally? If not, put the pinning back in place, if it does, then great.

[Brian49]

So imagine you just periodically remove the pinning and see if the new updates happen to be working correctly finally?

That's the idea. If you set up the pinning in /etc/apt/preferences, you can effectively disable the pinning by changing the last line of each entry from "Pin-Priority: -1" to "Pin-Priority: 500". If you have several such entries, you can use your text editor's Find & Replace tool to change them all at once.

[mockturtl]

So imagine you just periodically remove the pinning and see if the new updates happen to be working correctly finally? If not, put the pinning back in place, if it does, then great.

You can use aptitude hold / unhold, too. Potential upgrades are counted, but not performed.

Put this in ~/.bashrc so you don't have to remember: (reference)

Code: Select all

alias held="aptitude search ~ahold"

Code: Select all

$ sudo aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

$ held
ih  cinnamon                        - Cinnamon desktop  # `i` for installed, `h` for holding

[xircon]

Got some strange errors today, don't know if they are important:

Code: Select all

Setting up nodejs (0.6.19~dfsg1-3) ...
update-alternatives: warning: alternative /usr/bin/node (part of link group js) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/js is dangling; it will be updated with best choice
update-alternatives: using /usr/bin/rhino to provide /usr/bin/js (js) in auto mode
update-alternatives: using /usr/bin/nodejs to provide /usr/bin/js (js) in auto mode

Could this cause any problems?

Steve

[GregE]

Got some strange errors today, don't know if they are important:

Code: Select all

Setting up nodejs (0.6.19~dfsg1-3) ...
update-alternatives: warning: alternative /usr/bin/node (part of link group js) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/js is dangling; it will be updated with best choice
update-alternatives: using /usr/bin/rhino to provide /usr/bin/js (js) in auto mode
update-alternatives: using /usr/bin/nodejs to provide /usr/bin/js (js) in auto mode

Could this cause any problems?

Steve

Hi Steve, I am not getting those errors as I have a standard Gnome Shell and js engine. It appears to be coming from your installation of Rhino and/or node - neither of which are installed on my machine.

[xircon]

Cheers Greg, probably comes from a load of crap I installed in a vain attempt to get the Gnome extensions website working. Will strip them out.

Steve

[squeezy]

xircon, make sure you have the unzip package installed for the gnome extensions website to work. I banged my head on several installs until I ran across that bit of advice. The website magically worked after installing unzip!

[xircon]

I have always had unzip installed, it was just one of those things, one day it just magically started working.

Steve

[zerozero]

just to report that i'm (again) in the club

Code: Select all

zerozero@debian:~$ inxi -SxxxFr
System:    Host: debian Kernel: 3.2.0-3-amd64 x86_64 (64 bit, gcc: 4.6.3) 
           Desktop: Xfce 4.8.3 (Gtk 2.24.9) info: xfce4-panel dm: gdm Distro: Debian GNU/Linux wheezy/sid
Machine:   System: Dell product: Inspiron 1545 Chassis: type: 8
           Mobo: Dell model: 0G848F Bios: Dell version: A02 date: 11/17/2008
CPU:       Dual core Intel Pentium Dual CPU T3400 (-MCP-) cache: 1024 KB flags: (lm nx sse sse2 sse3 ssse3) bmips: 8644.04 
           Clock Speeds: 1: 1000.00 MHz 2: 1000.00 MHz
Graphics:  Card: Intel Mobile 4 Series Chipset Integrated Graphics Controller bus-ID: 00:02.0 
           X.Org: 1.12.3 drivers: intel (unloaded: fbdev,vesa) Resolution: 1366x768@60.0hz 
           GLX Renderer: Mesa DRI Mobile Intel GM45 Express Chipset GLX Version: 2.1 Mesa 8.0.4 Direct Rendering: Yes
Audio:     Card: Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Sound: ALSA ver: 1.0.24
Network:   Card-1: Broadcom BCM4312 802.11b/g LP-PHY driver: wl bus-ID: 0c:00.0
           IF: wlan0 state: up mac: 00:22:5f:68:ab:f4
           Card-2: Marvell 88E8040 PCI-E Fast Ethernet Controller driver: sky2 ver: 1.30 port: de00 bus-ID: 09:00.0
           IF: eth0 state: down mac: 00:23:ae:19:06:3a
Drives:    HDD Total Size: 250.1GB (-)
           1: id: /dev/sda model: WDC_WD2500BEVT size: 250.1GB serial: WD-WXEX08UZC370 
Partition: ID: / size: 21G used: 8.7G (44%) fs: ext4 
Sensors:   None detected - is lm-sensors installed and configured?
Repos:     Active apt sources in file: /etc/apt/sources.list
           deb http://ftp.debian.org/debian unstable main contrib non-free
           deb http://www.deb-multimedia.org sid main non-free
Info:      Processes: 107 Uptime: 1:13 Memory: 174.1/2985.6MB Runlevel: 2 Gcc sys: 4.7.1 alt: 4.6 Client: Shell inxi: 1.8.14 

[GeneC]

'zz'
Welcome back.
Gotta report that things have been pretty un-eventful here in SID-land.