Control: severity -1 important Thorsten Glaser <firstname.lastname@example.org> (08/04/2013): > Cyril Brulebois dixit: > > >Next time, can you please put the right people in the loop?! > > > >Cc-ing: > > email@example.com > > I did a reply-to-all on the mail. > > >is just plain stupid. Maintainers of the package you're reassigning to > >don't get your control mail. Way to communicate! > > I did not know that. I think this is a debbugs bug; it’s inconsistent > to require of the bug submitter to manually look up maintainers (for > example, I wasn’t aware debootstrap has anything to do with booting > Debian…) when reassigning, when one doesn’t have to do so normally. Thankfully there's $firstname.lastname@example.org so that no lookup is necessary. The doc says: Records that bug #bugnumber is a bug in package. This can be used to set the package if the user forgot the pseudo-header, or to change an earlier assignment. No notifications are sent to anyone (other than the usual information in the processing transcript). > If debootstrap tries to umount a symlink that points to outside the > chroot, I’d call it an issue with debootstrap, independent of… > > >wishlist in debootstrap to support the new thing pbuilder imposes, and > >an RC bug in pbuilder not to depend on a debootstrap version > >implementing said improved behaviour. > > … this one. Certainly not an RC one. Faulty setups can lead to suboptimal behaviours. That's one such case. Lowering severity accordingly (even if as I said, important is probably too high on the debootstrap side). > Yes, the maintainers of debootstrap (and possibly cdebootstrap), > pbuilder and cowbuilder should probably talk to each other. > Ideally. No kidding. > But right now, we have a bug that breaks unrelated software, by > umounting my /run/shm every time I create a chroot, and thus > deleting every piece of data that was put there. In this particular > instance, I’m the user who doesn’t really care about where the bug > is, or whose fault it is – this is one of the major problems with a > system based on packages of separate maintainers… In this particular instance, I'm the guy who really doesn't care about your opinion about what the major problems with a system based on packages of separate maintainers are. Please get your random rants elsewhere, preferably around /dev/null. KiBi.
Description: Digital signature