Re: 答复: Stunned by aptitude. - a lmost done - test 1 of 3
Does this message come across: - with an HTML part? - base64-encoded? Thanks. Daniel [Test 1 of 3: w/ chars; UTF-8]
Re: 答复: Stunned by aptitude.
Paul Johnson wrote: On Wed, 2008-07-02 at 10:03 -0400, Barclay, Daniel wrote: Paul Johnson wrote: On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Because it's error-prone. Because it's a poor-quality design. Might want to check yourself before you wreck yourself: The same could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. And even if I had sent HTML, how the hell would that change the truth of my statement? We're talking about Debian and improving it. My MUA has nothing to do with that. Daniel
Re: 答复: Stunned by aptitude.
Barclay, Daniel wrote: [...] could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. It's a dual-format message encoded in MIME base64 format. So, two things are wrong with the format of your message. One, it's both plain text and HTML, and two, it's MIME encoded. The latter is not necessarily a deal-breaker, if everyone has a modern mail-reading client, but the HTML makes some people cranky. Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
Mark Allums wrote: Barclay, Daniel wrote: [...] could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. It's a dual-format message encoded in MIME base64 format. So, two things are wrong with the format of your message. One, it's both plain text and HTML, and two, it's MIME encoded. The latter is not necessarily a deal-breaker, if everyone has a modern mail-reading client, but the HTML makes some people cranky. Mark Allums Hah!, my mail client is stupid, it responds in kind, so my last message (and this one, too) may have been sent in MIME and HTML as well. Sorry about this, I will try to fix it, so that it won't happen again. Wish me luck. Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复 : Stunned by aptitude.
On Mon, Jul 07, 2008 at 04:03:04PM -0500, Mark Allums wrote: Hah!, my mail client is stupid, it responds in kind, so my last message (and this one, too) may have been sent in MIME and HTML as well. Sorry No, no they haven't. :) about this, I will try to fix it, so that it won't happen again. Wish me luck. Good luck! =) -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
Mark Allums wrote: Barclay, Daniel wrote: [...] could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. It's a dual-format message encoded in MIME base64 format. Where the heck are you seeing base64 encoding? In both the copy of my message written directly to my Sent folder and the copy I got back from my mail server (because of my BCC header addressing myself), there was _no_ base64 encoding of anything. (That's from viewing the raw message using SeaMonkey's View Source command AND from double-checking with emacs.) Are you ascribing to my MUA (and my configuration and use of it) some transformation that something else is performing? (The only type of copy I can't find is a copy echoed back from the mailing list (to see what arrived at the other end). Do Debian lists not send copies back to the original sender?) So, two things are wrong with the format of your message. One, it's both plain text and HTML, Similarly: Where are you seeing HTML? There is _no_ HTML in what my MUA sent out. ... and two, it's MIME encoded. What do you mean by MIME encoded? That's ambiguous. MIME involves a lot of things. My message has no transfer encoding other than a straight one-byte-per-character encoding (and in fact it's the simplest, plainest ASCII-based encoding: 7-bit). My message doesn't have multiple parts, so there's no encoding of multiple parts. The latter is not necessarily a deal-breaker, if everyone has a modern mail-reading client, ... Surely you're not saying that people object to the MIME-Version header field (ignorable by MUAs that don't understand it), right? Daniel
Re: 答复: Stunned by aptitude.
On Mon, 2008-07-07 at 16:52 -0400, Barclay, Daniel wrote: Paul Johnson wrote: On Wed, 2008-07-02 at 10:03 -0400, Barclay, Daniel wrote: Paul Johnson wrote: On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Because it's error-prone. Because it's a poor-quality design. Might want to check yourself before you wreck yourself: The same could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. The message I am replying to, as was the one in question, is HTML, not plain text. And even if I had sent HTML, how the hell would that change the truth of my statement? We're talking about Debian and improving it. My MUA has nothing to do with that. If you got your MUA via Debian, and you don't know you're sending HTML, I suspect that's a bug we need to fix, eh? -- Paul Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 答复: Stunned by aptitude.
Barclay, Daniel wrote: Mark Allums wrote: Barclay, Daniel wrote: [...] could be said for your HTML-spewing MUA. What that heck are you talking about? My message was sent in plain text, not HTML. It's a dual-format message encoded in MIME base64 format. Where the heck are you seeing base64 encoding? Do View message Source or similar option with your MUA/client. Read the headers. In both the copy of my message written directly to my Sent folder and the copy I got back from my mail server (because of my BCC header addressing myself), there was _no_ base64 encoding of anything. (That's from viewing the raw message using SeaMonkey's View Source command AND from double-checking with emacs.) Are you ascribing to my MUA (and my configuration and use of it) some transformation that something else is performing? No. At least, I don't think so. (The only type of copy I can't find is a copy echoed back from the mailing list (to see what arrived at the other end). Do Debian lists not send copies back to the original sender?) So, two things are wrong with the format of your message. One, it's both plain text and HTML, Similarly: Where are you seeing HTML? There is _no_ HTML in what my MUA sent out. It's there. Again, with view source, it's quite plain. ... and two, it's MIME encoded. What do you mean by MIME encoded? That's ambiguous. MIME involves a lot of things. My message has no transfer encoding other than a straight one-byte-per-character encoding (and in fact it's the simplest, plainest ASCII-based encoding: 7-bit). My message doesn't have multiple parts, so there's no encoding of multiple parts. I beg to differ. Or rather, Mozilla Thunderbird begs to differ. The latter is not necessarily a deal-breaker, if everyone has a modern mail-reading client, ... Surely you're not saying that people object to the MIME-Version header field (ignorable by MUAs that don't understand it), right? No, not a deal-breaker means MIME is okay. (Except for ancient software, which may show someone the headers and extraneous info., then force them to view a couple of blocks of seemingly random text, which are the actual message text in base64 encoding.) Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 06:29:57PM -0700, Daniel Burrows wrote: On Wed, Jul 02, 2008 at 05:35:11PM +0200, Sven Joachim [EMAIL PROTECTED] was heard to say: On 2008-07-02 16:40 +0200, Daniel Burrows wrote: On Wed, Jul 02, 2008 at 06:39:26AM -0700, Daniel Burrows [EMAIL PROTECTED] was heard to say: I put the apt-get and aptitude code up side-by-side and I can only see one difference in the conditions they use to determine whether to clean the lists. I don't see why this would matter (surely pkgAcquire::Run returns Failure if files can't be downloaded?), but if there's anyone who *can* reproduce this on demand, it would be interesting to know if the attached patch helps. Once more, with feeling. I can 100% reproduce the problem, and this patch solves it for me. Ok, I'll fold it into the next release then. Wow, that was fast. Thanks Daniel, I was seeing that as well, but didn't care too much as I have a pretty good connection (know on wood). Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
答复: Stunned by aptitude.
I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. This gives it no right to erease all information stored locally. It is like, if my mobile was broken today, my wife could not contact with me, so she should think that I DIE? And call the cops, and throw out all my staff? It is not right, Mr. -邮件原件- 发件人: Paul Johnson [mailto:[EMAIL PROTECTED] 发送时间: 2008年7月2日 12:46 收件人: debian-user@lists.debian.org 主题: Re: Stunned by aptitude. On Wed, 2008-07-02 at 09:40 +0800, Magicloud wrote: Hello, When I used aptitude, I noticed that aptitude does not have an error handling mechanism. When I `aptitude update`, if the network is broken (like dns problem, route problem), it can not connect to the server, so it reports error, and clean up local apt record. If I stupidly `aptitude autoclean` then, all my debs are gone. It is doing error handling: If it can't reach that server, there's no point in considering it a valid source. If you have no valid sources, there's no current packages. It's working as designed. -- Paul Johnson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
On Wed, 2008-07-02 at 14:01 +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. That's by far the most round logic I've heard tonight. If it can't reach the repository to know about the packages, how in the world do you expect aptitude to know about the packages? This gives it no right to erease all information stored locally. It does when you update your package list to contain no packages, then tell it to autoclean. This is purely a pilot error. It is like, if my mobile was broken today, my wife could not contact with me, so she should think that I DIE? And call the cops, and throw out all my staff? This is more like if you broke your phone, then deliberately told your friend call your wife pretending to be the coroner to let her know you died. -- Paul Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
答复: 答复: Stunned by aptitude.
On Wed, 2008-07-02 at 14:01 +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. That's by far the most round logic I've heard tonight. If it can't reach the repository to know about the packages, how in the world do you expect aptitude to know about the packages? No, no. If you do not know how to deal with it, keep it. If aptitude could not separate can not connect with get a list with nothing in..., I was stunned again -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 06:06:56AM +, Paul Johnson wrote: On Wed, 2008-07-02 at 14:01 +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. That's by far the most round logic I've heard tonight. If it can't reach the repository to know about the packages, how in the world do you expect aptitude to know about the packages? If it knew about packages for that repository in the past but failed to contact the repository now it should not assume that it's ok to wipe out the package list. I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: 答复: Stunned by aptitude.
On Wed, 2008-07-02 at 14:33 +0800, Magicloud wrote: On Wed, 2008-07-02 at 14:01 +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. That's by far the most round logic I've heard tonight. If it can't reach the repository to know about the packages, how in the world do you expect aptitude to know about the packages? No, no. If you do not know how to deal with it, keep it. If aptitude could not separate can not connect with get a list with nothing in..., I was stunned again If it can't connect, the source isn't valid anyway for the time being. Think twice before using clean or autoclean next time: Don't reap unless you know your repositories are working. -- Paul Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 答复: Stunned by aptitude.
On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Apparently, there's a flag you can set the flag mentioned upthread if it's a bother for you. -- Paul Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 06:41:09AM +, Paul Johnson wrote: On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Apparently, there's a flag you apt is not aptitude. I've not seen this in apt and I just tested it by firewalling a mirror off and running apt-get update. The lists files are still there. I ran apt-get clean and they are still there. I ran apt-get autoclean too, just to be sure. Files remained. If aptitude behaves differently then it is broken. can set the flag mentioned upthread if it's a bother for you. I believe said flag controls wether or not apt automatically removes the lists files for repositories that are not actually in your sources.list file anymore. -- Police noticed some rustling sounds from Linn's bottom area and on closer inspection a roll of cash was found protruding from Linn's anus, the full amount of cash taken in the robbery. - http://www.smh.com.au/news/world/robber-hides-loot-up-his-booty/2008/05/09/1210131248617.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 02:01:44PM +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. This gives it no right to erease all information stored locally. It is like, if my mobile was broken today, my wife could not contact with me, so she should think that I DIE? And call the cops, and throw out all my staff? It is not right, Mr. -邮件原件- 发件人: Paul Johnson [mailto:[EMAIL PROTECTED] 发送时间: 2008年7月2日 12:46 收件人: debian-user@lists.debian.org 主题: Re: Stunned by aptitude. On Wed, 2008-07-02 at 09:40 +0800, Magicloud wrote: Hello, When I used aptitude, I noticed that aptitude does not have an error handling mechanism. When I `aptitude update`, if the network is broken (like dns problem, route problem), it can not connect to the server, so it reports error, and clean up local apt record. If I stupidly `aptitude autoclean` then, all my debs are gone. It is doing error handling: If it can't reach that server, there's no point in considering it a valid source. If you have no valid sources, there's no current packages. It's working as designed. Not really. See #201842 and #479620. Unfortunately Daniel Burrows still didn't comment on them. Maybe he will show up here? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 11:09:18AM +0300, Andrei Popescu [EMAIL PROTECTED] was heard to say: Not really. See #201842 and #479620. Unfortunately Daniel Burrows still didn't comment on them. Maybe he will show up here? The main reason I haven't touched those bugs is that there are many more important things to work on. This behavior might be annoying when it hits you, but the files that are wiped out are all cache files that you can download from the network when your connection is re-established. A secondary reason is that I can't figure out what's going on, because whenever I try taking my network down and running an update, my package lists are still around afterwards. I've read over the code and it looks to me like it only deletes the old package lists when it successfully downloaded new ones. Until I get more of a clue to go on, this looks to me like a way to waste a great deal of time. I put the apt-get and aptitude code up side-by-side and I can only see one difference in the conditions they use to determine whether to clean the lists. I don't see why this would matter (surely pkgAcquire::Run returns Failure if files can't be downloaded?), but if there's anyone who *can* reproduce this on demand, it would be interesting to know if the attached patch helps. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
Paul Johnson wrote: On Wed, 2008-07-02 at 14:01 +0800, Magicloud wrote: I don't think so. Obviously, if the network is broken, it absolutely does not mean that there is NO packages, just aptitude can not know. That's by far the most round logic I've heard tonight. What on earth are you talking about? There's no circular logic there. If it can't reach the repository to know about the packages, how in the world do you expect aptitude to know about the packages? He doesn't expect aptitude to know about the package. He just expects aptitude to not assume that it knows that there are no packages when it already knows that communication failed--and therefore, it should know that is doesn't know yet whether there are any packages or no. This gives it no right to erease all information stored locally. It does when you update your package list to contain no packages, then ... But aptitude shouldn't being updating the package list to list no packages when it didn't successfully communicate. It doesn't know that there are no packages. Daniel
Re: 答复: Stunned by aptitude.
Paul Johnson wrote: On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Because it's error-prone. Because it's a poor-quality design. Daniel
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 06:39:26AM -0700, Daniel Burrows [EMAIL PROTECTED]
was heard to say:
I put the apt-get and aptitude code up side-by-side and I can only see
one difference in the conditions they use to determine whether to clean
the lists. I don't see why this would matter (surely pkgAcquire::Run
returns Failure if files can't be downloaded?), but if there's anyone
who *can* reproduce this on demand, it would be interesting to know if
the attached patch helps.
Once more, with feeling.
Daniel
diff -r ce31088c455a src/generic/apt/download_update_manager.cc
--- a/src/generic/apt/download_update_manager.cc Sat Jun 28 13:05:54 2008 -0700
+++ b/src/generic/apt/download_update_manager.cc Wed Jul 02 07:39:54 2008 -0700
@@ -279,9 +279,37 @@
if(res != pkgAcquire::Continue)
return failure;
+ bool transientNetworkFailure = true;
+ result rval = success;
+
+ // We need to claim that the download failed if any source failed,
+ // and invoke Finished() on any failed items. Also, we shouldn't
+ // clean the package lists if any individual item failed because it
+ // makes users grumpy (see Debian bugs #201842 and #479620).
+ //
+ // See also apt-get.cc.
+ for(pkgAcquire::ItemIterator it = fetcher-ItemsBegin();
+ it != fetcher-ItemsEnd(); ++it)
+{
+ if((*it)-Status == pkgAcquire::Item::StatDone)
+ continue;
+
+ (*it)-Finished();
+
+ if((*it)-Status == pkgAcquire::Item::StatTransientNetworkError)
+ {
+ transientNetworkFailure = true;
+ continue;
+ }
+
+ // Q: should I display an error message for this source?
+ rval = failure;
+}
+
// Clean old stuff out
- if(fetcher-Clean(aptcfg-FindDir(Dir::State::lists)) == false ||
- fetcher-Clean(aptcfg-FindDir(Dir::State::lists)+partial/) == false)
+ if(rval == success !transientNetworkFailure
+ (fetcher-Clean(aptcfg-FindDir(Dir::State::lists)) == false ||
+ fetcher-Clean(aptcfg-FindDir(Dir::State::lists)+partial/) == false))
{
_error-Error(_(Couldn't clean out list directories));
return failure;
@@ -387,27 +415,6 @@
if(need_forget_new || need_autoclean)
apt_load_cache(progress, true);
- result rval = success;
-
- // We need to claim that the download failed if any source failed,
- // and invoke Finished() on any failed items.
- //
- // See also apt-get.cc.
- for(pkgAcquire::ItemIterator it = fetcher-ItemsBegin();
- it != fetcher-ItemsEnd(); ++it)
-{
- if((*it)-Status == pkgAcquire::Item::StatDone)
- continue;
-
- (*it)-Finished();
-
- if((*it)-Status == pkgAcquire::Item::StatTransientNetworkError)
- continue;
-
- // Q: should I display an error message for this source?
- rval = failure;
-}
-
if(apt_cache_file != NULL need_forget_new)
{
(*apt_cache_file)-forget_new(NULL);
Re: 答复: Stunned by aptitude.
On 2008-07-02 15:39 +0200, Daniel Burrows wrote: A secondary reason is that I can't figure out what's going on, because whenever I try taking my network down and running an update, my package lists are still around afterwards. Hm, just a few hours ago I tried that experiment and aptitude deleted them. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
On 2008-07-02 16:40 +0200, Daniel Burrows wrote: On Wed, Jul 02, 2008 at 06:39:26AM -0700, Daniel Burrows [EMAIL PROTECTED] was heard to say: I put the apt-get and aptitude code up side-by-side and I can only see one difference in the conditions they use to determine whether to clean the lists. I don't see why this would matter (surely pkgAcquire::Run returns Failure if files can't be downloaded?), but if there's anyone who *can* reproduce this on demand, it would be interesting to know if the attached patch helps. Once more, with feeling. I can 100% reproduce the problem, and this patch solves it for me. Cheers, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 答复: Stunned by aptitude.
On Wed, 2008-07-02 at 10:03 -0400, Barclay, Daniel wrote: Paul Johnson wrote: On Wed, 2008-07-02 at 16:19 +1000, CaT wrote: I believe that would be the point the original poster was getting at. If aptitude is really doing that then it is in the wrong. I understood it, but given that this is how apt has always worked and is documented to work, why change it now? Because it's error-prone. Because it's a poor-quality design. Might want to check yourself before you wreck yourself: The same could be said for your HTML-spewing MUA. -- Paul Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 答复 : Stunned by aptitude.
On Wed, Jul 02, 2008 at 05:35:11PM +0200, Sven Joachim [EMAIL PROTECTED] was heard to say: On 2008-07-02 16:40 +0200, Daniel Burrows wrote: On Wed, Jul 02, 2008 at 06:39:26AM -0700, Daniel Burrows [EMAIL PROTECTED] was heard to say: I put the apt-get and aptitude code up side-by-side and I can only see one difference in the conditions they use to determine whether to clean the lists. I don't see why this would matter (surely pkgAcquire::Run returns Failure if files can't be downloaded?), but if there's anyone who *can* reproduce this on demand, it would be interesting to know if the attached patch helps. Once more, with feeling. I can 100% reproduce the problem, and this patch solves it for me. Ok, I'll fold it into the next release then. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
