Your message dated Mon, 5 May 2008 15:05:28 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Issues with git source packages
has caused the Debian Bug report #477949,
regarding format `3.0 (git)': changes in working directory aren't ignored
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
477949: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477949
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.14.18
Severity: normal
File: /usr/bin/dpkg-source

I tried using the git format to proove a point and stumbled about
this. The dpkg-source manpage says that "-i" should ignore changes in
the working directory. But it doesn't:

dpkg-source -i -ICVS -b reprepro-3.3.2
dpkg-source: info: using source format `3.0 (git)'
dpkg-source: error: uncommitted, not-ignored changes in working directory: 
debian/changelog main.c
dpkg-buildpackage: failure: dpkg-source -i -ICVS -b reprepro-3.3.2 gave error 
exit status 255
debuild: fatal error at line 1319:
dpkg-buildpackage -rfakeroot -D -us -uc -ICVS -i failed

Further I think the dpkg-buildpackage manpage or the error message
should include that info (-i to ignore changes) more prominently. Like
"debuild" saying to use -d to override build-depends checking.


Last but not least I would suggest that changes are not
ignored. Instead when building source a temporary commit should be
made, packaged and removed from the working directory again.
dpkg-source -x of the packaged files should also remove the temporary
commit. That way there could be no mixups when people accidentally
upload a source with ignored files or delete the working directory in
the knowledge that they still have the git.tar.gz+dsc. But that is
just me. (alternatively something using --amend)

MfG
        Goswin

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22.2-mrvn
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg-dev depends on:
ii  binutils            2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  bzip2               1.0.5-0.1            high-quality block-sorting file co
ii  cpio                2.9-12               GNU cpio -- a program to manage ar
ii  dpkg                1.14.18              package maintenance system for Deb
ii  libtimedate-perl    1.1600-9             Time and date functions for Perl
ii  lzma                4.43-12              Compression method of 7z format in
ii  make                3.81-3.1             The GNU version of the "make" util
ii  patch               2.5.9-4              Apply a diff file to an original
ii  perl [perl5]        5.8.8-12             Larry Wall's Practical Extraction 
ii  perl-modules        5.8.8-12             Core Perl modules

Versions of packages dpkg-dev recommends:
ii  build-essential               11.3       informational list of build-essent
ii  gcc [c-compiler]              4:4.2.2-2  The GNU C compiler
ii  gcc-3.4 [c-compiler]          3.4.6-6    The GNU C compiler
ii  gcc-4.1 [c-compiler]          4.1.2-19   The GNU C compiler
ii  gcc-4.2 [c-compiler]          4.2.3-3    The GNU C compiler

-- no debconf information



--- End Message ---
--- Begin Message ---
severity 477954 normal
thanks

I'm CCing Joey who wrote the initial support for the git source package.
He might want to provide his input and maybe even a patch. Release
managers agreed to push changes/fixes in lenny for the new source package
formats since they are not used in lenny at all.

In response to Bug#477949:

On Fri, 25 Apr 2008, Goswin Brederlow wrote:
> I tried using the git format to proove a point and stumbled about
> this. The dpkg-source manpage says that "-i" should ignore changes in
> the working directory. But it doesn't:
> 
> dpkg-source -i -ICVS -b reprepro-3.3.2
> dpkg-source: info: using source format `3.0 (git)'
> dpkg-source: error: uncommitted, not-ignored changes in working directory: 
> debian/changelog main.c
> dpkg-buildpackage: failure: dpkg-source -i -ICVS -b reprepro-3.3.2 gave error 
> exit status 255
> debuild: fatal error at line 1319:
> dpkg-buildpackage -rfakeroot -D -us -uc -ICVS -i failed
> 
> Further I think the dpkg-buildpackage manpage or the error message
> should include that info (-i to ignore changes) more prominently. Like
> "debuild" saying to use -d to override build-depends checking.

You're confused "-i" doesn't ignore all changes but only those matching a
specific regular expression. If you want to ignore some specific changes,
then you have to modify that regular expression... which you didn't in
that example.

> Last but not least I would suggest that changes are not
> ignored. Instead when building source a temporary commit should be
> made, packaged and removed from the working directory again.

The changes are not ignored... it's a design decision to fail if
there are uncommitted changes. Thus I'm closing this bug.


In response to Bug#477954:

On Fri, 25 Apr 2008, Mike Hommey wrote:
> Severity: important

Downgraded to normal as it doesn't affect any important functionnality. 

> A .git.tar.gz resulting from dpkg-source -b will contain a lot of stuff
> that are not really or necessarily meant to be distributed:
> - gitk.cache
> - unpacked objects
> - remotes
> - stash
> - ORIG_HEAD
> - FETCH_HEAD
> - COMMIT_EDITMSG
> - config
> 
> It would be best to eliminate most of this by first cloning the repo,
> eliminate remotes, and gc --prune before creating the tarball.

I have not verified this, but if it's true, then I tend to agree with
Mike. It would be nice if we could improve here.

For "remotes" I might disagree however, it can make sense to keep them as
one might want to be able to push/pull from the remote repository used for
the maintenance. Of course, usage of "git clone" makes it more difficult
to preserve those...

Cheers,

PS: I only wanted to forward the bugs to Joey but ended up responding
and even closing the first bug. Thus I should have split this mail in
two... since I didn't please respond only to the relevant bug if you don't
respond to both.
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--- End Message ---

Reply via email to