Take bugs positively.
Bug reports are precious information that allows you to improve the quality of your packages: they are not insults to your skills, and there is nothing shameful in having a bug reported to your packages.
Having bugs reported is actually a sign that people are using your packages and are interested in them.
Interface with upstream.
As the maintainer of a package, you are also an interface between Debian users and upstream developers.
This can mean tracking upstream's development mailing lists, filtering bugs reports in the Debian BTS and forwarding relevant ones to upstream's bug tracking system. It is also needed to track what happens in upstream's bug tracking system with regards to bugs that are also reported to Debian.
If this means a lot of work, which is usually the case for popular packages, it can be a good idea to involve more people to help with the task. Usually the more a package is popular the more bugs are reported, but it is also easier to find people that could help.
Be open minded.
Bug reporters could be different people than what you expect: try not to make assuptions about them.
People could also be using the software in a different way than you do, and it may happen that your proposed solution to a problem might not work well for them, and a more general solution is needed.
These are four questions that can be very useful when the reporter seems to be working differently than what the developer expects:
What led up to the situation?
What did you do that was especially effective or ineffective?
What was the outcome or result of this action?
Why was this action effective, or what more effective action might have been expected?