Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

2017-01-11 Thread Ben Finney 
Control: retitle -1 devscripts: reject ‘debian/rules’ actions on unpatched 
source
Control: found -1 devscripts/2.13.4
Control: severity -1 wishlist

On 29-Oct-2013, Ximin Luo wrote:
> On 29/10/13 15:37, Ximin Luo wrote:
> > On 29/10/13 15:18, James McCoy wrote:
> >> This is not a bug in debuild. “debuild $target” should behave
> >> similar to “dpkg-buildpackage -T $target” […]
> 
> […] dpkg-buildpackage is quite a low-level tool used by buildd and
> other infrastructure, so does not need to be nice to users.[…]
> debuild is a user-facing tool, so you do not have that excuse.

Reading this bug report, it seems the package maintainers are
unconvinced by that reasoning.

I am altering this report to a request for new behaviour that you
describe.

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)to learn.” —Richard M. Stallman, 2002 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
Package: devscripts
Version: 2.13.4
Severity: important

It does not make sense to build or clean an unpatched source tree, since the
applied patches are considered strictly *part of the source package*. However,
`debuild build/clean`, and probably many other tools, still allows this to
happen without any warning.

This is partly a fault of policy which is very loose on what is a correct state
to initiate build actions from; I will file a separate bug for that too.

http://www.debian.org/doc/debian-policy/ch-source.html

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages devscripts depends on:
ii  dpkg-dev 1.16.12
ii  libc62.17-93
ii  perl 5.18.1-4
ii  python3  3.3.2-17
pn  python3:any  none

Versions of packages devscripts recommends:
ii  at3.1.14-1
ii  curl  7.32.0-1
ii  dctrl-tools   2.23
ii  debian-keyring2013.07.31
ii  dput  0.9.6.4
ii  equivs2.0.9
ii  fakeroot  1.18.4-2
ii  gnupg 1.4.15-1.1
ii  libcrypt-ssleay-perl  0.58-1+b1
ii  libdistro-info-perl   0.11
ii  libencode-locale-perl 1.03-1
ii  libjson-perl  2.59-1
ii  libparse-debcontrol-perl  2.005-4
ii  libsoap-lite-perl 0.716-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.05-1
ii  lintian   2.5.19
ii  man-db2.6.5-2
ii  patch 2.7.1-3
ii  patchutils0.3.2-2
ii  python3-debian0.1.21+nmu2
ii  python3-magic 1:5.14-2
ii  sensible-utils0.0.9
ii  strace4.5.20-2.3
ii  unzip 6.0-9
ii  wdiff 1.1.2-1
ii  wget  1.14-4
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii  build-essential  11.6
pn  cvs-buildpackage none
pn  devscripts-elnone
ii  gnuplot  4.6.3-2
ii  gpgv 1.4.15-1.1
ii  heirloom-mailx [mailx]   12.5-2
ii  libauthen-sasl-perl  2.1500-1
ii  libfile-desktopentry-perl0.07-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perlnone
ii  libtimedate-perl 1.2000-1
ii  libyaml-syck-perl1.27-2+b1
ii  mutt 1.5.21-6.4
ii  openssh-client [ssh-client]  1:6.2p2-6
pn  svn-buildpackage none
ii  w3m  0.5.3-11

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
On 29/10/13 12:14, Ximin Luo wrote:
 Package: devscripts
 Version: 2.13.4
 Severity: important
 
 It does not make sense to build or clean an unpatched source tree, since the
 applied patches are considered strictly *part of the source package*. However,
 `debuild build/clean`, and probably many other tools, still allows this to
 happen without any warning.
 
 This is partly a fault of policy which is very loose on what is a correct 
 state
 to initiate build actions from; I will file a separate bug for that too.
 
 http://www.debian.org/doc/debian-policy/ch-source.html
 

To clarify, I'm talking about the source format 3.0 (quilt), where the
application of patches is considered to be the responsibility of dpkg-source
rather than the build process itself.

If this basic check isn't done, bugs like this [1] happen to developers that
don't know about all the precise details of how build infrastructure works.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728097

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Bill Allombert 
On Tue, Oct 29, 2013 at 12:14:16PM +, Ximin Luo wrote:
 Package: devscripts
 Version: 2.13.4
 Severity: important
 
 It does not make sense to build or clean an unpatched source tree, since the
 applied patches are considered strictly *part of the source package*. However,
 `debuild build/clean`, and probably many other tools, still allows this to
 happen without any warning.

