summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* Only protect two kernels, not last installed oneJulian Andres Klode2022-04-071-16/+6
| | | | | | | | | | | | The kernel autoremoval algorithm was written to accomodate for Ubuntu's boot partition sizing, which was written to accomodate 3 kernels - 2 installed ones + a new one being unpacked. It seems that when the algorithm was designed, it was overlooked that it actually kept 3 kernels. LP: #1968154
* Fix build failure with gcc-12 due to missing includeDavid Kalnischkies2022-03-211-0/+1
| | | | | | | apt/test/interactive-helper/aptwebserver.cc: In function ‘std::string HTMLEncode(std::string)’: error: variable ‘constexpr const std::array<std::array<const char*, 2>, 6> htmlencode’ has initializer but incomplete type Reported-By: Helmut Grohne on IRC
* gpgv: Fix legacy fallback on unavailable keysJulian Andres Klode2022-03-071-0/+8
| | | | | | | | | | | | | | | | | | | | | If a repository is signed with multiple keys, apt 2.4.0 would ignore the fallback result if some keys were still missing, causing signature verification to fail. Rework the logic such that when checking if fallback was "succesful", missing keys are ignored - it only matters if we managed to verify one key now, whether good or bad. Likewise, simplify the logic when to do the fallback: If there was a bad signature in trusted.gpg.d, do NOT fallback at all - this is a minor security issue, as a key in trusted.gpg.d could fail silently with a bad signature, and then a key in trusted.gpg might allow the signature to succeed (as trusted.gpg.d key is then missing). Only fallback if we are missing a good signature, and there are keys we have not yet checked.
* Warn if the legacy trusted.gpg keyring is used for verificationJulian Andres Klode2022-02-221-0/+27
| | | | | With apt-key going away, people need to manage key files, rather than keys, so they need to know if any keys are in the legacy keyring.
* Allow --solver apt to work on apt satisfyDavid Kalnischkies2022-02-101-27/+62
| | | | | | | | | Our EDSP code is confused by the spaces in the package name, so we adopt a naming scheme similar to build-dep here instead of trying to teach EDSP to somehow encode the spaces as that is probably even more confusing for onlookers than this invalid package name is. Reported-By: Johannes Schauer Marin Rodrigues on IRC
* Silence ar by warping it in a testsuccess callDavid Kalnischkies2022-02-021-3/+3
| | | | | | | | The -q flag isn't quiet – it means quick – so ar happily prints an "ar: creating test.deb" which is harmless, but also pointless and it is the only testcase who produces output. Gbp-Dch: Ignore
* Enable tests commented out with no longer true fixmeDavid Kalnischkies2022-02-021-6/+5
| | | | | | | | Pinning and its display was reworked years ago, but the test and especially the comment never got the memo. References: a91aae406112df1d8fe16d00212333a20210f674 Gbp-Dch: Ignore
* Remove useless use of awkDavid Kalnischkies2022-02-021-6/+6
| | | | | | I have no idea what I was thinking 12 years ago. Gbp-Dch: Ignore
* Use moreutils parallel even if GNU parallel is installedDavid Kalnischkies2022-02-021-0/+2
| | | | | | | | GNU parallel diverts moreutils implementation away. As we us moreutils features just installing parallel breaks the test runner hence. We have this already for another naming scheme, so fixing this is easy enough. Gbp-Dch: Ignore
* Add a --full mode to apt showJulian Andres Klode2022-01-211-0/+14
| | | | | This adds back the missing fields that we do not show any other way.
* test/integration/test-policy-pinning: test listing multiple package in ↵Johannes Schauer Marin Rodrigues2022-01-031-0/+56
| | | | Package: field
* add pattern to select packages by codename (closes: #1002646)Johannes Schauer Marin Rodrigues2021-12-261-0/+5
|
* Support more than exact release matches in 'source'David Kalnischkies2021-11-231-0/+65
| | | | | | | | | | | | | | | | | 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
* Do not remove Essential/Protected due to dependenciesJulian Andres Klode2021-11-173-3/+27
| | | | | | | | 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 'feature/install-versioned-provides' into 'main'Julian Andres Klode2021-10-192-0/+100
|\ | | | | | | | | 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-271-0/+74
| | | | | | | | | | | | | | | | | | | | | | 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-271-0/+26
| | | | | | | | | | Edgecase of an edgecase at best, but it works just fine as a dependency, so it should really work on the commandline as well.
* | Add support for embedding PGP keys into Signed-By in deb822 sourcesJulian Andres Klode2021-10-181-0/+35
| | | | | | | | | | | | 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.
* | Merge branch 'pu/ifrange' into 'main'Julian Andres Klode2021-10-182-1/+92
|\ \ | | | | | | | | | | | | 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-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | 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-189-31/+86
|\ \ \ | | | | | | | | | | | | | | | | 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-131-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-138-31/+49
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-181-2/+8
|\ \ \ | | | | | | | | | | | | | | | | 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-041-2/+8
| | | |
* | | | Merge branch 'feature/barbarianarchs' into 'main'Julian Andres Klode2021-10-188-67/+524
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | Streamline access to barbarian architecture functionality See merge request apt-team/apt!184
| * | | Streamline access to barbarian architecture functionalityDavid Kalnischkies2021-09-043-1/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-0/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-17/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | Do not strip M-A for native build-dep resolutionDavid Kalnischkies2021-09-041-15/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back than M-A was added to build-dependencies (#558104) only the qualifiers :native and :any were considered at first which for the native case behave the same, so stripping was a good idea. Nowadays we could encounter arch-qualified dependencies, too, through – or slightly more likely conflicts perhaps – at least in theory as in practice native build-dep operations in Debian and elsewhere wouldn't have other architectures available anyhow. Still, we have full support for all this for the crossbuilding case which makes active use of this (at least is far more likely to do so), so it seems better to converge on one edgecase rather than keeping two in active use and so produce potentially different results for not specifying -a and -a $native.
| * | | Move apt specific test setup into its own functionDavid Kalnischkies2021-09-041-32/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APTs ad hoc testing framework for integration tests is not intending to be a general propose framework, but it is relatively easy to abuse it for other projects anyhow with some refactoring even if that is neither recommend nor officially supported. Gbp-Dch: Ignore
| * | | Ensure dpkg -C works correctly in our testcasesDavid Kalnischkies2021-09-043-2/+12
| |/ / | | | | | | | | | Gbp-Dch: Ignore
* | | Increase recursion limits from 100 to 3000David Kalnischkies2021-08-292-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you install dpkg on an empty status file with all recommends and suggests apt wants to install 4000+ packages. The deepest chain seemingly being 236 steps long. And dpkg isn't even the worst (~259). That is a problem as libapt has a hardcoded recursion limit for MarkInstall and friends … set to 100. We are saved by the fact that chains without suggests are much shorter (dpkg has 5, max seems ~43), but I ignored Conflicts in these chains, which typically trigger upgrades, so if two of the worst are chained together we suddenly get dangerously close to the limit still. So, lets just increase the limit into oblivion as it is really just a safety measure we should not be running into to begin with. MarkPackage was running years without it after all. 3000 is picked as a nice number as any other and because it is roughly the half of the stack crashs I saw previously in this branch.
* | | Stop autoremover from endlessly exploring cyclic providersDavid Kalnischkies2021-08-281-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fullyExplored is needed to keep track of having explored all providers of a package name, while Marked is tracking if we have explored a given real package (along its chosen version), so we should stop MarkPackage from exploring a (real) package if it is marked and let fullyExplored only guard the looping over the individual dependencies. The testcase is deceptively simple, but in practice only an ecosystem like rust who makes heavy use of cyclic dependency relations intermixed with versioned provides actually triggers this as seen by the buggy code being in use for four months in Debian and Ubuntu development releases. (easier to trigger if most packages are marked manual installed) Note that the testcase is successful already due to the earlier changes as we exit the recursion eventually and all packages are marked as they need to be already, but this fix does work standalone as well. Closes: #992993
* | | Try to show core dump info in test frameworkDavid Kalnischkies2021-08-281-2/+61
|/ / | | | | | | | | | | | | | | If the system tells us that a core dump was created we should try to display the contained info as that system might not be easily available when we see the error (like C-I or autopkgtest). Gbp-Dch: Ignore
* | tests (retry-downloads): Avoid delay in second testJulian Andres Klode2021-07-291-1/+1
| | | | | | | | This delay of 4+2+1=7 seconds in unnecessary.
* | Enhance test to check time spentJulian Andres Klode2021-07-291-1/+17
| | | | | | | | | | | | | | | | This is subject to clock skew, unfortunately, as we cannot read monotonic time in shell. We check for >=5s out of the 7s it should take to reduce the risk of skew a bit.
* | Add support for a maximum delay and testing of delayJulian Andres Klode2021-07-281-1/+12
| | | | | | | | | | | | This is very basic support on the testing side, we just test the debug output but not how long it actually took. Would be nice to check time really.
* | Merge branch 'fix/dpkgchroot' into 'main'Julian Andres Klode2021-07-051-0/+8
|\ \ | | | | | | | | | | | | Restore dpkg::chroot-directory functionality See merge request apt-team/apt!178
| * | Restore dpkg::chroot-directory functionalityDavid Kalnischkies2021-06-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we call dpkg inside a chroot we have to ensure that the temporary directory we construct to call dpkg --recursive is inside the chroot and that we strip the path to the chroot from the directory name we pass to dpkg. Note that the added test succeeds before and (hopefully) after as we can't really chroot here or fiddle with the needed settings as we are already setting up apt to work with a quasi-chroot. The test perhaps helps in ensuring we don't break it too much in the future though. (Broken five years (and one day) ago this seems to have an immense user base at the moment, but it might in the future via mmdebstrap) References: f495992428a396e0f98886c9a761a804aa161c68 Reported-By: Johannes Schauer Marin Rodrigues on IRC Tested-By: Johannes Schauer Marin Rodrigues
* | | Merge branch 'fix/sizesharing' into 'main'Julian Andres Klode2021-07-0516-39/+165
|\ \ \ | | | | | | | | | | | | | | | | Allow packages from volatile sources to be reinstalled See merge request apt-team/apt!177
| * | | Test that tiny differences result in different versionsDavid Kalnischkies2021-06-101-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just because two packages have the same version number doesn't mean it is the same package. APT can detect rebuilds and other "inconsistencies", but we had no explicit test for it so far. It turned out to be the wrong track in this branch, but as I wrote it already, lets add it at least. Gbp-Dch: Ignore
| * | | Give our test packages proper size informationDavid Kalnischkies2021-06-1016-41/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Temporary hacks should be temporary, especially if they hide bugs. After fixing one in the previous commit this is just busy work to add download information to the places which check that output. Gbp-Dch: Ignore
| * | | Store size from volatile sources for already installed versionsDavid Kalnischkies2021-06-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Volatile sources are parsed after the status file, so if we have a version already installed the size information is not stored, so that a reinstall of said version is refused claiming a broken repository. References: 1412cf51403286e9c040f9f86fd4d8306e62aff2
| * | | Use full item description in broken repo errorDavid Kalnischkies2021-06-101-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | The error says the repository is broken but doesn't mention which one it is. The item description gives us at least all the information, but is not as nicely formatted. As this message is not even marked for translation this is a rather temporary affair and we can survive without the eye candy for a while.
* / / Check sources.list could be parsed before adding volatile filesJulian Andres Klode2021-07-011-0/+15
|/ / | | | | | | | | | | | | We just used the pointer returned which might be nullptr, properly call BuildSourceList() and check the result first. Closes: #990518
* | No URL decode and quoting support for Files in SourcesDavid Kalnischkies2021-06-041-0/+10
| | | | | | | | | | | | | | | | The code exists since ever, but no other client supports this and the specification like debian-policy isn't asking for this either. What it does do is breaking than all others continue working through: If the filename includes in fact URI encoded bits (hopefully no quotes) which is rather unlikely, but none the less possible.
* | Do not use filename of local sources in 'apt download'David Kalnischkies2021-06-042-6/+4
| | | | | | | | | | | | | | | | | | | | If a source is not copying files to the destination the download code forces the copy – which in practice are local repositories accessed via file:/ – but in that process takes the filename the local repo used rather than the filename it e.g. advertised via --print-uris. A local repository could hence override a file in the current directory if you use 'apt download', which is a rather weak ability, but still.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-01 06:29:22 +0000