Lintian and Dpkg's :any multiarch acceptor
Hi, For a brief time between October 1 and October 15, Lintian gave potentially confusing advice on some build prerequisites. [1] The :any multiarch acceptor—a rarely used feature some other tools call the "muliarch qualifier"—was originally not implemented at all [2] and then implemented incorrectly. [3] Many people do not even know about the feature. To my knowledge it works now. Here are two questions: 1. Did anyone find the latest Lintian versions (2.109.0 and up) confusing as to whether the :any should be included? The material you would have encountered includes both the context offered by Lintian (the extra information after the tag) and any relevant tag descriptions. 2. Should Lintian issue any advice when it sees the :any multiarch acceptor? If so, for which packages? It might allow maintainers to undo erroneous advice they may have been given, although many folks use the feature legitimately, as well. Thank you! Kind regards Felix Lechner [1] The affected versions were 2.107.0 and 2.108.0. [2] https://bugs.debian.org/994902 [3] https://bugs.debian.org/995981
Re: deb822 sources by default for bookworm
Hi Julian, On 03-11-2021 16:45, Julian Andres Klode wrote: > There is some software "parsing" sources.list on its own, most of that > is better served by `apt-get indextargets` (and for downloading stuff > based on the urls, `apt-helper download-file`, such that it respects > proxies and supports all transports users may use in sources.list) Like autopkgtest. When I was working on it to support Debian's migration testing, I looked at python-apt and because that didn't support it, stopped thinking. With indextargets and download-file I guess we could work on it again. When were those introduced? Ubuntu needs it on old releases so before autopkgtest can change it, we'd need support for a while. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: deb822 sources by default for bookworm
On Wed, Nov 03, 2021 at 05:32:53PM +0100, Julian Andres Klode wrote: > I don't know, to be honest, have not thought about it yet. many thanks for your verbose reply! /me likes this timeline. > I think an automatic migration might be to painful what with all the > juju and ansible and saltstack (I feel like it'd be nice to have > those tools migrate config to new formats). I guess it would be nice if those tools (and users not using those tools) could run one standard tool doing the job :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This too shall pass. signature.asc Description: PGP signature
Re: deb822 sources by default for bookworm
On Wed, Nov 03, 2021 at 04:23:52PM +, Holger Levsen wrote: > Hi Julian, > > this sounds like a nice and useful plan and feature(s), thank you! > just one question: > > On Wed, Nov 03, 2021 at 04:45:15PM +0100, Julian Andres Klode wrote: > > I'd like us to move from > > /etc/apt/sources.list > > to > > /etc/apt/sources.list.d/debian.sources > [...] > > #timeline > > You didn't say so explicitly, but do you plan to support old style > /etc/apt/sources.list until forever? ;) Or do you envision automatic > migration of that file? Or? I don't know, to be honest, have not thought about it yet. With APT's 5 year interface stability and major version bump, The first time we could remove support for old releases would be trixie/apt 3.0 in 2025 (that schedule just happens because I don't want to release .10 versions, but keep the 2nd component single digit :D) I think an automatic migration might be to painful what with all the juju and ansible and saltstack (I feel like it'd be nice to have those tools migrate config to new formats). Of course, once everyone and their dog has migrated, I might feel different and complain about legacy sources.list and deprecate them. So presumably, we'd have both as supported in bookworm, sources.list deprecated for trixie, and then removed in 2030 in apt 4.0, but that's still 8 years to go. (all dates are 1 year after the change lands in unstable, as the changes land in odd numbers earlier in the cycle) -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: deb822 sources by default for bookworm
Hi Julian, this sounds like a nice and useful plan and feature(s), thank you! just one question: On Wed, Nov 03, 2021 at 04:45:15PM +0100, Julian Andres Klode wrote: > I'd like us to move from > /etc/apt/sources.list > to > /etc/apt/sources.list.d/debian.sources [...] > #timeline You didn't say so explicitly, but do you plan to support old style /etc/apt/sources.list until forever? ;) Or do you envision automatic migration of that file? Or? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
Re: deb822 sources by default for bookworm
On Wed, Nov 3, 2021 at 11:45 PM Julian Andres Klode wrote: > > Hi all, > > I'd like us to move from > > /etc/apt/sources.list > > to > /etc/apt/sources.list.d/debian.sources > While it's really a nice feature for the third-party repository, I don't see the benefits to change the default one, especially the path. I had to admit that I have countless scripts which run `sed /etc/apt/souces.list`, to change the default mirror, as well as in the Dockerfile. > in bookworm. > > # deb822 intro > > The deb822 format can be shorter and easier to read, to quote the > sources.list manual page: > >As an example, the sources for your distribution could look like this > in one-line-style format: > >deb http://deb.debian.org/debian bullseye main contrib non-free >deb http://security.debian.org bullseye-security main contrib > non-free > >or like this in deb822 style format: > >Types: deb >URIs: http://deb.debian.org/debian >Suites: bullseye >Components: main contrib non-free > >Types: deb >URIs: http://security.debian.org >Suites: bullseye-security >Components: main contrib non-free > > > Now if you mix unstable and testing, you could just have that it one > paragraph. > > The big advantage of deb822 sources is that you can embed larger data: > >Types: deb >URIs: https://deb.debian.org >Suites: stable >Components: main contrib non-free >Signed-By: > -BEGIN PGP PUBLIC KEY BLOCK- > . > > mDMEYCQjIxYJKwYBBAHaRw8BAQdAD/P5Nvvnvk66SxBBHDbhRml9ORg1WV5CvzKY > > CuMfoIS0BmFiY2RlZoiQBBMWCgA4FiEErCIG1VhKWMWo2yfAREZd5NfO31cFAmAk > > IyMCGyMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQREZd5NfO31fbOwD6ArzS > > dM0Dkd5h2Ujy1b6KcAaVW9FOa5UNfJ9FFBtjLQEBAJ7UyWD3dZzhvlaAwunsk7DG > 3bHcln8DMpIJVXht78sL > =IE0r > -END PGP PUBLIC KEY BLOCK- > > Oh yeah, a standalone sources file with embedded key - making third-party > repository management substantially more convenient. > > # issues > > several software does not support deb822 currently. I plan to work on > adding deb822 support to python-apt in the upcoming months, I don't know > what else is affected. > > There is some software "parsing" sources.list on its own, most of that > is better served by `apt-get indextargets` (and for downloading stuff > based on the urls, `apt-helper download-file`, such that it respects > proxies and supports all transports users may use in sources.list) > > In terms of setting up system, I guess debootstrap and d-i's apt-setup > module need changes? I admit I do not have a total overview. > > # timeline > > I do not know the total outcome of this. My hope would be that > we can switch the default in Summer 2022 and see what breaks, > although I don't know who's going to install from testing > d-i :D > > docker images probably can move earlier as they don't have > as much interactive users that use tools that might be broken > (e.g. software-properties). Possibly others, there's no need > to roll out in multiple places at the same time, as long as > we converge by freeze time. > > I invite people to test this out already on their own systems, > I know several people do; and extrepo also builds deb822 sources > files, but several people I guess do not know about it yet. Please > test and report bugs. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > -- Shengjing Zhu
deb822 sources by default for bookworm
Hi all, I'd like us to move from /etc/apt/sources.list to /etc/apt/sources.list.d/debian.sources in bookworm. # deb822 intro The deb822 format can be shorter and easier to read, to quote the sources.list manual page: As an example, the sources for your distribution could look like this in one-line-style format: deb http://deb.debian.org/debian bullseye main contrib non-free deb http://security.debian.org bullseye-security main contrib non-free or like this in deb822 style format: Types: deb URIs: http://deb.debian.org/debian Suites: bullseye Components: main contrib non-free Types: deb URIs: http://security.debian.org Suites: bullseye-security Components: main contrib non-free Now if you mix unstable and testing, you could just have that it one paragraph. The big advantage of deb822 sources is that you can embed larger data: Types: deb URIs: https://deb.debian.org Suites: stable Components: main contrib non-free Signed-By: -BEGIN PGP PUBLIC KEY BLOCK- . mDMEYCQjIxYJKwYBBAHaRw8BAQdAD/P5Nvvnvk66SxBBHDbhRml9ORg1WV5CvzKY CuMfoIS0BmFiY2RlZoiQBBMWCgA4FiEErCIG1VhKWMWo2yfAREZd5NfO31cFAmAk IyMCGyMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQREZd5NfO31fbOwD6ArzS dM0Dkd5h2Ujy1b6KcAaVW9FOa5UNfJ9FFBtjLQEBAJ7UyWD3dZzhvlaAwunsk7DG 3bHcln8DMpIJVXht78sL =IE0r -END PGP PUBLIC KEY BLOCK- Oh yeah, a standalone sources file with embedded key - making third-party repository management substantially more convenient. # issues several software does not support deb822 currently. I plan to work on adding deb822 support to python-apt in the upcoming months, I don't know what else is affected. There is some software "parsing" sources.list on its own, most of that is better served by `apt-get indextargets` (and for downloading stuff based on the urls, `apt-helper download-file`, such that it respects proxies and supports all transports users may use in sources.list) In terms of setting up system, I guess debootstrap and d-i's apt-setup module need changes? I admit I do not have a total overview. # timeline I do not know the total outcome of this. My hope would be that we can switch the default in Summer 2022 and see what breaks, although I don't know who's going to install from testing d-i :D docker images probably can move earlier as they don't have as much interactive users that use tools that might be broken (e.g. software-properties). Possibly others, there's no need to roll out in multiple places at the same time, as long as we converge by freeze time. I invite people to test this out already on their own systems, I know several people do; and extrepo also builds deb822 sources files, but several people I guess do not know about it yet. Please test and report bugs. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#998385: ITP: flake8-import-order -- Flake8 and pylama plugin that checks the ordering of import statements.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flake8-import-order Version : 0.18.1 Upstream Author : Alex Stapleton * URL : https://github.com/PyCQA/flake8-import-order * License : LGPLv3 Programming Lang: Python Description : Flake8 and pylama plugin that checks the ordering of import statements. A flake8 and Pylama plugin that checks the ordering of python imports. It does not check anything else about the imports. Merely that they are grouped and ordered correctly. In general stdlib comes first, then 3rd party, then local packages, and that each group is individually alphabetized, however this depends on the style used. Flake8-Import-Order supports a number of styles and is extensible allowing for custom styles.
Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
Am Donnerstag, dem 28.10.2021 um 11:58 +0300 schrieb Uladzimir Bely: > > I need to cache outside of schroot these .deb files that were downloaded by > apt. They are supposed to be used for creaing a local partial debian > repository, so that the second build will use this local repo instead of > internet one. I use a caching proxy for that (squid-deb-proxy). There is also various tools (e.g. apt-auto-proxy, squid-deb-proxy-client) to detect proxies automatically, which might require some special network setups in the chroot/container/VM though. Otherwise just set the proxy via Acquire::http::Proxy (/etc/sbuild/chroot//etc/apt/apt.conf.d/30proxy) or something similar. I use that for sbuild chroots, autopkgtest containers and VMs, and even when testing custom installer CDs. HTH and regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Re: Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies
I investigated $apt_keep_downloaded_packages=1 and found that this feature was added in more recent version of sbuild than debian `buster` provides (https:// bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=933723 is a bug where it was solved) Probably, that's why I couldn't get any results under `buster` host - apt cache is hardcoded to be cleaned by sbuild after installing dependencies. So, as I understood, the only way to cache dependency packages under `buster` is to download them in some external way. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov
