Re: Triggers status?
On Wed, 31 Oct 2007, Guillem Jover wrote: > If this was about fixing only log entries, there's several ways to > accomplish that that imply zero conflict resolution while merging, > 'git commit --amend', 'git format-patch' and editing the resulting > mails, 'git cherry-pick -n', the more advanced 'git-filter-branch', > etc. In general mostly yes, but it's not really true in the case of Ian's dpkg.triggers dpkg.speedup branch, see the tries that I did in <[EMAIL PROTECTED]>. That's because Ian based his speedup branch on his triggers branch and made several changes to the same area of code in both branches. That is if you rewrite history, you loose the merge information and you'll get some conflicts on those area (but they are trivial to fix for the one who has written the code). (That said, if you rewrite history on the parent branch, you should also rewrite it in the child branch) My only suggestions for the future are: 1/ Avoid implementing new features on top of an unmerged branch (if possible) 2/ If it's required, make sure that the unmerged branch is clean and ready to be merged 3/ Don't fear conflicts, they're not the root of all evil and git makes it easy to resolve them (and git-rerere helps you there to avoid resolving multiple times the same conflict, in case you rewrite the history multiple times) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20471: patch to check rdepends on unpack
On Tue, 30 Oct 2007, Ian Jackson wrote: > Raphael Hertzog writes ("Re: Bug#20471: patch to check rdepends on unpack"): > > Please either attach a copy of the patch or use git.debian.org so that we > > can browse the changes via gitweb. > > I had some difficulty with git.debian.org when I tried it a few days > ago and I didn't have time then to deal with it. And I'm afraid I've > run out of time today too. Feel free to ask me for help if needed. Also this page might be of some help: http://wiki.debian.org/Alioth/Git Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Next upload 2007-11-04 (dpkg 1.14.8)
Hi, This is a pessimistic schedule (I've to do some catch up with other Debian stuff), if it's ready before that date and there's no one complaining it could be uploaded sooner. So I'd like to clean up the dpkg-architecture mess, I've the changes locally, they mostly need splitting and committing and a bit more testing. And I'd like to commit a patch I've had around for some time to start supporting udebs. Let's target at least the trigger changes for 1.14.9. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Mon, 2007-10-22 at 17:45:43 +0100, Ian Jackson wrote: > Oops, unfinished paragraph: > > Ian Jackson writes ("Re: Triggers status?"): > >Guillem: in a spirit of trying to have better cooperation, can I > >ask that you if you feel you need to review these changes in detail > >you do so reasonably promptly, and get back to me with your > comments. I promise to try to engage constructively with the > substance of any criticisms you have and to make any changes > that we agree. If we cannot agree I suggest that we seek > consensus here on this list. Sure! As I've said on another mail, let's finish the current release and then I'll get to it. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Thu, 2007-10-25 at 16:30:24 +0100, Ian Jackson wrote: > Raphael Hertzog writes ("Re: Triggers status?"): > > And it would be wise & fine to proceed that way if your history > > was clean and all. I was just showing you that loosing the history > > doesn't involve as much work as you expected to, but of course it's > > more work. > I don't know what you mean by `not as much as you expected'. > The results you demonstrated seemed entirely consistent with what I > expected and it is precisely that kind of merging makework that my > approach avoids. > > Doing extra merge work for the benefit of cosmetic redaction of commit > logs (which is IMO itself of doubtful value) seems an absurd tradeoff. > Merging substantial conflicting changes is one of the most demanding > and error-prone programming tasks. I'm astonished that you're > seriously advocating a workflow that prefers to have humans running > around fixing up mistakes made by computers. If this was about fixing only log entries, there's several ways to accomplish that that imply zero conflict resolution while merging, 'git commit --amend', 'git format-patch' and editing the resulting mails, 'git cherry-pick -n', the more advanced 'git-filter-branch', etc. > Guillem, do you have an opinion about the use of git I'd like to see the changes split in logical patches/commits, with proper log messages. It makes the review task easier, but more importantly it makes the history in the main repo clearer, for people to dig into if needed in the future, or in the present, via the debian-dpkg-cvs mailing list, which is how the other part of the peer review is done right now. The fact that those changes are in a branch is no excuse to treat them in a different way in which they would be treated if submitted as incremental patches. To git this distinction is not meaningful; push, pull, format-patch, etc, are just ways to transfer the changes. It might also be easier for you to not make new changes dependant on some of your existing branches, to avoid unneeded conflicts and also this way merging them into the main repo should be easier. I also get the impression that your current workflow and derived complaints stem from a lack of familiarity with git and its commands and possible workflows, which should allow you to do less manual work and not more! I think there's enough people here that can (and might be willing to) help with specific issues. > or (preferably!) about the actual code ? I've not yet properly reviewed it, just skimmed over the changes some weeks ago, and found some of the problems Raphael described. I'd like to finish the current release and then I'll focus on the triggers stuff. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it possible to make a deb package in non-debian system but only dpkg installed?
Inuk You wrote: So once I've installed dpkg and checkinstall in the system. Is it problem to try to make .deb in non-debian system? (but dpkg is installed) checkinstall assumes that you are on a debian system when building a deb package. Wether this is the root of your problem or not is another issue, but it will most probably fail. Thanks Felipe Do you know how to build deb package on non-debian system? or do you know whether there is how to do that or not? If not, can you recommend the good package management tool like APT for non-distro linux? CPU : ARM Distro : N/A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, 2007-10-24 at 22:35:23 +0100, Ian Jackson wrote: > Raphael Hertzog writes ("Re: Triggers status?"): > > * you replaced a bunch of "NULL" by "(char*)0". This reverts > > > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e > > I believe you should use NULL everywhere. (My personal taste also favors > > NULL over "(char*)0" but it's not even a question of what I prefer since > > I'm not an official dpkg maintainer) > > This isn't a matter of preference, I'm afraid. I reverted this > because the change was wrong. NULL is incorrect in that context (a > stdarg function expecting a char*), because it may be #define'd to 0. That's true, but then I agree with others [0] that an environment that defines NULL to 0 (even if the standard allows that) is not sane. Such ancient environment will also not be able to cope with modern software like gtk, anyway. regards, guillem [0] http://lwn.net/Articles/93577/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it possible to make a deb package in non-debian system but only dpkg installed?
Inuk You wrote: > So once I've installed dpkg and checkinstall in the system. > Is it problem to try to make .deb in non-debian system? (but dpkg is > installed) checkinstall assumes that you are on a debian system when building a deb package. Wether this is the root of your problem or not is another issue, but it will most probably fail. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20471: patch to check rdepends on unpack
Raphael Hertzog writes ("Re: Bug#20471: patch to check rdepends on unpack"): > Please either attach a copy of the patch or use git.debian.org so that we > can browse the changes via gitweb. I had some difficulty with git.debian.org when I tried it a few days ago and I didn't have time then to deal with it. And I'm afraid I've run out of time today too. I'll look into it again tomorrow. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is it possible to make a deb package in non-debian system but only dpkg installed?
Hi there, I'm on testing whether possible to make a deb package or not, in non-debian system (only dpkg installed). Also if possible, can I install (# dpkg -i package.deb) "the package I made in the system" (not general deb package) to the system? So once I've installed dpkg and checkinstall in the system. Is it problem to try to make .deb in non-debian system? (but dpkg is installed) CPU : ARM Distro : N/A Test package : sed dpkg is installed by source compiling. Following is the error from checkinstall. # checkinstall -D ... Installation successful == ... Copying files to the temporary directory...OK Striping ELF binaries and libraries...OK Compressing man pages...OK Building file list...OK Building Debian package.../usr/local/sbin/checkinstall: line 2460: 4864 Broken pipe dpkg-deb -b $BUILD_DIR "$DEBPKG" >&${TMP_DIR}/dpkgbuild.log FAILED! *** Failed to build the package Do you want to see the log file? [y]: /usr/local/sbin/checkinstall: line 2414: /usr/bin/sensible-pager: No such file or directory Erasing temporary files...OK Writing backup package...OK Deleting temp dir...OK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]