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: fess <fe...@dd...> - 2004-03-26 00:48:13
|
On Mar 25, 2004, at 4:45 PM, fess wrote: > > download unpack build install reinstall For the phases I mean to say: download unpack build install reinstall upgrade and uninstall --fess |
From: fess <fe...@dd...> - 2004-03-26 00:45:10
|
I've been thinking for some time, that the packaging system for wigwam, should be a sort of meta packaging system to which other type packages could be added. We basically have this in wigwam 4. you can build a package that provides how to build and install any new package type. but even at this stage, packages have to conform to at least having certain files, such as the files file and the md5sums file, and all types are expected to have, description, and synopsis, ect.. in other words there is some meta information that all types of packaging systems provide. In order to implement a new type package you provide a package that provides the methods from the wigwam 4 package pipeline, download unpack build install reinstall I was thinking that the packaging API should be extended and that providers of new package types should also provide methods to access other standard information, such as the manifest, the maintainer, the synopsis. this way rpm type packages, wouldn't have to have the synopsis in the RPM, and in the synopsis file. or wouldn't have to have an installed_files file, because that info is also in the RPM. When I start thinking about manifests, I realize that source based packages can't really produce a manifest, until they are made binary, because on different architectures different files are sometimes produced. So, I realize I don't much like our source based packaging, because the packaging system doesn't have a binary intermediate form, in which the manifest, and other state ( md5sums, permission, ownership, ) are known about the file and installed into a database of installed stuff, by the packaging system when it installs. slightly related, I ran into build buddy, or the Ximian Build System, it has this very cool concept of a meta package description file, which has all the things common to many packaging systems, and from it can be built the package description files of other packages. and therefore other packages. Ximian uses it to make RPMs for different distro's and Debs, and RPMS for sun, ect.. http://primates.ximian.com/~thunder/bb/doc/bb-overview.txt this meta info file for making packages, will already have organized all the things you might want in a package API, for the information retrieval methods I mentioned above. ok.. enough stream of consciousness. --fess |
From: Michael R. <mr...@bl...> - 2004-03-23 01:34:34
|
fess writes: > also, the code seems to indicate that version 20.1 should be in the > set [10,20] this seems wrong, how does one specify a set that doesn't > include 20.1? > is it [10,20.0.0.0.0] ? It seems to me that in this case, the package > should specify [10,21) or [10,20.2) or [10,20.1] depending on what is > desired. IMO, (20.1 in [10,20]) is completely justified since usually "version 20" means "version 20.x" when a package has minor revisions. (But, I have nothing to do with versiontool, so that's just my uninformed opinion.) You are right, though, it seems like it's asking for trouble, or at least confusion, if a package lists a dependency version spec that doesn't have as many components as the other package's numbering scheme. Mike |
From: fess <fe...@fe...> - 2004-03-22 23:02:43
|
It looks like versiontool is broken still, since 3.0.49, the '*' seems to have stopped working, admittedly using the '*' is frowned upon in favor of using an empty string in the set notation [12,*) => [12,) however there are many packages that use this notation still. use of the '*' notation fails in two ways: The following completely hang, ( at least on my osx build ): versiontool test '[1.17-1,*)' 311.99 versiontool test '[1,*)' 311.99 versiontool test '[1,*)' 1.1 versiontool test '[1.17-1,*)' 11.19 versiontool test '[1.0,*)' 2.2 the following just give the wrong results: versiontool test '[1.17-1,*)' 1.19 versiontool test '[1.0,*)' 1.2 also, the code seems to indicate that version 20.1 should be in the set [10,20] this seems wrong, how does one specify a set that doesn't include 20.1? is it [10,20.0.0.0.0] ? It seems to me that in this case, the package should specify [10,21) or [10,20.2) or [10,20.1] depending on what is desired. Chris wonders if we can use the wigwam4 versiontool, to fix these problems, but I don't think wigwam4 is using a versiontool. it's using a perl library. perhaps a new versiontool can be written around that. as it stands now, wigwam [3.0.49,4.0) breaks existing projects. --fess |
From: fess <fe...@dd...> - 2004-03-10 17:31:41
|
[bcc'd internal overture distrobution list] As some of you know. Overture has had someone working on Documentation for wigwam 4. In order to have this process cycle more quickly. We're now placing drafts of that documentation on the wigwam-framework.org website. For those of you who haven't been participating in the wigwam 4 efforts, here's your chance to figure out the new stuff, and start improving it. Please review this documentation and give as much feedback as possible to the wigwam-devel list, or to Susan Woster directly. ( contact me for email addy. ) Thanks. --fess |
From: Paul M. <pmi...@he...> - 2004-02-26 17:19:48
|
On Wed, 25 Feb 2004, Tod E. Kurt wrote: > 1. Is there a more fine-grained way of saying "just build and install > this one in-project package"? packagectl reinstall packagename > 2. Is there a way to disable the syncing that 'packagectl' seems to do > at the drop of a hat? export WIGWAM_PACKAGECTL_NO_AUTO_SYNC=1 > 3. Is there a somewhat elegant way to route-around 'packagectl' so I > can just install the in-project package myself, without going through > all the crap that 'packagectl' does? no. > 4. How does everyone else deal with this problem? I can't really > believe that people put up with a 150 second delay between file save > and script run. i often have a 'make check' target that i can run directly from src/ -- p Sharing a market with Microsoft is like sharing a banana with a monkey. Take a piece and he'll sling his poop at you. |
From: Tod E. K. <to...@to...> - 2004-02-26 00:40:40
|
How do people efficiently develop in Wigwam4? I have a project that contains 3 in-project packages and uses a private package archive in addition to the public package archive. I'm quite frustrated at the additional lag time that is introduced into the edit->test->edit cycle. It went from a few seconds to 2.5 minutes! For instance, making a one-line change to a Perl module that is part of an in-project package and then running a test script that exercises that module now takes > 2 minutes because of the inordinate amount of time that 'packagectl update-packages' takes, uninstalls all my in-project packages, re-installs all my in project packages, probably syncing for each package. So: 1. Is there a more fine-grained way of saying "just build and install this one in-project package"? 2. Is there a way to disable the syncing that 'packagectl' seems to do at the drop of a hat? 3. Is there a somewhat elegant way to route-around 'packagectl' so I can just install the in-project package myself, without going through all the crap that 'packagectl' does? 4. How does everyone else deal with this problem? I can't really believe that people put up with a 150 second delay between file save and script run. |
From: Tod E. K. <to...@to...> - 2004-02-20 22:32:48
|
I'm using wigwam4. I've installed the package 'cricket-1.0.4pre2-2' thinking it was the latest one. I've since learned 'cricket-1.04-2' is really the latest one. A 'packagectl upgrade cricket' does nothing. So I try: % packagectl uninstall cricket Fatal: plan: can't satisfy constraints at /home/tod/projects/Linux/mondemand/ext/libexec/packagectl/plan line 1149. Fatal: packagectl: can't satisfy constraints - What does that error message mean? It makes no sense. - Does 'packagectl' think there's some dependency on cricket? (I'm not aware of one in my project. ) - If it is a dependency failure, why doesn't it say what the dependency is? - Is there a '--force' option to ignore dependencies? - How do I get out of this predicament? |
From: fess <fe...@dd...> - 2004-02-20 21:18:59
|
So, we recently visited with the authors of another packaging system, and picked up this good little tidbit. when packaging something like mod_perl which depends on apache, we tend to specify dependancies like this: apache [1.29,) meaning all versions of apache greater than or equal to 1.29, where as a much better idea when we're not in control of the source we're packaing is to specify the deps like this: apache [1.29,2.0) which means any version greater than or equal to 1.29 and less than 2.0 this is probably more accurate more of the time than the first approach. just an idea for those of you packaging things out there. |
From: Paul M. <pmi...@he...> - 2004-02-20 03:09:32
|
ok, generally, services in wigwam4 install into ext/services w/o a version number, e.g., for the btr-server project it looks like: pmineiro@zzyzx-3% ls ext/services ~/src/btr-server btr-init/ relay-master-secondary-sync-stunnel/ btr-update/ relay-master-stunnel/ gossip_master/ relay-master-sync-stunnel/ gossip_relay/ relay-stunnel/ gossip_slave/ slave-relay-sync-stunnel/ master-stunnel/ ----- so i suspect a wigwam4 bug and/or a package bug. -- p On Thu, 19 Feb 2004, Christopher B. Liebman wrote: > And the real one is broken too!!! there is a envar that gets expanded > during "install" in a here document creating the ping script... thus > 'test -f' with no file!!! I should be able to fix this tonight. > > -- Chris > > > On Thu, 2004-02-19 at 15:51, Tod E. Kurt wrote: > > It looks like some sort of install problem with the service wrt version > > numbers. > > > > % ls $PLAYPEN_ROOT/ext/services > > apache/ mod_perl/ mod_perl-0.2-1/ > > > > Why are there two service directories for mod_perl? Is this expected? > > > > % cat $PLAYPEN_ROOT/ext/services/mod_perl/ping > > #! /bin/sh > > /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping > > > > If it's proper to have two directories (one general, one versioned), > > why doesn't the above have the version in it? It has a partial, > > leading me to believe that it should insert the version number but the > > variable is blank. > > > > % cat $PLAYPEN_ROOT/ext/services/mod_perl-0.2-1/ping > > #!/bin/sh > > test -f || exit 1 > > exit 0 > > > > Ahh, here's the real ping for mod_perl. > > > > So what's the dealio? Should there be two service dirs for mod_perl, > > one versioned and one not? If so, why does the non-versioned script > > have an incomplete reference to the versioned one? And actually, where > > do these 'ping' scripts come from? They're not part of the package. > > > > > > > > On Feb 19, 2004, at 9:19 AM, Paul Mineiro wrote: > > > > > this is chris's new apache package ... dunno if this has been vetted > > > wrt > > > wigwam4. > > > > > > -- p > > > > > > On Wed, 18 Feb 2004, Tod E. Kurt wrote: > > > > > >> I'm getting a weird problem where 'statusctl' is trying to 'ping' > > >> mod_perl. > > >> > > >> For example, in a brand new project: > > >> > > >> % wigwam-bootstrap-4.1.0 --project=todtest3 > > >> % cd todtest3 > > >> % ./autogen.sh ; . ./setup-env > > >> % packagectl install service_apache_add_mod_perl > > >> % echo '# service_apache config \ > > >> APACHE_HOSTNAME=${APACHE_HOSTNAME="foo"} \ > > >> APACHE_PORT=${APACHE_PORT="62260"} \ > > >> APACHE_ADMIN=${APACHE_ADMIN="to...@ov..."} \ > > >> LOG_DIR=${LOG_DIR="$LOCAL_VAR"} \ > > >> ' > etc/project.conf > > >> % servicectl status > > >> Info: apache ping: checking pid file ... not running. > > >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl/ping: > > >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping: No such > > >> file or directory > > >> > > >> > > >> WTF? > > >> > > >> -=tod > > >> > > >> > > >> > > >> ------------------------------------------------------- > > >> SF.Net is sponsored by: Speed Start Your Linux Apps Now. > > >> Build and deploy apps & Web services for Linux with > > >> a free DVD software kit from IBM. Click Now! > > >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > > >> _______________________________________________ > > >> Wigwam-devel mailing list > > >> Wig...@li... > > >> https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > >> > > > > > > I don't want to have to buy MS brand toilet paper one day to make > > > my ass compatible. > > > > > > > > ------------------------------------------------------- > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > > Build and deploy apps & Web services for Linux with > > a free DVD software kit from IBM. Click Now! > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > I don't want to have to buy MS brand toilet paper one day to make my ass compatible. |
From: Christopher B. L. <li...@zo...> - 2004-02-20 00:01:19
|
And the real one is broken too!!! there is a envar that gets expanded during "install" in a here document creating the ping script... thus 'test -f' with no file!!! I should be able to fix this tonight. -- Chris On Thu, 2004-02-19 at 15:51, Tod E. Kurt wrote: > It looks like some sort of install problem with the service wrt version > numbers. > > % ls $PLAYPEN_ROOT/ext/services > apache/ mod_perl/ mod_perl-0.2-1/ > > Why are there two service directories for mod_perl? Is this expected? > > % cat $PLAYPEN_ROOT/ext/services/mod_perl/ping > #! /bin/sh > /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping > > If it's proper to have two directories (one general, one versioned), > why doesn't the above have the version in it? It has a partial, > leading me to believe that it should insert the version number but the > variable is blank. > > % cat $PLAYPEN_ROOT/ext/services/mod_perl-0.2-1/ping > #!/bin/sh > test -f || exit 1 > exit 0 > > Ahh, here's the real ping for mod_perl. > > So what's the dealio? Should there be two service dirs for mod_perl, > one versioned and one not? If so, why does the non-versioned script > have an incomplete reference to the versioned one? And actually, where > do these 'ping' scripts come from? They're not part of the package. > > > > On Feb 19, 2004, at 9:19 AM, Paul Mineiro wrote: > > > this is chris's new apache package ... dunno if this has been vetted > > wrt > > wigwam4. > > > > -- p > > > > On Wed, 18 Feb 2004, Tod E. Kurt wrote: > > > >> I'm getting a weird problem where 'statusctl' is trying to 'ping' > >> mod_perl. > >> > >> For example, in a brand new project: > >> > >> % wigwam-bootstrap-4.1.0 --project=todtest3 > >> % cd todtest3 > >> % ./autogen.sh ; . ./setup-env > >> % packagectl install service_apache_add_mod_perl > >> % echo '# service_apache config \ > >> APACHE_HOSTNAME=${APACHE_HOSTNAME="foo"} \ > >> APACHE_PORT=${APACHE_PORT="62260"} \ > >> APACHE_ADMIN=${APACHE_ADMIN="to...@ov..."} \ > >> LOG_DIR=${LOG_DIR="$LOCAL_VAR"} \ > >> ' > etc/project.conf > >> % servicectl status > >> Info: apache ping: checking pid file ... not running. > >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl/ping: > >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping: No such > >> file or directory > >> > >> > >> WTF? > >> > >> -=tod > >> > >> > >> > >> ------------------------------------------------------- > >> SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >> Build and deploy apps & Web services for Linux with > >> a free DVD software kit from IBM. Click Now! > >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >> _______________________________________________ > >> Wigwam-devel mailing list > >> Wig...@li... > >> https://lists.sourceforge.net/lists/listinfo/wigwam-devel > >> > > > > I don't want to have to buy MS brand toilet paper one day to make > > my ass compatible. > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: Tod E. K. <to...@to...> - 2004-02-19 23:56:51
|
It looks like some sort of install problem with the service wrt version numbers. % ls $PLAYPEN_ROOT/ext/services apache/ mod_perl/ mod_perl-0.2-1/ Why are there two service directories for mod_perl? Is this expected? % cat $PLAYPEN_ROOT/ext/services/mod_perl/ping #! /bin/sh /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping If it's proper to have two directories (one general, one versioned), why doesn't the above have the version in it? It has a partial, leading me to believe that it should insert the version number but the variable is blank. % cat $PLAYPEN_ROOT/ext/services/mod_perl-0.2-1/ping #!/bin/sh test -f || exit 1 exit 0 Ahh, here's the real ping for mod_perl. So what's the dealio? Should there be two service dirs for mod_perl, one versioned and one not? If so, why does the non-versioned script have an incomplete reference to the versioned one? And actually, where do these 'ping' scripts come from? They're not part of the package. On Feb 19, 2004, at 9:19 AM, Paul Mineiro wrote: > this is chris's new apache package ... dunno if this has been vetted > wrt > wigwam4. > > -- p > > On Wed, 18 Feb 2004, Tod E. Kurt wrote: > >> I'm getting a weird problem where 'statusctl' is trying to 'ping' >> mod_perl. >> >> For example, in a brand new project: >> >> % wigwam-bootstrap-4.1.0 --project=todtest3 >> % cd todtest3 >> % ./autogen.sh ; . ./setup-env >> % packagectl install service_apache_add_mod_perl >> % echo '# service_apache config \ >> APACHE_HOSTNAME=${APACHE_HOSTNAME="foo"} \ >> APACHE_PORT=${APACHE_PORT="62260"} \ >> APACHE_ADMIN=${APACHE_ADMIN="to...@ov..."} \ >> LOG_DIR=${LOG_DIR="$LOCAL_VAR"} \ >> ' > etc/project.conf >> % servicectl status >> Info: apache ping: checking pid file ... not running. >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl/ping: >> /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping: No such >> file or directory >> >> >> WTF? >> >> -=tod >> >> >> >> ------------------------------------------------------- >> SF.Net is sponsored by: Speed Start Your Linux Apps Now. >> Build and deploy apps & Web services for Linux with >> a free DVD software kit from IBM. Click Now! >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >> _______________________________________________ >> Wigwam-devel mailing list >> Wig...@li... >> https://lists.sourceforge.net/lists/listinfo/wigwam-devel >> > > I don't want to have to buy MS brand toilet paper one day to make > my ass compatible. |
From: fess <fe...@ov...> - 2004-02-19 18:18:21
|
> Nope! I did the upgrade to 1.0.4-2 (which, annoyingly, sorts as > "older" than 1.0.4pre2-1 and pre2-2), this comment reminded me, our version sorting enforces some policy about versions, but it's not stated in the docs, and should be. Could someone research this, and answer some of the following questions: - what is our current policy with respects to package version number formats. + how are packages with pre, r1, other text in the name sorted? + how should timestamp based version numbers be stated for nightly builds and from cvs builds. - is wigwam3 the same as wigwam4 in this respect. - are there any improvements that should be made to the current policy? It may be worth looking at debians package version number format http://www.debian.de/doc/debian-policy/ch-controlfields.html#s-f- Version and it would be nice to know what RPM does for it's version number format and for sorting, but I couldn't quickly find that info. --fess |
From: Paul M. <pmi...@he...> - 2004-02-19 17:25:04
|
this is chris's new apache package ... dunno if this has been vetted wrt wigwam4. -- p On Wed, 18 Feb 2004, Tod E. Kurt wrote: > I'm getting a weird problem where 'statusctl' is trying to 'ping' > mod_perl. > > For example, in a brand new project: > > % wigwam-bootstrap-4.1.0 --project=todtest3 > % cd todtest3 > % ./autogen.sh ; . ./setup-env > % packagectl install service_apache_add_mod_perl > % echo '# service_apache config \ > APACHE_HOSTNAME=${APACHE_HOSTNAME="foo"} \ > APACHE_PORT=${APACHE_PORT="62260"} \ > APACHE_ADMIN=${APACHE_ADMIN="to...@ov..."} \ > LOG_DIR=${LOG_DIR="$LOCAL_VAR"} \ > ' > etc/project.conf > % servicectl status > Info: apache ping: checking pid file ... not running. > /home/tod/projects/Linux/todtest3/ext/services/mod_perl/ping: > /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping: No such > file or directory > > > WTF? > > -=tod > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > I don't want to have to buy MS brand toilet paper one day to make my ass compatible. |
From: Tod E. K. <to...@to...> - 2004-02-19 01:23:08
|
I'm getting a weird problem where 'statusctl' is trying to 'ping' mod_perl. For example, in a brand new project: % wigwam-bootstrap-4.1.0 --project=todtest3 % cd todtest3 % ./autogen.sh ; . ./setup-env % packagectl install service_apache_add_mod_perl % echo '# service_apache config \ APACHE_HOSTNAME=${APACHE_HOSTNAME="foo"} \ APACHE_PORT=${APACHE_PORT="62260"} \ APACHE_ADMIN=${APACHE_ADMIN="to...@ov..."} \ LOG_DIR=${LOG_DIR="$LOCAL_VAR"} \ ' > etc/project.conf % servicectl status Info: apache ping: checking pid file ... not running. /home/tod/projects/Linux/todtest3/ext/services/mod_perl/ping: /home/tod/projects/Linux/todtest3/ext/services/mod_perl-/ping: No such file or directory WTF? -=tod |
From: Michael R. <mr...@bl...> - 2004-02-14 01:31:54
|
Ah, turns out that binmode (FILEHANDLE) does what we want without resorting to any 5.8-specific features. The fix is committed. That's funny, leave it to perl 5.8 to make us have to use binmode() on a unix system. (Overall, I am very displeased with the number of horribly incompatible changes perl 5.8 has introduced. Anyone else run afoul of "vstrings"?) But I guess in this specific case, binmode() was the right thing to do anyway (in case diff-playpens ever gets ported to windows, or whatever)... Mike Paul Mineiro writes: > On Fri, 13 Feb 2004, Michael Radford wrote: > > > So maybe setting LANG is simpler; I was just nervous that it might have > > unintended consequences, and explicitly asking for the raw i/o layer > > seemed to be exactly what we want. > > i'd rather ask for what we want. the LANG thing was because i couldn't > figure out the right way to do it. > > > > >It looks like the correct solution is to detect perl >= 5.8 and then > > > >explicitly call open ($fh, "<:unix", $file) or > > > >open ($fh, "<:stdio", $file). > > what would this look like ... and does it require pragmas that are not > perl 5.005 ? > > -- p > > I don't want to have to buy MS brand toilet paper one day to make > my ass compatible. |
From: Paul M. <pmi...@he...> - 2004-02-14 01:04:53
|
On Fri, 13 Feb 2004, Michael Radford wrote: > So maybe setting LANG is simpler; I was just nervous that it might have > unintended consequences, and explicitly asking for the raw i/o layer > seemed to be exactly what we want. i'd rather ask for what we want. the LANG thing was because i couldn't figure out the right way to do it. > > >It looks like the correct solution is to detect perl >= 5.8 and then > > >explicitly call open ($fh, "<:unix", $file) or > > >open ($fh, "<:stdio", $file). what would this look like ... and does it require pragmas that are not perl 5.005 ? -- p I don't want to have to buy MS brand toilet paper one day to make my ass compatible. |
From: Michael R. <mr...@bl...> - 2004-02-14 00:37:46
|
fess writes: > how positive are you on this LANG interactions? Not completely, just forwarding a report that changing LANG from "en_US.UTF-8" to "en_US" fixed it. > I know that we didn't know how to handle it across multiple versions of > perl > for the perl uwget, so we set LANG="C" before any call to it. > > anyhow sounds like a good solution, does it work with old perls? No, PerlIO is only in >= 5.8. That's why we'd have to check the perl version first. So maybe setting LANG is simpler; I was just nervous that it might have unintended consequences, and explicitly asking for the raw i/o layer seemed to be exactly what we want. Mike > On Feb 13, 2004, at 11:16 AM, Michael Radford wrote: > > >On one of our clusters, the environment variable LANG was set by > >default to "en_US.UTF-8"... > > > >This apparently causes perl >= 5.8 to open filehandles with the ":utf8" > >I/O layer (see manpages for perlfunc, PerlIO), and so > >ext/bin/publish/diff-playpens fails complaining about malformed UTF-8. > > > >An easy solution is just to set LANG=en_US. However, it seems like > >diff-playpens should treat everything as binary no matter what. > > > >It looks like the correct solution is to detect perl >= 5.8 and then > >explicitly call open ($fh, "<:unix", $file) or > >open ($fh, "<:stdio", $file). > > > >I can get to this eventually, but if anyone cares to beat me to it, > >feel free... :) > > > >Mike > > > > > >------------------------------------------------------- > >SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >Build and deploy apps & Web services for Linux with > >a free DVD software kit from IBM. Click Now! > >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >_______________________________________________ > >Wigwam-devel mailing list > >Wig...@li... > >https://lists.sourceforge.net/lists/listinfo/wigwam-devel > |
From: fess <fe...@dd...> - 2004-02-13 19:32:04
|
how positive are you on this LANG interactions? I know that we didn't know how to handle it across multiple versions of perl for the perl uwget, so we set LANG="C" before any call to it. anyhow sounds like a good solution, does it work with old perls? --fess On Feb 13, 2004, at 11:16 AM, Michael Radford wrote: > On one of our clusters, the environment variable LANG was set by > default to "en_US.UTF-8"... > > This apparently causes perl >= 5.8 to open filehandles with the ":utf8" > I/O layer (see manpages for perlfunc, PerlIO), and so > ext/bin/publish/diff-playpens fails complaining about malformed UTF-8. > > An easy solution is just to set LANG=en_US. However, it seems like > diff-playpens should treat everything as binary no matter what. > > It looks like the correct solution is to detect perl >= 5.8 and then > explicitly call open ($fh, "<:unix", $file) or > open ($fh, "<:stdio", $file). > > I can get to this eventually, but if anyone cares to beat me to it, > feel free... :) > > Mike > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: Michael R. <mr...@bl...> - 2004-02-13 19:18:26
|
On one of our clusters, the environment variable LANG was set by default to "en_US.UTF-8"... This apparently causes perl >= 5.8 to open filehandles with the ":utf8" I/O layer (see manpages for perlfunc, PerlIO), and so ext/bin/publish/diff-playpens fails complaining about malformed UTF-8. An easy solution is just to set LANG=en_US. However, it seems like diff-playpens should treat everything as binary no matter what. It looks like the correct solution is to detect perl >= 5.8 and then explicitly call open ($fh, "<:unix", $file) or open ($fh, "<:stdio", $file). I can get to this eventually, but if anyone cares to beat me to it, feel free... :) Mike |
From: Michael L. <mi...@mi...> - 2004-02-07 03:24:59
|
Maybe if you try to do a 'projectctl build' on the package archive and when the package archive inspects itself, it will either a) ignore this "bad" package, or b) print a warning so that you and any other package maintainer can see that this package isn't up to spec. And I used to put the .md5sums file in the .md5sums file, but I found that I needed to md5sum the .md5sums file twice, since md5summing the .md5sums file will change its content, and change its md5sum, requiring me to md5sum it again. Anyone else have this happen to them? Michael Radford wrote: > Surely the .files file is supposed to be in itself, but I don't know if > wigwam-base should complain. Ideally we would complain to the packager, > not the end user. > > Maybe we should start talking about stricter package policies for > wigwam4 (for the public archive at least). > > Also, I'd like to see the .md5sums file in the .md5sums file. :) > > Mike > > fess writes: > >>what's the "correct way" ? >>well I can only assume that since we have the files seperate >>from the md5sums that it was intended that the .files file was >>intended to have an md5sum in the md5sums file, and the way the >>md5sums helper tools work, I have to assume that it was intended >>that the .files file be listed in the .files file. >> >> >>opinions on how best to handle this situation? >> >>options: >> 1. just leave things as they are >> 2. have the md5sums tools warn if there is no .files file >> in the files file. >> 3. do number 2 as well as have wigwam-base complain if >> there is no md5sum for the files file. >> >> >>--fess >> >> >> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by EclipseCon 2004 >>Premiere Conference on Open Tools Development and Integration >>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>http://www.eclipsecon.org/osdn >>_______________________________________________ >>Wigwam-devel mailing list >>Wig...@li... >>https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: Michael L. <mi...@mi...> - 2004-02-07 03:19:46
|
i'm also in this camp, since the tarball's what we're really after, and that *is* in .md5sums so changing the .urls is "safe", and sometimes perhaps desired, should a certain package need to be rebuilt from scratch without an available mirror. fess wrote: > > On Feb 3, 2004, at 4:26 PM, Dave Benson wrote: > >> No, but i'm not sure where else i'd put it... >> >> Actually, looking at it a bit, i think there's >> no technical reason at all to list .urls in >> the .files and .md5sums files. if we didn't list it, >> it might alleviate my chief concern, and it would >> leave existing tools as is (like cheesy-upgrade and >> rebuild-package-archive would still work) > > > I agree, there are some packages that do not list the urls file in the > md5sums file > or the files file, so I'm all for that being the new best practice. > > and I'm in the "only the urls file should change camp" > > --fess > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: Michael R. <mr...@bl...> - 2004-02-06 18:14:55
|
Surely the .files file is supposed to be in itself, but I don't know if wigwam-base should complain. Ideally we would complain to the packager, not the end user. Maybe we should start talking about stricter package policies for wigwam4 (for the public archive at least). Also, I'd like to see the .md5sums file in the .md5sums file. :) Mike fess writes: > what's the "correct way" ? > well I can only assume that since we have the files seperate > from the md5sums that it was intended that the .files file was > intended to have an md5sum in the md5sums file, and the way the > md5sums helper tools work, I have to assume that it was intended > that the .files file be listed in the .files file. > > > opinions on how best to handle this situation? > > options: > 1. just leave things as they are > 2. have the md5sums tools warn if there is no .files file > in the files file. > 3. do number 2 as well as have wigwam-base complain if > there is no md5sum for the files file. > > > --fess > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: fess <fe...@ov...> - 2004-02-06 18:05:02
|
It looks like some packages list the .files file in their .files file, and some don't. the make-package-md5sums programs only md5sum those files that are in the .files file. wigwam4 and wigwam3 (I think 3) only check the md5sums on on things in the .files file, so if you list it it gets verified if you don't list it it just works but doesn't get checked. what's the "correct way" ? well I can only assume that since we have the files seperate from the md5sums that it was intended that the .files file was intended to have an md5sum in the md5sums file, and the way the md5sums helper tools work, I have to assume that it was intended that the .files file be listed in the .files file. opinions on how best to handle this situation? options: 1. just leave things as they are 2. have the md5sums tools warn if there is no .files file in the files file. 3. do number 2 as well as have wigwam-base complain if there is no md5sum for the files file. --fess |
From: fess <fe...@dd...> - 2004-02-05 20:03:12
|
so rebuild-package-list has this "feature" about bad packages where it reads a file src/bad_packages and presumably does not list those as a "bad" package. if that's the correct assumption, it doesn't actually work at all. because the bad_packages is parsed by a grep -v '^[^#]' piped to a while. this has two problems, the grep is like a double negative and only pulls out lines that have comments, and the pipe to while causes a subshell, and so the fact that the bad packages check was built up is ignored by the main shell. so, I've got that fixed, but I have a few questions about bad_packages. 1. is my assumption above correct about how it should work. 2. how is this "bad_packages" list any different than cvs removing the package? not being in the package list effectively makes it un-useable, but not removing it from cvs just makes it take up space. 3. does it make sense for the bad_packages list to be stored in $PLAYPEN_ROOT/src/bad_packages it would seem to me like this file should be in etc/ --fess |