Bug#569697: ldgfkjdkjg
# part of the multiarch release goal severity 569697 important user multiarch-de...@lists.alioth.debian.org usertag 569697 + multiarch thanks Hi, On Mon, Feb 06, 2012 at 04:29:24PM +, Mark Brown wrote: tag 569697 - patch so you removed the patch tag and are not actively helping others to rebase the patch onto your unreleased packaging you're holding back for months, without any signs of progress. Please note that relaxed NMU rules apply due to it being part of the multiarch release goal now. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#569697: ldgfkjdkjg
On Tue, Feb 07, 2012 at 10:53:10AM +0100, Philipp Kern wrote: On Mon, Feb 06, 2012 at 04:29:24PM +, Mark Brown wrote: tag 569697 - patch so you removed the patch tag and are not actively helping others to Yes, I've no intention of using it. I was very surprised when I saw it was tagged at all. rebase the patch onto your unreleased packaging you're holding back for months, without any signs of progress. Well, the packaging isn't there and frankly your attitude here is rather arrogant - we've had dpkg support for this in experimental for less than a week, it's not in unstable yet and you're upset that I've not been actively integrating this into unstable? I have this idea that for patches that affect everyone I ought to at least be able to try them for myself. Please note that relaxed NMU rules apply due to it being part of the multiarch release goal now. Well, I'd probably revert any NMU that someone tries to do in advance of dpkg in unstable. It really seems entirely irresponsible to just throw stuff in there without any serious testing and I really want to see a bunch of random users get multiarch (which pretty much means a multiarch enabled dpkg in unstable) before doing anything to try to make sure that the transition has been thought through and tested properly. I've had quite enough of being caught up in poorly thought through transitions and their reversions. Really, your mail is entirely demotivating - I'd really reconsider the way you're approaching maintainers here. The failure to get multiarch dpkg changes in unstable is unfortunate but calling everyone wasters isn't constructive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569697: ldgfkjdkjg
Hi Mark, Mark Brown broo...@debian.org (07/02/2012): It really seems entirely irresponsible to just throw stuff in there without any serious testing and I really want to see a bunch of random users get multiarch (which pretty much means a multiarch enabled dpkg in unstable) before doing anything to try to make sure that the transition has been thought through and tested properly. I've had quite enough of being caught up in poorly thought through transitions and their reversions. what about a zlib upload to experimental? That would greatly help early testers make sure everything is fine with multiarchified zlib, be it for the host architecture or for foreign architectures. That should lead to fewer troubles when core packages (dpkg, zlib, and friends) are uploaded to unstable. Mraw, KiBi. signature.asc Description: Digital signature
Bug#569697: ldgfkjdkjg
There may have been some misunderstanding here? I believe Philipp and Riku were interpreting this: This needs to be based on unreleased packaging which isn't anywhere public yet as saying you had some semi-finished packaging which you wanted people to rebase onto, but that they can't do so, because it isn't available to them. If that's not it, could you please say what you'd prefer packages to be relative to? Or, if they did understand correctly, could you please make that packaging available somewhere so someone can help to finish it, or prepare a patch that's more to your liking? When changing someone else's package the typical assumption is that they want you to start from the package's declared VCS or the last upload, and make minimal changes. If that's not the case for zlib, fine, but please say what starting point and which other changes you'd prefer to have. (I infer from the discussion so far that delete the Vcs-Bzr field so people don't try to follow it is one such change.) On 07/02/12 11:13, Mark Brown wrote: we've had dpkg support for this in experimental for less than a week, it's not in unstable yet and you're upset that I've not been actively integrating this into unstable? If you'd prefer experimental, that'd be good too. Having the library appear in multiarch directories and work for the main architecture is a significant step (and as far as I can see, in most cases, the only step needed), even if it can't immediately be installed for two or more architectures. Multiarch-compatible libraries for the main architecture don't require a multiarch dpkg, only a ld.so that loads from the multiarch-compatible directories (available in its final form, AFAICS, since last June). In some ways, the dependency relationship between multiarch dpkg and multiarch libraries is closer to being the other way round: a multiarch dpkg isn't useful (or testable without building local packages, i.e. by the random users you mentioned) until there are (dependency chains of) co-installable packages to install with it. For instance, GLib in testing is already installed to multiarch locations, as are all of its other dependencies. It works fine for a single-architecture system, but it isn't actually possible to install a second architecture of GLib right now, because they'd both require their architecture's zlib, and zlib isn't yet in multiarch locations, so you can only have it for one architecture. Similarly, multiarch installability of libpng/testing is only waiting for zlib, and gtk2/testing seems to only be waiting for zlib and cairo if I'm reading aptitude correctly. The patches proposed on this bug might not be perfect, but they're the minimal change. Ubuntu's zlib has had basically the same patch for almost a year (including 2 Ubuntu releases); I realise things in Ubuntu aren't always held to the same standard as in Debian, but it's not as if nobody has tried it. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569697: ldgfkjdkjg
On Tue, Feb 07, 2012 at 08:49:25PM +0100, Cyril Brulebois wrote: Mark Brown broo...@debian.org (07/02/2012): It really seems entirely irresponsible to just throw stuff in there without any serious testing and I really want to see a bunch of random users get multiarch (which pretty much means a multiarch enabled dpkg what about a zlib upload to experimental? That would greatly help early testers make sure everything is fine with multiarchified zlib, be it for the host architecture or for foreign architectures. That should lead to fewer troubles when core packages (dpkg, zlib, and friends) are uploaded to unstable. I probably will get round to it at some point hopefully before it gets into unstable but most likely not this week. I've probably spent most of the time I might've spent on it venting about the approach here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569697: ldgfkjdkjg
On Tue, Feb 07, 2012 at 08:16:06PM +, Simon McVittie wrote: There may have been some misunderstanding here? I believe Philipp and Riku were interpreting this: This needs to be based on unreleased packaging which isn't anywhere public yet as saying you had some semi-finished packaging which you wanted people to rebase onto, but that they can't do so, because it isn't available to them. If that's not it, could you please say what you'd prefer packages That's true, but it does mean I can't apply it directly. Well, I don't particularly think anyone should bother generating a new patch. to be relative to? Or, if they did understand correctly, could you please make that packaging available somewhere so someone can help to finish it, or prepare a patch that's more to your liking? That's really not a useful use of anyone's time - the change itself is trivial, it's just that I've been conservative about what I upload in general and when I've had time to look at zlib I've worked on redoing the package (or faffing around with VCSs). I can't remember but I think whatever I last had used the new paths, it's just never seemed important to get it in the archive (or we were in the freeze and there was no way something like that would get uploaded). On 07/02/12 11:13, Mark Brown wrote: we've had dpkg support for this in experimental for less than a week, it's not in unstable yet and you're upset that I've not been actively integrating this into unstable? If you'd prefer experimental, that'd be good too. Having the library appear in multiarch directories and work for the main architecture is a significant step (and as far as I can see, in most cases, the only step needed), even if it can't immediately be installed for two or more architectures. This was more a reference to the length of time things have been grinding on. I remember multi arch as having been going on since 2003 or something and we're now getting motivational mails like the one I originally replied to within a week of dpkg finally hitting experimental. Having said that I think I'm just going to throw whatever I've got over the wall. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
