Re: problems with 3.0 format
On Mon, Mar 29 2010, Bernhard R. Link wrote: > * Peter Krefting [100328 18:25]: >> Unfortunately, such a workflow can't easily be translated back into a set >> of patches to apply on top of the current upstream. > > I think it is a worse problem than only the impossiblity to create the > patches. That is only a consequence of the version control system > missing information about what the changes are. > > Not having that information also means that when you want to look for > what was changed for some bugfix, one has to look at the whole history > and collect the initial change and all the adoptions to newer upstream > versions. The information about what is changed is burried in the > information when it was changed. It also means one cannot tell upstream > or some other project to just cherry-pick a specific commit to get the > fix. I am working on a script that given two tree-ish objects, forks off a temporary branch of the first tree-ish object, rebases it onto the second tree-ish object, Creates a patch series, and deletes the temporary branch. I am doing this partially for work (which uses a hacked together git-to-perforce kludge), and partially to feed feature branches upstream more easily, while preserving history. It would be nice f I can also detect and squash merge nodes from the temporary branch. With this script, I think that merge workflow would become more viable. manoj -- Drop the vase and it will become a Ming of the past. The Adventurer Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878w9bfbxg@anzu.internal.golden-gryphon.com
Re: about dpkg-buildflags
On Fri, Mar 19 2010, Raphael Hertzog wrote:
> Hi,
>
> let's have the discussion on the list please. Other people can have useful
> feedback on the design too.
>
> On Fri, 19 Mar 2010, Raphael Geissert wrote:
>> Yesterday I was writing a plan on how to implement what at the moment
>> I'm calling 'dpkg-buildflags' but was not sure how it was decided it
>> should pass the flags to debian/rules.
>>
>> I'm thinking about having a global (/etc/dpkg/buildflags{,.d}) config
>> and a local one (~/.dpkg-buildflags I guess). The script would take
>> those settings into consideration in addition to the env vars at the
>> time of its execution.
>
> There should be:
> - the default value provided by dpkg
> - which can be overriden/expanded system-wide with
> /etc/dpkg/buildflags (no .d, I don't think it's wise to let random
> packages modify the build flags for all packages built on the
> machine)
> - which can be overriden/expanded by the user with
> ~/.config/dpkg-buildflags (does it make sense to use XDG-compliant
> config filenames for the home directory?)
> - which can be overriden/expanded by the caller with envionment
> variables (DEB_CFLAGS_OVERRIDE / DEB_CFLAGS_APPEND ?)
>
> Must we support other operations besides replacing the value and
> appending more stuff to it?
Is there a way for the package maintainer to know what the
source of the value is? Somewhat like the origin function that Make
has?
manoj
--
Sigh. I like to think it's just the Linux people who want to be on the
"leading edge" so bad they walk right off the precipice. (Craig E. Groeschel)
Manoj Srivastava <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5nevmwm@anzu.internal.golden-gryphon.com
Re: Conffiles
On Mon, Jan 04 2010, Russ Allbery wrote: >> Umm, directories can't be conffiles, no? So not considering >> directories, if symlinks can be conffiles, and regular files can be >> conffiles, I think users should be allowed to change one conffile into >> another. And the code must then handle that case. > > Yes, I think that's right. That could probably be handled in a way > similar to the current handling of a deleted conffile. The tricky case is if a user replaces a symlink with a copy of the original target -- no content changes whatsoever. Should the user be prompted? I can see arguments either way, and certainly the potential exists for violating the principle of least surprise whichever take we have on that. manoj -- It's later than you think, the joint Russian-American space mission has already begun. Manoj Srivastava <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conffiles
On Sun, Jan 03 2010, Russ Allbery wrote: > Manoj Srivastava writes: >> On Sun, Jan 03 2010, Russ Allbery wrote: > >>> I don't believe that listing symlinks as conffiles works properly at >>> the moment. See #421344. It doesn't make any sense to list a >>> directory as a conffile. I think that exhausts all the non-regular >>> files that can be in a Debian package. > >> A conffile is, after all, a configuration file. As such, it >> contains configuration data, and user changes to such data is what >> policy is concerned about preserving. Merely the presence or absence of >> a inode or a link does not rise to the level of "configuration data", >> in my view. Why add restrictions on what people can do? > > I think a symlink created by the package in /etc should be handled like a > conffile in the sense that if the sysadmin changes the symlink to point to > a different path, that's a change that should be preserved. As I recall, > that's the scenario that prompted Bug#421344 originally. Currently, I > believe such changes are not preserved on package upgrade. > >> Now, if the target of the symlink is under /etc, then the target >> is really the configuration file, if the target does not lie under >> /etc, we have a policy violation. > > Symlinks in /etc pointing to files not in /etc are used now, so I'm not > sure they should be Policy violations. /etc/nologin is the canonical > example. Depending on how and whether Debian adopts upstart, we may have > other cases. Hmm. The part that bothers me about this is that I can't just say $EDITOR /etc/foo-that-is-a-symlink and expect it to work, unless the symlink points to a file on a fs that is not mounted RO. But I guess this is not a major obstacle. I don't like configuration data not all being under /etc; s that backing up /etc no longer saves a snapshot of my configuration. >>> Symlinks as conffiles should ideally work. I think it's just a bug in >>> dpkg that they don't. > >> While it could be made to work, I am not sure I agree that the >> result would require the same protection in policy. > >> I am willing to be persuaded otherwise on this. > > Well, I think all that Policy requires for configuration files that would > be relevant to symlinks is: > > * If the administrator removes it, it stays removed on package upgrade. > > * If the administrator changes it, which in the case of a symlink just > means pointing it to a different path, that change is either preserved > or prompted about. > Both of those seem feasible and reasonable to me. (Of course, someone > would need to do the work, and I don't think it's the highest-priority > dpkg development goal.) If this does not yet work, it does not really belong in policy yet -- we should let the implementation happen and the design settle down before standardizing the behaviour. > I'm not sure what the implications of changing the symlink to be a real > file or a directory would be. (I'm not sure what happens if an > administrator changes a regular conffile to a directory.) Umm, directories can't be conffiles, no? So not considering directories, if symlinks can be conffiles, and regular files can be conffiles, I think users should be allowed to change one conffile into another. And the code must then handle that case. manoj -- There are bugs and then there are bugs. And then there are bugs. Karl Lehenbauer Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conffiles
On Sun, Jan 03 2010, Russ Allbery wrote: > Felipe Sateler writes: > >> Do conffiles have to be regular files? Policy does not seem to be >> explicit about this (although I'd be happy to be proven wrong on this), >> it seems to just talk about "files". > > I don't believe that listing symlinks as conffiles works properly at the > moment. See #421344. It doesn't make any sense to list a directory as a > conffile. I think that exhausts all the non-regular files that can be in > a Debian package. A conffile is, after all, a configuration file. As such, it contains configuration data, and user changes to such data is what policy is concerned about preserving. Merely the presence or absence of a inode or a link does not rise to the level of "configuration data", in my view. Why add restrictions on what people can do? Now, if the target of the symlink is under /etc, then the target is really the configuration file, if the target does not lie under /etc, we have a policy violation. > Symlinks as conffiles should ideally work. I think it's just a bug in > dpkg that they don't. While it could be made to work, I am not sure I agree that the result would require the same protection in policy. I am willing to be persuaded otherwise on this. manoj -- "We all suffer from the preoccupation that there exists ... in the loved one, perfection." -Sidney Poitier Manoj Srivastava <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Informative addendum to policy clarifying dpkg/maintainer script interface
On Wed, Oct 21 2009, Frank Küster wrote: > Manoj Srivastava wrote: > >> Hi, >> >> I have created a document to clarify the interaction between >> maintainer scripts and dpkg, and examines the state changes for a >> package when a user interacts with the packaging system. > > Thank you, that looks very useful. What I'm missing, however, is any > reference to debconf's config script. Isn't that called by dpkg, too? Hmm. There are three different ways the config script is called, one is (for apt version 0.5 or above) via /etc/apt/apt.conf.d/70debconf -- this calls dpkg-preconfigure (8) to do to preconfigure the packages it is trying to install. That is beyond the scope of the document, since it is just an external program (apt) calling dpkg-preconfigure; and no package state change happens here -- this is just a debconf db update thing. The second way is when you initiate debconf/confmodule in your postinst, then debconf tries to call the config script again; this activity is thus part of what the postinst does, and not something this document covers (since we do not say anything about what maintainer scripts do or not do, just how they are called and what they return). Thirdly, if you call dpkg-reconfigure, the config script is run, but, again, this document is not documenting dpkg-reconfigure (or dpkg-preconfigure). As far asI can see, dpkg-preconfigure also doe snot cause a package state transition, it just runs the scripts (prerm. config, postinst). Could the dpkg folks chine in if I am wrong? manoj -- Bugs, pl. n.: Small living things that small living boys throw on small living girls. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Informative addendum to policy clarifying dpkg/maintainer script interface
Hi, I have created a document to clarify the interaction between maintainer scripts and dpkg, and examines the state changes for a package when a user interacts with the packaging system. The dynamic interactions between the packaging system and the package's maintainer scripts are described formally using UML diagrams. This document does not attempt to describe what the maintainer scripts can or can not do, concentrating instead mostly one the packaging system interface. It also provides a call graph of the maintainer scripts. This document is meant to be informative, not normative, at this point, and is presented here mostly since the maintainer scripts interaction section of policy is one of the more opaque segments. However, it also is trying to formally define the packaging system interface formally, and is meant to become normative at some point in the future, once it has buy in from the interested parties and has been checked for correctness. An early draft was sent over to the debian policy mailing list, but I thought the time has come to widen the audience a bit. Any feedback is appreciated. Please follow up to the policy list (debian-pol...@lists.debian.org mailing.) Especially welcome would be any feedback from the dpkg folk about correctness of the interactions depicted. Oh, and before I forget, this is where the document lives currently: http://people.debian.org/~srivasta/MaintainerScripts.html Thanks in advance, manoj -- Today is a good day to bribe a high-ranking public official. Manoj Srivastava <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18 2008, Goswin von Brederlow wrote: >>Russ Allbery <[EMAIL PROTECTED]> writes: > Setting the environment on a distribution wide level is ugly and > fragile. Too many users will reset the environment in their .bashrc. > > Instead the idea was to have a vendor (set in > /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if > unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. > > The bugreports relevant for this have 2 solutions: > > 1) make dpkg-buildpackage use (or tool with equivalent environment >setting up capabilities) mandatory > > 2) have debian/rules call something to set DEB_VENDOR and possibly >more > >E.g. 'include /usr/share/dpkg/Makefile.dpkg' >or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) > DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) > > The argument against 2 is that is requires every source to be modified > if they want to support vendors whereas 1 only needs some small > modification to dpkg-buildpackage to support calling arbitrary targets > in debian/rules and a change in policy making its use mandatory. But you need to modify the rules file anyway to take advantage of the DEB_VENDOR variable, no? Currently, setting it does nothing for any package. So if people are changing the rules file, they can also add in those two lines. >> My objection is specifically to having dpkg-buildpackage set a >> variety of environment variables *by default*, and then telling >> package maintainers that they should rely on those environment >> variables being set in the default case. That breaks the >> debian/rules interface and requires that all package builds go >> through dpkg-buildpackage. Having dpkg-buildpackage set environment >> variables in the non-default case like Emdebian is not a problem, >> since for Emdebian builds (for example) Emdebian can decide that >> using dpkg-buildpackage or setting the environment variables manually >> is required. There is no existing precedent, and they can make that >> rule from scratch. I tend to agree. > Then you have one interface for Debian and one interface for every > other vendor including ubuntu (or option 2 above). >> My concern is for the default build where there *is* an existing >> precedent that debian/rules build should work sanely, not for support >> for special cases like that where the existing debian/rules interface >> already doesn't do the right thing without additional help. >> If you are going to go down this path of having dpkg-buildpackage set >> up an environment that package maintainers should rely on, you or >> someone else on the dpkg team needs to make a debian-devel-announce >> post making it clear that debian/rules build is no longer a supported >> interface for building packages and using dpkg-buildpackage is >> required for consistent behavior. I see that as a serious degradation in the quality of the distribution. > Plus a note in policy clarifying that debian/rules is only an > interface for dpkg-buildpackage but not users. No. Debian is a member of the free software community, and being able to just do a configure, or a build, or build a single binary, by end users, is a feature that should not be given up easily. And certainly not without some significant rationale; degrating features for most of our users to cater to other distributions does not actually cut it. >> Right now, I don't think most Debian Developers have any idea what the >> implications of these changes are. > I have to say i verry rarely do not use debuild. And 99% of the > exceptions are calling debian/rules clean. I have never ever used debuild. So there is another anecdote, which may or may not mean anything. manoj -- "Nothing can stop him. Not even common sense." Mark Komarinski Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Mon, 22 Oct 2007 23:15:13 +1000, Anthony Towns <[EMAIL PROTECTED]> said:
> On Sun, Oct 21, 2007 at 11:30:08PM -0500, Manoj Srivastava wrote:
>> On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns wrote: This is
>> because the default is to deny by default -- and thus security policy
>> modules _add_ the permissions for special tasks that packages need to
>> do. Lacking security policy does not mean you have a security hole
>> --
> Oh, well in that case you only need it to happen before the postinst,
> not before the preinst. That's much closer to something triggers could
> do -- for instance, if you hacked libc6 to be interested in a file
> trigger for /, then anytime you installed an arch:any package, you'd
> have:
Unfortunately, that would mean a different hack for dpkg, or a
relabel; current dpkg has been patched to correctly set the file label
as things are unpacked. So, if the proper file contexts are not in
place before the unpack happens, installing the policy _after_ the fat
is not enough -- we need to correct the permissions, which is messier.
Also, while I am reasonably convinced the short period of time
between unpack and postinst with the wrong permissions does not open
security holes, this is based on an offhand analysis of the security
policy; not on any formal information flow analysis, so I would much
prefer _not_ to have this window with wrong security labels to exist in
the first place.
So, once I have some time, I'll be looking into doing an early
hook, rather than trying to coerce triggers to do the task.
Interesting suggestion, though.
manoj
--
It gets late early out there. Yogi Berra
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: Triggers status?
On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns <[EMAIL PROTECTED]> said: > I wonder if it'd be possible to setup an SELinux policy so that dpkg > is only able to unpack files that are already known about by SELinux > -- at least that way you'd get an error on unpack, with dpkg's usual > bail-out attempts, rather than a possible hole introduced into your > system. That would be nice (the error on unpack, that is) -- but is hard to do: not all packages have a specific policy (indeed, this is the only sane scenario: 10,000 policy modules for Debian would be untenable). Nice, but not required for security, really -- since the default is to install the files with no special security domain, and no domain transitions on execution; so lacking a security policy you get a bog-common initial security domain, with no special privileges. This is because the default is to deny by default -- and thus security policy modules _add_ the permissions for special tasks that packages need to do. Lacking security policy does not mean you have a security hole -- it means that the package you installed might not have the permissions to do anything useful, perhaps including running stuff in the postinst (remember, running as root/apt_t does not buy you as much in a SELinux machine as running with root on a non-selinux box does). I'm trying to increase functionality with the pre-install hook, security is not the driver here. manoj -- ... Had this been an actual emergency, we would have fled in terror, and you would not have been informed. 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 Mon, 15 Oct 2007 17:55:13 +0100, Ian Jackson <[EMAIL PROTECTED]> said:
> Manoj Srivastava writes ("Re: [PATCH] proposed v3 source format using
> .git.tar.gz"):
>> 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.
> Ideally the NMUer would simply upload and would not need to send a
> diff to the BTS.
> The maintainer would fetch the source from the archive and would be
> able commit the NMUers changes and then merge etc. appropriately.
This works better for the distributed VCS's with the model that
every checkout contains a copy of the whole repository. With a
distributed model where every checkout does not pull in a copy of the
repo, this means the NMU'er would have to have write access to the repo
(unlikely), or create their own public repo with tagged version of the
software, or send in a diff.
It is fine if this patch is only about VCS's that ship the repo
with every checkout/tag/branch; that fact just was not clear to me in
the beginning.
manoj
--
Let the meek inherit the earth -- they have it coming to them. James
Thurber
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: 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
<> 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 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]
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: [PATCH] proposed v3 source format using .git.tar.gz
On Tue, 9 Oct 2007 01:10:00 +1000, Anthony Towns <[EMAIL PROTECTED]> said:
> On Mon, Oct 08, 2007 at 09:16:52AM -0500, Manoj Srivastava wrote:
>> In any case, I think the kinds of actions taken by joey's and Colin's
>> patches are probably not things that we'll have to do to support
>> shipping an arh working directory in the source packagel if we have
>> {arch} and .arch-id dirs in the source, the end user has access to
>> the distributed version control system;
> Joey's thing lets you do a clean tarball that only contains the git
> (or bzr, or darcs) information, and recreates the working directory by
> a checkout.
Well, an additional factor is that git/bzr/darcs contains all
the data required in the .git/.bzr/.darcs directories to recreate all
the sources, and do the diffs, etc, which is not the case with arch --
rch does not follow the model where every checkout is a repo; so the
checked dirs do not have all the info (you refer to the repo for the
rest). Unless you use {arch}/++pristine trees, which I have not used
in years.
[Snip bunches of git/bzr/darcs material]
> What's the point of that?
> There may not be any -- if you're just packaging something that's
> completely straightforward, just adding a pointer to the official
> repository is probably the most sensible thing to do anyway; whether
> that be a subversion url or a tla grab file, or something else, and
> you can already do that.
Right. I am not sure what I package is always trivial, though.
> Where it starts becoming relevant (afaics) is when there's a
> Debian-specific patch history (either due to it being a native
> package, complicated packaging, or significant patches against
> upstream) and we want the archive, as the primary way we distribute
> the source, to include a real change history rather than a simple
> snapshot.
This seems to fit my use case; I have often large feature
branches that only sporadically get merged back upstream.
The question is, how do I do this if I use arch as a version
control system? I can, or course, start shipping a cacherev + patches,
but that can be large; and might not mean much unless I also ship all
the feature branches and upstream branch at the same time; which can
blow up badly: see the ps for details.
If we just look at lenny, and I want to provide people with full
details of all changes that have been made in various feature branches
and upstream and debian packaging for lenny (etcvh is somewhat larger),
I get:
--8<---cut here---start->8---
3.0Mfvwm--autotools--2.5.18/
368Kfvwm--autotools--2.5.21/
88K fvwm--autotools--2.5.23/
3.0Mfvwm--debian--2.5.18/
356Kfvwm--debian--2.5.21/
5.3Mfvwm--debian--2.5.23/
3.1Mfvwm--devo--2.5.18/
392Kfvwm--devo--2.5.21/
1.7Mfvwm--devo--2.5.23/
3.0Mfvwm--terminal-emulator--2.5.18/
360Kfvwm--terminal-emulator--2.5.21/
1.5Mfvwm--terminal-emulator--2.5.23/
2.9Mfvwm--upstream--2.5.18/
344Kfvwm--upstream--2.5.21/
1.5Mfvwm--upstream--2.5.23/
600Kdebian-dir--fvwm--0.1/
27M total
--8<---cut here---end--->8---
What I ship currently:
--8<---cut here---start->8---
132 /usr/local/src/arch/done/fvwm_2.5.23-2.diff.gz
8 /usr/local/src/arch/done/fvwm_2.5.23-2.dsc
3244 /usr/local/src/arch/done/fvwm_2.5.23.orig.tar.gz
3.3M total.
--8<---cut here---end--->8---
This is almost an order of magnitude increase in size, which I
find hard to justify.
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 )
>> I am not sure how the pritine-tar bit fits in into the picture yet.
> I don't think it really does; though it makes it possible to confirm
> that the point in the repo that claims to match some upstream release,
> really does match the official tarball of that release from upstream,
> which might have some use.
> pristine-tar seems mostly useful for generating a v1 source package
> purely from a remote repository; this allows you to turn a repository
> _into_ a (v3) source package.
Thanks for the clarification.
manoj
ps: This is from my lenny archive
1.8Mangband--autotools--3.0/
1.8Mangband--debian--3.0/
1.8Mangband--devo--3.0/
1000K angband-doc--devel--3.0/
1.7Mangband--upstream--3.0/
292Kc2man--configure--2.0/
292Kc2man--devo--2.0/
2
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Mon, 8 Oct 2007 12:59:52 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 10:59:18PM -0500, Manoj Srivastava wrote:
>> On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld
>> <[EMAIL PROTECTED]> said:
>> > Lets not exagerate. At least for git the repository will usually be
>> > smaller or only little larger than the working directory. It will
>> > probably compress worse though.
>> How is this magic done? If I have several dozen feature branches, all
>> feeding back and forth, and have made lots and lots of changes in my
>> sources, how does git preserve all this information without a
>> commensurate increase in size? This makes the information theory
>> geek in me very very skeptical.
> By already using compression in the repository and by aggressively
> storing data as delta against earlier versions (both for binary and
> textual data).
Well, arch does this in the repo: base versions and cacherevs
are tar.gz files, and then it stores deltas from the most recent base
version or cached revisions (I generally cache every 20th revision).
In any case, I think the kinds of actions taken by joey's and
Colin's patches are probably not things that we'll have to do to
support shipping an arh working directory in the source packagel if we
have {arch} and .arch-id dirs in the source, the end user has access
to the distributed version control system; as soon as they register the
archive location mentioned in the control file entry.
I am not sure how the pritine-tar bit fits in into the picture
yet.
manoj
--
Eighty percent of married men cheat in America. The rest cheat in
Europe. Jackie Mason
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 Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 06:24:15PM -0500, Manoj Srivastava wrote:
>> On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld
>> <[EMAIL PROTECTED]> said:
>> > bzr and git always ship the complete repository with each working
>> > directory. This is why they are called "distributed". Arch seems to
>> > be some weird thing in between truly central and truly distributed
>> > VCS.
>>
>> I am not sure I see this. Arch repositories are distributed, and you
>> can pull, branch, and tag off any repository out there in the
>> meta-verse. But every directory also has a semi permanent URI; and
>> checking out a branch locally does not end up with you downloading
>> the terabytes of stuff in the repo out there.
> Lets not exagerate. At least for git the repository will usually be
> smaller or only little larger than the working directory. It will
> probably compress worse though.
How is this magic done? If I have several dozen feature
branches, all feeding back and forth, and have made lots and lots of
changes in my sources, how does git preserve all this information
without a commensurate increase in size? This makes the information
theory geek in me very very skeptical.
Or are you talking about "typical" usage, and is that why people
go around making "shallow" copies to cut down on the size of the
shipped repo?
>> This might be because you can have more than one project in a repo;
>> my repo contains CVS emacs, unicode emacs, as well as most of the
>> SELinux packages, etc, and I mirror partially to arch.d.o. I would
>> hate to see all of emacs in the local dir of people who just want to
>> check out devotee.
>>
>> So arch does have a different mechanism of doing distributed
>> repositories; but the repositories are distributed in the sense that
>> I control one repo, but branches in my repo are children of other
>> repositories, and can be merged and tagged back and from,
> Out of interest, which of the following actions would need remote
> access?
> log view (including diffs between revisions)
The ./{arch} directory does contain logs. Diffs between
revisions requires access to the repository (or the local cache
library, if that contains the revision we want to diff with or from)
> annotation/blame view
Same thing; you need access to the repo since the code for the
other revisions is not in the checked out directory.
> creating a new commit/revision/tag
Committing it would require access to the repo.
> reverting a dirty working tree to a clean one
I think you are talking about reverting local changes to the
latest revision from the repository. Well, that needs acess to the
repo or a local cache.
> For git/bzr, the answer is usually "no" to all of these. If you have a
> "shallow copy" in git, the answers to the first two become "yes, since
> you will need it convert to a full copy first" .
For arch, the answer is yes to all these cases.
> [...]
>> Assuming we consider trying to support arch-like distributed version
>> control systems in the new dpkg; it might well be that the current
>> approach is too focussed on git/bzr type version control to work well
>> with arch.
> It most probably is.
As far as I can tell, most of the things being done for git are
not required if I ship a working directory for for arch ({arch} and
.arh-ids); and the only other thing required would be to also ship what
lives in the grab file in the control file; so people can know where to
register the archive location from to get access to the other
information.
If people wanted to provide changes, all that is needed is for
them to tag the developers branch, hack, and ask the developers to pull
from their branch (people have done that for ucf and devotee in the
past).
What exactly is the goal of this dpkg addition? With arch, I can
ship a full working copy; and as long as people have the repository
registered, they have full access to older revisions and feature
branches and all.
Would shipping the full working dir get by the requirement of
shipping the diff.gz? If so, we can support arch with no changes to
dpkg whatsoever.
manoj
--
You never hesitate to tackle the most difficult 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 Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said: > On Sun, Oct 07, 2007 at 02:16:12PM -0500, Manoj Srivastava wrote: >> On Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld >> <[EMAIL PROTECTED]> said: >> > On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote: >> > You probably mean source package here and not .deb. Also the >> > original proposal just means shipping the repository data, since >> > most DVCS can easily create a working directory from that. >> >> Hmm. The repository data, as far as I can tell, means the name of the >> archive, and the location. Do you really mean we are not shipping >> any, say, foo.c file in the sources, just a locatio where you can get >> the foo.c file from, at a particular version? > bzr and git always ship the complete repository with each working > directory. This is why they are called "distributed". Arch seems to be > some weird thing in between truly central and truly distributed VCS. I am not sure I see this. Arch repositories are distributed, and you can pull, branch, and tag off any repository out there in the meta-verse. But every directory also has a semi permanent URI; and checking pout a branch locally does not end up with you downloading the terabytes of stuff in the repo out there. This might be because you can have more than one project in a repo; my repo contains CVS emacs, unicode emacs, as well as most of the SELinux packages, etc, and I mirror partially to arch.d.o. I would hate to see all of emacs in the local dir of people who just want to check out devotee. So arch does have a different mechanism of doing distributed repositories; but the repositories are distributed in the sense that I control one repo, but branches in my repo are children of other repositories, and can be merged and tagged back and from, >> > The whole idea of the proposal is to NOT create an export. >> >> If we are not creating and export, and we are only shipping the >> repository data, how come there needs to be a check for uncommitted >> files? If the changes are uncommitted, that means the repo does not >> know about it; and if we only ship the repository data, we are not >> shipping stuff not in the repo. >> >> What am I missing? > They might be uncommitted because the maintainer forgot to commit > them. The only question is whether we should abort, commit the > changes, or ignore the changes. There is no technical problem with > either of these cases. Well, as a developer, I would rather that someone else running dpkg source on a package not try to commit to my repo, since it shall fail. Assuming we consider trying to support arch-like distributed version control systems in the new dpkg; it might well be that the current approach is too focussed on git/bzr type version control to work well with arch. manoj -- DEATH: The penultimate commercial transaction finalized by probate. Bernard Rosenberg 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
Hi,
On Sun, 7 Oct 2007 15:49:55 -0400, Clint Adams <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 02:19:36PM -0500, Manoj Srivastava wrote:
>>On Sun, 7 Oct 2007 12:24:46 -0400, Clint Adams <[EMAIL PROTECTED]> said:
>>> I presume you could ship all the "normal" files in one tarball, the
>>> .arch-ids and {arch} directories in another, and the debian/ directory
>>> in a third.
>> Err, and why am I doing this? Why am I not shipping my working
>> directory as a tarball, complete instead of breaking it up
>> (apparently arbitrarily) into three parts?
> As opposed to an .orig.tar.gz and all the debian/, {arch}/, and
> .arch-ids/ components in the .diff.gz ?
Umm, I was asking about why the normal and the arch-ids and
{arch} directories are being separated, and the ./debian dir as well.
The idea of the wig & pen was so that we no longer used diff as
an version control system, or were able to use more than one tar ball
for the source.
How is this working in this proposal? I do not ship the
orig.tar.gz file, but I ship and orig.arch.tar.gz file with the
upstream branch?
Then I mostly duplicate this by shipping a working dir, and each
also somehow ship an delta that recreates the orig.tar.gzx file from
the upstream branch I am shipping?
>> How is git reconstituting the files if there is no network access?
>> Are they shipping all the bits needed to get a full working dir
>> without any network access?
> Yes. the .git/ (or .bzr/ ) directory contains the entire (or abridged
> in the case of these shallow clones) history so you can "check out"
> any of the covered revisions.
A history as in RCS-like history, with parches, as opposed to
the patch-log that is what the {arch} directories contain?
> This would be akin to you including a cachedrev of an arbitrary
> version followed by all the subsequent patches.tar.gz files, except
> that I believe git et al. are meant to be more space-efficient.
wow.
gulp.
OK, so for arch I suppose I just ship a working dir, period, and
people need network access to get the older versions, unless people
want terabytes of the archive in every source versions.
manoj
--
Mind your own business, Mr. Spock. I'm sick of your halfbreed
interference.
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 Sun, 7 Oct 2007 12:14:39 -0400, Clint Adams <[EMAIL PROTECTED]> said: > On Sun, Oct 07, 2007 at 10:52:45AM -0500, Manoj Srivastava wrote: >> What does this mean in non-git context? > I think truncating the patch-log history is unimportant for Arch, but > any ++pristine-trees should definitely be nuked prior to packing. OK, that's fair. I use revision libs, so I never have pristine trees in my working dir anyway. manoj -- Linux is obsolete (Andrew Tanenbaum) 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 Sun, 7 Oct 2007 12:24:46 -0400, Clint Adams <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 11:10:41AM -0500, Manoj Srivastava wrote:
>> Hmm. If I have just the ./{arch} directory, and none of the files,
>> then arch thinks the files have just been deleted; and you can't just
>> check out stuff, since the tree is up to date. Ah. Baz undo restores
>> all the files, cool.
> I presume you could ship all the "normal" files in one tarball, the
> .arch-ids and {arch} directories in another, and the debian/ directory
> in a third.
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
> That would give the NMUer a full working tree to run $TLA diff in.
> Only shipping a grab file would burden the end user with a need for
> http access and no guarantee that the source will be available.
How is git reconstituting the files if there is no network
access? Are they shipping all the bits needed to get a full working
dir without any network access?
>> The problem here is that the repository in question _has_ to be
>> registered by the user running this; so all the users would have to
>> register the arch repository in question before unpacking the source
>> tarball in order to tell baz/tla how to get access to the repo. Is
>> this going to be an issue?
> It shouldn't be too difficult to add an --autoregister switch to tla
> grab, though I don't know how safe it'd be.
caveat emptor, I think, given that some repository access seems
to be required for unpacking a version 3 source package. This is not
something I would do in an un-constrained environment.
manoj
--
It is impossible to make anything foolproof, because fools are so
ingenious.
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 Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote:
>> OK, commenting on this with my "I use arch" hat on. If I understand
>> correctly, we are proposing shipping a working directory in the .deb;
>> and not shipping an orig.tar.gz nor a diff.gz file. I like
> You probably mean source package here and not .deb. Also the original
> proposal just means shipping the repository data, since most DVCS can
> easily create a working directory from that.
Hmm. The repository data, as far as I can tell, means the name
of the archive, and the location. Do you really mean we are not
shipping any, say, foo.c file in the sources, just a locatio where you
can get the foo.c file from, at a particular version?
> The whole idea of the proposal is to NOT create an export.
If we are not creating and export, and we are only shipping the
repository data, how come there needs to be a check for uncommitted
files? If the changes are uncommitted, that means the repo does not
know about it; and if we only ship the repository data, we are not
shipping stuff not in the repo.
What am I missing?
>> for each tree_root and nested; do run $TLA CHANGES map {
>> $list{${NESTED_PATH}/$_} => 1; } join ",", `$TLA inventory -s` done
>> For all files in exclude list, go and set values in %list to 0 (or
>> delete the key)
>>
>> ** I have no idea what the prune and shallow copy commands do, or the
>> arch equivalent **
> git gc --prune deletes old data that isn't needed anymore. This is
> needed since all other git commands never change or overwrite data
> (file data, this is obviously not true for meta data), they only add
> some.
I am unsure what this means in term of arch.
>> sub post_unpack_tar make sure we have an ./{arch} directory.Look for
>> nested submodules: $tree_root=$($TLA tree-root); @nested=`$TLA
>> inventory -t --nested "$tree_root"`;
>> ** arch hooks are per user, not per repo -- iirc **
>> ** what does git-config do? or bzr checkout? **
> git-config is just an cli interface to the .git/config file. Since we
> only ship the repository we need to create the working tree. This is
> what git/bzr checkout do.
Well, I do not see how this is done in arch. If you are not
shipping the working tree; all I can see shipping for arch is the URI
of the repo. I am pretty sure this is not what you mean, since then any
arch based source would be three lines or so, and would need network
access to unpack the source tree.
>> Actually, at this point I am beginning to question my understanding
>> of the proposal. If we are shipping a working tree, what is this
>> step doing?
>>
>> Is this an svn update equivalent?
> No, that would be git fetch/pull (and probably something similar named
> in bzr)
I don't think I know what this means when you are using arch.
manoj
--
Earn cash in your spare time -- blackmail your friends.
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 Sun, 7 Oct 2007 15:44:47 +, Colin Watson <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 10:05:32AM -0500, Manoj Srivastava wrote:
>> On Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess <[EMAIL PROTECTED]> said:
>> > I've been working on making dpkg-source support a new source
>> > package format based upon git. The idea is that a source package
>> > has only a .dsc and a .git.tar.gz, which is just a git repo.
>>
>> > My implementation adds a new 3.0 version source format. A 3.0
>> > format debian source package can consist of any files allowed by
>> > formats 1 and 2, but may also contain .$VCS.tar.gz files. To build
>> > a version 3 source package, a new field is needed in
>> > debian/control:
>>
>> I do not yet grok git, so could someoe tell me what this means in
>> terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when
>> the we are using CVS?
> I think this only really makes sense for distributed revision control
> systems. For arch, the .arch.tar.gz would contain the {arch}
> directory, perhaps with a few adjustments similar to those being made
> in the git and bzr modules.
Hmm. If I have just the ./{arch} directory, and none of the
files, then arch thinks the files have just been deleted; and you can't
just check out stuff, since the tree is up to date. Ah. Baz undo
restores all the files, cool.
The problem here is that the repository in question _has_ to be
registered by the user running this; so all the users would have to
register the arch repository in question before unpacking the source
tarball in order to tell baz/tla how to get access to the repo. Is this
going to be an issue?
I would prefer to instead ship a grab file for arch instead of
the {arch} directory, since the latter really buys us nothing over the
grab file (since we are requiring the distributed source dir and
network access to unpack source packages).
Consider this grab file:
--8<---cut here---start->8---
Archive-Name: [EMAIL PROTECTED]
Archive-Location: http://arch.debian.org/arch/private/srivasta
Target-Revision: packages--debian--1.0
Target-Directory: manoj-packages
Target-Config: configs/ucf/debian/ucf-3.003
--8<---cut here---end--->8---
tla register-archive --present-ok $values-of-Archive-Location-field
tla grab
cd $value-of-field-Target-Directory//*
(room for standardization here)
manoj
--8<---cut here---start->8---
__> baz status
* looking for [EMAIL PROTECTED]/ucf--devel--3.0--patch-1 to compare with
* comparing to [EMAIL PROTECTED]/ucf--devel--3.0--patch-1
D .arch-ids
D examples
D examples/.arch-ids
D t
D t/.arch-ids
D .arch-ids/COPYING.id
D .arch-ids/ChangeLog.id
D .arch-ids/Makefile.id
D .arch-ids/lcf.1.id
D .arch-ids/lcf.id
D .arch-ids/ucf.1.id
D .arch-ids/ucf.conf.5.id
D .arch-ids/ucf.conf.id
D .arch-ids/ucf.id
D .arch-ids/ucfq.1.id
D .arch-ids/ucfq.id
D .arch-ids/ucfr.1.id
D .arch-ids/ucfr.id
D COPYING
D ChangeLog
D Makefile
D examples/.arch-ids/=id
D examples/.arch-ids/ChangeLog.id
D examples/.arch-ids/postinst.id
D examples/.arch-ids/postrm.id
D examples/ChangeLog
D examples/postinst
D examples/postrm
D lcf
D lcf.1
D t/.arch-ids/=id
D ucf
D ucf.1
D ucf.conf
D ucf.conf.5
D ucfq
D ucfq.1
D ucfr
D ucfr.1
__> baz update
* tree is already up to date
--8<---cut here---end--->8---
--
"Time is money and money can't buy you love and I love your outfit"
T.H.U.N.D.E.R. #1
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: Triggers status?
On Sun, 7 Oct 2007 10:13:45 -0400, Joey Hess <[EMAIL PROTECTED]> said: > 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 implementation changes incompatibly, so I'm >> curious as to how long I might need to wait. > I have a fairly vast number of things that I want to use triggers for > in debhelper.. 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. manoj -- "Linux: the operating system with a CLUE... Command Line User Environment". (seen in a posting in comp.software.testing) 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 Sun, 7 Oct 2007 09:54:39 -0400, Joey Hess <[EMAIL PROTECTED]> said: > 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 somehow; (c) not worry about it as long as it's only in the >> history; (d) something else? >> >> Verifying that not just the current tree is DFSG-free, but all the >> history is too seems potentially difficult. > Yes, the faq discusses this problem. This is why shallow repos are > IMHO important and non-shallow repos should only be uploaded with > caution. What does this mean in non-git context? manoj -- Don't get even -- get odd! 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
Hi,
OK, commenting on this with my "I use arch" hat on. If I
understand correctly, we are proposing shipping a working directory in
the .deb; and not shipping an orig.tar.gz nor a diff.gz file. I like
the idea; and I think I can support nested arch packages (submodules in
.git speak), based on the examples I have seen of joey's patch and
Colin's for bzr -- I just need some more information about what exactly
some of these git commands do.
sub prep_tar:
make sure we have an ./{arch} directory.
Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested "$tree_root"`;
** Why are we checking for uncommitted files here? I would think that
people would have done an export to actually build packages **
for each tree_root and nested; do
run $TLA CHANGES
map { $list{${NESTED_PATH}/$_} => 1; } join ",", `$TLA inventory -s`
done
For all files in exclude list, go and set values in %list to 0 (or
delete the key)
** I have no idea what the prune and shallow copy commands do, or the
arch equivalent **
sub post_unpack_tar
make sure we have an ./{arch} directory.Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested "$tree_root"`;
** arch hooks are per user, not per repo -- iirc **
** what does git-config do? or bzr checkout? **
Actually, at this point I am beginning to question my
understanding of the proposal. If we are shipping a working tree, what
is this step doing?
Is this an svn update equivalent?
manoj
--
"If a computer can't directly address all the RAM you can use, it's just
a toy." anonymous comp.sys.amiga posting, non-sequitur
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 Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess <[EMAIL PROTECTED]> said: > I've been working on making dpkg-source support a new source package > format based upon git. The idea is that a source package has only a > .dsc and a .git.tar.gz, which is just a git repo. > My implementation adds a new 3.0 version source format. A 3.0 format > debian source package can consist of any files allowed by formats 1 > and 2, but may also contain .$VCS.tar.gz files. To build a version 3 > source package, a new field is needed in debian/control: I do not yet grok git, so could someoe tell me what this means in terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when the we are using CVS? manoj -- We don't like their sound. Groups of guitars are on the way out. Decca Recording Company, turning down the Beatles, 1962 Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#307139: dpkg: Please pull from srivasta@debian.org--2005-selinux/dpkg--selinux--1.13
Hi, On Tue, 17 May 2005 13:17:56 +0100, Scott James Remnant <[EMAIL PROTECTED]> said: > On Sun, 2005-05-01 at 00:26 -0500, Manoj Srivastava wrote: >> I have created a small (68 lines addition in lib/star.c) patch for >> SELinux support in dpkg. This is against the version pulled from >> [EMAIL PROTECTED]/dpkg--devel--1.13--patch-137. Adding in >> changes to configure, Makefile.am's for the binaries, ChangeLog, >> and ./debian/changelog, we have 188 lines of addtions, 7 deletions >> over 10 files (the bulk being 68 lines of code change and 30 lines >> of ChangeLog). >> > I'm not sure that perror() is appropriate, is it really just a > warning if the context set fails or should ohshite() be called to > abort the installation? This is a preference thing. If the context set fails, then the file shall be installed like any file that the sys admin unpacked using tar -- that is, in the sysadm_t domain. The package may or may not be usable, depending on the security policy. It should be easier for a human to fix the security context manually if the file existed on disk. My first instinct was to not bomb out on the very first version where Se-Linux support has been implemented -- we cna always add the abort call once we are relatively sure that things do not screw up. Technically, inability to set the security context is a symptom of something really wrong, and it would make sense to abort at this point before we move back into Sid. manoj -- You can never tell which way the train went by looking at the tracks. 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#307139: dpkg: Please pull from srivasta@debian.org--2005-selinux/dpkg--selinux--1.13
Package: dpkg Version: 1.13.5~ Severity: wishlist Tags: patch Hi, I have created a small (68 lines addition in lib/star.c) patch for SELinux support in dpkg. This is against the version pulled from [EMAIL PROTECTED]/dpkg--devel--1.13--patch-137. Adding in changes to configure, Makefile.am's for the binaries, ChangeLog, and ./debian/changelog, we have 188 lines of addtions, 7 deletions over 10 files (the bulk being 68 lines of code change and 30 lines of ChangeLog). There is no change in the generated binaries unless configure is called with the --enable-selinux option, and then no change in behaviour on a non-selinux system. You can browse the branch at: http://www.golden-gryphon.com/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]/dpkg--selinux?expand? I have tested the build on SELinux UMLs, and on non-selinux machines. Pre-build binaries are available from deb http://people.debian.org/~srivasta/ packages/ deb-src http://people.debian.org/~srivasta/ packages/source/ Thanks, manoj ,[ diffstat /tmp/selinux.patch ] | ChangeLog | 29 | configure.ac |7 + | debian/changelog |8 + | debian/control |2 - | debian/rules |1 | dpkg-deb/Makefile.am |2 - | dpkg-split/Makefile.am |2 - | dselect/Makefile.am|2 - | lib/star.c | 68 + | src/Makefile.am|4 +- | 10 files changed, 118 insertions(+), 7 deletions(-) ` --- orig/ChangeLog +++ mod/ChangeLog @@ -1,3 +1,32 @@ +2005-04-30 Manoj Srivastava <[EMAIL PROTECTED]> + + * lib/star.c Include if compiling with selinux + support + (ExtractFile): Add code (inside a #ifdef WITH_Se-Linux) to + test if Se-Linux is enabled, and, if so, to find out what the + security context of a file is, given its path. We only test for + SELinux being enabled once, and not for every file. If we can + determine what the security context of the file ought to be, we + try and set the security context. If not, let the default security + context for the process be applied. + (SetModes): ditto. + + * configure.ac: Add a --enable-selinux option, and have it set the + WITH_SELINUX cpp var, as well as set LIB_SELINUX. + + * debian/control (Build-Depends): Add libselinux1-dev as a build + dependency. + + * debian/rules: Add --enable-selinux to the configure command. + + * dpkg-deb/Makefile.am (dpkg_deb_LDADD): Add @LIB_SELINUX@ to the binary + link command for dpkg_deb + * dpkg-split/Makefile.am (dpkg_split_LDADD): ditto for dpkg-split + * dselect/Makefile.am (dselect_LDADD): ditto for dselect + * src/Makefile.am (dpkg_LDADD): ditto for dpkg + (dpkg_query_LDADD): ditto for dpkg_query + + 2005-04-03 Scott James Remnant <[EMAIL PROTECTED]> * scripts/dpkg-architecture.pl (gnu_to_debian): Check cputable --- orig/configure.ac +++ mod/configure.ac @@ -11,6 +11,13 @@ AM_INIT_AUTOMAKE([1.8 gnu]) +dnl Give the chance to enable SELINUX +AC_ARG_ENABLE(selinux, dnl +[ --enable-selinux Enable use of the SELINUX libraries], +[AC_DEFINE(WITH_SELINUX, 1, [Define if you want to use SELINUX]) +LIB_SELINUX="-lselinux" +AC_SUBST(LIB_SELINUX)]) + AM_GNU_GETTEXT_VERSION(0.14.1) AM_GNU_GETTEXT() --- orig/debian/changelog +++ mod/debian/changelog @@ -1,6 +1,12 @@ dpkg (1.13.5~) experimental; urgency=low - * + * Added SELinux awareness to dpkg. This includeas adding libselinux1-dev +to the build dependencies, and adding a --enable-selinux switch to +configure, and adding -lselinux to the link command for various +binaries (anything that uses libdpkg, actually). If the +--enable-selinux switch is not invoked in ./debian/rules, there is no +SELinux dependency, and there is no run time performance hit (all the +code in lib/star.c would be compiled out). -- Manoj -- --- orig/debian/control +++ mod/debian/control @@ -6,7 +6,7 @@ Origin: debian Bugs: debbugs://bugs.debian.org Standards-Version: 3.6.1.0 -Build-Depends: debhelper (>= 4.1.81), libncurses5-dev | libncurses-dev, zlib1g-dev (>= 1:1.1.3-19.1), libbz2-dev +Build-Depends: debhelper (>= 4.1.81), libncurses5-dev | libncurses-dev, zlib1g-dev (>= 1:1.1.3-19.1), libbz2-dev, libselinux1-dev Package: dpkg Architecture: any --- orig/debian/rules +++ mod/debian/rules @@ -45,6 +45,7 @@ --sysconfdir=/etc \ --localstatedir=/var/lib \ --with-zlib=static \ +--enable-selinux \ --with-bz2=static # Build the package in build-tree --- orig/dpkg-deb/Makefile.am +++ mod/dpkg-deb/Makefile.am @@ -16,4 +16,4 @@ info.c \ main.c -dpkg_deb_LDADD = $(LIBINTL) ../lib/libdpkg.a $(ZLIB_LIBS) $(BZ2_LIBS) +dpkg_deb_LDADD = $(LIBINTL) ../lib/libdpkg.a $(ZLIB_LIBS) $(BZ2_LIBS) @LIB_SEL
Re: SE Linux in Etch - was Release sarge now, or discuss etch issues?
On Wed, 20 Apr 2005 10:13:54 +1000, Russell Coker <[EMAIL PROTECTED]> said:
> On Tuesday 15 March 2005 09:32, Joey Hess <[EMAIL PROTECTED]> wrote:
>> The fact that the release team now sees the light at the end of the
>> tunnel for the release of sarge means that now is the time we need
>> to begin planning for etch. Allowing unstable development to pick
>> back up after a release with no clear plan for the next release has
>> been shown time and time again to delay the next release by one to
>> two *years*. The rest follows from that.
> Currently we plan to have libselinux in base for Etch. SE Linux
> code is in cron and logrotate which can be simply recompiled for
> full SE support. Fcron already is compiled with SE Linux support.
> The maintainer of sysvinit has agreed in concept to compile with SE
> support once libselinux is in base.
> We can basically make SE Linux usable by most people with a small
> amount of work once the above changes are made.
> I would like to see a general goal for Etch to have SE Linux as an
> option at install time.
In pursuance of that goal, I have made available a patched
branch of dpkg-devel which has support for SELinux. Please pull from
[EMAIL PROTECTED]/dpkg--selinux--1.13
(http://arch.debian.org/arch/private/srivasta/archive-2005-selinux)
This branch should have a small, very non-intrusive patch that
does not have a performance hit on a non-SELinux system. It does add
a dependency on libselinux1 for dpkg.
Please see
http://www.golden-gryphon.com/software/security/selinux.xhtml
for details.
You may browse the repository at
http://www.golden-gryphon.com/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]/?expand
If you want to try out this selinux aware dpkg, as well as
Greg T. Norris' selinux patched coreutils package, please point apt
at:
deb http://people.debian.org/~srivasta/ packages/
deb-src http://people.debian.org/~srivasta/ packages/source/
manoj
Repository links
dpkg--stable
The stable upstream DPKG branch, meant for Sarge.
dpkg--devel
The upstream development branch for dpkg. This is meant for Etch
-- and since Etch can promote libselinux1 to an essential
priority, this branch of dpkg could be linked against libselinux1.
dpkg--selinux-old
Russell Coker's modifications to dpkg, which introduce
{pre,post}{inst,rm}.d/ directories to label installed package
files correctly, using setfiles. Unfortunately, these changes were
deemed too far reaching, and really suboptimal, by dpkg authors,
since they were not comfortable introducing the general purpose
hook directories, which could lead to non-deterministic behaviour,
and could be open to all kinds of abuse.
dpkg--selinux
A new modification of dpkg, using SELinux library calls
(matchpathcon and {l,f}setfilecon) to set the security context of
component files just after unpacking. This approach may be more
acceptable, since it does not create a whole set of directories
that are open to potential abuse, and fits in with the chown/chmod
calls that dpkg already makes.
--
What is food to one, is to others bitter poison. Titus Lucretius Carus
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
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]
This is not a policy bug
reassign 254998 dpkg thanks The fact that dpkg does not follow what the policy recommends is by no means a policy bug. It also is not clear that section 9.4 applies to dpkg in the first place (dpkg is not an initscript). I understand the aesthetic motivation, but thefact that packages are sometimnes restarted during upgrades/installs and the dpkg output does not jell with initscript output does not imply that initscript output policy is somehow buggy. So this is an aesthetic wishlist against dpkg at best, so reassigning there. manoj -- If you tell the truth you don't have to remember anything. Mark Twain Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 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: dpkg branches
On Tue, 9 Nov 2004 17:55:23 -0600 (CST), Adam Heath <[EMAIL PROTECTED]> said: > On Wed, 3 Nov 2004, Scott James Remnant wrote: >> Yeah, but there are two thoughts on how to do this. The patch in >> the BTS at the moment adds a /etc/dpkg/postinst.d directory whose >> contents get run every time a package is installed. You drop an >> SELinux script in there to update contexcts. > This is so very wrong on so many levels. It does not consider any > fail states, nor transactions. Ie, what happens to the package > being installed when some hook fails? What happens if a new hook is > installed after several packages are installed? Before getting into lets-examine-the-bark-on-this-tree, I would like to step back and have a look at the forest: When a packages files are installed, there is already something in place to ensure that ownership and permissions are set correctly (implementation details are irrelevant, even if it is just tar doing the job). SELinux security contexts are another layer of file attributes, except that they are different from the unix ownership/permissions in that they are modified by local sysadmin policy. So, after tha package is unpacked, but before anything can use one of the files just deposited on the file system, something that is aware of local security policies must go in and paint the contexts on these files (there is a simple call that does this). Now, how this is implemented I'll leave to the dpkg domain experts -- but a per package script seems suboptimal. manoj -- "Stop annoying Mister President with impertinent questions, Junior." Death Race 2000 Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: dpkg branches
On Tue, 02 Nov 2004 10:53:40 +, Scott James Remnant <[EMAIL PROTECTED]> said: > On Mon, 2004-11-01 at 11:01 -0600, Manoj Srivastava wrote: >> Could you please post the registration info for the dpkg arch >> repository again? >> > Sure: http://people.ubuntu.com/~scott/arch/personal/ is the mirror > with the highest bandwidth at the moment. > http://people.ubuntu.com/~scott/arch/Arch-For-Dpkg is worth a quick > read for conventions and stuff that I use. >> I would like to create branches tagged off the official tree for >> SELinux changes, which would make it easier to maintain the dpkg-se >> package, as well as to feed back the changes in the future if the >> SELinux stuff becomes more palatable for dpkg maintainers. >> > Yup, no problem. Which set of changes were you planning on making? > The support for the "run this after every postinst" directory or the > support for actually changing SELinux gubbins inside dpkg itself on > installation? I was actually merely looking to import the changes that Russell Coker has made to dpkg source to enable setting file contexts on install, Even if these changes are not acceptable upstream, every new upstream version would merely mean a tla replay How often do you sync with upstream? manoj -- "Pok pok pok, P'kok!" Superchicken Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: dpkg branches
Hi, Could you please post the registration info for the dpkg arch repository again? I would like to create branches tagged off the official tree for SELinux changes, which would make it easier to maintain the dpkg-se package, as well as to feed back the changes in the future if the SELinux stuff becomes more palatable for dpkg maintainers. manoj -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#213038: kernel-package: segfault if destination partition is full
reassign 213038 dpkg thanks Hi, On Sat, 27 Sep 2003 23:04:34 +0200, Gunter Ohrner <[EMAIL PROTECTED]> said: > A make-kpkg generated kernel-image*.deb causes a segfault during > installation if the destination partition ran out of space. I'm > using a rather small /boot partition which filled up with test > kernels today, and suddenly I got SIGSEGvs after > Unpacking replacement kernel-image- ... The package itseldf is not repsonsible for unpacking, it all is done by the package management suite. Reassigning as needed. manoj -- Never ask the barber if you need a haircut. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#132901: dpkg: There is no man page for dpkg.cfg
Package: dpkg Version: 1.9.19 Severity: normal Hi, There is no man page documenting /etc/dpkg/dpkg.cfg (reading the file itself intimates that all command line options are permitted, but the file may not be present on all systems, or modified to remove the comment). manoj -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux glaurung 2.4.17 #1 Fri Dec 21 21:06:24 CST 2001 i586 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages dpkg depends on: ii libc62.2.5-3 GNU C Library: Shared libraries an ii libncurses5 5.2.20020112a-3 Shared libraries for terminal hand ii libstdc++2.10-glibc2.2 1:2.95.4-2 The GNU stdc++ library
Re: RFD: translated description with dpkg
Hi, [BTW, is this still relevant on [EMAIL PROTECTED] >>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: Steve> My point, which people seem to keep ignoring, is that I Steve> *personally* have no way of judging the quality of a Steve> translation. Therefore, I cannot take responsibility for Steve> including random translation submissions into my package. Most people packaging complex pieces of software can not, personally, take responsibility for that in the first place. You hitnk the kernel image maintainers know and are responsible for every nuance of every drivber packaged? Hell, I package make, and I have no idea how the rules processor works. Even significant time spent into device drivers is unlikely to allow me to correct them; The same is true for the intricate internals of gnus. We already package things that we ourselces can't completely fix. or even know if they are totally screwed up or not. (I do not use nnimap, and I can't tell whether it is screwed up wither -- how long do you want to wait until I package a enw release?) What We are indeed responsible for is that when informed of the problem, we go and ask people in the know. We ask upstream, we go to upstream mailing lists, we ask other developers, any one in the community -- and we work together with the people who know and the people who report problems to resolve the issue. Translations are like that. W4e have upstream translators -- and, wonder of wonders, these upstream translators are likely to be developers. We have infrastructure to help a developer correct the translation when informed the translation is sub optimal. >> >> These are my packages. I am responsible. Mine! Mine! all >> Mine! is a bad way to think of your relationship to your packages. Steve> Maybe I communicate badly, but that is not at all what I said. Would Steve> you include arbitrary MIPS assembly code patches into your Steve> packages? There is arbitrary assembly code in all kernels. I can see my way to maintaining a kernel image package, yes. Steve> And in fact, I have a better chance of correctly decoding arbitrary Steve> assembly code than, say, Mandarin. Or Greek. I'm happy to accept and Steve> consider patches to my packages. But if I just incorporated them with Steve> checking, you, Manoj, would be first in line to criticize me. And you'd Steve> be completely justified. Rubbish. I know developers are not god. I expect you, when told it is wrong, to find a mandarin speaking developer (and we should make this easier) and request a correction. Pretending we are really supermen who know all that is to be known about our packages, and that we are ultimately responsible for every aspect of out packages, and that we never, ever, need help correcting parts of out package, smacks of pride. manoj -- Certainly there are things in life that money can't buy, But it's very funny -- did you ever try buying them without money? Ogden Nash Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: RFD: translated description with dpkg
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: Steve> I, as a developer, am responsible for what is in my Steve> packages. How can I be responsible for things I can't read? I Steve> mean, I suppose I could work my way through one of the Western Steve> Europeans. But Polish? Or Korean? Hah! I maintain kernel-package. I have no idea what it takes to maintain kernel image packages for i386, much less for other archs. But I also have people who do, and who help me put together a working kernel-package package. Linus himself admits he just works with 5% of kernel code; he has delegated trust and responsibility. We have this thing called a community. And we cooperate. We help each other in areas we have strengths in, and together, we produce results that are more than the efforts of the individuals alone could have done. These are my packages. I am responsible. Mine! Mine! all Mine! is a bad way to think of your relationship to your packages. manoj can't we all just pretend we are in this together? -- A CODE OF ETHICAL BEHAVIOR FOR PATIENTS: DO NOT COMPLAIN IF THE TREATMENT FAILS TO BRING RELIEF. You must believe that your doctor has achieved a deep insight into the true nature of your illness, which transcends any mere permanent disability you may have experienced. NEVER ASK YOUR DOCTOR TO EXPLAIN WHAT HE IS DOING OR WHY HE IS DOING IT. It is presumptuous to assume that such profound matters could be explained in terms that you would understand. SUBMIT TO NOVEL EXPERIMANTAL TREATMENT READILY. Though the surgery may not benefit you directly, the resulting research paper will surely be of widespread interest. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: RFD: translated description with dpkg
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: Steve> I doubt very many people go around browsing random .debs with Steve> 'dpkg-deb -I'. You gotta be kidding. == __> less /home/srivasta/bin/lessopen #!/bin/bash # Decode directories: if [ -d "$1" ]; then echo "$1:"; ls -als $1 else case "$1" in [SNIPPAGE] *.deb) echo "$1:"; if [ -x /usr/bin/dpkg ]; then dpkg --info $1; echo -e '\n*** Contents:'; dpkg-deb --contents $1 else echo -e '\n*** Control:'; ar -p $1 control.tar.gz | tar zvvft - echo -e '\n*** Contents:'; ar -p $1 data.tar.gz | tar zvvft - fi ;; == manoj who peeks into debs all the time -- progasm: the feeling you get when your code works the first time uunet!sugar!karl (hm) Keeping 255 messages and deleting 158. [EMAIL PROTECTED] (wk) re Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [ANNOUNCE] experiemental dpkg available
Hi, >>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: Jason> Only if you are connecting through a straw or are not using a CD. Around Jason> here the time to download is <<< time to install even with gzip! Then consider mst of the world as connecting through a straw. Brodband is accesible only in a few cities in north america (I have no such options, for example), and few people not in north america have these options, I would imagine. The most common case is not universities, offices, or people with ADSL/cable modems. manoj now in atlanta airport -- You have the power to influence all with whom you come in contact. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C fingerprint = 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#43773: dpkg: purge and remove options make a pause, then parse arguments
Hi, >>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> I agree with the rest of this, but making a short, easy option Ben> to purge a package is bad. If you accidentally -r a package, it Ben> can be easily fixed with a reinstall and all configuration files Ben> will be kept. If you accidentally --purge, then you could have Ben> some problems. Force people to know exactly what they are doing Ben> in this extreme instance. This does not seem to follow the rest of the UNIX philosophy. By the same token, rm, fsck, restore, dd, et all should be horrendously hard to use. Protecting users from themselves, not making things convenient because they are too dangerous leads one to Windows. I am not convinced that this is the right path. manoj -- If anger is not restrained, it is frequently more hurtful to us, than the injury that provokes it. -- Seneca Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#31521: dpkg: dpkg dying in eterm
Hi, >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes: Richard> Manoj Srivastava wrote: >> Please tell me how one disable sigpipe specifically for a >> child process, and I shall do my best to convince the authors not to >> do the same. Richard> You fork, and then change the sigpipe setting before you exec. Quite. But is this the case here? If it is, then it is indeed *also* an eterm bug, and I should even advocate raising the priority. I suspect, however, that eterm does not really gratuitously go around ignoring sigals like that. Wihch brings me to my original point: unless eterm is doing what you said above, it is not an eterm bug. manoj -- Aberdeen was so small that when the family with the car went on vacation, the gas station and drive-in theatre had to close. Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#31521: dpkg: dpkg dying in eterm
Hi, >>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes: Jules> The parent *may* have had a valid reason to reset something. In this Jules> particular example, the parent had no reason to disable sigpipe in its Jules> children, and doing so will cause any program which relies on sigpipe to Jules> malfunction. So this seems like a bug, to me.. Please tell me how one disable sigpipe specifically for a child process, and I shall do my best to convince the authors not to do the same. The program may well have reason to ignore sigpipe itself, hmmm? The child should set up handlers for thuings that cause it to break when not ignored. Yes, it is a bug. In the child program manoj -- "Computer literacy is a contact with the activity of computing deep enough to make the computational equivalent of reading and writing fluent and enjoyable. As in all the arts, a romance with the material must be well under way. If we value the lifelong learning of arts and letters as a springboard for personal and societal growth, should any less effort be spent to make computing a part of our lives?" Alan Kay, "Computer Software", Scientific American, September 1984 Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#31521: dpkg: dpkg dying in eterm
>>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes: Jules> On 1 Mar 1999, Manoj Srivastava wrote: Jules> So every single program should start with a long set of Jules> signal(___,SIG_DFL)? Long set? Fortunately for us programmer types, someone invented a construct called the loop. #include int i = 0; for (i=1;i<=32;i++) signal (i, SIG_DFL); See? Then ignore what you want to. But this should not be required, anyway, for most signals. Jules> And reset all environment variables to some useful default? If you crash and burn depending on the status of these variables, hell, yes. Have a reasonable default, and test within your code. Jules> The way I see this, is that the parent process *may* have Jules> reset the signals for some bona fide reason (debuggers play Jules> this kind of trickery, I believe). True enough. When a program is _exec_ed the status of all signals is either default or ignore. Normally, all signals are set to their default action, *unless the process that calls _exec_ is ignoring the signal*". However, if setting some signal handlers to SIG_IGN makes you crash; test and reset that handler. Jules> However, the gnome-* packages have *no* valid reason to reset Jules> SIGPIPE for child processes. So it's a bug if they do. "Set SIG_PIPE for child processes"? That's a strange way of looking at it. No, noone sets signals for child processes. One sets handlers for oneself. However, there are numerous other properties of the parent that are inherited by the child -- signal masks and dispositions are affected, for one thing. Jules> If I destroy PATH and IFS, I can expect subprocesses to break. Jules> I don't file bugs against them for not checking.. (unless Jules> they're suid root, of course :) A system level program, very critical to the machine, should not be coded so amateurishly. I fully expect critical code to have a decent set of defaults, especially once a flag is raised about problems. The flag is so raised for dpkg now. manoj -- "And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions." David Jones @ Megatest Corporation Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#31521: dpkg: dpkg dying in eterm
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Klaus Weide writes ("Bug#31521: dpkg: dpkg dying in eterm"):
>> Ian Jackson wrote:
>> > I know what is causing dpkg to misbehave and it's this
>> > SIGPIPE problem. That's not dpkg's fault.
>>
>> Pardon me, but it seems to me that if dpkg needs SIGPIPE non-ignored
>> to function properly, then it is up to dpkg to make it so. Which
>> should be very simple to do. Or is there ever a reason to honor a
>> parent process's SIG_IGN for SIGPIPE?
Ian> There might be. The main point is that a program is entitled to
Ian> assume that all signal handlers start in the default state.
Really? Where do we get that from? The tenets of defensive
programming seem to dictate that is your code crashes and burns
depending on some state of a signal handler, you should take care of
it.
>> Is there something that support the claim that it is a bug if program A
>> fork/execs program B with SIGPIPE ignored? For example some Unix specs,
>> or a Debian policy doc?
Ian> How about ANSI C ?
What about ANSI C? Is this a fishing expedition?
The standard does not even know about fork. And says nothing
about what programs can expect wrt signal handling in parent
processes.
manoj
--
The first half of our lives is ruined by our parents and the second
half by our children. Clarence Darrow
Manoj Srivastava <[EMAIL PROTECTED]><http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#28177: dpkg --print-architecture requires gcc
Hi, >>"Barak" == Barak Pearlmutter <[EMAIL PROTECTED]> writes: Barak> The emacs20 package (version 20.3-1) fails to configure, as it gets an Barak> error from "dpkg --print-architecture", which fails because it in turn Barak> calls "gcc --print-libgcc-file-name" but there is no gcc. Please file a bug against emacs. It should be using dpkg --print-installation-architecture which does not require gCC Barak> Perhaps dpkg, should its invocation of gcc fail, could resort to a Barak> lesser means of figuring out the architecture. It already does. dpkg --print-architecture print target architecture (uses GCC) dpkg --print-gnu-build-architecture print GNU version of target arch dpkg --print-installation-architecture print host architecture (for inst'n) This report should be reassigned to emacs20. manoj -- It's amazing how much "mature wisdom" resembles being too tired. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#27128: Request for dpkg -D4 semantics
Hi,
>>"Colin" == Colin Plumb <[EMAIL PROTECTED]> writes:
Colin> Given the trouble people have with {pre,pos}{inst,rm} scripts,
Colin> it would be *very* handy to be able to watch those scripts
Colin> getting executed. I'd like to be able to pass -x to the shell
Colin> that executes them, or some similar debugging measure.
Pass -x to my perl script and you shall be very surprised. A
better ieda is to choose either a commandline option, or an
environement variable that should be heeded (DPKG_TRACE or something)
manoj
--
Gee, Toto, I don't think we're in Kansas anymore.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#15590: kernel-package: kernel-package does not work on my system
Hi, There is a problem with this report. Looking at the bug in question, you can see it has been reassigned to dpkg-dev. __ Debian bug report logs - #15590 kernel-package: kernel-package does not work on my system Package: dpkg-dev; Reported by: <[EMAIL PROTECTED]>; dated Wed, 3 Dec 1997 09:18:01 GMT; Maintainer for dpkg-dev is Klee Dienes and Ian Jackson <[EMAIL PROTECTED]>. _ Bug reassigned from package `kernel-package' to `dpkg-dev'. Request was from Manoj Srivastava <[EMAIL PROTECTED]> to [EMAIL PROTECTED] Full text available. _ __ This should be looked into. manoj -- The boy stood on the burning deck, Eating peanuts by the peck. His father called him, but he could not go, For he loved those peanuts so. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: dpkg non-non maintainer release
Hi, >>"Martin" == Martin Schulze <[EMAIL PROTECTED]> writes: Martin> PS: As a sidenote I tried apt, it forced me to do vi Martin> /var/lib/dpkg/status three times where dselect/dpkg didn't Martin> force me. I think that is because dselect/dpkg are unaware of broken systems, and because apt is stricter, it probably means that there is less chance of mysterious failures on your machine than under the more lax policy followed so far. This is a good thing (tm) manoj -- THE THREE LAWS OF ROBOTICS 1 - A robot may not injure a human being, or, through inaction, allow a human being to come to harm. 2 - A robot must obey the orders given it by human beings except where such orders would conflict with the First Law. 3 - A robot must protect its own existence as long as such protection does not conflict with the First or Second Law. Isaac Asimov Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Hooks mechanism
Hi, >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> I propose to have _one_ hook script for each package triggered Ian> by the hooks mechanism, which will be invoked for all hooks. Ian> This will make it obvious that it has to be idempotent. Ok. Ian> It will be much simpler if we don't have to record why the Ian> script is being run (ie, what triggered the hook) - then we can Ian> have the package have a new Status value meaning `need to run Ian> the hooks for this package'. Hmm. This last bit maybe problematic. See below. Ian> * Package hooks. The control file contains: Ian> Hook-Packages: Ian> If any status change happens to any package listed or a provider of Ian> such a package, then the package whose control file this appears in Ian> has its hook triggered. `Status change' includes such a package being Ian> installed, removed, or upgraded, unless all the versions of the Ian> package(s) involved fail to satisfy the dependency. Let us take an example. IF package A is installed, package B needs to provide a hook for package A. The package may break if the hook is present and pkg A is not; and if the hook is not present but pkg A is. If the hook script is just called, with no indication what happened; then the hook scripts needs have an easy way to determine the state of package A. At the moment, there is no easy (supported) method. You are already thinking pf providing the "pathnames of the new or changed file(s)" to the in the File-in-directory hook scripts; this should be an easy extention. (Of course, you may generate the new/changed file list on the fly for the script, but that is getting kludgy). Ian> * File/directory hooks. The control archive contains a file Ian> `filehooks' with a list of absolute pathnames. If dpkg installs, Ian> upgrades or removes a package which contains a file or directory whose Ian> name is listed in this file then the package with the filehook script Ian> has its hook triggered. Is there any limit to the number of hooks that a package may register? If not, then providing the name of the altered file/dir could help the hook script a bit (I do not feel strongly about this). Ian> * File-in-directory hooks. The `filehooks' file contains a line of Ian> the form: \t Ian> In this case, after new or changed file(s) have been installed in the Ian> directory (or one of its subdirectories), the will Ian> be run with the pathnames of the new or changed file(s) _before_ dpkg Ian> leaves the installation/upgrade stage. If the Ian> fails then dpkg's error message will say which package declared the Ian> check, but then back out of the install or upgrade of the package with Ian> the new or changed (hopefully faulty) file. This is in addition to Ian> the usual function of the filehooks file. manoj -- "Based on what you know about him in history books, what do you think Abraham Lincoln would be doing if he were alive today? Writing his memoirs of the Civil War. Advising the President. Desperately clawing at the inside of his coffin." David Letterman Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#26024: dpkg-dev: [patch] files to ignore diffs of...
>>"Karl" == Karl M Hegbloom <[EMAIL PROTECTED]> writes:
Manoj> I think that dpkg should not unilaterally ignore any
Manoj> files. And this problem is already solved, by using
Manoj> something like cvs-buildpackage. I think that any
Manoj> interactions with version control systems etc should be
Manoj> layered modularily on top of dpkg; and not integrated with
Manoj> it.
Karl> What if I make it an option switch then, off by default, then a
Karl> switch to turn it on with a default regex, or with a given regex?
Karl> Give the word and I'll have a patch for you in a few hours.
I like this idea much better. It would be wonderful if you can
do that. Please.
Karl> The thing is, `cvs-buildpackage' works from a repository where I can
Karl> check in the debian/* files and make tags at will. It won't work
Karl> where I'm tracking upstream sources via anon CVS.
You have a point.
manoj
--
FACILITY REJECTED 10004420;
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#26024: dpkg-dev: [patch] files to ignore diffs of...
I think that dpkg should not unilaterally ignore any files. And this problem is already solved, by using something like cvs-buildpackage. I think that any interactions with version control systems etc should be layered modularily on top of dpkg; and not integrated with it. manoj -- Aim for the moon. If you miss, you may hit a star. Clement Stone Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Processed: Re: Bug#24207: kernel-source 2.0.34 doesn't depend on gcc
reassign 24207 kernel-package retitle 24207 kernel-source 2.0.34 should use dpkg --print-installation-architecture thanks Hi, Sorry for the bogus redirect. As James pointed out, tis is really a bug in kernel-package, there is no need not to use --print-installation-architecture in the postinst. I shall fix this in the next upload to kernel-package. manoj -- UNOBTRUSIVE MEASURES: Experimental techniques of unclear origin having something to do with work tiles. Observing madam in her bath without bringing forth screams. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
