You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
(8) |
Mar
(53) |
Apr
(2) |
May
(14) |
Jun
(15) |
Jul
(13) |
Aug
(2) |
Sep
|
Oct
|
Nov
(9) |
Dec
|
2003 |
Jan
(1) |
Feb
(9) |
Mar
(25) |
Apr
(17) |
May
(87) |
Jun
(30) |
Jul
(21) |
Aug
(4) |
Sep
(46) |
Oct
(15) |
Nov
(2) |
Dec
(62) |
2004 |
Jan
(65) |
Feb
(31) |
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(4) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(17) |
2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: John F. <fe...@dd...> - 2002-02-26 23:19:29
|
I do not recall. however I did publish all your updates. --fess On Tue, 26 Feb 2002, Paul Mineiro wrote: > hey, as you may have noticed, i've been migrating codegrok packages to > the public repository. > > so, the previous mysql package was listed as essentially completely > non-relocatable (!). i didn't do this for the codegrok package, which is > now in the public archive, 3.23.49-1. does anybody remember why it was > listed non-relocatable (e.g., does the --basedir flag to mysqld not work > as expected?). > > -- p > > "The content industry controls everything, but ha!, we, the great hackers > & crackers, will break everything they come up with, and then we will > distribute it for free! But if they ask nicely, we will still send the > artists a check, or something." > > > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > |
From: Paul M. <pmi...@mi...> - 2002-02-26 19:02:08
|
hey, as you may have noticed, i've been migrating codegrok packages to the public repository. so, the previous mysql package was listed as essentially completely non-relocatable (!). i didn't do this for the codegrok package, which is now in the public archive, 3.23.49-1. does anybody remember why it was listed non-relocatable (e.g., does the --basedir flag to mysqld not work as expected?). -- p "The content industry controls everything, but ha!, we, the great hackers & crackers, will break everything they come up with, and then we will distribute it for free! But if they ask nicely, we will still send the artists a check, or something." |
From: John F. <fe...@dd...> - 2002-02-18 03:41:59
|
well, I don't know if the tools are harder to get or install, but they seem to be seperated into different tools for print or html: http://docbook.sourceforge.net/projects/xsl/doc/publishing.html I'm going to try out sablotron because that's what yozhik uses (I think). He even packaged it for wigwam. we'll see where I get from there. I'm currently going to mess with xml/xsl docbook for some other projects, before I think about changeing the way wigwam is working. --fess On Sun, 17 Feb 2002, Dave Benson wrote: > I'd definitely appreciate it if someone could > suggest a docbook variant (docbook-xsl for example) > that is easy to install and makes html / ps / pdf / txt. > > The xml-based variants seem much more popular; > i just don't know the details of how to process them. > > I gather that no one thinks sgml/dsssl is maintainable and i think > that contributes to the slackly maintained jade/sgmltools situation; > it's quite hard to get sgmltools and its dependencies properly installed. > > Although docbook-xml seems to have been around for a while, > i don't myself know of a simple installation procedure. > > Any help in figuring out what to do here is appreciated, > i really don't know the current situation. > > - dave > > ps. i'm recommend forwarding this to wigwam-devel to see if anyone > has a suggestion. > > > On Sun, Feb 17, 2002 at 06:23:23PM -0800, John Fessenden wrote: > > So, I'm off to learn things docbook, with a strong slant on learning to > > customize my stylesheets to control output. > > > > I'm inclined to go down the path of xml docbook with xsl for stylesheets, > > do you have any opinions on xml vs. sgml docbook? or more importantly > > xsl vs. dssl stylesheets and accompaning parsers/renderers? > > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > |
From: Dave B. <da...@ff...> - 2002-02-18 03:08:09
|
I'd definitely appreciate it if someone could suggest a docbook variant (docbook-xsl for example) that is easy to install and makes html / ps / pdf / txt. The xml-based variants seem much more popular; i just don't know the details of how to process them. I gather that no one thinks sgml/dsssl is maintainable and i think that contributes to the slackly maintained jade/sgmltools situation; it's quite hard to get sgmltools and its dependencies properly installed. Although docbook-xml seems to have been around for a while, i don't myself know of a simple installation procedure. Any help in figuring out what to do here is appreciated, i really don't know the current situation. - dave ps. i'm recommend forwarding this to wigwam-devel to see if anyone has a suggestion. On Sun, Feb 17, 2002 at 06:23:23PM -0800, John Fessenden wrote: > So, I'm off to learn things docbook, with a strong slant on learning to > customize my stylesheets to control output. > > I'm inclined to go down the path of xml docbook with xsl for stylesheets, > do you have any opinions on xml vs. sgml docbook? or more importantly > xsl vs. dssl stylesheets and accompaning parsers/renderers? |
From: John F. <fe...@dd...> - 2002-02-17 19:35:23
|
Paul, let's make use of te wigwam-devel list for these type of things. I haven't messed with a provides package in a bit, so I don't know exactly what the behavior is. I'll try to look at that in a bit. Are you saying you are instlling service_y requires service_x or service_x_debug so therefore service_y could require provides_x and service_x and service_x_debug would provide provides_x but when you do this you then cannot install both service_x and service_x_debug at the same time? --fess On Mon, 11 Feb 2002, Paul Mineiro wrote: > hey, we're in a situation where we want to force installation of at > least one of two services, > but installing both is ok (namely, service_x and service_x_debug). if > we use a provides, installation > is mutually exclusive. if we just use servicedep, it's possible to have > neither installed. what to do? > > one possibility is if the .dep file supported "or" syntax like the > version numbers do. what do you > think of this solution? is there an easier way to "bolt on" this > functionality? > > -- p > |
From: John F. <fe...@dd...> - 2002-02-07 08:52:39
|
ok, it appears that it actually publishes. it just whines about a few things. the next publish seems to work, however the packages were rebuilt. the next publish seemed to work fine. not quite as urgent. --fess On Wed, 6 Feb 2002, John Fessenden wrote: > > > crap. > > it appears that new projects fail to publish for the first time. > > I just bootstrapped a project, > Checked it in, > checked it out, > configured a cluster, > checked it all in, > tagged and published. > > publish fails. > > it appears to have to do with the ext/build symlink speed up. > the scripts don't work right when $playpen_root isn't there allready. > > I have to take off for seattle for a couple of days, > so maybe someone will get to it before me. > maybe I'll be able to figure it out, while on the road. > > here's the way publish fails: > > fess@herbie-968% pubtool publish poop --tag pooptest > pubtool: (Using ext/logs/pubtool-4231.log as the logfile) > Publish pooptest to poop (Y/n)? > pubtool: Preparing master copy of project at pooptest... > pubtool: Checking that we have access to publish... > > pubtool: Copying publication data to cluster... > > pubtool: Duplicating playpens on cluster... > > pubtool: Copying project to cluster... > > pubtool: Preparing new playpens on cluster... > > fe...@he...: Checking wigwam requisites... .......... looks good. > fe...@he...: Excuse me while I configure and install wigwam-base > 3.0.46-1. > fe...@he...: I am going to write a log in > /tmp/wigwam-bootstrap-fess-4355.log > fe...@he...: It may be useful if something goes wrong. > fe...@he...: Building wigwam-base-3.0.46-1... done. > fe...@he...: The project in choko is now ready. > pubtool: Making new playpens live... > > fe...@he...: rm: /home/fess/tmp/chokopoop/ext/build: is a > directory > fe...@he...: use-new-playpen: WARNING: /home/fess/tmp/chokopoop/ext/build > wasn't a symlink. > fe...@he...: mv: /home/fess/tmp/chokopoop.backup/ext/build: No > such file or directory > fe...@he...: use-new-playpen: error moving real ext/build in place > of symlink! [IGNORED] > pubtool: Done. > > > > > |
From: John F. <fe...@dd...> - 2002-02-07 07:12:37
|
crap. it appears that new projects fail to publish for the first time. I just bootstrapped a project, Checked it in, checked it out, configured a cluster, checked it all in, tagged and published. publish fails. it appears to have to do with the ext/build symlink speed up. the scripts don't work right when $playpen_root isn't there allready. I have to take off for seattle for a couple of days, so maybe someone will get to it before me. maybe I'll be able to figure it out, while on the road. here's the way publish fails: fess@herbie-968% pubtool publish poop --tag pooptest pubtool: (Using ext/logs/pubtool-4231.log as the logfile) Publish pooptest to poop (Y/n)? pubtool: Preparing master copy of project at pooptest... pubtool: Checking that we have access to publish... pubtool: Copying publication data to cluster... pubtool: Duplicating playpens on cluster... pubtool: Copying project to cluster... pubtool: Preparing new playpens on cluster... fe...@he...: Checking wigwam requisites... .......... looks good. fe...@he...: Excuse me while I configure and install wigwam-base 3.0.46-1. fe...@he...: I am going to write a log in /tmp/wigwam-bootstrap-fess-4355.log fe...@he...: It may be useful if something goes wrong. fe...@he...: Building wigwam-base-3.0.46-1... done. fe...@he...: The project in choko is now ready. pubtool: Making new playpens live... fe...@he...: rm: /home/fess/tmp/chokopoop/ext/build: is a directory fe...@he...: use-new-playpen: WARNING: /home/fess/tmp/chokopoop/ext/build wasn't a symlink. fe...@he...: mv: /home/fess/tmp/chokopoop.backup/ext/build: No such file or directory fe...@he...: use-new-playpen: error moving real ext/build in place of symlink! [IGNORED] pubtool: Done. |
From: Michael R. <mr...@bl...> - 2002-01-16 21:39:46
|
I just moved a playpen and ran 'packagectl new-playpen-root ...', but ext/bin/glib-config remained unchanged with the old prefix still at the top. So I guess this is a bug in the glib-1.2.10-1 package. It should be marked as non-relocatable, etc. Mike |
From: Heather L S. <he...@id...> - 2001-12-27 23:22:46
|
On Thu, Dec 27, 2001 at 03:21:36PM -0800 or thereabouts, John Fessenden wrote: > Which package archive are you trying to publish? idealab or wigwam? Just trying to create my own. (I need php_mysql to be compiled with "--with-gettext"). Heather |
From: John F. <fe...@dd...> - 2001-12-27 23:21:38
|
hmm. yeah, that file is actually in the wigwam-packaging-utils. I'll fix it. Which package archive are you trying to publish? idealab or wigwam? --fess On Thu, 27 Dec 2001, Heather L Sherman wrote: > It contains an explicit reference to "md5sum". This breaks package archive > building under FreeBSD. Presumably it should know to use wwmd5 instead? > > Heather > > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > |
From: Heather L S. <he...@id...> - 2001-12-27 22:51:33
|
It contains an explicit reference to "md5sum". This breaks package archive building under FreeBSD. Presumably it should know to use wwmd5 instead? Heather |
From: Dave B. <da...@ff...> - 2001-12-06 16:32:19
|
On Wed, Dec 05, 2001 at 07:21:43PM -0800, John Fessenden wrote: > anyhow.. the real strange issue is that the patch is failing to apply on > solaris. It turns out that this is because patch doesn't have write > permision to the file it's trying to patch. That's because the archive has > the files stored without the write bit set, and solaris's tar preserves > those permissions when it unpacks it, ughh. > > currently patches are applied in ext/bin/build/expand-sources right after > the untar, so theres no hook in which to fix the perms. unless there's a better way, maybe a patch to add the hook is appropriate: --- doc/wigwam.sgml 2001/08/15 21:34:01 1.12 +++ doc/wigwam.sgml 2001/12/06 16:28:49 @@ -2230,7 +2230,25 @@ optional, and may contain support files, usually from the author of the package. </para> - +<para> + If a package's source files need modifications, + for example, for portability or to make them better adapted to wigwam, + you may include patches in the package. These should + be normal patches, produced with <command>diff -u</command>. + They will be automatically found and applied if + they end with <filename>.patch</filename>, <filename>.patch.bz2</filename> + or <filename>.patch.gz</filename>. +</para> +<para> + Sometimes patching sources is not enough to fix them so they build. + For example, sometimes a file's permission needs to be changed. + To do that, one can put code in the <filename>.prepatch</filename> + file: +<programlisting> + chmod +x configure-helper-script + chmod +w some-random-file +</programlisting> +</para> <para> Makefile-style packages recognized the additional variables: --- build-scripts/expand-sources 2001/07/28 13:45:58 1.2 +++ build-scripts/expand-sources 2001/12/06 16:28:48 @@ -14,8 +14,12 @@ Note that PATCHES must be included as an empty argument if there are no patches. -Recognized ARCHIVE formats: .tar.gz, .tar, .tar.bz2, .tgz, .zip, .arj" +Recognized ARCHIVE formats: .tar.gz, .tar, .tar.bz2, .tgz, .zip, .arj +Additionally, if .prepatch or .postpatch files are found +parallel to OPTIONS-FILE, those scripts are run before +or after the patches are applied." + options_file="$1" archives="$2" patches="$3" @@ -114,6 +118,11 @@ true fi +# Give the user a chance to fix up sources before applying +# the patches. This is mostly to allow permission fixes. +options_file_base=`echo "$options_file" | sed -e 's/\\.options$//'` +test -r "$options_file_base.prepatch" && ( . "$options_file_base.prepatch" ; ) + # _ _ _ # __ _ _ __ _ __| |_ _ _ __ __ _| |_ __| |_ ___ ___ # / _` | '_ \ '_ \ | || | | '_ \/ _` | _/ _| ' \/ -_|_-< @@ -163,5 +172,9 @@ echo "$id: patch $patch_flags" 1>&2 } done + +# Apply the postpatch script, if it exists. +# For example, maybe you want to 'chmod +x newly-created-file'. +test -r "$options_file_base.postpatch" && ( . "$options_file_base.postpatch" ; ) exit 0 |
From: John F. <fe...@dd...> - 2001-12-06 03:21:56
|
so, I have this package perl-IO-1.20 which has a patch applied to it so that it will build on perl 5.6.* (yeah perl 5.6 allready has IO-1.20 but I want it in the project because some of the machines the project is working on don't have perl-IO-1.20... so .. ) anyhow.. the real strange issue is that the patch is failing to apply on solaris. It turns out that this is because patch doesn't have write permision to the file it's trying to patch. That's because the archive has the files stored without the write bit set, and solaris's tar preserves those permissions when it unpacks it, ughh. currently patches are applied in ext/bin/build/expand-sources right after the untar, so theres no hook in which to fix the perms. anyone have an idea for an elegant solution to this? --fess |
From: John F. <fe...@dd...> - 2001-12-04 21:43:40
|
As an update to this, his project was using wigwam 3.0.30 so perhaps this is a false alarm. --fess On Tue, 4 Dec 2001, John Fessenden wrote: > > > hmm, > > there is a proccess where it trys to avoid copying the build directory > (to make publishing faster. ) and a symlink and a mv is involved there. > I'll have to look at again to see what it was doing. > > I'm not quite sure how you can get into a state where you symlink to > yourself. > > What version of wigwam are you using? > > What is the 'ls -l' of the symlink? > > Try --cvs-only if you can, ( it will force a brand new site out. > and a full rebuild. ) then try updating once after that. If that works > then you somehow got into a strange state, and I'll try to figure out how > that can happen. > > --fess > > > On Tue, 4 Dec 2001, Travis Foster wrote: > > > > > I have a project that always seems to mess up it's ext/build dir when > > publishing. It appears to create a symlink to itself. As in > > /web/ideahome/ext/build links to /web/ideahome/ext/build. Which makes it > > so you have to remove that link and then rebuild everything when you > > publish. Is this a bug in a certain version of wigwam or is this problem > > with the project? > > > > -Travis > > > > > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > |
From: John F. <fe...@ov...> - 2001-12-04 18:46:25
|
hmm, there is a proccess where it trys to avoid copying the build directory (to make publishing faster. ) and a symlink and a mv is involved there. I'll have to look at again to see what it was doing. I'm not quite sure how you can get into a state where you symlink to yourself. What version of wigwam are you using? What is the 'ls -l' of the symlink? Try --cvs-only if you can, ( it will force a brand new site out. and a full rebuild. ) then try updating once after that. If that works then you somehow got into a strange state, and I'll try to figure out how that can happen. --fess On Tue, 4 Dec 2001, Travis Foster wrote: > > I have a project that always seems to mess up it's ext/build dir when > publishing. It appears to create a symlink to itself. As in > /web/ideahome/ext/build links to /web/ideahome/ext/build. Which makes it > so you have to remove that link and then rebuild everything when you > publish. Is this a bug in a certain version of wigwam or is this problem > with the project? > > -Travis > |
From: Heather L. S. <he...@id...> - 2001-11-01 08:04:12
|
On Wed, Oct 31, 2001 at 06:47:26PM -0800 or thereabouts, Heather L. Sherman wrote: > I feel like I'm channelling the past :-) Hmmm, and like the past, much of the problems I encountered exploded from one or two original mistakes I made, namely: - mistakenly checking wigwam-base out from cvs.idealab.com and not completely removing it - initially running autogen.sh on a Redhat box and trusting make clean (and make distclean) to clean things up rather than just checking out again. So, README and INSTALL need .. something. I'll do it. And I still have the problem that make does fail when it reaches docs with: raise IOError, "Couldn't resolve pubid [%s]" % id IOError: Couldn't resolve pubid ["-//SGMLtools//DOCUMENT Docbook Style Sheet for Lynx Text//EN"] ../misc-scripts/convert-sgml: error converting to text. *** Error code 1 While just "cd docs; make wigwam.ps" is unhappy about the no X server thing So, with luck, that last message I sent will just disappear into oblivion and I can report only real problems and no one will realize that I am an idiot. Although I still consider it a valuable skill that I can emulate "the stupidest user" so very well. Heather |
From: Heather L. S. <he...@id...> - 2001-11-01 02:47:28
|
I feel like I'm channelling the past :-) 1) at wigwam.sourceforge.net there's a broken link off documentation to "documentation as one page" (it would be really, really nice if there were PDF versions of the docs there). 2) at http://sourceforge.net/docman/?group_id=16596 there's no documentation at all. Shouldn't there be? 3) Is the sourceforge CVS copy the master? The README in wigwam-base-46 that I checked out says: This wigwam-base project was moved to sourceforge no more development should happen in this idealab! cvs repository. the tag right before all the files were removed is: daveb-move-to-sf Thank you. This seems totally wrong -- I'll update it, I guess. 4) INSTALL says "please see user docs... for now". Guess what, I'm trying to process these. I'll update this to say "run autogen.sh, then run make, (gmake under FreeBSD)" It would be really nice if there were a list of the stuff you should have installed first (automake, sgmltools-lite, dia, anything else?). Presumably I should include a "you probably don't really want this, you probably want wigwam-bootstrap instead" comment. 5) The make file doesn't work at all with make under FreeBSD, and doesn't quite work with gmake under FreeBSD. On erie they (respectively) report: erie% make Making all in build-scripts Making all in misc-scripts "Makefile", line 203: Need an operator "Makefile", line 209: Need an operator "Makefile", line 210: Need an operator "Makefile", line 211: Need an operator "Makefile", line 215: Need an operator "Makefile", line 216: Need an operator "Makefile", line 217: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /mnt/godfather/idealab/home/heather/cvs/wigwam-base. erie% gmake Making all in build-scripts gmake[1]: Entering directory `/mnt/godfather/idealab/home/heather/cvs/wigwam-base/build-scripts' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/mnt/godfather/idealab/home/heather/cvs/wigwam-base/build-scripts' Making all in misc-scripts gmake[1]: Entering directory `/mnt/godfather/idealab/home/heather/cvs/wigwam-base/misc-scripts' Makefile:203: *** missing separator. Stop. gmake[1]: Leaving directory `/mnt/godfather/idealab/home/heather/cvs/wigwam-base/misc-scripts' gmake: *** [all-recursive] Error 1 Am I just stupid? 6) gmake in just doc doesn't work -- even doing stuff which shouldn't need any dia conversions results in: erie% make process.ps ../misc-scripts/convert-sgml process.sgml ps:process.ps ../misc-scripts/convert-sgml: dia failed. dia output: dia output: Gtk-WARNING **: cannot open display: cat: /tmp/diaxserver-45535: No such file or directory usage: kill [-s signal_name] pid ... kill -l [exit_status] kill -signal_name pid ... kill -signal_number pid ... rm: /tmp/diaxserver-45535: No such file or directory *** Error code 1 Stop in /mnt/godfather/idealab/home/heather/cvs/wigwam-base/doc. erie% make wigwam.ps ../misc-scripts/convert-sgml wigwam.sgml ps:wigwam.ps ../misc-scripts/convert-sgml: dia failed. dia output: dia output: Gtk-WARNING **: cannot open display: cat: /tmp/diaxserver-45577: No such file or directory usage: kill [-s signal_name] pid ... kill -l [exit_status] kill -signal_name pid ... kill -signal_number pid ... rm: /tmp/diaxserver-45577: No such file or directory *** Error code 1 Why is dia being invoked in such a way that it requires a functioning X server from make? Ah. Because: wigwam-base (3.0.15) * Publication showstoppers fixed by mrad. * convert-sgml no longer requires an X server, even if dia is run, unless Xvfb is not available. And Xvfb appears not to be on erie. For the nonce, I conclude: "Dia blows". 'tany rate, does anyone have a current wigwam.ps that I can print out for myDave? He's experimenting with wigwam for a project and I want to incorporate the confusion he's having into the documentation. Or rather, some reduction of the confusion . . . Thanks, Heather ----- End forwarded message ----- |