Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 2) is the right way to proceed for _Debian_. People in a hurry can use 1, but not us. 2) imply that packages will not have DEB_VENDOR support unless some check they support it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18 2008, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. But you need to modify the rules file anyway to take advantage of the DEB_VENDOR variable, no? Currently, setting it does nothing for any package. So if people are changing the rules file, they can also add in those two lines. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. I tend to agree. Then you have one interface for Debian and one interface for every other vendor including ubuntu (or option 2 above). My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. I see that as a serious degradation in the quality of the distribution. Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. No. Debian is a member of the free software community, and being able to just do a configure, or a build, or build a single binary, by end users, is a feature that should not be given up easily. And certainly not without some significant rationale; degrating features for most of our users to cater to other distributions does not actually cut it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. I have never ever used debuild. So there is another anecdote, which may or may not mean anything. manoj -- Nothing can stop him. Not even common sense. Mark Komarinski Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). (And I don't see why one way would be more Debianish than the other) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
Goswin von Brederlow [EMAIL PROTECTED] writes: Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right. If you want to make this a rule, then we should discuss it, reach a consensus, document and publicize the change, and so forth. Right now, I feel like this change is being made as part of dpkg development, without general recognition of what's happening and without the corresponding changes to Policy so that DDs know what to expect. (I don't think this is *intentional* on your part, more a case of a set of decisions that all seemed like a good idea at the time but which cumulatively have a significant impact.) I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. The hard part of standards isn't the common case. Currently, debian/rules is defined as the package build interface, and while most people don't normally rely on that, we don't know what might break; one of the points of a standard is to let people rely on it without having to tell you first what they're doing. Personally, I use debian/rules build all the time for testing, and would never have thought to mention it to anyone. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote: On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). So it still call debian/rules directly in some case. (And I don't see why one way would be more Debianish than the other) Neither I do, but then I do not attempt to kill one way in favour of the other. I would object to a proposal policy making dpkg-buildpackage mandatory to build packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
Russ Allbery [EMAIL PROTECTED] writes: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. Then you have one interface for Debian and one interface for every other vendor including ubuntu (or option 2 above). My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. MfG Goswin PS: with dpkg-buildpackage setting env vars like it does now you already have a verry confusing situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 2) is the right way to proceed for _Debian_. People in a hurry can use 1, but not us. 2) imply that packages will not have DEB_VENDOR support unless some check they support it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). (And I don't see why one way would be more Debianish than the other) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499070: dpkg leaves system in unusable state after running out of diskspace
Hey, On Tue, 2008-09-16 at 23:14:04 +0300, Guillem Jover wrote: So I think there's two things to fix here, one is that the fseek() in createimptmp() should be done just before the fwrite() in modstatdb_note_core() to guarantee that we are going to be always at the beginning, and we make proper use of the reserved space allocated previously with those '#padding' lines to avoid the out of space condition. That's a 4-liner patch, which should be fine for lenny, and prevents this bogus condition were the user most probably is going to remove that file to be able to continue, which might produce an inconsistent state in the dpkg db. And the real problem is that there might not be an easy manual fix by the users if the status data could not be completely written to the update file. I take this back, the fseek() needs to be there to guarantee that the data has been written. So moving it would only help partially, as we would always be writting at the beginning but the fwrite() might not have enough space from the reserved padding, and the data might get truncated. The other is that when onerr_abort is signaled dpkg should not continue processing anything anymore, it should just do whatever cleanup is required and exit. But that can wait probably post-lenny. So this is the proper fix, and it should not be that big, probably less than 10 lines? Will cook something today or tomorrow... regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497893: marked as done (dpkg: [INTL:vi] Vietnamese program translation update)
notfixed apt/0.7.15~exp1 thanks Hi Michael, On Tue, 2008-09-16 at 22:10:16 +, Debian Bug Tracking System wrote: [...] Package: dpkg Tags: l10n patch Severity: wishlist The updated Vietnamese translation for the program file: dpkg translated and submitted by: Clytie Siddall Vietnamese Free-Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n Date: Tue, 16 Sep 2008 21:32:06 + From: Michael Vogt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#497893: fixed in apt 0.7.15~exp1 X-Spam-Status: No, score=-14.7 required=4.0 tests=BAYES_00,FROMDEVELOPER, FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,HEADER_X_KATIE,IMPRONONCABLE_2, MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2,PGPSIGNATURE autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Source: apt Source-Version: 0.7.15~exp1 We believe that the bug you reported is fixed in the latest version of apt, which is due to be installed in the Debian FTP archive: [...] Changes: apt (0.7.15~exp1) experimental; urgency=low [...] [ Program translations ] * Vietnamese updated. Closes: #497893 Seems you closed the wrong bug, no big deal though as this was already closed, but you might want to correct the changelog and close the relevant bug in apt. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
Goswin von Brederlow [EMAIL PROTECTED] writes: Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right. If you want to make this a rule, then we should discuss it, reach a consensus, document and publicize the change, and so forth. Right now, I feel like this change is being made as part of dpkg development, without general recognition of what's happening and without the corresponding changes to Policy so that DDs know what to expect. (I don't think this is *intentional* on your part, more a case of a set of decisions that all seemed like a good idea at the time but which cumulatively have a significant impact.) I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. The hard part of standards isn't the common case. Currently, debian/rules is defined as the package build interface, and while most people don't normally rely on that, we don't know what might break; one of the points of a standard is to let people rely on it without having to tell you first what they're doing. Personally, I use debian/rules build all the time for testing, and would never have thought to mention it to anyone. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote: On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). So it still call debian/rules directly in some case. (And I don't see why one way would be more Debianish than the other) Neither I do, but then I do not attempt to kill one way in favour of the other. I would object to a proposal policy making dpkg-buildpackage mandatory to build packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