I think I understand Ximin issue:

debclean can fail in a source tree when using the source format 3.0 quilt,
if 'debian/rules clean' requires the patches to be applied to work, for example
an upstream Makefile is fixed,
because debclean does not make sure the patches are applied.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
On 29/10/13 14:23, Bill Allombert wrote:
 On Tue, Oct 29, 2013 at 12:14:16PM +, Ximin Luo wrote:
 Package: devscripts
 Version: 2.13.4
 Severity: important

 It does not make sense to build or clean an unpatched source tree, since the
 applied patches are considered strictly *part of the source package*. 
 However,
 `debuild build/clean`, and probably many other tools, still allows this to
 happen without any warning.
 
 I think I understand Ximin issue:
 
 debclean can fail in a source tree when using the source format 3.0 quilt,
 if 'debian/rules clean' requires the patches to be applied to work, for 
 example
 an upstream Makefile is fixed,
 because debclean does not make sure the patches are applied.
 
 Cheers,
 

Thanks, Bill! Yes that's what I meant.

One possible way to fix this, is to change `debuild $TARGET` so that it runs:

$ dpkg-source --before-build
$ debian/rules $TARGET
$ dpkg-source --after-build

instead of just `debian/rules $TARGET`.

This works for my use case, but I'm less certain if it is completely correct.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
reopen 728198
reassign 728198 dpkg-dev
retitle 728198 dpkg-buildpackage, debuild, et al, must reject debian/rules 
actions on unpatched source trees 
affects 728198 +devscripts

On 29/10/13 15:18, James McCoy wrote:
 On Tue, Oct 29, 2013 at 12:14:16PM +, Ximin Luo wrote:
 It does not make sense to build or clean an unpatched source tree, since the
 applied patches are considered strictly *part of the source package*. 
 However,
 `debuild build/clean`, and probably many other tools, still allows this to
 happen without any warning.
 
 This is not a bug in debuild.  “debuild $target” should behave similar to
 “dpkg-buildpackage -T $target” and as stated in dpkg-buildpackage(1):
 
 1. It prepares the build environment by setting various environment
variables  (see  ENVIRONMENT)  and calls dpkg-source
--before-build (unless -T or --target has been used).
 …
 3. If  a  specific  target  has been selected with the -T or
--target option, it calls that target and stops here. Otherwise
it calls fakeroot debian/rules clean to clean the build-tree
(unless  -nc  is specified).
 
 From this, we can see that when a specific target is provided:
 a) “dpkg-source --before-build” (which is what applies the patches)
should not be called and
 b) “debian/rules $target” will be called directly and then the build
