[SCM] dpkg's main repository branch, master, updated. 1.14.8_newshlib-26-gd72e531
The branch, master has been updated via d72e5312894dddf9ab6112408555819a7e2ab2e9 (commit) via 853dc7860121b8a97efc0e1756597fb9b648bbf4 (commit) via d82b1c13dd756294c62bd05d2c37eef45bf94360 (commit) via 20fbbf435e754cb14a84e1d49edda96f4112f0d0 (commit) from 2b6c769da754d9c6d98a1fe2aecf566116122a0b (commit) - Shortlog d72e531 dpkg-source.1: Some random housekeeping. 853dc78 dpkg-source: Update description of -W and -E d82b1c1 ChangeLog police 20fbbf4 dpkg-source: Some cleanup on the -Z feature Summary of changes: ChangeLog| 11 --- man/ChangeLog| 11 ++- man/dpkg-buildpackage.1 |8 man/dpkg-source.1| 31 --- scripts/dpkg-buildpackage.pl |4 ++-- scripts/dpkg-source.pl | 27 --- 6 files changed, 56 insertions(+), 36 deletions(-) --- Details of changes: commit d72e5312894dddf9ab6112408555819a7e2ab2e9 Author: Frank Lichtenheld [EMAIL PROTECTED] Date: Wed Oct 10 00:08:03 2007 +0200 dpkg-source.1: Some random housekeeping. Fix some syntax inconsistencies. Also if a broken sentence. Partly suggested by Helge Kreutzmann. diff --git a/man/dpkg-source.1 b/man/dpkg-source.1 index 5ae6c96..6eae108 100644 --- a/man/dpkg-source.1 +++ b/man/dpkg-source.1 @@ -124,12 +124,11 @@ files. Supported values are: .BR \-i [\fIregexp\fP] You may specify a perl regular expression to match files you want filtered out of the list of files for the diff. (This list is -generated by a find command.) \fB\-i\fR by itself enables the option, +generated by a find command.) \fB\-i\fP by itself enables the option, with a default that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. There can only be one active regexp, of multiple -\-i options only the last one will take effect. - +\fB\-i\fP options only the last one will take effect. This is very helpful in cutting out extraneous files that get included in the diff, e.g. if you maintain your source in a revision control @@ -150,7 +149,7 @@ example, \-ICVS will make tar skip over CVS directories when generating a .tar.gz file. The option may be repeated multiple times to list multiple patterns to exclude. -\fB\-I\fR by itself adds default \-\-exclude options that will +\fB\-I\fP by itself adds default \-\-exclude options that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. @@ -204,7 +203,7 @@ but will remove that directory after it has been used. .TP .B \-ss Specifies that the original source is available both as a directory -and as a tarfile. If will use the directory to create the diff, but +and as a tarfile. dpkg-source will use the directory to create the diff, but the tarfile to create the .BR .dsc . This option must be used with care - if the directory and tarfile do commit 853dc7860121b8a97efc0e1756597fb9b648bbf4 Author: Frank Lichtenheld [EMAIL PROTECTED] Date: Tue Oct 9 23:59:39 2007 +0200 dpkg-source: Update description of -W and -E -W is the default for quite some time already. Adapt the description of -W and -E. Also update the description of this options in dpkg-buildpackage. diff --git a/ChangeLog b/ChangeLog index 82ad100..5cadbaf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -5,6 +5,11 @@ 2007-10-09 Frank Lichtenheld [EMAIL PROTECTED] + * scripts/dpkg-source.pl (usage): -W is the default + for quite some time already. Adapt the description of + -W and -E. + * scripts/dpkg-buildpackage.pl (usage): likewise. + * scripts/dpkg-buildpackage.pl: Add -z/-Z to passthrough opts (will be passed to dpkg-source). diff --git a/man/ChangeLog b/man/ChangeLog index f876f15..d92fed2 100644 --- a/man/ChangeLog +++ b/man/ChangeLog @@ -1,5 +1,10 @@ 2007-10-09 Frank Lichtenheld [EMAIL PROTECTED] + * dpkg-source.1: -W is the default for quite + some time already. Adapt the description of + -W and -E. + * dpkg-buildpackage.1: likewise. + * dpkg-source.1: Change the rest of the man page to not contain any hardcoded .gz references. diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1 index d53a52e..5041457 100644 --- a/man/dpkg-buildpackage.1 +++ b/man/dpkg-buildpackage.1 @@ -85,15 +85,15 @@ Check build dependencies and conflicts; abort if unsatisfied. .B \-d Do not check build dependencies and conflicts. .TP -.B \-W -Turn certain errors into warnings. Only \fBdpkg\-source\fP uses this, but +.B \-E +Turn certain warnings into errors. Only \fBdpkg\-source\fP uses this, but .BR
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Tue, 9 Oct 2007 14:17:17 +1000, Anthony Towns [EMAIL PROTECTED] said:
So that leaves:
I still think that shipping a full working dir, with no dpkg changes,
seem to be the way to go, along with a tla grab file, which I think I
should consider putting into the package itself (If I can work around
the chicken and egg issue of adding a grab file changes the source
revision which means the grab file should change which means a new
revision is needed )
If you're just distributing a snapshot, rather than a full repository
as Joey's basically proposing, why can't your grab file be
autogenerated? ie,
1. hack on the source, merge changes, blahblah, finish, tag
2. do a checkout from version control
3. autogenerate anything necessary
4. create source package
5. build
6. upload
If you're using pristine-tar to create a pristine .orig.tgz from your
repo (rather than keeping one around), that needs to be autogenerated
at step 3 too, afaics. Worst case you could check the autogenerated
files into a parallel repository and use a config or something,
afaics.
I can (and do) autogenerate the grab file -- and I guess I can
add it to the source package after I check things out of the version
control. I guess I was quibbling over having stuff in the source
package that was not in my version control and not generated by dpkg
and friends -- but even I can see it is a pretty weak quibble.
Anyway, thanks for the clarifications: I'll just re-start
shipping a full working sir in the source tree, along with a grab file
for registration; the overhead is pretty minimal compared to that of
the full repo that git ships; and if people can deal with .git dirs,
they can deal with {arch} and .arch-id dirs as well.
Which concludes my involvement in this thread.
manoj
--
He flung himself on his horse and rode madly off in all directions.
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: [RFC] dpkg-buildpackage development goal
On Mon, Oct 08, 2007 at 09:34:14PM -0300, Otavio Salvador wrote:
On the other hand one could argue that dpkg-buildpackage should
intentionally remain simple and that people are expected to write
their own wrappers or replacements if they need.
What do you think?
I personally think it ought to be kept simple since is very easy to
write other more feature-rich wrappers around it.
It needs to support all basic features of dpkg but no more then that.
In principle I agree with that.
However as a matter of fact nowadays is not that easy to switch from one
dpkg-buildpackage wrapper to the another, due to the variety of needed
configurations, different invocation APIs and such and such (here I'm
thinking at the ones I've used so far in my DD experience:
dpkg-buildpackage itself, debuild, pbuilder, cowbuilder,
{svn,bzr,git,...}-buildpackage.
*If* (I'm not sure it will) integrating some of their features directly
in dpkg-buildpackage can ease the switching from one to the other I
would say: go and implement them in dpkg-buildpackage.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
signature.asc
Description: Digital signature
For dpkg translators: new git instructions
Hello dear translators, we have updated the instructions on the Git usage that we expect you to do: see http://wiki.debian.org/Teams/Dpkg/GitUsage The short summary is: 1/ Don't use git pull but use instead git fetch git rebase origin/master (this is to avoid seeing many merge commits which do not add any value, see below for an example) 2/ Don't multiply local commits uselessly. If you have several commits to push please use git rebase -i origin/master to merge them in a single one. This command displays a list of pending commits of you, each on a single line starting with pick. Keep the pick on the first line but replace all other occurences of pick by squash. Save and exit the editor. Enter a new log message for the single commit that will replace the previous serie of commits. The wiki page has a more concrete example of usage. Basically we have seen a few push like this: bb55e03 Update Polish translations. 3dc3d8e Merge branch 'master' of ssh://git.debian.org/git/dpkg/dpkg ea5926f Merge branch 'master' of ssh://git.debian.org/git/dpkg/dpkg 84556e3 Update to 322t69f71u 4e85e21 Update to 1165t23f110u 229afa4 Initial Polish translation of scripts - 100t185f177u 9386ce0 Updated to 1125t32f141u be0f3cb Merge branch 'master' of ssh://git.debian.org/git/dpkg/dpkg 3513003 Updated to 1098t27f160u bac2e4e Update Polish translation to 1071t24f190u (I took Robert as example, but others are doing the same. I don't blame anyone, you couldn't know... but now we'll try to improve the situation a bit) Please understand that this is not useful historical information and as such we'd like to avoid seeing it. We want a single Update Polish translations instead of 10 similar commits. Thanks for your help and if you have questions, feel free to ask. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
On Tue, Oct 09, 2007 at 02:13:41AM +0200, Frank Lichtenheld wrote: On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. I like this thought. On the other hand, something like integrating dpkg-sig(s) functionality might be a good thing to do. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
On Tue, 09 Oct 2007, Frank Lichtenheld wrote: Obviously one could attempt to merge in new features especially from debuild which reimplements dpkg-buildpackage but with many fancy additions. (While e.g. pbuilder and sbuild wrap dpkg-buildpackage but do not replace it) On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. I think this needs to be evaluated on a feature-by-feature basis. Some features should be handled in a standardized ways while some corner-case features are better left to external wrappers. It depends on how much creativity a given feature requires... when there's only one right way to do it, it should be in dpkg-buildpackage, otherwise it can be easily left out. Like Julian, I think package signatures ought to be handled at this level because only one implementation is really needed IMO. Also now that you offered a command line option (-j) for DEB_BUILD_OPTIONS=parallel=n, I think it would make sense to offer similar options for other common options like debug,nostrip (#154468). #4655 (checking versions in changelogs, if we do it) would also be a waste if it was reimplemented in various wrappers. BTW, with the BTS using the historical changelog information for its version tracking, it probably makes sense to do it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Mon, Oct 08, 2007 at 09:34:14PM -0300, Otavio Salvador wrote:
On the other hand one could argue that dpkg-buildpackage should
intentionally remain simple and that people are expected to write
their own wrappers or replacements if they need.
What do you think?
I personally think it ought to be kept simple since is very easy to
write other more feature-rich wrappers around it.
It needs to support all basic features of dpkg but no more then that.
In principle I agree with that.
However as a matter of fact nowadays is not that easy to switch from one
dpkg-buildpackage wrapper to the another, due to the variety of needed
configurations, different invocation APIs and such and such (here I'm
thinking at the ones I've used so far in my DD experience:
dpkg-buildpackage itself, debuild, pbuilder, cowbuilder,
{svn,bzr,git,...}-buildpackage.
*If* (I'm not sure it will) integrating some of their features directly
in dpkg-buildpackage can ease the switching from one to the other I
would say: go and implement them in dpkg-buildpackage.
Personally I think it's a different problem.
A week ago I was talking to Arnaud (squashfs Debian maintainer, on Cc)
and we were talking about this problem and we think the best way to
avoid this problem is to have a common place for configuration so all
those wrappers avoid duplicated settings.
It would be better to offer a way to set and get settings in a common
way and then make all those tools to use it. This would make the
switch much easier.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
Microsoft sells you Windows ... Linux gives
you the whole house.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
Frank Lichtenheld writes ([PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format): 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. I haven't double-checked but I suspect it's pretty much the same text as I wrote all those years ago. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. Originally what is now the policy manual was two documents (both of which I wrote): * dpkg Programmers' Manual * Debian Policy Manual The former described the behaviour of dpkg, from a package maintainer's point of view, and documented the restrictions and requirements which are inherent in dpkg's behaviour. The latter described other decisions made by Debian which weren't direct consequences of the behaviour of dpkg. I wasn't there when it was decided to merge these, so I can't say for sure what the reasons were. Obviously before reversing this decision again it would be sensible to understand the reasons behind it, and to consider whether we agree with them and whether they still apply. Two obvious reasons I can think of are that it may have been felt confusing to maintainers to have to consult two documents, and that there may have been a desire to put the dpkg Programmers Manual into some kind of formal change process or at least to take it out of the hands of what were at the time the rather chaotic hands of the various dpkg maintainers. Personally I think merging this documents was a mistake and they should be separated again. However, others may disagree. Times have changed quite a bit. When these manuals were separate dpkg was the principal complex piece of code which handled packages. Now the higher-level tools like apt, archive management software, package tracking systems, etc. etc., all have reliance on the package format - so changing it isn't as simple as changing dpkg. On the other hand, the we need it in one place argument is less strong now, because nowadays we have a plethora of documents which a maintainer is expected to keep abreast of. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Firstly I'd just like to say that I think this is a fantastic direction to be heading in. I look forward very much to the demise of dpatch :-). I do however very much share Colin's view about the desirability of preserving the .orig.tar.gz's, the ability to unpack a Debian source package with non-Debian tools, and the ability to unpack a source package without needing to install a suitably recent one of fourteen possible revision control systems :-). On Sun, Oct 07, 2007 at 10:18:17PM +1000, Anthony Towns wrote: (I have a strong adverse reaction to duplicated information, so shipping the working tree in .git format and .orig.tar.gz format irks me, particularly if it's required) Like Colin, I can quite understand this point of view. I'd like to make a completely crazy suggestion. 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 ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using .git.tar.gz): What exactly is the goal of this dpkg addition? This is a sensible question to ask. Goals I would suggest: * Enable all people who work with a Debian source package to do so with the benefits of the distributed revision control system in use, which includes smart merging, and so forth; * Specifically, to enable the above for NMUers in such a way that a minimum of additional work is needed by the maintainer to merge changes. * Abolish dpatch (and similar excresences) and specifically to get back to the point where a Debian source package can be unpacked to the point of seeing the source code without having to execute any of it. * Make life easier for derived distributions by making it possible for them to merge from us, and us from them, using all of the usual features of the RCSs in use. * Make it possible (once more) for NMUers to make a change to a package without having to learn and interact with a revision control system, even if the maintainers are using one. Ie, make it possible to acquire the source, inspect it, edit it, build it, test it, and upload it, using only tools which either do not depend on the RCS or which entirely hide it, without disrupting or being disrupted by the revision control system. * When an RCS-agnostic NMUer has done their work, still give the benefit of the RCS to the maintainer (and others) when merging the NMUer's work. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Colin Watson writes (Triggers status?): 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 implementation changes incompatibly, so I'm curious as to how long I might need to wait. The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. I think you should just upload your man-db change to Debian. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. This is (a) a bad idea as previously discussed and (b) not at all like what is now called a trigger so please call it something different. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Next upload 2007-09-30 (dpkg 1.14.7)
Guillem Jover writes (Re: Next upload 2007-09-30 (dpkg 1.14.7)): About starting the dpkg-cross merge, after some conversations with Neil and reading some of the dpkg-cross code, I think I've got a pretty good idea but needs done, but I've some reservations about the paths used, I'll post a separate mail later. I've deferred it until next version, sorry Neil... I haven't checked - does the dpkg-cross stuff involve any changes to the dpkg C code or is it all in dpkg-source et al ? If it makes changes to the C then I think I should review it. Is there a git branch I can look at ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Frank Lichtenheld writes ([RFC] dpkg-buildpackage development goal): Since I haved hacked quite a bit on dpkg-buildpackage in the last one or two weeks I wanted to gather some comments on what people think should be the goal of dpkg-buildpackage development. I think I have an answer to this question. The interface provided by a Debian source package is that specified for debian/rules. This interface needs to be kept stable in the sense that feeding new packages to old tools, and old packages to new tools, needs to keep working. It also needs to be kept simple for packages, since we must conform to this interface in all of our packages. It used to be the case that very few programs needed to interact in any at all complicated way with source packages. But this is becoming less true, and the interfaces keep getting more feature-rich. At the moment if we want to introduce some new feature for packages to provide then either we need backward-compatibility code in every relevant package, or we need backward-compatibility code in every program which uses packages. I think dpkg-buildpackage should take up the role of being the single place where this impedance matching is done. That is, the interface for packages should be made such that it is as straightforward as possible to make a correct package, and packages' callers should rely on dpkg-buildpackage to communicate their requirements appropriately to the underlying packages with fallback if necessary. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Otavio == Otavio Salvador [EMAIL PROTECTED] writes: Hello, Otavio A week ago I was talking to Arnaud (squashfs Debian Otavio maintainer, on Cc) and we were talking about this problem Otavio and we think the best way to avoid this problem is to have a Otavio common place for configuration so all those wrappers avoid Otavio duplicated settings. Otavio It would be better to offer a way to set and get settings in Otavio a common way and then make all those tools to use it. This Otavio would make the switch much easier. I think we should have one configuration file (~/.rcs-buildpackage.conf maybe?) and if needed another configuration files for specific RCS options. The latter would override the former settings. Choosing this approach means that we should have common options, I haven't had the time yet to check whether the different *-buildpackage tools share the same options. But I think it shouldn't be so complicated to patch the different tools for using the configuration file mentioned above. What do you think? Regards, Arnaud Fontaine pgpqi92Ur1PiK.pgp Description: PGP signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
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 being efficiently binary deltaed, so, you'll still end up with approximatly 2x doubled data. This is probably true of many revision control backends, though not all .. you might be able to do it with CVS. It might be possible to start with the pristine source, check it into git, and apply a set of git packs that merges the resulting repository forward to match the maintainer's git repository. However, I think this could only work if the maintainer's git repository began with importing that same pristine source[1]. Which means throwing away your git repo for each new upstream version and starting afresh, which doesn't seem very practical. -- see shy jo [1] git's sha1sums are AIUI based on the entire history of the repo, so you can't go back and change history signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
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 project I've seen a good idea be indefinitely delayed or killed when everyone piles on and nitpicks it to death. This idea is in danger of that happening. If the dpkg maintainers decide to add support to this format to dpkg, I'll be happy to work with them to make any further fixes needed to my patch. (My git repo has a couple more fixes in it BTW.) -- see shy jo signature.asc Description: Digital signature
Re: Triggers status?
On Tue, 9 Oct 2007 19:02:38 +0100, Ian Jackson [EMAIL PROTECTED] said: Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. This is (a) a bad idea as previously discussed Well, no. You think it is a bad idea; I do not think that makes it so. and (b) not at all like what is now called a trigger so please call it something different. Well, when one or more packages are going to be installed a not trigger but something that walks like a trigger, sounds like a trigger goes off, and calls a utility function with the names of the packages going to be installed (so, goes off in the pre-install phase), and this utility function ensure that the security policy is in place before the packages get unpacked. I don't care what this is called; as long as it gets invoked. I'll be happy to call it a pre-install hook. manoj -- Every solution breeds new problems. 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: [PATCH] proposed v3 source format using .git.tar.gz
On Tue, 9 Oct 2007 16:42:38 -0400, Joey Hess [EMAIL PROTECTED] said: 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 project I've seen a good idea be indefinitely delayed or killed when everyone piles on and nitpicks it to death. This idea is in danger of that happening. I do apologize if my quest for understanding your proposal sounded like nitpicking; that ws not my intent. I truly did not understand what I needed to do while using arch (and it turns out no changes are really required in dpkg for arch). manoj feeling obtuse -- Suicide is the sincerest form of self-criticism. Donald Kaul 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: [PATCH] proposed v3 source format using .git.tar.gz
On Tue, 9 Oct 2007 18:58:19 +0100, Ian Jackson
[EMAIL PROTECTED] said:
I am going to comment on this with my I use arch hat on.
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
What exactly is the goal of this dpkg addition?
This is a sensible question to ask. Goals I would suggest:
Thanks for clarifying.
* Enable all people who work with a Debian source package to do so
with the benefits of the distributed revision control system in use,
which includes smart merging, and so forth;
This, of course, means you have to have the distributed SCM
system installed and configured, and perhaps a bit of configuration
work done.
Shipping an arch working dir, with {arch} and .arch-ids; allows
people to see the log history, and, after they have registered the
repository this was checked from, to do diffs and so on. Commits won't
be possible unless they have commit access to the distributed repo; but
they can tag/branch to their local repo, and ask the developer to pull
from there.
This requires no dpkg change.
* Specifically, to enable the above for NMUers in such a way that a
minimum of additional work is needed by the maintainer to merge
changes.
Sure. Tag the checked out tree to a repo you have commit rights
to, ask developers to pull from there.
* Abolish dpatch (and similar excresences) and specifically to get
back to the point where a Debian source package can be unpacked to
the point of seeing the source code without having to execute any of
it.
All for it.
* Make life easier for derived distributions by making it possible for
them to merge from us, and us from them, using all of the usual
features of the RCSs in use.
ok
* Make it possible (once more) for NMUers to make a change to a
package without having to learn and interact with a revision control
system, even if the maintainers are using one. Ie, make it possible
to acquire the source, inspect it, edit it, build it, test it, and
upload it, using only tools which either do not depend on the RCS or
which entirely hide it, without disrupting or being disrupted by the
revision control system.
Hmm, OK. Well, as long as people ignore the extra directories,
shipping an arch checked out dir will allow people to work with plain
old make, etc, with no changes to dpkg.
* When an RCS-agnostic NMUer has done their work, still give the
benefit of the RCS to the maintainer (and others) when merging the
NMUer's work.
Well, this is tricky. I am not sure how the NMU'er communicates
with the developer; I assume it is by sending in a diff. If so, this
works with an arch checked out dir, and unmodified dpkg.
So, in conclusion, I can happily say that no change in dpkg is
needed to help arch using developers accomplish these goals; they
need just stop stripping out the {arch} and .arch-id directories to
accomplish all these.
Silencing Lintian would be a good start.
manoj
--
If I am elected, the concrete barriers around the WHITE HOUSE will be
replaced by tasteful foam replicas of ANN MARGARET!
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]
Bug#134758: Most popular medical goods.
Good afternoon. bro! Do you want to be a king of bed? You will forget about all ED problems. at the present day we want to offer you huge choice of medicines at the extremely low costs. Hurry up! http://bryogis.searchhappen.com/?266094038224 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#188235: catch .. 523
Want to meet with young girl or boy? Want to have sex with teens ? We will help you ! mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#89697: All ED difficultieshave already solved!
Hi. bro! Do you want to be a king of bed? You will forget about all ED problems. at the present day we want to offer you huge choice of medical products at the extremely low costs. Hurry up! http://aocyzfl.representbasic.net/?537949129115 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445852: dpkg-buildpackage: fails with perl errors
All'incirca Mon, 8 Oct 2007 22:16:21 +0200, Frank Lichtenheld [EMAIL PROTECTED] sembrerebbe aver scritto: These don't look like perl errors, but like shell errors. Somehow the perl script gets executed as shell script. Do you have dpkg-cross installed? Hmm, but why does it happens? I have dpkg-cross installed, but I can't see what does this mean. Sorry, I'm not very expert with Perl! Giovanni. -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) signature.asc Description: PGP signature
Bug#445858: dpkg: Minor errors in man pages
Hello Frank, On Mon, Oct 08, 2007 at 10:28:05PM +0200, Frank Lichtenheld wrote: On Mon, Oct 08, 2007 at 06:43:57PM +0200, Helge Kreutzmann wrote: Here I am unsure, please verify: -shlibs.local, B/etc/dpkg/shlibs.override, the Bshlibs control area file +shlibs.local, B/etc/dpkg/shlibs.override, the Bshlibs area in the controle file shlibs control file is correct I think The word I had really problems with is area. For me area implies some space which is separated. shlibs control file area is still unclear to me. Could area may be dropped? -tarfile. If will use the directory to create the diff, but the tarfile to +tarfile. It will use the directory to create the diff, but the tarfile to It is more correct. Just writing dpkg-source is probably better. Yes, I also would prefer to spell it out, I just made the minimal patch necessary to get a sensible sentence. Once I'll see the changes applied, I'll update the German man pages accordingly (which probably will require few changes only). Greetings Helge -- Dr. Helge Kreutzmann [EMAIL PROTECTED] Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#373003: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
Frank Lichtenheld writes ([PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format): 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. I haven't double-checked but I suspect it's pretty much the same text as I wrote all those years ago. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. Originally what is now the policy manual was two documents (both of which I wrote): * dpkg Programmers' Manual * Debian Policy Manual The former described the behaviour of dpkg, from a package maintainer's point of view, and documented the restrictions and requirements which are inherent in dpkg's behaviour. The latter described other decisions made by Debian which weren't direct consequences of the behaviour of dpkg. I wasn't there when it was decided to merge these, so I can't say for sure what the reasons were. Obviously before reversing this decision again it would be sensible to understand the reasons behind it, and to consider whether we agree with them and whether they still apply. Two obvious reasons I can think of are that it may have been felt confusing to maintainers to have to consult two documents, and that there may have been a desire to put the dpkg Programmers Manual into some kind of formal change process or at least to take it out of the hands of what were at the time the rather chaotic hands of the various dpkg maintainers. Personally I think merging this documents was a mistake and they should be separated again. However, others may disagree. Times have changed quite a bit. When these manuals were separate dpkg was the principal complex piece of code which handled packages. Now the higher-level tools like apt, archive management software, package tracking systems, etc. etc., all have reliance on the package format - so changing it isn't as simple as changing dpkg. On the other hand, the we need it in one place argument is less strong now, because nowadays we have a plethora of documents which a maintainer is expected to keep abreast of. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445852: dpkg-buildpackage: fails with perl errors
On Tue, 09 Oct 2007, Giovanni Mascellani wrote: All'incirca Mon, 8 Oct 2007 22:16:21 +0200, Frank Lichtenheld [EMAIL PROTECTED] sembrerebbe aver scritto: These don't look like perl errors, but like shell errors. Somehow the perl script gets executed as shell script. Do you have dpkg-cross installed? Hmm, but why does it happens? I have dpkg-cross installed, but I can't see what does this mean. Sorry, I'm not very expert with Perl! It means that dpkg-cross diverted /usr/bin/dpkg-buildpackage and installed its own copy of that file. That copy reuses the original dpkg-buildpackage by sourcing it, and thus making the assumption that's it's written in shell. That assumption has been broken by the latest upload. So this is really a dpkg-cross bug. See http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/54-dpkg-cross-2.0.0-fragility-expected!.html Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#32595: Mlcro5oft + Ado6e t|tles as L0W as 1O$
S*ftware as |ow as 1O$. V1s1t. cheapxpsoft. com . for m0re deta1|s.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108587: Mlcro5oft + Ado6e t|tles as L0W as 1O$
S*ftware as |ow as 1O$. V1s1t. cheapxpsoft. com . for m0re deta1|s.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: this assignment is broken
Processing commands for [EMAIL PROTECTED]: # this bug doesn't have anything to do with ri-li, but with dpkg reassign 445753 dpkg Bug#445753: ri-li-data: On installing changes uid Bug reassigned from package `ri-li-data' to `dpkg'. forcemerge 343578 445753 Bug#343578: dpkg: delete available-new when 'No space left on device' Bug#445753: ri-li-data: On installing changes uid Forcibly Merged 343578 445753. severity 445753 normal Bug#445753: ri-li-data: On installing changes uid Bug#343578: dpkg: delete available-new when 'No space left on device' Severity set to `normal' from `normal' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Processed: this assignment is broken
Processing commands for [EMAIL PROTECTED]: retitle 445753 dpkg: On installing changes uid Bug#445753: ri-li-data: On installing changes uid Changed Bug title to `dpkg: On installing changes uid' from `ri-li-data: On installing changes uid'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#60639: Mlcro5oft + Ado6e t|tles as L0W as 1O$
S*ftware as |ow as 1O$. V1s1t. cheapxpsoft. com . for m0re deta1|s.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445858: dpkg: Minor errors in man pages
On Tue, Oct 09, 2007 at 06:24:48PM +0200, Helge Kreutzmann wrote: On Mon, Oct 08, 2007 at 10:28:05PM +0200, Frank Lichtenheld wrote: On Mon, Oct 08, 2007 at 06:43:57PM +0200, Helge Kreutzmann wrote: Here I am unsure, please verify: -shlibs.local, B/etc/dpkg/shlibs.override, the Bshlibs control area file +shlibs.local, B/etc/dpkg/shlibs.override, the Bshlibs area in the controle file shlibs control file is correct I think The word I had really problems with is area. For me area implies some space which is separated. shlibs control file area is still unclear to me. Could area may be dropped? That was what I meant. Sorry if that was unclear. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
