[pacman-dev] [GIT] pacman branch, master now at v3.0.0-410-g7325ebb
Hello,
This is an automated email from the git hooks/update script, it was
generated because a ref change was pushed to the repository.
Updating branch, master,
via 7325ebbc22091c698fd19140b7ed6986024ec6e8 (commit)
via d34b2c4ed84bc40f4a895846785481fad88116a2 (commit)
via d50390c089c23ca20c23febc45ea8b9cc24e70f0 (commit)
via 82a1129539ee6c1a87ffbe816a0c8c42f3469177 (commit)
via afdcf7552cc7afc26ff2f793f3c50e4b9172c1b6 (commit)
via acfdad6db3ac6c934d8f1885b37520680a610bec (commit)
via 3955858a2d75592ff3f7e2636b39841fc7269174 (commit)
via 708488f6fe8bf5e06ae724243381b40586301633 (commit)
via f131ee9c56b99429374dfcce583872ad9259ed96 (commit)
via c9189f54cd9e57a4d66124d14467848db9fcc8f1 (commit)
via d2613b97fa8173920ef7440cf291ca24a05b5b7c (commit)
via cd5b38a4b0e8cfe634b31fc730bddbc373eb17ce (commit)
via e412ac19f549afa26b58dbd2a2090ed95ca9cb95 (commit)
via f1fac6abfb676b081ee2d474ab3e15f6d07d0416 (commit)
via ab87657b937f3de392b1796e7f93c4008cc21f01 (commit)
via 499b750c2fbbedde27ad25d241f0c95566e5a0b7 (commit)
via fe9a0de32edaf1db58e46a3fd3f1c05ad0b0e6c2 (commit)
via be0a472cb798f0bfd4a75d1cfe165b4005a8ca90 (commit)
via 493e5fb7828793a8b834d5ecfd2e83050fcd920c (commit)
via 2f7d2485f5c23223dad2b827d5c384837c878c5a (commit)
via 168b795f9eb12c08d70d05f2ee313165004564e3 (commit)
via 91f175270142aa8b03e4efc108a07ddf71f7080d (commit)
from b0aa51059233849b0a7ef8d6a851750776ce6645 (commit)
- Log -----------------------------------------------------------------
commit 7325ebbc22091c698fd19140b7ed6986024ec6e8
Author: Dan McGee
2007/9/18, Dan McGee
Hello,
This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository.
hmm, I cannot see most of these changes in shortlog. I guess the changes that was made in a (asciidoc) branch don't show up in master summary/shortlog. But it *seems* that git on kernel.org does this (which is good, IMO, for tracking changes for adding to NEWS file). Is there way to get the same behaviour in pacman git. I'm not expert in git so sorry if what I'm saying is stupid. :-P -- Roman Kyrylych (Роман Кирилич)
On 9/18/07, Roman Kyrylych
2007/9/18, Dan McGee
: Hello,
This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository.
hmm, I cannot see most of these changes in shortlog. I guess the changes that was made in a (asciidoc) branch don't show up in master summary/shortlog. But it *seems* that git on kernel.org does this (which is good, IMO, for tracking changes for adding to NEWS file). Is there way to get the same behaviour in pacman git. I'm not expert in git so sorry if what I'm saying is stupid. :-P
They are there. By default GIT outputs its log entries in chronological order. Topological order makes more sense for a case like this. You'd have to search Google for the myriad of git-log options. -Dan
On Tue, Sep 18, 2007 at 12:04:23AM -0400, Dan McGee wrote:
commit 708488f6fe8bf5e06ae724243381b40586301633 Merge: b0aa51059233849b0a7ef8d6a851750776ce6645 f131ee9c56b99429374dfcce583872ad9259ed96 Author: Dan McGee
Date: Sun Sep 16 21:10:44 2007 -0500 Merge branch 'asciidoc' into working
We're getting close to release, so might as well do this now so people can actually update some of our documentation.
Hmm, apparently pacman doesn't build anymore, I get : Making all in doc make[2]: Entering directory `/data/share/devel/pacman/pacman/doc' make[2]: *** No rule to make target `pacman.8', needed by `all-am'. Stop. make[2]: Leaving directory `/data/share/devel/pacman/pacman/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/share/devel/pacman/pacman' make: *** [all] Error 2 After checking asciidoc was installed, doing ./configure --enable-asciidoc , and installing docbook-xsl , it compiled fine. I'm a bit confused. So now for getting man pages, we need asciidoc and docbook-xsl as makedepends , and adding that --enable-asciidoc configure flag, right? And if --enable-asciidoc isn't specified, no man pages can be built at all, and it's just a little quirck left in the Makefiles?
Xavier wrote:
On Tue, Sep 18, 2007 at 12:04:23AM -0400, Dan McGee wrote:
commit 708488f6fe8bf5e06ae724243381b40586301633 Merge: b0aa51059233849b0a7ef8d6a851750776ce6645 f131ee9c56b99429374dfcce583872ad9259ed96 Author: Dan McGee
Date: Sun Sep 16 21:10:44 2007 -0500 Merge branch 'asciidoc' into working
We're getting close to release, so might as well do this now so people can actually update some of our documentation.
Hmm, apparently pacman doesn't build anymore, I get : Making all in doc make[2]: Entering directory `/data/share/devel/pacman/pacman/doc' make[2]: *** No rule to make target `pacman.8', needed by `all-am'. Stop. make[2]: Leaving directory `/data/share/devel/pacman/pacman/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/share/devel/pacman/pacman' make: *** [all] Error 2
After checking asciidoc was installed, doing ./configure --enable-asciidoc , and installing docbook-xsl , it compiled fine.
I'm a bit confused. So now for getting man pages, we need asciidoc and docbook-xsl as makedepends , and adding that --enable-asciidoc configure flag, right?
And if --enable-asciidoc isn't specified, no man pages can be built at all, and it's just a little quirck left in the Makefiles?
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Official source releases will come with the man pages built, that was the plan wasn't it Dan? Andrew
On 9/18/07, Andrew Fyfe
Xavier wrote:
On Tue, Sep 18, 2007 at 12:04:23AM -0400, Dan McGee wrote:
commit 708488f6fe8bf5e06ae724243381b40586301633 Merge: b0aa51059233849b0a7ef8d6a851750776ce6645 f131ee9c56b99429374dfcce583872ad9259ed96 Author: Dan McGee
Date: Sun Sep 16 21:10:44 2007 -0500 Merge branch 'asciidoc' into working
We're getting close to release, so might as well do this now so people can actually update some of our documentation.
Hmm, apparently pacman doesn't build anymore, I get : Making all in doc make[2]: Entering directory `/data/share/devel/pacman/pacman/doc' make[2]: *** No rule to make target `pacman.8', needed by `all-am'. Stop. make[2]: Leaving directory `/data/share/devel/pacman/pacman/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/share/devel/pacman/pacman' make: *** [all] Error 2
After checking asciidoc was installed, doing ./configure --enable-asciidoc , and installing docbook-xsl , it compiled fine.
I'm a bit confused. So now for getting man pages, we need asciidoc and docbook-xsl as makedepends , and adding that --enable-asciidoc configure flag, right?
And if --enable-asciidoc isn't specified, no man pages can be built at all, and it's just a little quirck left in the Makefiles?
Official source releases will come with the man pages built, that was the plan wasn't it Dan?
Andrew
Correct. The way it works is this- you will have to build with asciidoc enabled at least once to get the manpages, and they are never cleaned up in a "make clean" target call. They are also distributed in the pacman tarball created by "make dist" or "make distcheck". As a developer, I figure everyone can get asciidoc installed in order to build the manpages. If not...well if you can come up with a patch that still satisfies the above requirements, then I'll take it (some sort of patch that doesn't fail if targets in doc/ can't be built). Thus, we don't need asciidoc or docbook-xsl as makedepends, and also the reason --enable-asciidoc is off by default. Something to check, however- "make dist" should probably enforce that --enable-asciidoc is actually enabled and working. -Dan
On 9/18/07, Dan McGee
As a developer, I figure everyone can get asciidoc installed in order to build the manpages. If not...well if you can come up with a patch that still satisfies the above requirements, then I'll take it (some sort of patch that doesn't fail if targets in doc/ can't be built).
Ah, asciidoc. It's so cool once it's all built, but I always had problems getting it working. But I think that was on dreamhost and maybe perl related... Thankfully, Dan has this in [community] so we need not be afeared!
On 9/18/07, Aaron Griffin
On 9/18/07, Dan McGee
wrote: As a developer, I figure everyone can get asciidoc installed in order to build the manpages. If not...well if you can come up with a patch that still satisfies the above requirements, then I'll take it (some sort of patch that doesn't fail if targets in doc/ can't be built).
Ah, asciidoc. It's so cool once it's all built, but I always had problems getting it working. But I think that was on dreamhost and maybe perl related...
Thankfully, Dan has this in [community] so we need not be afeared!
Yeah. Let me know if things aren't working correctly. I could move asciidoc to extra but didn't see the need right now. The docbook-xsl package was broken for a bit, but seems to be working now. The big advantage this gives us is much more user-friendly editing of the manpages, much better HTML output (with linking between them), and the ability to do some macros and such that aren't from the 1970s. Now we just need someone to volunteer to keep these bad boys up to date. :) Patches always welcome. -Dan
On Tue, Sep 18, 2007 at 10:46:30AM -0500, Dan McGee wrote:
On 9/18/07, Aaron Griffin
wrote: On 9/18/07, Dan McGee
wrote: As a developer, I figure everyone can get asciidoc installed in order to build the manpages. If not...well if you can come up with a patch that still satisfies the above requirements, then I'll take it (some sort of patch that doesn't fail if targets in doc/ can't be built).
Ah, asciidoc. It's so cool once it's all built, but I always had problems getting it working. But I think that was on dreamhost and maybe perl related...
Thankfully, Dan has this in [community] so we need not be afeared!
Yeah. Let me know if things aren't working correctly. I could move asciidoc to extra but didn't see the need right now. The docbook-xsl package was broken for a bit, but seems to be working now.
It's alright, it was very easy to get working, just pacman -S asciidoc docbook-xsl and done, so good job :) Also, if these man pages will be shipped in tarballs, and then a simple "./configure && make" still works, then it's not really an issue. I still find it not ideal that this isn't possible anymore with the git tree. So as you said, a patch that doesn't fail if targets in doc/ can't be built would be a very good idea imo. But it's not a big deal indeed.
The big advantage this gives us is much more user-friendly editing of the manpages, much better HTML output (with linking between them), and the ability to do some macros and such that aren't from the 1970s.
On this subject, an user recently wanted to get informations fron the current HTML manpages, but they seem a bit outdated : http://www.archlinux.org/pipermail/arch/2007-September/015447.html But if they are going to be both updated and improved for 3.1 , its probably fine :) Also archlinux.org/pacman could be updated for 3.0.6 .
Eeek, I don't know which thread to reply to! Let's go with the new one. 8)
On 9/18/07, Xavier
The big advantage this gives us is much more user-friendly editing of the manpages, much better HTML output (with linking between them), and the ability to do some macros and such that aren't from the 1970s.
I couldn't agree more with Dan here. Asciidoc documentation is a great boon, BUT asciidoc is a big nasty mess of an app. Still, nroff code can't be much prettier.
On this subject, an user recently wanted to get informations fron the current HTML manpages, but they seem a bit outdated : http://www.archlinux.org/pipermail/arch/2007-September/015447.html But if they are going to be both updated and improved for 3.1 , its probably fine :)
Also archlinux.org/pacman could be updated for 3.0.6 .
I marked this, I will try and get to it tonight, but I won't be getting home for some time.
On 9/18/07, Aaron Griffin
Eeek, I don't know which thread to reply to! Let's go with the new one. 8)
On 9/18/07, Xavier
wrote: The big advantage this gives us is much more user-friendly editing of the manpages, much better HTML output (with linking between them), and the ability to do some macros and such that aren't from the 1970s.
I couldn't agree more with Dan here. Asciidoc documentation is a great boon, BUT asciidoc is a big nasty mess of an app. Still, nroff code can't be much prettier.
On this subject, an user recently wanted to get informations fron the current HTML manpages, but they seem a bit outdated : http://www.archlinux.org/pipermail/arch/2007-September/015447.html But if they are going to be both updated and improved for 3.1 , its probably fine :)
Also archlinux.org/pacman could be updated for 3.0.6 .
I marked this, I will try and get to it tonight, but I won't be getting home for some time.
Taken care of (mostly). Just need someone to write up the ChangeLog entry and send it to me for GIT and then I will get it online, otherwise I'll do it sometime later tonight. -Dan
On Tue, Sep 18, 2007 at 12:46:50PM -0500, Dan McGee wrote:
Taken care of (mostly). Just need someone to write up the ChangeLog entry and send it to me for GIT and then I will get it online, otherwise I'll do it sometime later tonight.
Hmm, not sure what you meant, but maybe something like that could do : - config files updated to reflect the current -> core repository shuffle - several bugfixes : - symlink overwriting issue (bug #7484) - config parsing failed with tr_TR locale (bug #7235) - install of large packages failed (bug #7578)
participants (6)
-
Aaron Griffin
-
Andrew Fyfe
-
Dan McGee
-
Dan McGee
-
Roman Kyrylych
-
Xavier