Backports ubuntu что это
Обновлено: 04.07.2024
Это то, что я вижу, когда пытаюсь бежать sudo apt-get update . Я сделал обновление на моем экземпляре вчера и сейчас испытываю это.
обзор
Ваш вопрос состоит из двух частей:
Временное решение
Вполне вероятно, что эта проблема либо:
- временно из-за того, что ваш интернет-провайдер неправильно перенаправляет интернет-имена (DNS) на свои или на внешние DNS-серверы, или
- из-за изменений в вашей сети аналогичным образом заблокировано это наименование - например, новый маршрутизатор / модем, перенастроивший коммутатор с новой конфигурацией.
Давайте посмотрим на возможные проблемы с DNS.
Сначала временно добавьте известный DNS-сервер в вашу систему.
Тогда беги sudo apt-get update .
8.8.8.8 это собственный DNS-сервер Google.
Другим примером DNS-сервера, который вы можете использовать, является OpenDNS - например:
вопросы управления пакетами
Откройте терминал и введите
Найдите в списке строки с другим именем дистрибутива, чем вы ожидали - в вашем случае - вы выполнили обновление, oneiric но у вас есть другое имя выпуска. natty
Сохраните и повторно запустите:
Вы не должны иметь больше ошибок именования релизов.
На момент написания этого, возможные общие имена релиза включают в себя lucid , maverick , natty , oneiric , precise , quantal , raring , saucy , trusty , utopic и vivid .
Когда во время обновления появляется одно имя, вы можете пропустить манипуляции с DNS и перейти непосредственно к списку источников. Скорее всего, это проблема DNS с Docker, которая не позволяет обновлению apt-get пройти успешно.Обратите внимание, что этот ответ был написан для старых версий Ubuntu. В текущих версиях используется локальный сервер имен, управляемый D-Bus, для которого применяется диагностическая часть этого ответа, но не решение. Если /etc/resolv.conf содержит nameserver 127.0.1.1 или в более общем смысле nameserver 127.X.Y.Z , не изменяйте его.
«Устранение временного сбоя…» означает, что ваш DNS , т. Е. Перевод имен хостов в IP-адреса, не работает. Вы недавно что-то перенастроили на своей машине? Если нет, это может быть временная ошибка у вашего интернет-провайдера.
ping -n 8.8.8.8 Показывает ли линии как 64 bytes from 8.8.8.8: … ? (Нажмите Ctrl +, C чтобы остановить ping .)
- Если это не так, у вас есть проблема с IP-подключением. Запустите traceroute -n 8.8.8.8 и посмотрите, где он останавливается: если он находится в вашем доме / офисе, проверьте сетевое оборудование. Если вы можете связаться с вашим провайдером, пожаловайтесь им.
- Если это так, у вас есть проблемы с DNS. Проверьте содержимое /etc/resolv.conf ; должна быть строка вроде nameserver 1.2.3.4 (возможно, несколько из них). Если линии есть, вероятно, существует временная проблема в вашем интернет-провайдере, и вы можете обойти ее, добавив nameserver 8.8.8.8 в этот файл (это объявляет дополнительный DNS-сервер, который предоставляется Google бесплатно). Если первое число после nameserver 127 - это значит, что на вашем компьютере есть DNS-ретранслятор (это хорошо), и вы должны настроить это DNS-реле, а не модифицировать его /etc/resolv.conf . В современных версиях Ubuntu по умолчанию есть ретранслятор DNS, это Dnsmasq , и он управляется D-Bus.
Вы можете прокомментировать неразрешенный репозиторий из файла sources.list, найденного в каталоге dir / etc / apt /
После изменения sources.list очистите репозиторий apt-get как
Это постоянное решение временной проблемы DNS. Если вы забудете изменить его обратно, программное обеспечение из этого хранилища больше не будет обновляться или станет недоступным для установки.Иногда, когда вы находитесь за прокси-сервером, вам даже необходимо создать apt.conf файл /etc/apt/ и заполнить его конкретными записями, например:
Если требуется аутентификация, файл конфигурации выглядит следующим образом:
Я не могу войти в свой аккаунт из-за проблем, с которыми я сталкиваюсь с lightdm, мне нужно обновить lightdm, можете ли вы расширить свой ответ о том, как решить проблему? Благодарю.Я испытывал похожие ошибки при запуске apt-get команд. Оказывается, у меня на консоли была открыта панель обновления программного обеспечения.
Казалось, это блокирует командную строку apt-get , но я не уверен.
Это проблема DNS. Проверьте свой /etc/resolv.conf файл.
например, в моем случае, когда у меня возникла эта проблема и проверил этот файл, файл был пустым! но он должен содержать ваш DNS-сервер имен
192.168.10.x is my gateway ip address
Не могли бы вы уточнить, что нужно проверить /etc/resolv.conf ?У меня была эта ошибка. Следуя совету поддержки Linode, я закомментировал все строки IPv6 в / etc / hosts, а затем начало работать обновление apt-get.
Для тех, кто использует EC2, не забудьте проверить, что настройки вашей группы безопасности разрешают исходящие соединения с веб-сайтами, с которых вы обновляетесь. Вы можете установить весь исходящий трафик и посмотреть, работает ли он.
Мое невероятно грязное решение для исправления этой ошибки - добавить разрешенные домены вручную с /etc/hosts помощью этого короткого сценария:
Теперь обновление должно работать:
Я получил ту же проблему в виртуальной машине VMware, хост и гостя оба Ubuntu. Я решил проблему, изменив настройки виртуальной машины. Вместо использования NAT я установил Bridged. У меня сработало
Решение для этого конкретного случая: подключите кабель Ethernet, затем загрузитесь в Recovery и выполните apt-get update или переустановите с нуля и убедитесь, что вы включаете обновления
This page documents the development process for the Ubuntu Backports Project, as well as some of the justification for the project’s policies.
If you’re not familiar with what backports are, or are trying to figure out how to install a package backported through the Backports Project, then our user documentation might be a good place to start.
Responsibilities of the Backporter
You (or your sponsor) will need to prepare the backported package. This should be done with as few changes as possible to the backported package; any changes required should be explicitly stated in the changelog entry of the backported package.
Testing the Backport
You must test the backport in the Ubuntu release(s) you are requesting the backport for.
Functionality of the Backported Package
- Each package being backported must install cleanly and without errors.
- The software shipped in the package must also run.
- You must detail your test process and results in the backport tracking bug.
- In particular, make sure to run any build-time tests and autopkgtests **before** uploading.
Continued Functionality of Reverse-Dependencies
In addition to the backported package itself working, any other software that depends on the backported package must continue to run with the backported package installed, and any package that has a build-dependency on the backported package must build with the new package installed. In case that's not possible, the backported package must set appropriate package relations (Breaks, et al.) to prevent any incompatible installation (such Breaks could conceivably be part of the original package, it needs not be a backport-specific change).
Future Maintenance of the Backport
The Ubuntu Backports team is not responsible for the backported package.
The backporter is responsible for monitoring the backported package in the future for any bug reports, security patches, or additional updates that should be backported. Furthermore, the backporter is also responsible for any backport-specific bug that might be found in the backported package that wasn't present in the original version the backport was done from.
Prepare and upload the package
The procedure is intentionally very similar to the existing SRU procedure, with minor changes specific to the purpose of the backports pocket. You should first read and understand that process, as this will page will only highlight the specific differences, and it assumes you are familiar with the SRU process.
Select the package to backport
- There are some packages the Ubuntu Backports Team forbids from backporting.
- There are some packages the Ubuntu Backports Team handles themselves.
- Backports to non-LTS are not accepted (with exceptions).
- Backports are expected to come:
- from the current Ubuntu stable release (preferred), or
- from the current LTS release, targetting the prior LTS release, or
- from the current package version in the current Ubuntu development release.
Currently decided exceptions to the above are documented at the bottom of this page, anything else needs to be discussed with the Ubuntu Backports team either in the tracking bug or in the mailing list.
Open a Bug
The first step is to open a bug in Launchpad for the backport. Open the bug against the package that you want backported, and include the prefix [BPO] in the bug subject. The bug description should include the BPO bug template, filled out with specific details for the requested backport.
Unlike the SRU process, which does not allow requesting a SRU to add features or functionality, the backport process does allow the need for new features or functionality. The backport bug does not need to list all fixed bugs or all the new functionalities but should highlight and/or summarize the key fixes or features or other reasons for needing to backport the package.
The bug's intention is to provide a location for any paperwork that might be required for the backport. For example, if any questions are raised during review or if any discussion is required, as well as providing a reference for anyone who might want to later see why and how a specific package was backported.
Preparing the Backported Package
As in the SRU process, you must prepare a package for the backport. If you have upload rights, you can then upload directly into the backports queue. Note that unlike uploading for SRU, when uploading into the backports queue, you should use the backports pocket; for example, in the changelog instead of using the release focal you should use focal-backports. Additionally, the version number you use should exactly match the version number you are backporting from, with a specific suffix added in the format
bpoRELEASE.1, for example if backporting to release 20.04, append the suffix
This page documents the development process for the Ubuntu Backports Project, as well as some of the justification for the project’s policies.
If you’re not familiar with what backports are, or are trying to figure out how to install a package backported through the Backports Project, then our user documentation might be a good place to start.
Responsibilities of the Backporter
You (or your sponsor) will need to prepare the backported package. This should be done with as few changes as possible to the backported package; any changes required should be explicitly stated in the changelog entry of the backported package.
Testing the Backport
You must test the backport in the Ubuntu release(s) you are requesting the backport for.
Functionality of the Backported Package
- Each package being backported must install cleanly and without errors.
- The software shipped in the package must also run.
- You must detail your test process and results in the backport tracking bug.
- In particular, make sure to run any build-time tests and autopkgtests **before** uploading.
Continued Functionality of Reverse-Dependencies
In addition to the backported package itself working, any other software that depends on the backported package must continue to run with the backported package installed, and any package that has a build-dependency on the backported package must build with the new package installed. In case that's not possible, the backported package must set appropriate package relations (Breaks, et al.) to prevent any incompatible installation (such Breaks could conceivably be part of the original package, it needs not be a backport-specific change).
Future Maintenance of the Backport
The Ubuntu Backports team is not responsible for the backported package.
The backporter is responsible for monitoring the backported package in the future for any bug reports, security patches, or additional updates that should be backported. Furthermore, the backporter is also responsible for any backport-specific bug that might be found in the backported package that wasn't present in the original version the backport was done from.
Prepare and upload the package
The procedure is intentionally very similar to the existing SRU procedure, with minor changes specific to the purpose of the backports pocket. You should first read and understand that process, as this will page will only highlight the specific differences, and it assumes you are familiar with the SRU process.
Select the package to backport
- There are some packages the Ubuntu Backports Team forbids from backporting.
- There are some packages the Ubuntu Backports Team handles themselves.
- Backports to non-LTS are not accepted (with exceptions).
- Backports are expected to come:
- from the current Ubuntu stable release (preferred), or
- from the current LTS release, targetting the prior LTS release, or
- from the current package version in the current Ubuntu development release.
Currently decided exceptions to the above are documented at the bottom of this page, anything else needs to be discussed with the Ubuntu Backports team either in the tracking bug or in the mailing list.
Open a Bug
The first step is to open a bug in Launchpad for the backport. Open the bug against the package that you want backported, and include the prefix [BPO] in the bug subject. The bug description should include the BPO bug template, filled out with specific details for the requested backport.
Unlike the SRU process, which does not allow requesting a SRU to add features or functionality, the backport process does allow the need for new features or functionality. The backport bug does not need to list all fixed bugs or all the new functionalities but should highlight and/or summarize the key fixes or features or other reasons for needing to backport the package.
The bug's intention is to provide a location for any paperwork that might be required for the backport. For example, if any questions are raised during review or if any discussion is required, as well as providing a reference for anyone who might want to later see why and how a specific package was backported.
Preparing the Backported Package
As in the SRU process, you must prepare a package for the backport. If you have upload rights, you can then upload directly into the backports queue. Note that unlike uploading for SRU, when uploading into the backports queue, you should use the backports pocket; for example, in the changelog instead of using the release focal you should use focal-backports. Additionally, the version number you use should exactly match the version number you are backporting from, with a specific suffix added in the format
bpoRELEASE.1, for example if backporting to release 20.04, append the suffix
When Ubuntu releases a new version of its OS every 6 months, that release is largely frozen in time. While the software that is part of that release will get bug fixes and security patches, new major releases of software and the new features that come with them will not be available.
That’s where Ubuntu Backports comes in. Backports offers a way to selectively provide newer versions of software for older Ubuntu releases. Most commonly, the Backports team will provide new versions of standalone applications which can be safely updated without impacting the rest of the system.
Security Support for Backports
Unlike the packages released with Ubuntu, Backports do not come with any security support guarantee. The Ubuntu Security Team does not update packages in Backports. When a package which has been backported receives a security update, it is the responsibility of the person who requested and performed the backport for that package to maintain it with later patches for bug fixes and security updates.
Stability of Backports
When using Backports, it is important to understand that there is an inherent risk in backporting software. Although backported packages are tested by the community before they are included in the repository, there are very occasionally bad interactions with the older software on your system that are overlooked.
Additionally, the very nature of Backports means that backported packages will change the behavior of the package in ways that may be unfamiliar to users of the older versions, and may be incompatible with configuration format and other options of the older versions.
You must determine whether apt should automatically install packages from Backports, or only install packages from Backports when they are manually requested. The Ubuntu Backporters Team recommends the latter option, which is the default.
When Backports Are Installed
There are two primary configurations for when the Ubuntu package manager will install packages from Ubuntu Backports. By default, apt will only install packages from Ubuntu Backports when they are explicitly requested, however you can configure apt to always install packages from Ubuntu Backports.
Manually Installing Packages from Backports
Option 1: install the package from Backports, resolve its dependencies from Main.
To do that append /trusty-backports to the package name. For example:
Option 2: install both the package and its dependencies from Backports.
Automatically Installing Packages from Backports
If you would like to request a new backport, please see our documentation on the backport process.
UbuntuBackports (последним исправлял пользователь ddstreet 2021-10-20 15:58:39)
The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for detailsЧитайте также: