summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* http: Finish copying data from server to file before sending stuff to serverJulian Andres Klode2020-07-241-7/+7
| | | | | | This avoids a case where we read data, then write to the server and only then realize the connection was closed. It is somewhat slower, though.
* http: Die(): Do not flush the buffer, error out insteadJulian Andres Klode2020-07-241-18/+3
| | | | | | | By changing the buffer implementation to return true if it read or wrote something, even on EOF, we should not have a need to flush the buffer in Die() anymore - we should only be calling Die() if the buffer is empty now.
* http: Only return false for EOF if we actually did not read anythingJulian Andres Klode2020-07-241-4/+4
| | | | | | | | | This should avoid the need to Flush the buffer in Die(), because if we read anything, we are returning true, and not entering Die() at that point. Also Write() does not have a concept of EOF, so get rid of code handling that there. Was that copied from Read()?
* http: Die(): Merge flushing code from Flush()Julian Andres Klode2020-07-241-0/+5
| | | | | | | Die() needs its own Copy() of Flush() because it needs to return success or failure based on some states, but those are not precisely the same as Flush(), as Flush() will always return false at the end, for example, but we want to fall through to our error handling.
* http: Always Close() the connection in Die()Julian Andres Klode2020-07-241-2/+2
| | | | | If we reached Die() there was an issue with the server connection, so we should always explicitly close it.
* Release 2.1.72.1.7Julian Andres Klode2020-07-085-6/+36
|
* Detect pkg-config-dpkghook failure in tests to avoid fallbackDavid Kalnischkies2020-07-071-4/+8
| | | | | | | | | | | | | | | | | dpkg (>= 1.20.3) has better support for its own DPKG_ROOT resulting in architectures for the root being reported rather than the host system. Sadly the hookscript from pkg-config is not prepared for this resulting in our `dpkg --add-architecture` calls failing in the hook after dpkg has successfully added the architecture internally. The failure triggered fallback handling in the tests to work with an older version of dpkg with a different multi-arch implementation. So instead of doing the fallback, we ignore the failure if it seems like pkg-config-dpkghook is involved only producing a bunch of warnings to hint at this problem, but otherwise make the tests work again as it is a post-invoke script. References: #824774
* Fix test due to display change in ls (coreutils 8.32)David Kalnischkies2020-07-071-1/+1
| | | | | | | | | | | | | | | | | | | The test runs ls on the opened fds and greps the result for 'root root' which is how ls (<= 8.30) used to report user and group for these. Now that Debian contains 8.32 it reports user and group of the process owning them (supposedly). grepping for both unbreaks the test. lr-x------ 1 root root 64 Jul 7 19:07 0 -> 'pipe:[10458045]' lrwx------ 1 root root 64 Jul 7 19:07 1 -> /dev/pts/12 lrwx------ 1 root root 64 Jul 7 19:07 2 -> /dev/pts/12 lr-x------ 1 root root 64 Jul 7 19:07 3 -> /proc/1266484/fd vs (assuming user:group is david:david) lr-x------ 1 david david 64 Jul 7 19:07 0 -> 'pipe:[10458045]' lrwx------ 1 david david 64 Jul 7 19:07 1 -> /dev/pts/12 lrwx------ 1 david david 64 Jul 7 19:07 2 -> /dev/pts/12 lr-x------ 1 david david 64 Jul 7 19:07 3 -> /proc/1266484/fd
* Reorder config check before result looping for SRV parsing debugDavid Kalnischkies2020-07-021-11/+6
| | | | | It isn't needed to iterate over all results if we will be doing nothing anyhow as it isn't that common to have that debug option enabled.
* Reorder config check before checking systemd for non-interactive httpDavid Kalnischkies2020-07-021-9/+13
| | | | | | If this option is disabled (which it is by default in Debian), we don't have to make the call and the checks around it. Not that it really matters that much as if it would we would be better checking only once.
* Dutch program translation updateFrans Spiesschaert2020-07-021-20/+15
| | | | Closes: #963008
* Add dependency points in the resolver also to providersDavid Kalnischkies2020-07-022-9/+147
| | | | | | | | | | | We were traditionally adding points for some dependency types to the real package, but we should also do it for providers of that package to help the resolver especially if the real package is for some reason not tagged for removal yet/anymore. While at it we ensure that the points are only attributed once for each package as especially with versioned provides a package can nowadays provide another many times and would hence acquire a lot of points.
* Filter out impossible solutions for protected propagationDavid Kalnischkies2020-07-024-5/+51
| | | | | | | | If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one.
* Delay removals due to Conflicts until Depends are resolvedDavid Kalnischkies2020-07-024-80/+176
| | | | | | | | | | | | | | | | | Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically.
* Merge branch 'patch-1' into 'master'Julian Andres Klode2020-07-011-1/+1
|\ | | | | | | | | Minor Catalan grammar typo See merge request apt-team/apt!123
| * Minor Catalan grammar typoSergio Oller Moreno2020-06-301-1/+1
|/
* Add basic support for the Protected fieldJulian Andres Klode2020-06-298-2/+47
| | | | This will be mapped to Important for the time being.
* Replace some magic 64*1024 with APT_BUFFER_SIZEJulian Andres Klode2020-06-232-4/+3
|
* Deduplicate EDSP Provides line of M-A:foreign packagesDavid Kalnischkies2020-06-142-10/+18
| | | | | | | | | | | | M-A:foreign causes Provides to apply to all architectures and as we wanted to avoid resolver changes for M-A those are done by explicitly creating these provides instead of forcing the resolvers to learn about this. The EDSP is a different beast though & we don't need this trick here especially as it leads to needless (but harmless) duplication. No sort+unique is done to avoid changing order (not that it should matter, but just to be sure), but the sets should be small enough to not make a huge difference either way.
* Tell EDSP solvers about all installed pkgs ignoring archDavid Kalnischkies2020-06-142-3/+10
| | | | | | | | We usually tell EDSP solvers only about architectures we are configured to treat as native/foreign, but the system could have packages from other architectures installed (even if very unlikely) which could influence the solution (e.g. requiring a removal) so we make sure to tell them.
* Do not sent our filename-provides trick to EDSP solversDavid Kalnischkies2020-06-142-5/+22
| | | | | | | | | | | | If package is installed via an explicitly given deb file we store the filename as a provides, so that the frontend can request the filename and get the usual "Selected foo instead of foo.deb" message. We do not need to trouble the EDSP solvers with that though as these provides are not valid in various ways and we have already solved the link between commandline and package (and version) for them. Closes: #962741
* Portuguese manpages translation updateAmérico Monteiro2020-06-141-170/+242
| | | | Closes: #962483
* Do not hardcode (wrong) group and mode in setup warningDavid Kalnischkies2020-06-061-3/+3
| | | | | | | | | | | | | | Partial directories are created with 0700, but the parent is 0755, while the error message would report 0700 for both… that isn't right and can be pretty confusing. Turns out that the messages aren't marked for translation, so no unfuzzing is required & we just leave it as untranslated for now. Especially as the more detailed error strings derived from errno are translated. Reported-By: Wakko Warner <wakko@animx.eu.org> Closes: #962310
* Release 2.1.62.1.6Julian Andres Klode2020-06-035-6/+17
|
* Deal with duplicates in the solution space of a depDavid Kalnischkies2020-06-032-22/+28
| | | | | | | | | | | | | While we process the possible solutions we might modify other solutions like discarding their candidates and such, so that then we reach them they might no longer be proper candidates. We also try to drop duplicates early on to avoid the simple cases of these which test-explore-or-groups-in-markinstall triggers via its explicit duplication but could also come via multiple provides. It only worked previously as were ignoring current versions which usually is okay expect if they are marked for removal and we want to reinstate them so the ProblemResolver can decide which one later on.
* Allow 20 instead of 10 loops for pkgProblemResolverDavid Kalnischkies2020-06-032-1/+3
| | | | | | | | Especially if a lot packages have to be removed due to not to explicitly expressed conflicts the problem resolver can take a few turns to remove them all. Allowing it to try a little longer if needed seems beneficial as the worst which can happen is that we now take two times as long to present an error message to the user.
* Consider if a fix is successful before claiming it isDavid Kalnischkies2020-06-022-35/+23
| | | | | | | | | For protected packages the "Fixing" done via KillList in the ProblemResolver will usually not happen as the state change is not allowed, so the debug message is just confusing and the resolver is needlessly looping here (which might push it over the edge), so if we didn't do our thing successfully here we short-circuit a bit to help the next iteration come to a solution.
* Consider protected packages for removal if they are marked as suchDavid Kalnischkies2020-05-292-1/+25
| | | | | | | | | | The pkgProblemResolver incorrectly skips protected packages while considering packages for removal, which was always wrong but is now a lot more visible as (potentially) far more packages are considered protected in their state. Note that the testcase shows that we need more changes to make this proper.
* Fix small memory leak in MethodConfigDavid Kalnischkies2020-05-271-1/+1
| | | | | | | | | We are leaking a d-pointer currently weighting a boolean in size and MethodConfig is instantiated in small numbers only, so nobody will actually notice a difference, but proper cleanup is important. Reported-By: clang LeakSanitizer References: 04ab37fecaf286f724bef2e0969d2b67ab5ac1b1
* Release 2.1.52.1.5Julian Andres Klode2020-05-265-6/+24
|
* Dutch manpages translation updateFrans Spiesschaert2020-05-251-17/+3
| | | | Closes: #961431
* Mark PatternTreeParser::Node destructor as virtualDavid Kalnischkies2020-05-251-0/+1
| | | | | | | | | The non-virtual base-destructor causes its derivate classes to leak tiny bits of memory otherwise. The header is private and not to be used outside of APT, so we can perform this tiny ABI break as there is no ABI to break. Reported-By: valgrind and clang -fsanitize=leak
* Stub out i18n methods for -DUSE_NLS=OFFDavid Kalnischkies2020-05-251-4/+9
| | | | | | | | | | | | | | | | | Replacing the macros with stub inline functions allows for more versatile usage, e.g. fixing this compile error: In file included from /usr/include/x86_64-linux-gnu/c++/9/bits/c++locale.h:41, from /usr/include/c++/9/bits/localefwd.h:40, from /usr/include/c++/9/ios:41, from /usr/include/c++/9/ostream:38, from /usr/include/c++/9/iostream:39, from include/apt-pkg/configuration.h:30, from ../apt-pkg/contrib/netrc.cc:16: /usr/include/c++/9/clocale:54:11: error: ‘::setlocale’ has not been declared 54 | using ::setlocale; Gbp-Dch: Ignore
* Allow FMV SSE4.2 detection to succeed on clangDavid Kalnischkies2020-05-253-8/+6
| | | | | | | | | As the builtins were used in the feature test also in the default branch clang fails to compile the test helpfully complaining that you need to compile with sse4.2 to use that while on gcc it is optimized out as unused code and produces only a warning for that… removing the code from the default branch fixes this problem, but we adapt the code some more to avoid compilers optimizing it out in the future just in case.
* Silence clang warning -Wstring-plus-intDavid Kalnischkies2020-05-252-5/+5
| | | | | | | | | | | | | ../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] Cnf.CndSet("Dir::State", STATE_DIR + 1); ../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning We have a few instances of that & it should be reasonably clear that we are not actually trying to append here, but ignoring or silencing this warning with an override is far more costly than just using what clang suggests here. Reported-By: clang Gbp-Dch: Ignore
* Ensure EDSP doesn't use a dangling architecture stringDavid Kalnischkies2020-05-251-4/+2
| | | | | | | | | | | ../apt-pkg/edsp.cc:861:23: error: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] const char *arch = _config->Find("APT::Architecture").c_str(); Compilers are probably optimizing it the way the patch does by hand now. Small string optimisation helps likely as well. Othwise that should have failed left and right as EDSP is used by experimental and such builders to talk to aspcud. Reported-By: clang
* Don't update candidate provides map if the same as currentDavid Kalnischkies2020-05-251-6/+6
|
* Don't set variables to conditionally override them 2 lines laterDavid Kalnischkies2020-05-251-5/+7
| | | | Gbp-Dch: Ignore
* Allow pkgDepCache to be asked to check internal consistencyDavid Kalnischkies2020-05-243-5/+106
| | | | | | | | For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266.
* Keep status number if candidate is discarded for kept back displayDavid Kalnischkies2020-05-233-16/+12
| | | | | | | | | | | | | | | | It looks like hack and therefore I wanted this to be a very isolated commit so we can find it & revert it easily if need be, but for now it seems to work. The idea is that Status is telling us how the candidate is in relation to the current installed version which is used to figure out if a package is "kept back" by the algorithm or not, but by discarding the candidate version we loose this information. Ideally we would keep better tabs on what we do to a package and why, but for now that seems okayish. It will cause the wrong version to be displayed though as if the package is installed the installed version becomes the candidate and hence (installed => installed) is displayed.
* Known-bad candidate versions are not an upgrade optionDavid Kalnischkies2020-05-231-1/+9
| | | | | | | | | | | | | If we have a negative dependency to deal with we prefer to install an upgrade rather than remove the current version. That is why we split the method rather explicitly in two in 57df273 but there is a case we didn't react to: If we have seen the candidate before as a "satisfier" of this negative dependency there is no point in trying to upgrade to it later on. We keep that info by candidate discard if we can, but even if we can't we can at least keep that info around locally. This "fixes" (or would hide) the problem described in 04a020d as well as you don't have to discard installations you never make.
* Reset candidate version explicitly for internal state-keepingDavid Kalnischkies2020-05-236-17/+152
| | | | | | | | | | | | | | | | | | | | | | | | For a (partially) installed package like the one MarkInstall operates on at the moment we want to discard the candidate from, we have to first remove the package from the internal state keeping to have proper broken counts and such and only then reset the candidate version which is a trivial operation in comparison. Take a look at the testcase: Now, what is the problem? Correct, git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries to switch the architecture of git here (which is pointless, it knows that this won't work, but lets fix that in another commit) will eventually realize that it can't install it and wants to discard the candidate of git:i386 first removing the broken indication like it should, removing the install flag and then reapplies the broken indication: Expect it doesn't as it wants to do that over the candidate version which the package no longer had so seemingly nothing is broken. It is a bit of a hairball to figure out which commit it is exactly that is wrong here as they are all influencing each other a bit, but >= 2.1 is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie. Closes: #961266
* Release 2.1.42.1.4Julian Andres Klode2020-05-195-6/+13
|
* Check satisfiability for versioned provides, not providing versionDavid Kalnischkies2020-05-192-1/+35
| | | | References: dcdfb4723a9969b443d1c823d735e192c731df69
* Release 2.1.32.1.3Julian Andres Klode2020-05-185-6/+25
|
* private-search: Only use V.TranslatedDescription() if goodJulian Andres Klode2020-05-181-1/+1
| | | | | | | | | | | When we could not find a translated description, we were pushing V.TranslatedDescription() to the vector, but that one might not have been good either. Add the check so we don't crash later when trying to access it. LP: #1877987
* Recognize propagated protected in pkgProblemResolverDavid Kalnischkies2020-05-185-17/+33
| | | | | | | | | | | | | | | | | | | | | | | | | Turns out that pkgDepCache and pkgProblemResolver maintain two (semi) independent sets of protected flags – except that a package if marked protected in the pkgProblemResolver is automatically also marked in the pkgDepCache as protected. This way the pkgProblemResolver will have as protected only the direct user requests while pkgDepCache will (hopefully) propagate the flag to unavoidable dependencies of these requests nowadays. The pkgProblemResolver was only checking his own protected flag though and based on that calls our Mark* methods usually without checking return, leading to it believing it could e.g. remove packages it actually can't remove as pkgDepCache will not allow it as it is marked as protected there. Teaching it to check for the flag in the pkgDepCache instead avoids it believing in the wrong things eventually giving up. The scoring is keeping the behaviour of adding the large score boost only for the direct user requests though as there is no telling which other sideeffects this might have if too many packages get too many points from the get-go. Second part of fixing #960705, now with pkgProblemResolver output which looks more like the whole class of problem is resolved rather than a teeny tiny edgecase it was before.
* Propagate protected to already satisfied dependenciesDavid Kalnischkies2020-05-183-46/+89
| | | | | | | | The previous commit deals with negative, now we add the positive side of things as well which makes this a recursive endevour. As we can push the protected flag forward only if a single solution for a dependency exists it is easy for trees to not get it, so if resolving becomes difficult it won't help at all.
* Propagate protected to already satisfied conflictsDavid Kalnischkies2020-05-182-30/+113
| | | | | | | | | | | If we propagate protected e.g. due to a user request we should also act upon (at the moment) satisfied negative dependencies so that the resolver knows that installing this package later is not an option. That the problem resolver is trying bad solutions is a bug by itself which existed before and after and should be worked on. Closes: #960705
* Deal with protected solution providers firstDavid Kalnischkies2020-05-181-3/+6
| | | | | | | | For positive dependencies this isn't giving much as the dependency should already be satisfied by such a provider if its protectiveness would help, but it doesn't hurt to check them first and for negative dependencies it means that we check those first which are the most likely to fail to be removed – which is a good idea.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-02 09:23:27 +0000