Comment 17 for bug 1505670
Revision history for this message
| Christian Ehrhardt (paelzer) wrote Re: "uncaptured python exception" | #17 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Rolf,
let me try to calm things down a bit via clarifications on the
technical and ubuntu-process side of this.
> I'm not sure I understand what you did and what your results were. It
> appears that you got the issue of an "uncaptured python exception" at
> least once "when you removed squid-deb-proxy"? I really don't know what
> you mean there. Then you list the output of /usr/share/
> client/
> result once and an IPv6 result on the next, identical invocation.
The bug initially just describes to run apt-avahi-discover and it would fail.
That is exactly what everyone retrying it here did AFAICS.
But that does not fail that way.
The later insight posted on the bug that "more than one host/IP discovered via avahi" are required isn't enough either. The setup those people used has Ipv4+ipv6 = 2 IPs in avahi but still work fine.
And yes - as you quoted on Miriams example - under that condition it is reporting one of the potential IPv4/IPv6 proxy addresses in a random fashion and that might be another bug. But not a problem here.
It seems @Miriam then still didn't give up on your case, but went further trying to provoke a similar exception by removing some of the python sources and wondered if that could be similar to the reported issue. It isn't similar nor helpful in hindsight - but I appreciate that she did insist on trying to help you by evaluating other options.
> The problem with squid-deb-proxy is easy to trigger. All it needs is two
> or more responses to the avahi discovery in your LAN. See the initial
> report where it shows three different IP numbers. These days, I believe an
> IPv4 and IPv6 response from the same server is actually enough.
I've re-read it all again, but the bug description (= the initial report) does not tell that in any way. "Three" as in your last post definitely isn't mentioned anywhere before and as I outlined before "multiple" was mentioned but IPv4+IPv6 = 2 and that does not trigger it.
Comment #1 then re-analyzed the same issue providing an initial fix which is great, but still has no further details how to reproduce this. Up to comment #4 it is about revising the patch, you then kindly tested the patch #5 and called for consideration #6.
So far all was great, and then I agree the lack of a reaction then is what makes this a bad case.
Then in comment #7 you clarified that to trigger it one will need "more than one host/IP discovered via avahi." But the test setup that Andreas (comment #8) and Miriam (comment #14) was a common LXD setup which has multiple IPs which also causes the alternating ipv4/ipv6 responses.
For example here from a similar setup to the one they used:
$ avahi-browse -kprtf _apt_proxy._tcp
+;eth0;
+;eth0;
=;eth0;
=;eth0;
So it might strictly need multiple-hosts with multiple-ipv4 adresses then?
Or is it three (as you say above)?
Or "three or more?"
If so is it "three or more IPv4?" or does IPv47IPv6 not matter?
Can those IPs be on the same host, or does it have to be different systems?
...
You do know at least from your example, but we or anyone else just reading the case does not.
And as far as I read comment #14 Miriam is mostly asking for "I don't see your issue here can you help me to see why". The proper answer would IMHO be elaborating out how to setup the surrounding environment so that avahi-browse will return a set of hosts/IPs that will make it break avahi.
BTW no one ever adapted the bug description summarizing any of the new insights - I did this now to help anyone looking at it later on. There are a few open questions there which you might be able to fill in @Rolf.
> Frankly, we don't need more bug triage here, it's all been laid out
> forever, we've had a working patch for years. The patch is as far as I can
> tell correct in that it is not simply a workaround. I assume you haven't
> looked at the code.
That might be another misunderstanding - again let me try to help to clarify.
This isn't so much about triaging, but about finding a way to reliable steps to recreate it.
They want to help you and anyone else affected, but to apply the patch to anything else but future Ubuntu releases it will have to go through the SRU process [1] and that rather strictly dictates reproducibility for a test along the publishing & verification. So without very special conditions the lack of a clear test/repro can be almost as inhibiting as the lack of a fix in
the first place.
> Truth be told, the state of this bug is disgusting and demotivating.
> Ubuntu used to be about making Debian polished and usable. How come we
> dropped the ball so badly on this awesome USP?
This section is more assumption/opinion than knowledge, to be clear I agree it is dormant way too long.
But there are also reasons this might have happened. Squid-deb-proxy is not in main [2] and thereby might get less polishing and attention than you are used from other portions that make up Ubuntu. Handling of Universe packages depends mostly on the activity of the maintainer and/or a community around its users. Looking back at all the years "Ubuntu" as in [2] "Main - Canonical-
supported free and open-source software." has certainly got much better.
Response times, patch quality, regular updates and maintenance, extended use cases, even bug handling - which is the problem here - got way better. But there are things in Universe that do not get that much attention.
> ... Have you actually read the ticket? ...
Actually I think people have really read it, but as I outlined above it just
isn't as clear to someone else looking at the case than it is to you.
You have to understand that people that want to help might still never consciously have used squid-deb-
And in reverse it doesn't seem helpful to drive those people away that try to help - even out of rightful frustration for a lack of a timely reaction.
An alternative read of the "have you actually read the ticket" situation reoccuring could be "if multiple people don't get it, maybe the content/
I hope my updates here and to the description will help to avoid that aspect from ever being a problem again on this case.
> What needs to be done here is for @mvo to finally
> comment on whether or not this is the correct way to fix it or reject the
> patch (and come up with an alternative patch).
Again - I understand your frustration since this clearly is too much time, but as you say we will need to get MVO to have a look since he is the upstream&debian maintainer of the package.
I'd assume his many other duties these days just made him not see the case yet.
I want to help to get this resolved, but IMHO the lack of that response isn't justifying the hard language to Miriam or Ubuntu Developers in general. It is not my mission nor intent to further resolve the social aspect of this, but I wanted to state that to not leave all of them out in the rain alone.
So, no matter how late it is, I agree that (other than missing valid steps to recreate for the SRU policies as I mentioned above) one thing we need is MVO to consider,ack and apply it in the upstream repo.
I have contacted him via the IRC info that is on every developers [3] page and he said he will later today have a look at it.
Kind regards,
Christian
[1]: https:/
[2]: https:/
[3]: https:/