LMDE BREAKAGES - tracking TESTING

[sidneyk]

Just a quick update... I'm still working on mintUpdate and adding a little dialog that will pop up whenever the selected updates trigger the installation or removal or packages. The dialog will show you the list of packages added/removed.

I've noticed today that when I run mintUpdate now, in LMDE x64, that when it finishes applying the updates that it just automatically closes without indication if everything was successful and installed and/or removed as expected. Is that the indication that everything succeeded? I thought before that it gave a summary dialog just like in Synaptics?

[clem]

@sidneyk: Yes, if it closes down it means everything was successful.

Here is a significant update:

mintupdate (4.2.6) katya; urgency=low

* mintUpdate now only list upgrades, not dependencies
* packages to be installed or removed to satisfy dependencies are listed in a dialog which pops up to warn the user

-- Clement Lefebvre <root@linuxmint.com> Sun, 27 Mar 2011 19:47:00 +0000

A lot of code changes were involved here. It's been tested for regressions of course, but if you see anything wrong, please use this thread to let me know. Basically, it checks much more things than before. Overall, compared to what we had a week ago, mintupdate is now faster to check for updates and slower to apply them, because it runs a simulation and warns you of any additions/deletions of packages.

[linuxviolin]

I have not read every pages or posts, but here you talk about "LMDE BREAKAGES" with updates, right? Without laugh! Again and always the joys of the (broken by design) rolling release model...

[kmb42vt]

@sidneyk: Yes, if it closes down it means everything was successful.

Here is a significant update:

mintupdate (4.2.6) katya; urgency=low

* mintUpdate now only list upgrades, not dependencies
* packages to be installed or removed to satisfy dependencies are listed in a dialog which pops up to warn the user

-- Clement Lefebvre <root@linuxmint.com> Sun, 27 Mar 2011 19:47:00 +0000

A lot of code changes were involved here. It's been tested for regressions of course, but if you see anything wrong, please use this thread to let me know. Basically, it checks much more things than before. Overall, compared to what we had a week ago, mintupdate is now faster to check for updates and slower to apply them, because it runs a simulation and warns you of any additions/deletions of packages.

One quick question about the new MintUpdate, Clem. Is there any policy yet on what update levels should be used by default now that MintUpdate has been modified to be more compatible with LMDE? Currently most of us have been using 'apt-get dist-upgrade' via the terminal or updating LMDE using Synaptic which is essentially the same thing. Right now I have MintUpdate levels 1 through 5 enabled but up till now have only been using the tray icon for update notifications.

[clem]

Well, the rationale is different for Ubuntu and Debian Testing.

On Ubuntu, it's about filtering per level to prevent novice users from upgrading sensitive parts of their system. On Debian Testing, since it's rolling, it's about skipping temporary issues until they get resolved... so it's not a matter of filtering per level, but snapshoting the flow of updates and releasing it when it's stable.

With this in mind, mintupdate in its current form is still very much designed for an Ubuntu base. You can enable all 5 levels in it and get the same level of functionality as with apt itself, but what's really needed is a snapshot repository of Debian Testing and a fork of mintupdate designed specifically for LMDE. This will be designed and released after Mint 11.

[kmb42vt]

Well, the rationale is different for Ubuntu and Debian Testing.

On Ubuntu, it's about filtering per level to prevent novice users from upgrading sensitive parts of their system. On Debian Testing, since it's rolling, it's about skipping temporary issues until they get resolved... so it's not a matter of filtering per level, but snapshoting the flow of updates and releasing it when it's stable.

With this in mind, mintupdate in its current form is still very much designed for an Ubuntu base. You can enable all 5 levels in it and get the same level of functionality as with apt itself, but what's really needed is a snapshot repository of Debian Testing and a fork of mintupdate designed specifically for LMDE. This will be designed and released after Mint 11.

That makes it all clear. Now when the question comes up in the near future I can point them right to your comment. Thanks for explanation, Clem.

[amina]

I just did my first update using 4.2.6, but did not get a summary of changes before install.
Does the popup only appear if there are new packages to install or packages to be removed?

[clem]

Yes, it doesn't appear if no additional changes are required.

[asymmetros]

Updated successfully Nvidia drivers (plus the new 2.6.32 kernel).
A pop-up window informed me that it will install a new package (nvidia-common if i am right). Nice and clean. Mintupdate looks more polished and is more responsive now. Looking forward for the new LMDE's mintupdate.

[gosa]

Hi All..

This morning I'm getting this message when trying to "refresh my Mint Update:

Code: Select all

E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/packages.linuxmint.com_dists_debian_upstream_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: _cache->open() failed, please report.

Same message appears when trying to run sudo apt-get update
The thing is that I didn't have any problems with the same action when I ran it two days ago, and I haven't made any changes between them (other than refreshing Mint Update.

Ideas?

Edit: This only happens with my x64 desktop install. The Netbook running the x86 version of LMDE seems to have no problem.

UPDATE: Now it complains about another document/list/package or whatever it's called:

Code: Select all

E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/packages.linuxmint.com_dists_debian_import_i18n_Translation-en
E: The package lists or status file could not be parsed or opened.
E: _cache->open() failed, please report.

UPDATE/EDIT 2:

Being able to find a solution on your own feels kind of nice... I gave google a last shot (turned out I was a bit too specific this morning) and found a thread here in the forums that fixes my problem.
(viewtopic.php?f=141&p=399038)

[gorade]

Wonder if this belongs here?
I posted to viewtopic.php?f=141&t=66995&p=401062#p401062 too, but that thread is labled SOLVED

When I upgrade from gdm3 2.30.5-6squeeze1 to gdm3 2.30.5-6squeeze2 the computer doesn't find USB-keyboard, USB-mouse and USB3 storage. Only current HDD and two CD/DVD-units are found.

Unplugging and replugging keyboard, mouse and backupstationi makes them work again. Just removing .bin files from /var/apt/ is not enough. I have to run reinstall from the backup which I make befor every upgrade nowadays.

So what makes gdm3 2.30.5-6squeeze2 wreck USB-recognition?

[gorade]

Just removing .bin files from /var/apt/ is not enough.

/var/cache/apt/ I mean of course.

[kmb42vt]

Wonder if this belongs here?
I posted to viewtopic.php?f=141&t=66995&p=401062#p401062 too, but that thread is labled SOLVED

When I upgrade from gdm3 2.30.5-6squeeze1 to gdm3 2.30.5-6squeeze2 the computer doesn't find USB-keyboard, USB-mouse and USB3 storage. Only current HDD and two CD/DVD-units are found.

Unplugging and replugging keyboard, mouse and backupstationi makes them work again. Just removing .bin files from /var/apt/ is not enough. I have to run reinstall from the backup which I make befor every upgrade nowadays.

So what makes gdm3 2.30.5-6squeeze2 wreck USB-recognition?

When I installed this morning's updates gdm3 shows as gdm3 2.30.5-8 (no squeeze2 or anything after it) and my USB devices work fine. Not too sure what version I was running before but I've never had any problems with any USB device (so far). Are your repos still set to "testing" or did you change them to "squeeze"?

[sgosnell]

Are your repos still set to "testing" or did you change them to "squeeze"?

The real question is what are your repos set to? That is set on each individual machine, not by the LMDE team. I think the original sources.list has Squeeze, which was Testing at the time. If you want to continue with Testing, you need to change your /etc/apt/sources.list file to use either Wheezy or Testing, not Squeeze.

[zerozero]

The LMDE's original source.list are set to testing

[kmb42vt]

Are your repos still set to "testing" or did you change them to "squeeze"?

The real question is what are your repos set to? That is set on each individual machine, not by the LMDE team. I think the original sources.list has Squeeze, which was Testing at the time. If you want to continue with Testing, you need to change your /etc/apt/sources.list file to use either Wheezy or Testing, not Squeeze.

Actually the repos were set by the LMDE team when they built the .iso in the first place and by default were set to "testing" not "squeeze". "Testing" always remains "testing" regardless of the next Debian release being developed. There can be some confusion caused by Debian "testing" being "frozen" (except for critical/blocker bugs) just before a new version of Debian is released. Once the new version of Debian is released then "testing" is unfrozen and development continues. The user, of course, can change his or her sources.list from "testing" to "squeeze" if they desire the extra stability but LMDE will no longer be rolling in this case. So if you to a clean install of LMDE the repos in your "sources.list" will be set to "testing".

In my case my LMDE is a default install and the default repos are unchanged ("testing") which would explain why my gdm3 version is higher. This is why I asked if "gorade" had changed repos (sources.list) to "squeeze".

[sgosnell]

A program can't change sources.list without your approval. You might click and add your password without fully understanding what is going on, but you still have to approve with a password any changes to any system configurations. And it's easy enough to look at sources.list and see what is there. If there are Squeeze packages in the Testing repo, that's done by Debian. But there are the Mint repos, which could contain packages from any version, theoretically.

I can't remember exactly what was in my sources.list at install, it's been a long time and I've made a lot of changes. If testing is what was there, so be it.

[gorade]

When I installed this morning's updates gdm3 shows as gdm3 2.30.5-8 (no squeeze2 or anything after it) and my USB devices work fine. Not too sure what version I was running before but I've never had any problems with any USB device (so far). Are your repos still set to "testing" or did you change them to "squeeze"?

The repos is squeeze. No testing

[linmint777]

So what's the deal with kexec-tools? It was recently introduced and appears to cause booting problems (for some)?

I have it installed but haven't rebooted recently (I reboot mostly/only for new kernels). Should I remove or pin it? What's the "average user case" for that package?

If you are dual or multi-booting with other OSs then you can run this command:
sudo dpkg-reconfigure kexec-tools
and a window will come up asking if kexec should handle reboots. Answer no and you'll be able to get back to your grub menu when you do reboot. The kexec package will still be installed in case you want to use it at some point, but it won't frustrate you trying to figure out what's going on. Basically, kexec lets you warm reboot into a new kernel instead of going through a complete reboot back to the grub menu for testing purposes. The only way I was able to get back to grub was to shutdown and then restart my computer until I ran the command above to reconfigure kexec-tools.

Hey guys, Another solution is to choose between the reboot with or without kexec-tools, give it a chance. ------> viewtopic.php?f=141&t=69493

[Bonsaii]

Hi,

the update seems to have broken my sound.
The speakers still work, but no mic.

Sound worked fine and out of the box with
the first install in Oct 2011 on my HP Compaq
nx7300, all though I have the notorious HDA
Intel chip, no internal mic, and use a head set
plugged into the jack.

I tried this:[url]
https://help.ubuntu.com/community/HdaIntelSoundHowto[/url]

cat /proc/asound/card0/codec#* | grep Codec gives me:
Codec: Analog Devices AD1981
Codec: LSI ID 1040

Editing /etc/modprobe.d/alsa-base.conf did not help.

There is a bug report here:
[url]https://bugs.launchpad.net/linuxmint/+bug/723317
[/url]

Nothing is muted in pulseaudio, Gnome Alsa Mixer
or alsamixer.

Purging Pulseaudio did not solve the problem.

All I get with Sound Recorder and/or Skype testing is
a constant noice.

Any help is highly appreciated

Thanks,
Bonsaii

Update: Solved, hardware problem.