summaryrefslogtreecommitdiff
path: root/test/integration/test-sourceslist-trusted-options
Commit message (Collapse)AuthorAgeFilesLines
* test exitcode as well as string equalityDavid Kalnischkies2015-03-161-2/+2
| | | | | | | | We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore
* chown finished partial files earlierDavid Kalnischkies2014-10-231-2/+8
| | | | | | | | | | | | | | | | | partial files are chowned by the Item baseclass to let the methods work with them. Now, this baseclass is also responsible for chowning the files back to root instead of having various deeper levels do this. The consequence is that all overloaded Failed() methods now call the Item::Failed base as their first step. The same is done for Done(). The effect is that even in partial files usually don't belong to _apt anymore, helping sneakernets and reducing possibilities of a bad method modifying files not belonging to them. The change is supported by the framework not only supporting being run as root, but with proper permission management, too, so that privilege dropping can be tested with them.
* testcases: do not allow warnings in testsuccessDavid Kalnischkies2014-10-201-6/+6
| | | | | | | | | | Adds a new testwarning which tests for zero exit and the presents of a warning in the output, failing if either is not the case or if an error is found, too. This allows us to change testsuccess to accept only totally successful executions (= without warnings) which should help finding regressions. Git-Dch: Ignore
* testcases runable as rootDavid Kalnischkies2014-10-151-1/+1
| | | | | | | Running the testcases is usually not a good idea, but it can be handy to check if the privilege dropping works. Git-Dch: Ignore
* fix compile and tests errorDavid Kalnischkies2014-10-131-0/+27
| | | | | | I am pretty sure I did that before committing broken stuff… Git-Dch: Ignore
* trusted=yes sources are secure, we just don't know whyDavid Kalnischkies2014-10-131-0/+168
Do not require a special flag to be present to update trusted=yes sources as this flag in the sources.list is obviously special enough. Note that this is just disabling the error message, the user will still be warned about all the (possible) failures the repository generated, it is just triggering the acceptance of the warnings on a source-by-source level. Similarily, the trusted=no flag doesn't require the user to pass additional flags to update, if the repository looks fine in the view of apt it will update just fine. The unauthenticated warnings will "just" be presented then the data is used. In case you wonder: Both was the behavior in previous versions, too.