will stop.
 
 The expection when a specific target is going to be run is that the
 working tree is in a proper state to run that target.
 
 When a target isn't specified, debuild runs dpkg-source
 --before-build/--after-build just like dpkg-buildpackage does.
 
 This has previously been discussed in #628481[0].
 
 [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628481#16
 
 Cheers,
 

I'm sorry, closing this bug is a lazy cop-out that ignores a legitimate 
usability issue. Right now I cannot easily cleanup after a build; I do not want 
to use -tc because I'd like to examine the build products manually first, and 
manually running `dpkg-source --{before,after}-build` is usability bullshit.

I agree there is an expectation [..] that the working tree is in a proper 
state, but this is enforced no-where by the user-facing tools. Fixing the 
behaviour as I suggested DOES NOT BREAK ANYTHING, since it simply puts the tree 
into the state it is *supposed to already be in*. What's more, it might even 
expose subtle bugs where maintainers are incorrectly depending on a non-patched 
tree, for example #728097. That bug would not even exist if this issue had been 
properly detected by the build tools.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
On 29/10/13 15:37, Ximin Luo wrote:
 On 29/10/13 15:18, James McCoy wrote:
 This is not a bug in debuild.  “debuild $target” should behave similar to
 “dpkg-buildpackage -T $target” and as stated in dpkg-buildpackage(1):

 
 I'm sorry, closing this bug is a lazy cop-out that ignores a legitimate 
 usability issue. Right now I cannot easily cleanup after a build; I do not 
 want to use -tc because I'd like to examine the build products manually 
 first, and manually running `dpkg-source --{before,after}-build` is usability 
 bullshit.
 
 I agree there is an expectation [..] that the working tree is in a proper 
 state, but this is enforced no-where by the user-facing tools. Fixing the 
 behaviour as I suggested DOES NOT BREAK ANYTHING, since it simply puts the 
 tree into the state it is *supposed to already be in*. What's more, it might 
 even expose subtle bugs where maintainers are incorrectly depending on a 
 non-patched tree, for example #728097. That bug would not even exist if this 
 issue had been properly detected by the build tools.
 

Thinking about this some more, I'm leaning towards the opinion that this is 
more correctly devscripts problem. dpkg-buildpackage is quite a low-level tool 
used by buildd and other infrastructure, so does not need to be nice to users. 
It might even be better for them to assume certain things about the source tree.

However, (and correct me if I'm wrong), but debuild is a user-facing tool, so 
you do not have that excuse. There is no need for debuild to behave similar to 
dpkg-buildpackage -T $target. The description of devscripts is scripts to 
make the life of a Debian Package maintainer easier. Me having to run 
dpkg-source --{before,after}-build does not make my life easier.

If you don't disagree, I'll re-assign this back to devscripts.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Dmitry Smirnov 
Dear Ximin,

While I agree with you that it would be nice to have a big fat warning
when `debuild` attempts to build package with no patches applied, I
must mention that sometimes current behaviour is quite useful. When
you're hacking the source tree and finalising your patches it is
convenient that `debuild -b` is not trying to re-apply them. This is
only happening when you're building with -b option. Without -b
patches will be applied and `debuild` will fail on any error.

Regarding #728097 that you mentioned you should have build your
package in clean environment (e.g. using pbuilder) in first
place. Many other problems will happen if you're not building in clean
chroot before upload.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread James McCoy 
On Oct 29, 2013 12:30 PM, Ximin Luo infini...@gmx.com wrote:

 Thinking about this some more, I'm leaning towards the opinion that this
is more correctly devscripts problem. dpkg-buildpackage is quite a
low-level tool

I would disagree with that. dpkg-buildpackage is the standard tool to
perform package builds. debuild is an intentionally thin wrapper around it,
and we are trying to push for more of the functionality to live in
dpkg-buildpackage (c.f., #476221).

 However, (and correct me if I'm wrong), but debuild is a user-facing
tool, so you do not have that excuse. There is no need for debuild to
behave similar to dpkg-buildpackage -T $target.

Sure there is. dpkg-buildpackage's behavior is the interface that people
should expect when running builds. This doesn't mean that debuild can't add
functionality (like the log file and hook points) but the functionality
should be enhancing, not replacing, dpkg-buildpackage's behavior.

For another discussion of the behavior you're questioning, see #649531.

Cheers,
-- 
James

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Ximin Luo 
On 29/10/13 16:50, Dmitry Smirnov wrote:
 Dear Ximin,
 
 While I agree with you that it would be nice to have a big fat warning
 when `debuild` attempts to build package with no patches applied, I
 must mention that sometimes current behaviour is quite useful. When
 you're hacking the source tree and finalising your patches it is
 convenient that `debuild -b` is not trying to re-apply them. This is
 only happening when you're building with -b option. Without -b
 patches will be applied and `debuild` will fail on any error.
 

I'm not sure if I follow. `quilt refresh` syncs debian/patches with your source 
tree, then re-applying the patches simply has no effect since `dpkg-source 
--before-build` is idempotent, at least for 3.0 (quilt). You can try it and see:

- do a `dpkg-source --before-build`
- edit one of the files that the top patch affects
- `dquilt refresh`, assuming you have the `dquilt` alias set up
- `dpkg-source --before-build` several times more gives no error

Also, when I'm hacking on the patches themselves, I skip debuild and just call 
debian/rules directly (along with rolling back the debhelper logs).

 Regarding #728097 that you mentioned you should have build your
 package in clean environment (e.g. using pbuilder) in first
 place. Many other problems will happen if you're not building in clean
 chroot before upload.
 

I realise this and will go and set that up when I get some time, but my problem 
there wasn't caused by my build environment.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild ( others) must reject debian/rules actions on unpatched source trees

2013-10-29 Thread Dmitry Smirnov 
On Wed, 30 Oct 2013 04:14:00 Ximin Luo wrote:
 I'm not sure if I follow.

It is really simple. When you build using `debuild -b` you may have
only some patches applied in source tree or you may have pending
changes that are not yet written to patch files using `quilt
refresh`. So you can build package, try it, and then refresh your
patches if they are ready. `debuild -b` just builds the package and
leaves patch management to you which is convenient when you need to
apply just some patches (but not all of them) or experiment with
source tree changes. I hope that makes sense.

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org