summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Release 2.3.132.3.13Julian Andres Klode2021-11-245-6/+22
|
* Merge branch 'ck/fix-basehttp-enum' into 'main'Julian Andres Klode2021-11-232-22/+22
|\ | | | | | | | | basehttp: Rename HaveContent's Tristate See merge request apt-team/apt!202
| * basehttp: Rename HaveContent's TristateCameron Katri2021-11-232-22/+22
|/ | | | | | Darwin systems define TRUE and FALSE as preprocessor macros for use with bool. This conflicts with the enum values causing the compilation to fail.
* Merge branch 'pu/reltagmatchforsource' into 'main'Julian Andres Klode2021-11-234-48/+127
|\ | | | | | | | | Support more than exact release matches in 'source' See merge request apt-team/apt!201
| * Support more than exact release matches in 'source'David Kalnischkies2021-11-234-48/+127
|/ | | | | | | | | | | | | | | | | The Debian 11 release notes elevate matching with regex to a documented and much used feature, which it previously wasn't. For binary packages this is not a problem, but source packages are special and it turns out that matching by release is here an exact string match only. A bit of refactoring later we can reuse the code we use for Packages files also for Release files, which is what we have for Sources files as those files itself have no representation in the cache. This means that we do not support matching based on components (c=main) in source, but we didn't before and we can cross that bridge if anyone notices… Closes: #998444
* Portuguese manpages translation updateAmérico Monteiro2021-11-231-118/+92
| | | | Closes: #1000424
* Merge branch 'musl-fix' into 'main'Julian Andres Klode2021-11-221-0/+1
|\ | | | | | | | | apt-pkg/contrib/srvrec.h: Explicitly include sys/types.h See merge request apt-team/apt!200
| * apt-pkg/contrib/srvrec.h: Explicitly include sys/types.hAlexander Kanavin2021-11-221-0/+1
|/ | | | This avoids type errors with musl C library.
* Release 2.3.122.3.12Julian Andres Klode2021-11-1747-791/+856
| | | | This release is dedicated to Linus Tech Tips.
* Release 2.3.12Julian Andres Klode2021-11-172-0/+34
|
* Merge branch 'pu/essential-removal' into 'main'Julian Andres Klode2021-11-175-3/+46
|\ | | | | | | | | Do not remove Essential/Protected due to dependencies See merge request apt-team/apt!198
| * Do not remove Essential/Protected due to dependenciesJulian Andres Klode2021-11-175-3/+46
| | | | | | | | | | | | | | | | Suggesting the removal of Essential and Protected packages as a solution leads to situations where YouTubers end up removing their desktop. Let's not remove such packages ourselves.
* | Merge branch 'pu/no-prompt-essential-removal' into 'main'Julian Andres Klode2021-11-173-32/+1
|\ \ | | | | | | | | | | | | Require argument to remove essential packages, do not prompt See merge request apt-team/apt!199
| * | Require argument to remove essential packages, do not promptJulian Andres Klode2021-11-173-32/+1
| |/ | | | | | | Let's make this one step harder.
* | Merge branch 'egrep' into 'main'Julian Andres Klode2021-11-131-1/+1
|\ \ | | | | | | | | | | | | bash completion: use `grep -E` instead of `egrep` See merge request apt-team/apt!197
| * | bash completion: use `grep -E` instead of `egrep`Ville Skyttä2021-11-131-1/+1
|/ / | | | | | | | | | | `egrep` has been deprecated in GNU grep since 2007, and in current post 3.7 Git it has been made to emit obsolescence warnings: https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a9515624709865d480e3142fd959bccd1c9372d1
* | Dutch manpages translation updateFrans Spiesschaert2021-11-091-36/+25
| | | | | | | | Closes: #998830
* | Merge branch 'fix-debug-output-from-signed-by' into 'main'Julian Andres Klode2021-11-051-1/+0
|\ \ | | | | | | | | | | | | Don't print every inline PGP key in Signed-By See merge request apt-team/apt!195
| * | Don't print every inline PGP key in Signed-ByVictor Westerhuis2021-11-051-1/+0
|/ / | | | | | | It looks like a debug line was left in accidentally.
* | Merge branch 'command-v' into 'main'Julian Andres Klode2021-11-043-17/+6
|\ \ | |/ |/| | | | | Use `command -v` instead of `which` See merge request apt-team/apt!193
| * Use `command -v` instead of `which`Ville Skyttä2021-11-043-17/+6
|/ | | | | | | | | | `which` has been deprecated in debianutils 5.0+. The recommended replacement, `command -v`, is mandated by Debian policy these days, in addition to being required by POSIX and its predecessor specs at least since 1994. Not found commands cause no output from `command -v` per POSIX, so remove the redundant 2>&1's while at it.
* Release 2.3.112.3.11Julian Andres Klode2021-10-2148-491/+508
|
* Invalidate cached architecture list when building cacheJulian Andres Klode2021-10-192-1/+5
| | | | | | | | Fix a regression in python-apt where switching the architectures in the config between cache invocations regressed. Regression-Of: 8ff4e226af55a9feb168477a2b1a99f9c5152e54 Gbp-Dch: full
* Merge branch 'feature/install-versioned-provides' into 'main'Julian Andres Klode2021-10-197-67/+287
|\ | | | | | | | | Allow =version and /release selectors on virtual packages See merge request apt-team/apt!121
| * Allow =version and /release selector on virtual packagesDavid Kalnischkies2020-05-275-60/+253
| | | | | | | | | | | | | | | | | | | | | | We already have code for figuring out if a virtual package is only provided by a single provider (and otherwise show a list) we can auto-select for the user, so we can adapt that to work with versioned provides as well and while at it also release selectors. The code tries to keep ABI backward compatible and hence turns relatively ugly as we need a parameter (the selector) to be passed around without adding a parameter or new virtual methods.
| * Allow version selection to match versioned self-providesDavid Kalnischkies2020-05-272-7/+34
| | | | | | | | | | Edgecase of an edgecase at best, but it works just fine as a dependency, so it should really work on the commandline as well.
* | Respect NO_COLOR environment variableJulian Andres Klode2021-10-192-2/+3
| | | | | | | | | | When color has not been turned on explictly in the configuration file or options, only turn it on if NO_COLOR is not set.
* | Merge branch 'fakechroot' into 'main'Julian Andres Klode2021-10-191-2/+12
|\ \ | | | | | | | | | | | | apt-pkg/deb/dpkgpm.cc: make DPkg::Chroot-Directory work under fakechroot See merge request apt-team/apt!189
| * | apt-pkg/deb/dpkgpm.cc: make DPkg::Chroot-Directory work under fakechrootJohannes Schauer Marin Rodrigues2021-09-191-2/+12
| | |
* | | Release 2.3.102.3.10Julian Andres Klode2021-10-1816-27/+544
| | |
* | | Merge branch 'pu/signed-by-embedded-key' into 'main'Julian Andres Klode2021-10-185-9/+104
|\ \ \ | | | | | | | | | | | | | | | | Add support for embedding PGP keys into Signed-By in deb822 sources See merge request apt-team/apt!176
| * | | Only allow full Signed-By keys where filenames are allowedJulian Andres Klode2021-10-181-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | Rename the argument to Introducer and generalize it to anything that introduces new keys into the trusted vector, like file names and full keys.
| * | | Add support for embedding PGP keys into Signed-By in deb822 sourcesJulian Andres Klode2021-10-184-5/+98
| | | | | | | | | | | | | | | | | | | | | | | | Extend the Signed-By field to handle embedded public key blocks, this allows shipping self-contained .sources files, making it substantially easier to provide third party repositories.
| * | | acquire-item: Quote Signed-By before sending itJulian Andres Klode2021-10-181-2/+2
|/ / / | | | | | | | | | | | | | | | This currently has no effect, as there are no quotable characters inside it, but it will allow us to send embedded keys through to the method.
* | | Merge branch 'pu/content-length-0' into 'main'Julian Andres Klode2021-10-182-15/+28
|\ \ \ | | | | | | | | | | | | | | | | basehttp: Turn HaveContent into a TriState See merge request apt-team/apt!179
| * | | Set haveContent to FALSE on `Content-Length: 0`Julian Andres Klode2021-07-011-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set haveContent to HaveContent::FALSE when Content-Length is 0, and change remaining code to only set it to TRUE if it has not been set so far. Closes: #990281
| * | | basehttp: Turn HaveContent into a TriStateJulian Andres Klode2021-07-012-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | We need to be able to set HaveContent to false if the Content-Length is 0, and not have that overriden just because a later header is Content-Type.
* | | | Merge branch 'pu/ifrange' into 'main'Julian Andres Klode2021-10-184-6/+125
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | Add AllowRange option to disable HTTP Range usage See merge request apt-team/apt!188
| * | | | Use exact If-Range match in our test webserverDavid Kalnischkies2021-09-162-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC7233 3.2 If-Range specifies the comparison to be an exact match, not a less or equal, which makes no sense in this context anyhow. Our server exists only to write our tests against it so this isn't much of a practical issue. I did confirm with a crashing server that no test (silently) depends on this or exhibits a different behaviour not explicitly checked for.
| * | | | Disable HTTP Range usage if varnish < 6.4 is involvedDavid Kalnischkies2021-09-162-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Debian buster (oldstable) ships 6.1 while bullseye (stable) ships 6.5 and so the later is 'fixed'. Upstream declares 6.0 still as supported. It might be still a while we encounter "bad" versions in the wild, so if we can detect and work around the issue at runtime automatically we can save some users from running into "persistent" partial files. References: https://varnish-cache.org/docs/6.4/whats-new/changes-6.4.html#changes-in-behavior
| * | | | Add AllowRange option to disable HTTP Range usageDavid Kalnischkies2021-09-163-5/+83
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | apt makes heavy usage of HTTP1.1 features including Range and If-Range. Sadly it is not obvious if the involved server(s) (and proxies) actually support them all. The Acquire::http::AllowRange option defaults to true as before, but now a user can disable Range usage if it is known that the involved server is not dealing with such requests correctly.
* | | | Merge branch 'fix/file-https-proxy' into 'main'Julian Andres Klode2021-10-1814-105/+173
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | Fix file:/// vs file:/ hang & https-proxy for http See merge request apt-team/apt!187
| * | | | Use https config on https proxies for http serversDavid Kalnischkies2021-09-135-69/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The settings used for unwrapping TLS connections depend on the access and hostname we connect to more than what we eventually unwrap. The bugreport mentions CaInfo, but all other https-settings should also apply (regardless of generic or hostname specific) to an https proxy, even if the connection we proxy through it is http-only. Closes: #990555
| * | | | Read and work with canonical file-URIs from sources.listsDavid Kalnischkies2021-09-139-36/+54
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We allow file (and other file-based methods) URIs to either be given as file:///path or as file:/path, but in various places of the acquire system we perform string comparisons on URIs which do not handle this expecting the canonical representation produced by our URI code. That used to be hidden by us quoting and dequoting the URIs in the system, but as we don't do this anymore we have to be a bit more careful on input. Ideally we would do less of these comparisons, but for now lets be content with inserting a canonicalisation early on to prevent hangs in the acquire system.
* | | | Merge branch 'bug-989558' into 'main'Julian Andres Klode2021-10-184-2/+30
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | add pattern to select packages by priority (closes: #989558) See merge request apt-team/apt!185
| * | | | add pattern to select packages by priority (closes: #989558)Johannes Schauer Marin Rodrigues2021-10-044-2/+30
| | | | |
* | | | | Merge branch 'feature/barbarianarchs' into 'main'Julian Andres Klode2021-10-1817-132/+604
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | Streamline access to barbarian architecture functionality See merge request apt-team/apt!184
| * | | | Streamline access to barbarian architecture functionalityDavid Kalnischkies2021-09-048-24/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APT is not the place this information should be stored at, but it is a good place to experiment and see what will be (not) needed in the future for a proper implementation higher up the stack. This is why "BarbarianArchitectures" is chosen instead of a more neutral and/or sensible "VeryForeign" and isn't readily exported in the API to other clients for this PoC as a to be drawn up standard will likely require potentially incompatible changes. Having a then outdated and slightly different implementation block a "good" name would be bad. The functionality itself mostly exists (ignoring bugs) since the introduction of MultiArch as we always had the risk of encountering packages of architectures not known to dpkg (forced onto the system, potentially before MultiArch) we had to deal with somehow and other edge cases. All this commit really does is allowing what could previously only be achieved with editing sources.list and some conf options via a single config option: -o APT::BarbarianArchitectures=foo,bar
| * | | | Barbarian M-A:allowed don't satisfy :any deps of other archsDavid Kalnischkies2021-09-042-4/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | What does a M-A:allowed package from non-native/non-foreign architecture provide? If we look at M-A:foreign, such a package satisfies dependencies within its own architecture, but not in other architectures, so the same should apply to :any dependencies on M-A:allowed packages, but we have a problem: While unqualified package names are architecture-specific, the virtual package name qualified with :any is not (see 3addaba1ff). We could of course make it architecture-specific now, but that would introduce many virtual packages for this relatively minor usecase and would reintroduce a need for special display handling. So, we pull a trick here: Barbarian M-A:allowed packages do not provide the architecture-independent :any package anymore, but only a specific one and every :any dependency from a barbarian package is rewritten to an or-group of the specific and the independent :any package. References: 3addaba1ff
| * | | | Do not make provides of M-A:allowed implicit M-A:foreignDavid Kalnischkies2021-09-042-22/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we don't know which architectures we will deal with and to avoid creating many "unneeded" packages (and provides) the cache generation uses a scheme of on-demand creation (see ecc138f858). This assumed a particular handling of :any which got changed later (3addaba1ff) making this code path not only no longer needed for M-A:allowed, but actually wrong as it would go on and create provides for the explicit Provides of a package as if the package would be M-A:foreign. The result was that a package A:amd64 providing B tagged as M-A:allowed would satisfy a "C:armel depends on B". Note that this bug does NOT effect "C:armel depends on A" which is (correctly) not satisfied as before. References: ecc138f858, 3addaba1ff
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-05-12 16:15:07 +0000