Hi,
We see a lot of packages now in noble-updates.
What Noble users have to do with this?
Here mesa, e.g. :
A lot of updates are due to migration of time representation from 32bit to 64bit https://en.wikipedia.org/wiki/Year_2038_problem. This obviously affects many libraries and applications suffixed by t64. check: apt list --installed | grep t64
No, I think there is another point here.
Why are these noble-updates packages outdated and t64-less?
eg. Mutter, etc.
Because they likely depend on some library that is in the t64 transition and has not fully migrated yet
1 Like
Hmm they’re rolled back, not simply outdated here.
For my knowledge it’s quite unusual to see an older package in updates than release one:
https://launchpad.net/ubuntu/+source/mesa
?
What’s going on right now is a very long, laborious process of rebuilding every package with a dependency on xz/lzma.
More detail on that here.
Here’s a little snippet from #ubuntu-release on IRC yesterday that should explain more the particular behavior you’re seeing:
< vorlon> so here's what's happening now
< vorlon> we're still finalizing the list of packages that would need rebuilt, but right now we have 7207 packages whose current amd64
binaries were built after xz-utils publication
< vorlon> I'm in the process of copying old, good versions of these packages (one by one) to noble-updates
< vorlon> as they publish, I will be removing the current amd64 binaries from noble+noble-proposed
< vorlon> that is slowest, because launchpad doesn't like binary removals
< vorlon> and only once that's all done we will start uploading no-change rebuilds
7 Likes
Ok I was obviously thinking about this main reason but did not understand why this was necessary as xz used by Noble was the good(?)-old one. But 5.6* was used to build some packages, if I understand correctly?
Does it mean that a Noble up to date install is infected by the backdoor?
Should I completely reinstall Noble once this huge cleanup will be done?
The malicious version only made it to proposed, so unless your Noble install has proposed enabled, you do not have that. However, many packages that made it to release were built against those libraries and are potentially impacted, too. That said, I’d consider any Noble install problematic at this point.
5 Likes
To be clear, it’s not about rebuilding packages “with a dependency on xz/lzma”. By and large, those packages are dynamically linked to liblzma, so rolling back the liblzma library itself is sufficient to address any runtime impact of liblzma.
However, the compromised liblzma and xz-utils were present in the build environment of every amd64 package built since February 26. And both apt and dpkg link to liblzma. Since analysis by security researchers of the compromised payload is still ongoing and we don’t know what other tricks might be included in addition to the sshd backdoor, out of an abundance of caution we are treating all amd64 binaries built while this compromised liblzma was installed as “tainted” and are in the process of rebuilding.
Expect a more detailed explanation to be published in the next couple of days (possibly not until after the holiday weekend).
11 Likes
I am trying to install dolphin in Noble, and get errors like the following. It seems that many dependencies have updated version, but the packages that depend on it have not been updated.
$ sudo apt install dolphin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
dolphin : Depends: libdolphinvcs5 (= 4:23.08.5-0ubuntu1) but 4:23.08.5-0ubuntu2 is to be installed
E: Unable to correct problems, you have held broken packages.
I am encountering similar errors in qt based packages like Octave and Kalzium.
Is this error possibly related to this post?
That’s this problem, yes.
Would this be connected too?
This error could be caused by required additional software packages which are missing or not installable. Furthermore there could be a conflict between software packages which are not allowed to be installed at the same time.
Transaction failed: Package dependencies cannot be resolved
The following packages have unmet dependencies:
init: systemd-timesyncd: Depends: libsystemd-shared (= 255.4-1ubuntu6) but 255.4-1ubuntu6 is to be installed
Would it be considered advisable to remove / format any current Noble installs and replace them once more is known, or is that not necessary?
The Noble archives are in a changing state and have been for a while with the time_t transition. Now they’re in a similar—if not worse—state with a security bug whose impact is not fully understood. Personally, I’d avoid using any Noble installs right now. When everything is well known and the archive is in a manageable state, and ISOs start building again, then I would make a new install and carry on like normal.
The one thing I’d absolutely advise: don’t use Noble in production right now.
6 Likes
Moderator Note:
This topic is for sharing constructive information about the problem, status of solutions, and relevant questions and discussion. Questions to help folks understand are on-topic and welcome.
This is not a topic for general complaints. Off-topic items will be removed to keep this conversation on-topic.
Folks who are frustrated that Noble isos aren’t working for them today: Please understand that everybody already knows, and that everybody already agrees with you.
Thank you for your understanding.
7 Likes
So, atm all the proposed up-to-date packages are being updated too.
I appreciate all the effort being done to ensure things are done correctly instead of done quickly. I’ll happily wait for all this work to complete considering the XZ issues.
4 Likes
Yes, thanks to this huge effort this weekend.
1 Like