Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.0.9.5 2014-12-23T13:11:13Z 2014-12-23T13:11:13Z David Kalnischkies david@kalnischkies.de 2014-12-23T13:11:13Z urn:sha1:0312a4ab115195b3b34ddf5a7a50ee1a07a59d1a 2014-12-23T10:43:16Z James McCoy jamessan@debian.org 2014-12-10T15:16:02Z urn:sha1:e5ef23145f0dc6523a5c5321a21407c955777ad2 The current filtering matches the names of the image metapackages on the i386 architecture: $ dpkg-query -l | awk '/^ii[ ]+(linux|kfreebsd|gnumach)-image-[0-9]/ && $2 !~ /-dbg$/ { print $2 }' linux-image-3.16.0-4-586 linux-image-586 This results in an extra image package being removed from APT::NeverAutoRemove, losing the intended effect of keeping the {current, previous, latest} set of images installed. Requiring a “.” in the package name tightens the matched package names to those that are installing a specific version of the image, thus eliding the meta-packages. Closes: 772732 2014-12-23T10:43:16Z David Kalnischkies david@kalnischkies.de 2014-12-22T22:14:08Z urn:sha1:748a2177dcf8ff72bca90f5c7d516559ddd67352 Commit 299aea924ccef428219ed6f1a026c122678429e6 fixes the problem of not logging terminal in case stdin & stdout are not a terminal. The problem is that we are then trying to pass-through stdin content by reading from the apt-process stdin and writing it to the stdin of the child (dpkg), which works great for users who can control themselves, but pipes and co are a bit less forgiving causing us to pass everything to the first child process, which if the sending part of the pipe is e.g. 'yes' we will never see the end of it (as the pipe is full at some point and further writing blocks). There is a simple solution for that of course: If stdin isn't a terminal, we us the apt-process stdin as stdin for the child directly (We don't do this if it is a terminal to be able to save the typed input in the log). Closes: 773061 2014-12-23T10:43:16Z David Kalnischkies david@kalnischkies.de 2014-11-18T18:53:56Z urn:sha1:a2a75ff4516f7609f4c55b42270abb8d08943c60 dpkg checks now for dependencies before running triggers, so that packages can now end up in trigger states (especially those we are not touching at all with our calls) after apt is done running. The solution to this is trivial: Just tell dpkg to configure everything after we have (supposely) configured everything already. In the worst case this means dpkg will have to run a bunch of triggers, usually it will just do nothing though. The code to make this happen was already available, so we just flip a config option here to cause it to be run. This way we can keep pretending that triggers are an implementation detail of dpkg. --triggers-only would supposely work as well, but --configure is more robust in regards to future changes to dpkg and something we will hopefully make use of in future versions anyway (as it was planed at the time this and related options were implemented). Note that dpkg currently has a workaround implemented to allow upgrades to jessie to be clean, so that the test works before and after. Also note that test (compared to the one in the bug) drops the await test as its is considered a loop by dpkg now. Closes: 769609 2014-12-23T10:43:16Z David Kalnischkies david@kalnischkies.de 2014-12-10T21:26:59Z urn:sha1:e18f6133b254db9e1dc7b202366b067b15a68123 If we have no controlling terminal opening a terminal will make this terminal our controller, which is a serious problem if this happens to be the pseudo terminal we created to run dpkg in as we will close this terminal at the end hanging ourself up in the process… The offending open is the one we do to have at least one slave fd open all the time, but for good measure, we apply the flag also to the slave fd opening in the child process as we set the controlling terminal explicitely here. This is a regression from 150bdc9ca5d656f9fba94d37c5f4f183b02bd746 with the slight twist that this usecase was silently broken before in that it wasn't logging the output in term.log (as a pseudo terminal wasn't created). Closes: 772641 2014-12-22T13:23:39Z David Kalnischkies david@kalnischkies.de 2014-11-29T16:59:52Z urn:sha1:92e8c1ff287ab829de825e00cdf94744e699ff97 Real webservers (like apache) actually send an error page with a 416 response, but our client didn't expect it leaving the page on the socket to be parsed as response for the next request (http) or as file content (https), which isn't what we want at all… Symptom is a "Bad header line" as html usually doesn't parse that well to an http-header. This manifests itself e.g. if we have a complete file (or larger) in partial/ which isn't discarded by If-Range as the server doesn't support it (or it is just newer, think: mirror rotation). It is a sort-of regression of 78c72d0ce22e00b194251445aae306df357d5c1a, which removed the filesize - 1 trick, but this had its own problems… To properly test this our webserver gains the ability to reply with transfer-encoding: chunked as most real webservers will use it to send the dynamically generated error pages. (The tests and their binary helpers had to be slightly modified to apply, but the patch to fix the issue itself is unchanged.) Closes: 768797 2014-12-22T11:42:17Z Theppitak Karoonboonyanan thep@debian.org 2014-12-22T11:42:17Z urn:sha1:988d4f441eb2c7ac64cec339dbc02daa47fe84a4 Closes: 772913 2014-12-22T11:39:24Z Kenshi Muto kmuto@debian.org 2014-12-22T11:39:24Z urn:sha1:3efd046e3f1168de5ca1e5e7c04cc55c2bf4e811 Closes: 772678 2014-12-22T11:36:25Z Zhou Mo cdluminate@gmail.com 2014-12-22T11:36:25Z urn:sha1:220cf74e3c33fefb9f90853a22a5f828a15ff521 Closes: 771982 2014-12-22T11:30:32Z Jean-Pierre Giraud jean-pierregiraud@neuf.fr 2014-12-22T11:30:32Z urn:sha1:6393a493035d7b1e0000bbc7b74bc5b31b32eacd Closes: 771967