Guillem Jover wrote:
> Hi Joey and Nicolas!
>
> Long time ago the Debconf::Gettext [O] module got imported into the dpkg
> code base [I] with some modifications from Nicolas. The current module
> in the dpkg code base is [C], which has seen substantial modifications
> by me since its import.
>
>
Package: dpkg-dev
Version: 1.17.18
Severity: normal
The new dpkg-buildpackage -g option can also be passed to
dpkg-genchanges, but is not documented on its man page. This makes it
hard to figure out that dpkg-buildpackage --changes-option=-g can be
used.
-- System Information:
Debian Release:
Guillem Jover wrote:
Hmm, I had already pondered about this when I saw the announcement. So,
while I agree such option would make life easier for people that want
to do “almost-source-only uploads” right now (because TBH the other
alternatives are very annoying), on first thought this seemed
Raphael Hertzog wrote:
Funnily this can already be done with “dpkg-buildpackage
--changes-option=-S” but it will generate a _arch.changes file
that list only the source package (that's because the filename
is decided by dpkg-buildpackage while the content comes from
dpkg-genchanges).
Hmm, so
Guillem Jover wrote:
But, this has a nice side-effect, you can also do something like:
$ dpkg-buildpackage --changes-option=-g
which will perform a normal full build, but filter the generated
.changes file to only include source+arch-indep packages. Which I
think is what you'd be
Package: dpkg-dev
Version: 1.17.10
Severity: wishlist
Now that the archive supports source-only uploads, with the exception
that arch:all debs have to still be uploaded (as no autobuilder is
responsible for them), dpkg-genchanges -S is useful, but not quite
right.
It would be good to have an
Package: dpkg-dev
Version: 1.17.1
Severity: minor
dgit obsoletes the 3.0 (git) source format, which is unused anyway.
Please remove it.
--
see shy jo
signature.asc
Description: Digital signature
Guillem Jover wrote:
While it's true the format is not being used in Debian, that dgit might
obsolete it there too, that it might have been a mistake to add the git
and bzr formats to dpkg and that the formats are marked as experimental,
I'd be slightly uncomfortable removing them from dpkg,
Michael Biebl wrote:
Couldn't debhelper/dh_installdeb generate that Pre-Depends via
${misc:Pre-Depends} if debian/*.triggers contains noawait?
That sounds better to me then hard-coding the dependency.
This would have the additional benefit, that in jessie+1, a simple
rebuild would be
Nicholas Bamber wrote:
Techincally the shell script
fragments incorporated into Debian maintance scripts by debhelper may
fall into this category
For code that is licensed like so?
Redistribution and use in source and binary forms, with or without
modification, are permitted under any
Colin Watson wrote:
+ my $templates=`dpkg-query --control-path $pkg templates`;
+ my $path_script=`dpkg-query --control-path $pkg $script`;
+ open (QUERY, '-|', 'dpkg-query', '-W',
+ '-f', '${Package} ${Triggers-Pending}\n');
It's a shame that
Goswin von Brederlow wrote:
pkg:arch will still be unique and the dpkg/apt output will use the
architecture where required for uniqueness. So I think that after some
getting used to it it will be clear enough again.
Here are a few examples of the problems I worry about. I have not
verified any
Raphael Hertzog wrote:
Joey, would it be possible to also extract the language code from the
path when the dirname matches m{/man/([a-z][a-z](?:_[A-Z][A-Z])?)/man\d$} ?
It's specific enough to avoid wrong guesses and it seems to make sense
when you want to use dh_installman to install manual
Guillem Jover wrote:
Aside from what I said on my other reply, I just wanted to note that
this seems to be a recurring point of tension in the project when it
comes to archive wide source package changes, where supposed short
term convenience (with its usually long term harmful effects)
Modestas Vainius wrote:
I don't think it is a fair statement. Examples of minimal dh rules all over
the place in your blog, debhelper package and dh manual page DO NOT have
build
flags handling. It is true that it's the result of inappropriate dpkg-
buildpackage behaviour but it's still a
I keep seeing people complain that this bug is not fixed, but every
time I look at it, I find myself unable to fix it, and with issues like
these:
* Where are these variables documented?
(Appears that they're basically not, which makes it sorta hard to
know that they are being set, or used,
Raphael Hertzog wrote:
My question is thus: are there triggers currently in use where this
relaxed behaviour would be wrong? Or more simply are there packages which
are really not working before the processing of their awaited triggers?
python-support seems to need that; python does not see
Raphael Hertzog wrote:
I don't know anything about Haskell. What does the trigger do? Is it some
sort of non-optional byte-compilation?
It makes the cabal package manager aware of the package installed by the
dpkg package manager, iirc.
--
see shy jo
signature.asc
Description: Digital
Raphael Hertzog wrote:
Please reconsider. I think it's been well explained that version numbers
ought to start with a number.
Where? Also, f is a number around here.
Example breakage includes the bitlbee bzr snapshots, which many stable
users of bitlbee were probably using.
--
see shy jo
Sven Joachim wrote:
No, it does not like the trailing space after urgency=low in the 2.50
entry.
I see. dpkg-parsechangelog has no problem with trailing space, so
maybe dpkg-mergechangelog should also be less strict.
(dropping severity to minor)
--
see shy jo
signature.asc
Description:
Phillip Susi wrote:
I've noticed triggers being invoked repeatedly during upgrades rather
than once at the end, as they are supposed to. I started looking at
/var/log/dpkg.log to try and figure out why.
Becaue apt has not been changed to tell dpkg to defer trigger processing,
and to them run
Raphaël Hertzog wrote:
dpkg-gencontrol could be modified to always append the value of
${implicit:fieldname} at the end of the corresponding field.
Note this would mean that for depends fields, the content of the
substvar would need to start with , .
CCing -devel and Joey Hess to have some
Based on a patch by Tanguy Ortolo.
---
man/dpkg-source.1 | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/man/dpkg-source.1 b/man/dpkg-source.1
index 3d87bc5..69b84fe 100644
--- a/man/dpkg-source.1
+++ b/man/dpkg-source.1
@@ -555,12 +555,18 @@ The generated
---
man/dpkg-source.1 |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/man/dpkg-source.1 b/man/dpkg-source.1
index ac3ff82..3d87bc5 100644
--- a/man/dpkg-source.1
+++ b/man/dpkg-source.1
@@ -587,6 +587,7 @@ include. It may also be any parameter that can be passed to
the
It was looking in the current directory, which works most of the time,
but not always.
---
scripts/Dpkg/Source/Package/V3/git.pm |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/Dpkg/Source/Package/V3/git.pm
b/scripts/Dpkg/Source/Package/V3/git.pm
index
Some questions I have..
* Do you anticipate adding more flags later? [1]
* Do you think it would be a good idea for packages to set all flags
dpkg-buildflags supports?
* If packages should set all the flags, have you considered having a
mode where it lists them all (like dpkg-architecture
Peter Krefting wrote:
How does this interact with the actual Git repository, when it comes
to detecting patches to upstream and such? I haven't really read up
on how the format is specified, so please point me in that direction
if what I am asking is obvious.
It *is* the actual git
Tollef Fog Heen wrote:
| * All history is currently included (via the --all switch to git-bundle),
| but I plan to add a format-specific dpkg-source option, to allow
| filtering of what is included in the bundle.
Maybe allow a filter to be specified in debian/source somewhere?
It should
,
so their history is not included.
--
see shy jo
From 1d1da3324366280b1cfd79bd0508377dccc3bbfb Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Tue, 1 Jun 2010 16:01:35 -0400
Subject: [PATCH] modify 3.0 (git) to use git bundle
Much better than the old approach of a tarball
--
see shy jo
From 4ea8342f75f1fd5119b1a0732fb0227b0ab06382 Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Tue, 1 Jun 2010 16:01:35 -0400
Subject: [PATCH] modify 3.0 (git) to use git bundle
Much better than the old approach of a tarball of the .git repository,
the git bundle format
Package: dpkg-dev
Version: 1.15.7.2
Severity: wishlist
--merge-prereleases is nice, but requires
a) Everyone used the same base version number. There are many
ways that can not happen, maybe someone thinks the next
version will be 1.1 and someone else 1.0.1. Or maybe
the version is
Raphael Hertzog wrote:
* If doing as the man page suggests and avoiding a pre-depends
by testing dpkg-maintscript-helper supports.
Here you'd presumably still want to let the action happen
in a later upgrade if the old conffile is still present.
(At least when removing an old
Package: dpkg
Version: 1.15.7.2
Severity: minor
When run without a parameter, dpkg-maintscript-helper fails
trying to shift away parameters that do not exist.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1,
Package: dpkg
Version: 1.15.7.2
Severity: normal
It's not clear from dpkg-maintscript-helper(1) if the package
version is optional. Omitting the package version can be useful:
* If doing as the man page suggests and avoiding a pre-depends
by testing dpkg-maintscript-helper supports.
Here
Raphael Hertzog wrote:
Why? I mean dh_shlibdeps already does the right thing and is passing
binaries only to dpkg-shlibdeps.
At the expense of wasting time running file on everything to determine
which are binaries, which has been marked TODO:slow in the source
forever.
And then, file is
cwillu wrote:
New information on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891
Turns out to have been an unsafe assumption on dpkg's part with
apparently astronomic odds of being triggered on most filesystems.
Putting /var/lib/dpkg on an ext3 mount (I used a bind mount from my
Didier Raboud wrote:
while updating one of my packages (which again dropped a conffile), I had to
modify its preinst, according to http://wiki.debian.org/DpkgConffileHandling .
This works but is IMHO suboptimal: the code referenced on the wiki has to be
hand copied in each and every package
Joachim Wiedorn wrote:
I still use CDBS and I use simple-patches - but now without CDBS
support. My minor change is the file patches/series which let
dpkg-buildpackages know that there are patches. This seems very simple,
too. To get the old manner, I must only delete the series file and add
I support changing 3.0 (git) to use a bundle. Besides closing the bugs
mentioned in this thread, a bundle consists of a simple header + a standard
git pack. Since git packs are used as a wire format, this provides better
assurance that future versions of git will retain compatability with
the
Eugene V. Lyubimkin wrote:
They are important. Unless .deb have a canonical name, I cannot use packed
.debs as cached archives to install with cupt/apt.
apt web-escapes various characters, including the : in an epoch, so
you would have to modify filenames even if the epoch was included.
I'd forgotten that I submitted a patch to dpkg over a year ago to add a
dpkg-conffile(8) utility.
Note that the code on the wiki has changed slightly to handle a couple
of cases since I wrote dpkg-conffile last year. The wiki version puts a
space after $CONFFILE here to work around a bug:
Raphael Hertzog wrote:
I can add .swo but I don't think it's safe/interesting to ignore .sw[a-p].
Is that enough for you?
Flash file are .swf for examples and it would be annoying to lose them
because we were too generous in the default ignore list.
Is it not possible to ignore `.*.sw?`
Package: dpkg-dev
Version: 1.14.25
Severity: minor
The default ignores includes vi .swp files, but vim will also create
.swo, .swn, etc if the same file is being edited by two or more vims
at once.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable')
reassign 503954 dpkg-dev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Raphael Hertzog wrote:
Even if there's only two things, the fact is that the package maintainer
wants not only to decide what is supported but he might also want to
enable some features...
Did you think about having two fields, one to specify the set of
supported options, and one to allow
Phillip Susi wrote:
I'm afraid you have it backwards. In CVS when you move a file it thinks
you removed one file and added a totally new file somewhere else. In
SVN, it thinks that you copied the old file to a new location, and then
removed it. In git, the diff clearly shows fileA -
Phillip Susi wrote:
You tell git when you move a file and it records the fact in the change
record.
No, that's how every VCS *except* git works.
--
see shy jo
signature.asc
Description: Digital signature
Raphael Hertzog wrote:
Package: dpkg
Version: 1.14.19
Severity: wishlist
On Wed, 04 Jun 2008, Joey Hess wrote:
The triggered script is called once at the end of the dpkg run, and once
after the set of changed packages are unpacked. (I'm not sure why the
latter call happens.)
We
# Automatically generated email from bts, devscripts version 2.10.28
reassign 484469 dpkg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Guillem Jover wrote:
Just to clarify, for upgrades the original file is not directly deleted,
but in shell examples that's the closest we can do to test the
behaviour. Something like this roughly simulates what dpkg would do:
$ s-s-d start dictd
$ cd /usr/sbin
$ cp /bin/ls dictd.new
Guillem Jover wrote:
The test on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471060#37
seems bogus to me, as the original file would have been removed at
postinst configure time, and s-s-d should work then.
It doesn't matter if dictd is copied to dictd.orig as in my example, or
deleted
, generating a changelog
file like this:
splix (1.1.1-2) experimental; urgency=low
* Converted from .rpm format to .deb by alien version 8.71
-- Joey Hess [EMAIL PROTECTED] Thu, 01 May 2008 15:00:54 -0400
- New upstream release
- Removed PPDs for the Xerox Paser 6100, they are provided from
Sven Joachim wrote:
This is because initramfs-tools already uses triggers, see #447611¹.
I'm not convinced that it is a very good idea to do this in Lenny
packages, since the Etch versions of apt and aptitude lack support for
the new trigger states. While dpkg 1.14.18 conflicts with these
Raphael Hertzog wrote:
By contrast to old formats like tar, the git pack (and idx) formats _do_
contain a version number. Three versions exist: Version 1 was never
broadly used. (Throw one away.) Version 3 is not generated by current
versions of git. Git might start generating it at some
Package: dpkg-dev
Version: 1.14.18
Severity: normal
dpkg-buildpackage exporting CFLAGS can cause packages to FTBFS. See for
example #475979. In this case the package consists of a top-level
makefile, that runs a makefile in a subdirectory. The toplevel makefile
sets CFLAGS to some value, but does
Raphael Hertzog wrote:
The version of the software called git (we have nothing better to
identify the internal format AFAIK).
If the internal format changes, I expect that git will upgrade it in place
or something similar. However a source package published in a given
release is a git
Could the maintainers clarify what criteria are used to mark a given source
format such as 3.0 (git) as experimental?
It doesn't seem to be when the format was implemented or merged, or the
amount of testing the format has had, since the git format seems as good
or better than other
Ian Jackson wrote:
(Also, while I'm here, I note that #438547 is still open. I hope apt
has been updated already; if not it should be done forthwith.)
Apt was updated quite a while ago, this bug seems to remain open in
error since your changelog line shows up in version 0.7.7.
A file
So I've modified update-menus as the triggers docs suggest, so that
when it's run by a postinst and --real is not passed, it runs
dpkg-trigger /usr/share/menu and then exits. If --real is passed, it
does a menu update (in the foreground, no more forking to background).
I made menu declare interest
Package: dpkg-dev
Version: 1.14.18
Severity: normal
The trigger documentation should be included.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686
Hmm, on -user there have been some (detail-less) complaints lately of
dpkg apparently looping.
http://lists.debian.org/debian-user/2008/03/msg01417.html
ISTR another bug can't find it in the archives.
--
see shy jo
signature.asc
Description: Digital signature
William Pitcock wrote:
I think you mean package install-time improvements, due to postponing
ldconfig until the end of the installation. However, I am not sure how
useful this is because many maintainer scripts not generated by
debhelper call ldconfig locally.
Obviously the maintainer
Adam D. Barratt wrote:
reassign 452806 dpkg
retitle 452806 [dpkg-parsechangelog] Please maintain trailing whitespace
kthxbye
Hi,
On Sun, 2007-11-25 at 11:41 +0100, Josselin Mouette wrote:
Package: devscripts
Version: 2.10.10
Severity: normal
File: /usr/bin/dch
When dch -a is
Adam D. Barratt wrote:
reassign 452806 dpkg
retitle 452806 [dpkg-parsechangelog] Please maintain trailing whitespace
kthxbye
Hi,
On Sun, 2007-11-25 at 11:41 +0100, Josselin Mouette wrote:
Package: devscripts
Version: 2.10.10
Severity: normal
File: /usr/bin/dch
When dch -a is
Russ Allbery wrote:
(it's not yet clear to me that Git can usefully represent changesets
via feature branches, but that's another argument that is already
ongoing elsewhere).
People are arguing about that because bikeshedding and random discussion
of lattices, is, apparently, fun.
apt-cache
I haven't checked, but this sounds very similar to #20471. There's a patch
in that bug. If you can take some time to verify if it also fixes this
issue, it would be nice.
I applied this patch on top of current git master
(rev 98cdd8883f0661e24ff72d4c29d73554586eddf8), and have been using it
Frank Lichtenheld wrote:
I've now added this branch to the official dpkg repository on alioth
with the intention to work on it. I've at least fixed it up so that
it works with the current code base.
Excellent. I had kept it merged to master, but haven't checked that it's
not bit-rotted lately.
...
Setting up libzlcore (0.8.13-1) ...
Setting up libzltext (0.8.13-1) ...
Setting up fbreader (0.8.13-1) ...
[EMAIL PROTECTED]:/home/joey/src/packages/fbreaderdpkg -s libzlui-gtk
Package: libzlui-gtk
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 220
Maintainer: Joey Hess
Michael Biebl wrote:
Interesting. When I rename an obsolete, modified conffile in preinst to
.dpkg-bak, I can't find a reference anymore in /var/lib/dpkg/status or
/var/lib/dpkg/info/$pkg.*
Where does dpkg store the information about conffile then?
It must drop it from the status file
Michael Biebl wrote:
It was discussed briefly on debian-devel, but there is also the case
that the backup files should be cleaned up on purge.
dpkg tracks obsolete conffiles, but on removal/purge, it does not remove the
obsolete conffile. If it did, it would make sense for it to also remove
Michael Biebl wrote:
Hm, when you rename the conffile to *.dpkg-bak in pre-inst, dpkg does no
longer track the conffile (as the original conffile does no longer
exist). So how do you think, dpkg should handle that?
dpkg does continue to remember that there was an obsolete conffile, even
GPL2+.
Signed-off-by: Joey Hess [EMAIL PROTECTED]
---
debian/changelog |3 +
debian/copyright |3 +-
debian/dpkg.install |3 +
man/Makefile.am |1 +
man/dpkg-conffile.8 | 132 ++
scripts/Makefile.am
Raphael Hertzog wrote:
We have changed that to optional in the git repo. Did you also open a
bug on ftpmaster's side?
No, it seemed better to let the dpkg maintainers decide if I was right
and handle replying to the override messages as usual.
--
see shy jo
signature.asc
Description:
Package: dselect
Version: 1.14.7
Severity: normal
Tags: d-i
dselect's priority was recently dropped from required to important
(#452652), but important is still a much-inflated priority (so is
standard -- optional would be ok). dselect is not the kind of core unix
tool that policy defines as
Guillem Jover wrote:
Well then there's also the argument that there's no point in having it
in the source control either, it could be inferred from the section.
But those seem quite weak and specific ways to do so.
Determining a file's type from its extension is weak and specific?
Tell that to
Guillem Jover wrote:
There's 278 udebs in the current main Packages file. Each Package-Type
field takes 19 bytes, so 5282 bytes of bloat. In comparison the
Description field takes 49416 bytes. If you are really concerned about
bloat, maybe you could trim those down instead.
We are constantly
Frans seems to be spot on, dpkg should honor XC-Package-Type, and
Package-Type should be treated as an implicitly XC field, that is not
propigated into built packages. Unless you have a plan for including
Package-Type in a [u]]deb that I'm unaware of.
--
see shy jo
signature.asc
Description:
Guillem Jover wrote:
It's not included and has never been, because only the ones with B are.
But now it's explicit given that dpkg-gencontrol supports the
field. Package-Type should have been XB- from the beginning. That
information is pertinent to the binary package and not to the changes
Package: dpkg-dev
Version: 1.14.8
Severity: normal
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Seen while running dpkg-shlibdeps
Package: dpkg-dev
Version: 1.14.8
Severity: serious
dpkg-gencontrol -plibaa-bin -ldebian/changelog -isp
-Tdebian/libaa-bin.substvars -Pdebian/libaa-bin
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable
To reproduce this bug, run dpkg-shlibdeps on a package that does not
yet have a debian/tmp/DEBIAN directory.
For example, this displays the perl warning. It also generates an empty
substvars file despite the binaries linking to libc6 and stuff.
[EMAIL PROTECTED]:~package/aalibdpkg-shlibdeps
Ian Jackson wrote:
Many packages nowadays are maintained by teams sharing a revision
control system. When this happens many others who work with the
package end up using the same RCS to prepare NMUs, local versions,
etc.
So I think in these cases the fact that a particular RCS is being
Ryan Lortie wrote:
The reason for these files is obviously to avoid the need to remember to
type -I or -i every time.
3) debuild
The obvious way to solve needing to type -I and -i every time is to use
a wrapper, such as debuild, to do it.
I've been using a personal build wrapper[1] for 9
Ryan Lortie wrote:
+ * Add 'tarignore' and 'diffignore' functionality
+- list files (eg: '.git' or '.bzr') one per line to debian/tarignore
+ for dpkg-source -b to exclude them from the tarball
+- list regexps one per line to debian/diffignore for dpkg-source -b
+ to
Raphael Hertzog wrote:
I just gave a quick look to your branch:
I can understand why all these might be best practices for submitting
patches via git for a project like the linux kernel, but dpkg is not
exactly drowning in perfectly-presented git patchsets, and IMHO there are
good reasons to
Phillip Susi wrote:
Joey Hess wrote:
A sample dpkg source package built using this is at
http://kitenet.net/~joey/tmp/git-demo/. This demo package includes only
the last 200 commits to the dpkg git repo, so it's more than 1 mb
*smaller*
than dpkg's normal .tar.gz!
What was removed from
Phillip Susi wrote:
Why is that a bad thing? What good does it do to have the git repo packed
inside the source archive?
http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/
--
see shy jo, over and over, and out
signature.asc
Description: Digital
Ian Jackson wrote:
How about we ship the .orig.tar.gz, plus an rsync batched update (with
a suitably early rsync version) which turns the unpacked source into
working tree plus revision history ?
I'm afraid that due to consisting of many small gzipped compontents,
.git is not ameanable to
FWIW, I listed my goals and reasons for working on this in the blog post
linked to in the head of this thread.
I feel that I should bow out of this thread here. I've presented an
idea, a working implementation, and addressed the issues with it to the
best of my ability. Far too many times in this
Anthony Towns wrote:
Maybe providing a feature on packages.debian.org (or similar) to download
sources in simple, non-VC, tarball format would make this a complete
non-issue though?
pristine-tar could be used for this, it would just need source packages
to put the delta somewhere
Anthony Towns wrote:
Oh, one question that comes to mind: how does this affect checking for
non-free stuff in past revisions? If 3.1-4 had some non-free files that
get reimplemented for 3.2-1, do we (a) expect the maintainer to do a
no-history upload for 3.2-1; (b) check that this happens
Florian Weimer wrote:
What about empty directories?
Do you mean empty directories under .git or empty directories stored
*in* git (can't be done, use a .gitignore in the directory)
I really think you need to work off a clone (or a cleaned-up cp -al'ed
copy). For instance, you do not
Colin Watson wrote:
FWIW, I was thinking much more of native packages here; non-native
packages already tend to just import the upstream tarball which usually
contains generated files, which is probably why this hasn't been a
problem for things like git-buildpackage. If nothing else, there are
Colin Watson wrote:
I have a change to man-db that uses triggers to update the manual page
database automatically, fixing my second oldest remaining bug. I'd love
to upload this. While it doesn't break with a non-triggers-supporting
dpkg, I'd rather wait until triggers are merged in case their
@@ -0,0 +1,257 @@
+#!/usr/bin/perl
+#
+# git support for dpkg-source
+#
+# Copyright © 2007 Joey Hess [EMAIL PROTECTED].
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation
Russ Allbery wrote:
It's a little disturbing to have content in parentheses be significant in
a format based on RFC 822, although we have broken this rule elsewhere
(most notably in dependency fields, of course).
If it helps, the (git) comment is only used in debian/control, it's
not put in
Anthony Towns wrote:
Is a .gitdiff.tar.gz possible, so the archive doesn't need to have the
full git repo replaced by each upload? ie, something like
Files:
foo_1.0-1.git.tar.gz
foo_1.0-2.gitdiff.tar.gz
so that a small patch only adds a small file to the
Joey Hess wrote:
Maybe providing a feature on packages.debian.org (or similar) to download
sources in simple, non-VC, tarball format would make this a complete
non-issue though?
pristine-tar could be used for this, it would just need source packages
to put the delta somewhere standaised
Joey Hess wrote:
Bonus points: rather than debian/rules clean, create a diff, build,
have dpkg do debian/rules clean, commit any uncommitted changes with the
commit message being the changes from the changelog, create a .git.tgz,
build for git-source-format packages.
I have a feeling
Frank Lichtenheld wrote:
I think there is a mechanism in git to disallow replacing old pack
files (i.e. forcing to create additional ones with only new objects),
however, I haven't used that myself, yet.
The packs in the diff package would be basically the same packs that
git-send-pack
1 - 100 of 233 matches
Mail list logo
