[1.32 Release] Draft tarballs are available
Draft zip/tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation), or, if there are none, to confirm that pending a few issues below, we are finally ready to release. For your convenience, the unpacked contents is also available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website. KNOWN ISSUES ------------ The following is a list of known issues present in the tarballs which grant them their draft status: 1) A small number of unmarked test failures (but no regressions). 2) A small number of broken links as follows: doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png doc/html/libraries.html: broken link: ../boost.pdf libs/libraries.htm: broken link: ../boost.docbook, broken link: ../boost.fo, broken link: ../boost.pdf libs/numeric/conversion/doc/converter.html: broken link: udt_support.html libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html 3) No documentation in PDF format ("boost.pdf"), due to some build issues (I'll post separate email on this). 4) Placeholder pages in place of the revoked pre-1.32 MPL documentation. If you encounter any issues that are not in the above list, please report them here! TESTING ------- To run regression tests on the archives, you need to: 1) Grab the archive for your platform from one of the above locations. 2) Grab the latest "regression.py" from http://www.meta-comm.com/engineering/boost/regression.py 3) Put the archive and "regression.py" in the same directory and invoke the latter with the following command line: python regression.py --local=<archive name> --runner=<your runner id> --toolsets=<your toolsets> [<more options as needed>] For example, python regression.py --local=boost_1_32_0.zip --runner=metacomm --toolsets=msvc,vc7,vc-7_1,cw-8_3 --pjl-toolset=vc-7_1 The results will be automatically uploaded to ftp://fx.meta-comm.com/boost-regression/boost_1_32_0/. Finally, thanks in advance to everybody who will be looking at this! -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
For your convenience, the unpacked contents is also available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website.
It looks like only some of the documentation is using the new style sheet. Compare these two: http://www.meta-comm.com/engineering/boost/1_32_0_draft/doc/html/any.html http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/bind/bind.html Kind of messed up. Should I edit all the HTML files to make them refer to the new style sheet? Or back out the style sheet for this release? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Aleksey Gurtovoy wrote:
For your convenience, the unpacked contents is also available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website.
It looks like only some of the documentation is using the new style sheet.
It's more than that, but you're probably right that a uniform stylesheet would smooth the most visible differences.
Compare these two:
http://www.meta-comm.com/engineering/boost/1_32_0_draft/doc/html/any.html
This one is BoostBook-generated.
http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/bind/bind.html
And this one is hand-crafted (AFAIK).
Kind of messed up.
I agree that the lack of consistency is significantly more obvious than what we had in the previous release. Different font styles in particular are probably the most visible part of the discrepancy. IMO the other differences fall into the category of "acceptable". Come to think about it, the Spirit docs didn't change from the previous release and still have the old look & feel that is even more different from everything else: http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/spirit/index.ht... I'm not sure whether we should do something about that or not (but I'd welcome uniformity here as well, if Spirit folks want to tackle it!).
Should I edit all the HTML files to make them refer to the new style sheet?
I'm afraid that would require approval from the corresponding authors of the library. I'm sure some library authors weren't participating in the look & feel debate partly because as long as it was about BoostBook-generated docs, it didn't affect them. If we were to change the look of _every_ documentation page, it would require a significantly wider consensus, and possibly acknowledgement of the bits which are left up to individual preferences.
Or back out the style sheet for this release?
I'd consider backing out on the fonts, and leaving everything else as is. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Eric Niebler writes:
Should I edit all the HTML files to make them refer to the new style sheet?
I'm afraid that would require approval from the corresponding authors of the library.
Good point.
Or back out the style sheet for this release?
I'd consider backing out on the fonts, and leaving everything else as is.
That doesn't appeal to me, but I'd be interested to hear other opinions. There was broad consensus on boost-docs that sans-serif was ultimately what we wanted for boostbook documentation. I'm inclined to stick with it, live with the inconsistency for this release, and encourage people to port their docs to boostbook for the next one. BTW, how come the "Nightly CVS" documentation (linked to from boost.org/) doesn't have the non-boostbook docs? And in general, it doesn't look much like the documentation in the tarball? Seems that whatever process we're using to generate the docs for the release should be the same as what we use to generate the "Nightly CVS" documentation, so that any problems can be spotted early. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Aleksey Gurtovoy wrote:
Eric Niebler writes:
Should I edit all the HTML files to make them refer to the new style sheet?
I'm afraid that would require approval from the corresponding authors of the library.
Good point.
Or back out the style sheet for this release?
I'd consider backing out on the fonts, and leaving everything else as is.
That doesn't appeal to me, but I'd be interested to hear other opinions. There was broad consensus on boost-docs that sans-serif was ultimately what we wanted for boostbook documentation.
Sure. But my point was that people might have perceived this as BoostBook-specific discussion. The consensus might be different when the issue is re-raised in the content of the common look & feel for *all* docs. If you ask every library author not employing BoostBook for the docs at the moment how they would feel about switching to the new look and feel, you might see that in fact there is no consensus. At least I wouldn't make any assumptions on this.
I'm inclined to stick with it, live with the inconsistency for this release, and encourage people to port their docs to boostbook for the next one.
This may never happen, though.
BTW, how come the "Nightly CVS" documentation (linked to from boost.org/) doesn't have the non-boostbook docs?
Because they are not nightly generated. But that's mostly an excuse for not not having time to address the issue -- the very reason why the "Nightly CVS" link is going to go from the main page in 1.32.
And in general, it doesn't look much like the documentation in the tarball?
What do you mean? Looks perfectly the same for me.
Seems that whatever process we're using to generate the docs for the release should be the same as what we use to generate the "Nightly CVS" documentation, so that any problems can be spotted early.
It _is_ the same process. If there is one thing that we are guilty of here, it's not generating the PDF, and it has already bit us -- http://article.gmane.org/gmane.comp.lib.boost.devel/112563. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation), or, if there are none, to confirm that pending a few issues below, we are finally ready to release.
In libs/filesystem/src/operations_posix_windows.cpp around line 600 the remove function BOOST_FILESYSTEM_DECL bool remove( const path & ph ) { if ( exists( ph ) ) { ... will not delete dangling symlinks. Instead, the exists() line should be replaced with if ( exists( ph ) || symbolic_link_exists ( ph ) ) Regards, Walter Landry wlandry@ucsd.edu
At 01:56 PM 10/31/2004, Walter Landry wrote:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation), or, if there are none, to confirm that pending a few issues below, we are finally ready to release.
In libs/filesystem/src/operations_posix_windows.cpp around line 600 the remove function
BOOST_FILESYSTEM_DECL bool remove( const path & ph ) { if ( exists( ph ) ) { ...
will not delete dangling symlinks. Instead, the exists() line should be replaced with
if ( exists( ph ) || symbolic_link_exists ( ph ) )
Fixed in both main trunk and RC_1_32_0. Thanks! --Beman
Aleksey Gurtovoy writes: [...]
KNOWN ISSUES ------------
The following is a list of known issues present in the tarballs which grant them their draft status:
1) A small number of unmarked test failures (but no regressions).
2) A small number of broken links as follows:
doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png doc/html/libraries.html: broken link: ../boost.pdf libs/libraries.htm: broken link: ../boost.docbook, broken link: ../boost.fo, broken link: ../boost.pdf libs/numeric/conversion/doc/converter.html: broken link: udt_support.html libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html
2.5) Program Options library is missing from http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/libraries.htm [Reported by Matthew Burgess and fixed in the branch] -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
2.5) Program Options library is missing from
http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/libraries.htm
[Reported by Matthew Burgess and fixed in the branch]
Thanks! Should I do RC->trunk merge? - Volodya
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
2.5) Program Options library is missing from
http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/libraries.htm
[Reported by Matthew Burgess and fixed in the branch]
Thanks! Should I do RC->trunk merge?
Please feel free to. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
If you encounter any issues that are not in the above list, please report them here!
The documentation for the serialization library contains a page "Miscellaneous/BOOST_STATIC_WARNING", but the page is empty. Not a serious problem, though :) Regards, Daniel
Daniel Frey writes:
Aleksey Gurtovoy wrote:
If you encounter any issues that are not in the above list, please report them here!
The documentation for the serialization library contains a page "Miscellaneous/BOOST_STATIC_WARNING", but the page is empty.
Robert? -- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip> The first two archives does not give write permissions to the user (for the unarchived files). Permissions are -r--r--r-- for files and dr-xr-xr-x for directories. Should be -rw-r--r-- and drwxr-xr-x. At least it's not 777 like last time :D Cheers, -- Tarjei
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip>
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
Permissions are -r--r--r-- for files and dr-xr-xr-x for directories. Should be -rw-r--r-- and drwxr-xr-x. At least it's not 777 like last time :D
Well, obviously we've worked on this :). -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files. That gives no protection, really. If I unintentionally remove some files, I can just reinstall. If I want to edit them, I'll edit them anyway. Write protection will just get in the way. BTW, just like it gets in the way with Boost CVS -- somehow all files are read only and I constantly have to change permissions or tell Emacs to override them. - Volodya
Vladimir Prus wrote:
Aleksey Gurtovoy wrote: [snip] reinstall. If I want to edit them, I'll edit them anyway. Write protection will just get in the way. BTW, just like it gets in the way with Boost CVS -- somehow all files are read only and I constantly have to change permissions or tell Emacs to override them.
You may need to force a "cvs unwatch" on those files then. Many GUI clients make it a little easy to "watch" files by accident, causing no end of pain for those who don't use GUI clients. An easy way of determining if this is the problem is to change the permissions on a file, then cvs update it. If the permissions are reset to read-only, then you probably have some unintentional cvs watchers. Michael
Vladimir Prus <ghost@cs.msu.su> writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files. That gives no protection, really. If I unintentionally remove some files, I can just reinstall. If I want to edit them, I'll edit them anyway. Write protection will just get in the way. BTW, just like it gets in the way with Boost CVS -- somehow all files are read only and I constantly have to change permissions or tell Emacs to override them.
Personally I like that. I don't tell Emacs to override them, I use `C-x v v' to "cvs edit" them. There are CVS options to control this. In fact, unless you have CVSREAD set in your environment, CVS checks out writable files. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At 09:22 AM 11/1/2004, David Abrahams wrote:
Vladimir Prus <ghost@cs.msu.su> writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files. That gives no protection, really. If I unintentionally remove some files, I can just reinstall. If I want to edit them, I'll edit them anyway. Write protection will just get in the way. BTW, just like it gets in the way with Boost CVS -- somehow all files are read only and I constantly have to change permissions or tell Emacs to override them.
Personally I like that. I don't tell Emacs to override them, I use `C-x v v' to "cvs edit" them.
There are CVS options to control this. In fact, unless you have CVSREAD set in your environment, CVS checks out writable files.
There must be more to the story than that. I don't have CVSREAD set, but always get read-only files from the main CVS yet read-write files from the sandbox. It's a mystery! --Beman
On Mon, Nov 01, 2004 at 12:51:19PM -0500, Beman Dawes wrote:
There must be more to the story than that. I don't have CVSREAD set, but always get read-only files from the main CVS yet read-write files from the sandbox. It's a mystery!
AFAIK, the reason for this behaviour is that, main cvs have an active watchers list. It is the functionalilty that generates notification mails. I'm not sure what is the exact internal cvs logic, but enabling the watchers list makes the cvs to checkout files as read only. Regards, Pavol
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
That gives no protection, really.
It prevents you from accidental editing/deletion.
If I unintentionally remove some files, I can just reinstall.
I'd rather be saved from that.
If I want to edit them, I'll edit them anyway.
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter. IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
Write protection will just get in the way. BTW, just like it gets in the way with Boost CVS -- somehow all files are read only and I constantly have to change permissions or tell Emacs to override them.
Completely unlike it, IMO. In the above situation, it's a CVS checkout, you are a developer, and editing is a normal workflow. Everything is exactly the opposite with the tarball. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
FWIW, Debian policy says the same: http://www.debian.org/doc/debian-policy/ch-files.html#s10.9
If I want to edit them, I'll edit them anyway.
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter.
Why I'm not supposed to do that? Say, I have a number of patches which are needed for my project (which I do have). I'd expect to be able to get tarball and apply the patches.
IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
This all is pretty subjective, so I'd suggest to stick to existing practices. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
This all is pretty subjective, so I'd suggest to stick to existing practices.
Every way in which Boost distributions deviate from standard distribution practice (and there are many) has historically caused problems for Unix users. I think we should do whatever is commonly done here. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
FWIW, Debian policy says the same:
http://www.debian.org/doc/debian-policy/ch-files.html#s10.9
If I want to edit them, I'll edit them anyway.
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter.
Why I'm not supposed to do that? Say, I have a number of patches which are needed for my project (which I do have). I'd expect to be able to get tarball and apply the patches.
IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
This all is pretty subjective, so I'd suggest to stick to existing practices.
That was the intention from the very beginning; I just had a misconception what they are, and other arguments weren't very convincing. -- Aleksey Gurtovoy MetaCommunications Engineering
On Mon, 1 Nov 2004 09:04:24 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Vladimir Prus writes:
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
I concur with Vladimir. Files in a distribution tarball should be created writeable by the owner (e.g. octal mode 644 for files, 755 for directories). I have encountered a handful of distributions which do not behave this way and have immediately done a "chmod -R +w <dir>" on each, as I did with this one.
That gives no protection, really.
It prevents you from accidental editing/deletion.
If I unintentionally remove some files, I can just reinstall.
I'd rather be saved from that.
Its the "Doctor, it hurts when I do this" argument. Don't do that then. But let ME do it if I want to. Its a free world.
If I want to edit them, I'll edit them anyway.
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter. IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
Well, I for one unpacked the .tar.gz version of the distribution on my PC (using cygwin tar) and tried to build with Visual Studio .NET 2003. The build of bjam failed because the compiler couldn't write its .pdb files in the write-protected directories. I suspect I would have run into similar build problems on the UNIX side if I hadn't chmodded the entire directory tree first (and if I didn't already have a pre-builld bjam executable there). Please make the files and directories in the tarballs writeable. It makes sense to *install* the headers and libraries non-writeable as part of the "bjam install" step, but having the sources write-protected is just a pain in the neck. -- Caleb Epstein caleb.epstein@gmail.com
On Mon, 2004-11-01 at 16:04, Aleksey Gurtovoy wrote:
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
Confirmed.
That gives no protection, really.
It prevents you from accidental editing/deletion.
But that's putting the protection in at the wrong level in unix-land. For a system install, the files would be installed to a system wide location by the root user and thus only be writable by root. If I'd like to download boost and put it somewhere in my $HOME, I expect to be able to do whatever I like to the files. I.e. experiment with the code (this would not affect other users).
If I unintentionally remove some files, I can just reinstall.
I'd rather be saved from that.
You are if you install boost as root (as you should if you're installing it system wide on any unix installation). Access control is more fine grained on unix - read only is only applicable as a "security measure" on windows IMHO. Cheers, -- Tarjei
Tarjei Knapstad writes:
On Mon, 2004-11-01 at 16:04, Aleksey Gurtovoy wrote:
Vladimir Prus writes:
Aleksey Gurtovoy wrote:
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
No unix source package I ever downloaded had read-only files.
Could our long-time unix users confirm/negate this experience?
Confirmed.
That gives no protection, really.
It prevents you from accidental editing/deletion.
But that's putting the protection in at the wrong level in unix-land. For a system install, the files would be installed to a system wide location by the root user and thus only be writable by root. If I'd like to download boost and put it somewhere in my $HOME, I expect to be able to do whatever I like to the files. I.e. experiment with the code (this would not affect other users).
OK, got it.
If I unintentionally remove some files, I can just reinstall.
I'd rather be saved from that.
You are if you install boost as root (as you should if you're installing it system wide on any unix installation).
Access control is more fine grained on unix - read only is only applicable as a "security measure" on windows IMHO.
Thanks for the explanation! -- Aleksey Gurtovoy MetaCommunications Engineering
Tarjei Knapstad wrote:
Access control is more fine grained on unix
Actually, it's not. Fine-grained security is probably more commonly applied on Unix than on Windows, however.
read only is only applicable as a "security measure" on windows IMHO.
Read-only is a nuissance everywhere and shouldn't be used at all IMHO. -cd
Aleksey Gurtovoy wrote:
Could our long-time unix users confirm/negate this experience?
I don't think it is common for ANY sort of source distribution for files to be read-only. For example, are your compiler's header files read-only? Are the SDKs you normally use read-only? Is example code normally read-only?
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter. IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
I have been annoyed time-after-time by the read-only Boost files. I don't understand what possible purpose there is in making the files read-only. Sure, it helps prevent accidental editing or deletion, but seriously, I think this is on par with "Oops I accidentally deleted my term paper/operating system kernel/girlfriend's picture." And why precisely are users not supposed to be editing Boost sources? I edit them all the time, as oftentimes its just the easiest way to find a bug, or figure out how something works, or fix a minor incompatibility, or whatever. Our users aren't those same people who are telling tech support during blackouts; they're computer scientists and engineers who are hopefully fully qualified for this sort of thing. And keep in mind that unlike our Emacs users, not everyone has an editor for which overriding read-only attributes is easy. On more than one occasion have I been trying to edit the read-only source files of some foolish distribution, remotely in an editor that doesn't support writing to read-only files, or shell escapes. Its a real pain, even on Windows, to have to manually browse for the offending file and change its permissions when Notepad spits back some error message about not being able to save my work. Aaron W. LaFramboise
On Mon, 01 Nov 2004 14:38:24 -0600, Aaron W. LaFramboise
I don't think it is common for ANY sort of source distribution for files to be read-only. For example, are your compiler's header files read-only? Are the SDKs you normally use read-only? Is example code normally read-only?
Once they are INSTALLED, yes. But not in the unpacked distribution. Not sure how other folks around here do it, but I view the build tree as one thing (source code, configuration scripts, etc) and the installed tree (compiled libraries and header files) as another. The former is usually owned by a normal user and usually lives (briefly) in their home directory. The latter is owned by a privileged user (e.g. root) or set read-only to prevent accidental modification. -- Caleb Epstein caleb.epstein@gmail.com
On Mon, 2004-11-01 at 13:33, Aleksey Gurtovoy wrote:
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip>
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
Maybe not for the files, but the directories definitely need +w, otherwise I can't write to them. (In other words, I can't even build now without changing the permissions of at least the directories because jam can't write to/create the build directories).
Permissions are -r--r--r-- for files and dr-xr-xr-x for directories. Should be -rw-r--r-- and drwxr-xr-x. At least it's not 777 like last time :D
Well, obviously we've worked on this :).
After the above gets fixed: Good job :) -- Tarjei
Tarjei Knapstad writes:
On Mon, 2004-11-01 at 13:33, Aleksey Gurtovoy wrote:
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip>
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
Maybe not for the files, but the directories definitely need +w, otherwise I can't write to them. (In other words, I can't even build now without changing the permissions of at least the directories because jam can't write to/create the build directories).
You are right, of course; will be fixed. -- Aleksey Gurtovoy MetaCommunications Engineering
Tarjei Knapstad <tarjei.knapstad@predichem.com> writes:
On Mon, 2004-11-01 at 13:33, Aleksey Gurtovoy wrote:
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip>
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
Maybe not for the files, but the directories definitely need +w, otherwise I can't write to them. (In other words, I can't even build now without changing the permissions of at least the directories because jam can't write to/create the build directories).
The preferred method is to set the build directory outside the boost tree with --builddir=XXXXX. You're supposed to be able to build boost from readonly media. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
Draft zip/tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip
These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation)
<snip>
The first two archives does not give write permissions to the user (for the unarchived files).
That's intentional. After all, normally you shouldn't be modifying anything in the distribution. Or should you?
I should and I have. The code is not magically blessed, delivered by the gods from on high. People need to make modifications for whatever reason. Regards, Walter Landry wlandry@ucsd.edu
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
3) Put the archive and "regression.py" in the same directory and invoke the latter with the following command line:
python regression.py --local=<archive name> --runner=<your runner id> --toolsets=<your toolsets> [<more options as needed>]
I'd like to run the tests, but what are the exact python dependencies of regression.py? (Sorry if this is on a website somewhere, but I couldn't find it..) First I was missing tarfile, but was able to find python-tarfile and python-bz2 which got me a bit further. Now I get: File "regression.py", line 758, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 602, in regression setup( comment, toolsets, bjam_toolset, pjl_toolset, monitored, proxy, [] ) File "regression.py", line 373, in setup import_utils() File "regression.py", line 342, in import_utils import utils as utils_module ImportError: No module named utils Where can I find this "utils" package? (preferably a Fedora Core 1 RPM, but that's not too important) Regards, -- Tarjei
Tarjei Knapstad writes:
On Sun, 2004-10-31 at 18:27, Aleksey Gurtovoy wrote:
3) Put the archive and "regression.py" in the same directory and invoke the latter with the following command line:
python regression.py --local=<archive name> --runner=<your runner id> --toolsets=<your toolsets> [<more options as needed>]
I'd like to run the tests, but what are the exact python dependencies of regression.py? (Sorry if this is on a website somewhere, but I couldn't find it..)
The 'regression.py' docs are here -- http://www.meta-comm.com/engineering/regression_setup/instructions.html, but at the moment they don't document its [external] Python module dependencies, which are: xml.sax.saxutils, urllib, tarfile, ftplib, zipfile, socket, time, getopt, glob, shutil, stat, os.path, os, inspect, traceback, string, sys and, possibly, depending on the options, 'smtplib' and 're'.
First I was missing tarfile, but was able to find python-tarfile and python-bz2 which got me a bit further. Now I get:
File "regression.py", line 758, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 602, in regression setup( comment, toolsets, bjam_toolset, pjl_toolset, monitored, proxy, [] ) File "regression.py", line 373, in setup import_utils() File "regression.py", line 342, in import_utils import utils as utils_module ImportError: No module named utils
Where can I find this "utils" package? (preferably a Fedora Core 1 RPM, but that's not too important)
'utils' is imported from the inside of the unpacked archive, so the above probably means that the latter didn't unpack properly. Let me do a quick test of the whole thing on OS X... Oh, it seems like 'tarfile' (at least as in Python 2.3) is not able to handle either of the tarballs -- it doesn't fail, but doesn't unpack anything either. [It works fine with zip on Windows]. We'll have to look into it further, but meanwhile I modified 'regression.py' to accept both the tarball and the unpacked directory name, so you have an option of unpacking the thing manually and then invoking the script like this: chmod -R +w boost_1_32_0 # permissions *do* get in the way python regression.py --local=boost_1_32_0 --runner=<your runner id> ^^^^^^^^^^^^ --toolsets=<your toolsets> [<more options as needed>] The updated script is available from the same location -- http://www.meta-comm.com/engineering/boost/regression.py. Let us know if you come across any other issues, and thank you for doing the tests! -- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, 31 Oct 2004 11:27:14 -0600, Aleksey Gurtovoy wrote
2) A small number of broken links as follows:
doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png
Aleksey -- we are looking into this now, hope to have a solution shortly...should boil down to removing the first link and adding the png file back into cvs.
3) No documentation in PDF format ("boost.pdf"), due to some build issues (I'll post separate email on this).
Unfortunately, there have been earlier emails on the Boost-Doc list about this which no one responded to. It's been broken in the mainline for a few months now... Jeff
On Mon, 1 Nov 2004 10:02:17 -0700, Jeff Garland wrote
On Sun, 31 Oct 2004 11:27:14 -0600, Aleksey Gurtovoy wrote
2) A small number of broken links as follows:
doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png
Aleksey -- we are looking into this now, hope to have a solution shortly...should boil down to removing the first link and adding the png file back into cvs.
Fixes are checked in now... Jeff
Jeff Garland writes:
On Mon, 1 Nov 2004 10:02:17 -0700, Jeff Garland wrote
On Sun, 31 Oct 2004 11:27:14 -0600, Aleksey Gurtovoy wrote
2) A small number of broken links as follows:
doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png
Aleksey -- we are looking into this now, hope to have a solution shortly...should boil down to removing the first link and adding the png file back into cvs.
Fixes are checked in now...
Thank you! Pending the PDF problem, that closes all broken links issues. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (14)
-
Aaron W. LaFramboise -
Aleksey Gurtovoy -
Beman Dawes -
Caleb Epstein -
Carl Daniel -
Daniel Frey -
David Abrahams -
Eric Niebler -
Jeff Garland -
Michael van der Westhuizen -
Pavol Droba -
Tarjei Knapstad -
Vladimir Prus -
Walter Landry