LMDE BREAKAGES - tracking TESTING
Forum rules
LMDE 2 has reached end of support as of 1-1-2019
LMDE 2 has reached end of support as of 1-1-2019
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
What happened, zerozero? Did the kernel upgrade break X for you? I did it yesterday and came through unscathed. Running nouveau here, no proprietary video drivers.
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
yep dkms failed to build the nvidia modules to the new kernel (again)
nouveau is almost an option for me but runs 10-12c hotter here and it's noticeable noisier
nouveau is almost an option for me but runs 10-12c hotter here and it's noticeable noisier
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
This and things like it are whats stopping me from bringing my main laptop over from Mint 13. The box I do run debian testing on has an intel video card and has a liquorix kernel. Do liquorix kernel updates cause the same problem with nvidia?
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
cww,
the question here is:
- nvidia and fglrx are not exactly part of debian
http://packages.debian.org/search?suite ... nvidia-glx (non-free)
http://packages.debian.org/search?suite ... ords=fglrx (non-free)
http://www.debian.org/security/faq#contrib
this happened in the last kernel update (x.3) and now in this one as well (x.4)
one option is http://smxi.org/ (i guess i'm just stubborn and prefer dkms)
the question here is:
- nvidia and fglrx are not exactly part of debian
http://packages.debian.org/search?suite ... nvidia-glx (non-free)
http://packages.debian.org/search?suite ... ords=fglrx (non-free)
http://www.debian.org/security/faq#contrib
(the quote is regarding security but shows the general idea)Contrib and non-free aren't official parts of the Debian Distribution and are not released, and thus not supported by the security team.
this happened in the last kernel update (x.3) and now in this one as well (x.4)
one option is http://smxi.org/ (i guess i'm just stubborn and prefer dkms)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Ok. If/when I move to debian on my laptop, I'll use smxi or not even bother with proprietary graphics as I don't do anything that my Intel HD 3000 can't handle, and there are ways to use bumblebee with the open source drivers.
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Hi
I have been using LMDE for a long time now and needed advice.
This is my sources list:
and this is my preferences:
Was just wondering if these are correct for what I want. I want to be tracking Debian Testing, but a few packages seem to be old in LMDE, e.g Iceweasel is version 10 while it is version 17 in C# (Crunchbang) that I also have installed. How can I get Iceweasel 17 in LMDE.
I have been using LMDE for a long time now and needed advice.
This is my sources list:
Code: Select all
diwate narendra # inxi -r
Repos: Active apt sources in file: /etc/apt/sources.list
deb http://ftp.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.deb-multimedia.org/ testing main non-free
deb http://packages.linuxmint.com/ debian upstream import main
Active apt sources in file: /etc/apt/sources.list.d/opera.list
deb http://deb.opera.com/opera/ stable non-free
Code: Select all
Package: *
Pin: release o=linuxmint
Pin-Priority: 700
Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 700
Package: *
Pin: release o=Debian
Pin-Priority: 500
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
narendra.d,
the repos are fine, the preferences i personally would level it all to 500 (although now with fontconfig and related packages coming directly from upstream, the main reason for concern is gone)
iceweasel is at v. 10 (esr)in testing (http://packages.debian.org/search?suite ... =iceweasel). probably in #! you are using http://mozilla.debian.net/ (here you can find newer builds)
the repos are fine, the preferences i personally would level it all to 500 (although now with fontconfig and related packages coming directly from upstream, the main reason for concern is gone)
iceweasel is at v. 10 (esr)in testing (http://packages.debian.org/search?suite ... =iceweasel). probably in #! you are using http://mozilla.debian.net/ (here you can find newer builds)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Firefox from the Linux Mint repo is at version 17 (and so is thunderbird). Iceweasel in Testing and Unstable are the Extended Support Releases (ESR), and they are up to date AFAIK (I think both are 10.0.11 right now). If you want to go back to the standard releases, you have a few options. First, you can install from the Mint Repo, which would get you firefox 17. You could also use apt-pinning and pull iceweasel down from experimental. Finally, you could try to use other distros repos to get thunderbird, but I wouldn't recommend this. Currently, your preferences will work, but it could cause problems in the future if packages from the mint repo stop working with testing. It would be better to assign them all equal priority or to delete the contents. Hunspell is incompatible with Thunderbird (but not icedove), so if you were to install from the mint repo, you'd have to remove hunspell which is important for spell checking.
If you do plan on installing iceweasel from experimental, make sure you remove the third entry (the debian one) because that will assign all debian releases a pin of 500, meaning you would upgrade everything to experimental, which would be bad unless you wanted to.
Edit: the link that zerozero gave recommends using experimental for the latest release of iceweasel, and it gives instructions.
If you do plan on installing iceweasel from experimental, make sure you remove the third entry (the debian one) because that will assign all debian releases a pin of 500, meaning you would upgrade everything to experimental, which would be bad unless you wanted to.
Edit: the link that zerozero gave recommends using experimental for the latest release of iceweasel, and it gives instructions.
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
good catch cww i forget this more than i shouldcwwgateway wrote:because that will assign all debian releases a pin of 500
outside the default latest/incoming repos it's safer to simply delete that file (i say it again: it has a purpose and works very well within the UP-schema, once we leave it we should also forget that apt-pinning)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
I agree, and when looking at other distros I've been impressed how well the UP system works. However, in general debian, I think that apt-pinning is one of its biggest strengths for me. I really like running debian testing while running iceweasel/icedove from experimental (even though that's probably not recommended).zerozero wrote:good catch cww i forget this more than i shouldcwwgateway wrote:because that will assign all debian releases a pin of 500
outside the default latest/incoming repos it's safer to simply delete that file (i say it again: it has a purpose and works very well within the UP-schema, once we leave it we should also forget that apt-pinning)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
@zerozero and @cww: Thank You both for your replies.
I certainly have no plan or intention of going to debian experimental any time. I do not think I am that cutting edge and am not ready for the issues that I may have to encounter. I think I can live with Iceweasel 10 ESR. I was thinking something was wrong with my Preferences file that the big difference was there. It just seemed highly improbable that a system tracking Testing would have that big a difference in version numbers from the upstream (version 10 to 17 is a big jump, though there may not be too many differences that I as a user can see).
Thank you again for confirming that there is nothing wrong.
The C# system does not have Mozilla in the sources list, but the preferences file has Crunchbang Waldorf with 1001 and debian testing as 500 .
I certainly have no plan or intention of going to debian experimental any time. I do not think I am that cutting edge and am not ready for the issues that I may have to encounter. I think I can live with Iceweasel 10 ESR. I was thinking something was wrong with my Preferences file that the big difference was there. It just seemed highly improbable that a system tracking Testing would have that big a difference in version numbers from the upstream (version 10 to 17 is a big jump, though there may not be too many differences that I as a user can see).
Thank you again for confirming that there is nothing wrong.
The C# system does not have Mozilla in the sources list, but the preferences file has Crunchbang Waldorf with 1001 and debian testing as 500 .
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Hi, new to tracking Testing -apologise if this is not the place to ask questions.
Today I see updates libavcodec54 libavformat54 libavutil51 libicu48 libpostproc52 libswscale2 xserver-xorg-video-nouveau
-it's the nouveau that I'm curious about. I use nvidia proprietary and wonder if accepting the update will override my chosen proprietary drivers. If so, how should I proceed?
Tracking Testing has been fun and educational so far.
Apologies again if this should be asked elsewhere.
Today I see updates libavcodec54 libavformat54 libavutil51 libicu48 libpostproc52 libswscale2 xserver-xorg-video-nouveau
-it's the nouveau that I'm curious about. I use nvidia proprietary and wonder if accepting the update will override my chosen proprietary drivers. If so, how should I proceed?
Tracking Testing has been fun and educational so far.
Apologies again if this should be asked elsewhere.
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
I've updated and rebooted and I'm doing well right now. I run bumblebee with optimus, though, and I didn't run anything using optirun, so I don't know if optirun is still working (I think so, though).fiver22 wrote:Hi, new to tracking Testing -apologise if this is not the place to ask questions.
Today I see updates libavcodec54 libavformat54 libavutil51 libicu48 libpostproc52 libswscale2 xserver-xorg-video-nouveau
-it's the nouveau that I'm curious about. I use nvidia proprietary and wonder if accepting the update will override my chosen proprietary drivers. If so, how should I proceed?
Tracking Testing has been fun and educational so far.
Apologies again if this should be asked elsewhere.
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
hi fiver22,
welcome to the party yeahh it's the place to ask questions.
regarding the nouveau update it won't interfere with the nvidia driver that you have installed but i will do the test
these are the updates
this is my graphics card info right after update and before a reboot that i will do now
EDIT:
and now the same query after reboot
welcome to the party yeahh it's the place to ask questions.
regarding the nouveau update it won't interfere with the nvidia driver that you have installed but i will do the test
these are the updates
Code: Select all
Start-Date: 2012-11-28 23:15:54
Commandline: /usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 69206122 -o Synaptic::closeZvt=true --progress-str Please wait, this can take some time --finish-str Update is complete --set-selections-file /tmp/tmpkRMdjS
Upgrade: libswscale2:amd64 (1.0-dmo2, 1.0-dmo4), libavformat-dev:amd64 (1.0-dmo2, 1.0-dmo4), libavutil51:amd64 (1.0-dmo2, 1.0-dmo4), libicu48:amd64 (4.8.1.1-9, 4.8.1.1-10), libavutil-dev:amd64 (1.0-dmo2, 1.0-dmo4), libavcodec-dev:amd64 (1.0-dmo2, 1.0-dmo4), libavfilter3:amd64 (1.0-dmo2, 1.0-dmo4), libavdevice54:amd64 (1.0-dmo2, 1.0-dmo4), libavcodec54:amd64 (1.0-dmo2, 1.0-dmo4), ffmpeg:amd64 (1.0-dmo2, 1.0-dmo4), libpostproc52:amd64 (1.0-dmo2, 1.0-dmo4), xserver-xorg-video-nouveau:amd64 (1.0.1-3, 1.0.1-4), libavformat54:amd64 (1.0-dmo2, 1.0-dmo4), libswresample0:amd64 (1.0-dmo2, 1.0-dmo4)
End-Date: 2012-11-28 23:16:24
Code: Select all
zerozero@deb-kde ~ $ inxi -Gx
Graphics: Card: NVIDIA G92 [GeForce GTS 250] bus-ID: 01:00.0 X.Org: 1.12.4 driver: nvidia Resolution: 1440x900@59.9hz
GLX Renderer: GeForce GTS 250/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 304.48 Direct Rendering: Yes
and now the same query after reboot
Code: Select all
zerozero@deb-kde ~ $ inxi -Gx
Graphics: Card: NVIDIA G92 [GeForce GTS 250] bus-ID: 01:00.0 X.Org: 1.12.4 driver: nvidia Resolution: 1440x900@59.9hz
GLX Renderer: GeForce GTS 250/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 304.48 Direct Rendering: Yes
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Ready or not... here's multi-arch! (If you put it off like I did, review the sid thread.)
(Note, nspluginwrapper is dead)
As with any major transition, don't let aptitude try to handle this. It's like an eager puppy that keeps bringing you the same dead bird.
I didn't need to modify my sources.
Finally, housekeeping:
Code: Select all
$ full-upgrade
The following packages will be upgraded:
ia32-libs{b} ia32-libs-gtk{b}
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 134 kB of archives. After unpacking 118 MB will be freed.
The following packages have unmet dependencies:
ia32-libs : Depends: ia32-libs-i386 which is a virtual package.
ia32-libs-gtk : Depends: ia32-libs-i386 which is a virtual package.
Depends: ia32-libs-gtk-i386 which is a virtual package.
The following actions will resolve these dependencies:
Remove the following packages:
1) ia32-libs
2) ia32-libs-gtk
3) nspluginwrapper
4) skype
Code: Select all
$ sudo dpkg --add-architecture i386
$ cat /var/lib/dpkg/arch
amd64
i386
$ update
$ sudo apt-get dist-upgrade
I didn't need to modify my sources.
Code: Select all
$ remove ia32-libs*
The following packages will be REMOVED:
ia32-libs ia32-libs-gtk
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 133 kB will be freed.
The following packages have unmet dependencies:
skype : Depends: ia32-libs but it is not going to be installed.
Depends: ia32-libs-gtk but it is not going to be installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) skype
Accept this solution? [Y/n/q/?] y
...
$ install skype:i386
Code: Select all
$ remove $(deborphan)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
Uh oh: what's it mean if I don't see this update?
I also tried cat /var/lib/dpkg/arch and no such file or dir (arch).
It really is fun to have more changes to deal with -so far no major issues but I am learning lots.
(thanks zerozero for the previous advice re: nouveau)
I also tried cat /var/lib/dpkg/arch and no such file or dir (arch).
It really is fun to have more changes to deal with -so far no major issues but I am learning lots.
(thanks zerozero for the previous advice re: nouveau)
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
If you're on 32-bit, don't sweat it. It's only relevant for 64-bit systems.fiver22 wrote:Uh oh: what's it mean if I don't see this update?
I also tried cat /var/lib/dpkg/arch and no such file or dir (arch).
It really is fun to have more changes to deal with -so far no major issues but I am learning lots.
(thanks zerozero for the previous advice re: nouveau)
Code: Select all
$ dpkg --print-architecture # shows i386 or amd64
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
I'm on a 64 bit system. Ack, what then?mockturtl wrote:(...)]If you're on 32-bit, don't sweat it. It's only relevant for 64-bit systems.Code: Select all
$ dpkg --print-architecture # shows i386 or amd64
Are my sources wrong, perhaps? or should I change my apt-pinning?
Code: Select all
deb http://packages.linuxmint.com/ debian main upstream import
deb-src http://packages.linuxmint.com/ debian main upstream import
deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.deb-multimedia.org testing main non-free
Package: *
Pin: release o=linuxmint
Pin-Priority: 700
Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 700
Package: *
Pin: release o=Debian
Pin-Priority: 500
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
hey
so wanted or not multiarch is in wheezy (it's going be default in the upcoming debian7 so this inclusion now makes sense)
personally i can't say i'm convinced but we have no option now.
fiver22:
there's nothing wrong with your sources.list; on the other hand it's a risk to be on testing with that apt-pinning;
what is happening here (better: what is not happening) and because you don't see any of the problems MT is reporting is the same reason i couldn't see it either in this system: we don't have ia32-libs installed, we don't have any of the 32bit app installed like skype, wine, google-earth but that doesn't mean that we shouldn't make this conversion asap because more app/lib are going to be converted to multiarch (that was my "fear" from the beginning: multiarch could stimulate some laziness as in just maintaining one arch of app that were dual arch until now) >> next in line will be v4l-utils
so wanted or not multiarch is in wheezy (it's going be default in the upcoming debian7 so this inclusion now makes sense)
personally i can't say i'm convinced but we have no option now.
fiver22:
there's nothing wrong with your sources.list; on the other hand it's a risk to be on testing with that apt-pinning;
what is happening here (better: what is not happening) and because you don't see any of the problems MT is reporting is the same reason i couldn't see it either in this system: we don't have ia32-libs installed, we don't have any of the 32bit app installed like skype, wine, google-earth but that doesn't mean that we shouldn't make this conversion asap because more app/lib are going to be converted to multiarch (that was my "fear" from the beginning: multiarch could stimulate some laziness as in just maintaining one arch of app that were dual arch until now) >> next in line will be v4l-utils
Re: LMDE BREAKAGES - tracking TESTING - updated 15 May
So then: should I change the pinning to all the same? 500, 500, 500 for example? Is that what most people who are tracking testing do?zerozero wrote:(...)
fiver22:
there's nothing wrong with your sources.list; on the other hand it's a risk to be on testing with that apt-pinning;
what is happening here (better: what is not happening) and because you don't see any of the problems MT is reporting is the same reason i couldn't see it either in this system: we don't have ia32-libs installed, we don't have any of the 32bit app installed like skype, wine, google-earth but that doesn't mean that we shouldn't make this conversion asap because more app/lib are going to be converted to multiarch (that was my "fear" from the beginning: multiarch could stimulate some laziness as in just maintaining one arch of app that were dual arch until now) >> next in line will be v4l-utils
Regardless of that answer I think you're saying I should I bite the bullet and install ia32libs because more things will now be converted to multiarch -can do. Thanks again o/