Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
Toby == Toby Wintermute t...@wintrmute.net writes: Toby I still get a lot of test failures from OpenBSD and FreeBSD users on Toby CPANTS, and I think it's simply down to the postgres binaries being Toby installed in different locations. Toby If you run either of those systems, would you be able to tell me the Toby path to the executables? Toby On most Linux distros, they are in Toby /usr/lib/postgresql/$VERSION/bin FreeBSD puts them in a sane place: /usr/local/bin/psql etc. As I recall, OpenBSD ditto. Why the heck would people put bin stuff under a *lib* directory? That's just... insane. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
Toby == Toby Wintermute t...@wintrmute.net writes: Why the heck would people put bin stuff under a *lib* directory? That's just... insane. Toby Well, you can have multiple versions installed at once that way. Then Toby /usr/bin/ contains scripts that pass control to the appropriate Toby version binary based upon environment variables. Yeah, but lib is for ... libraries. Not bins. Also, picking bins based on env is about as silly as writing #!/usr/bin/env perl. *My* env is not necessarily *yours*. Put the right path there, please. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On 11 August 2014 15:48, Randal L. Schwartz mer...@stonehenge.com wrote: Toby == Toby Wintermute t...@wintrmute.net writes: Toby I still get a lot of test failures from OpenBSD and FreeBSD users on Toby CPANTS, and I think it's simply down to the postgres binaries being Toby installed in different locations. Toby If you run either of those systems, would you be able to tell me the Toby path to the executables? Toby On most Linux distros, they are in Toby /usr/lib/postgresql/$VERSION/bin FreeBSD puts them in a sane place: /usr/local/bin/psql etc. As I recall, OpenBSD ditto. Why the heck would people put bin stuff under a *lib* directory? That's just... insane. Well, you can have multiple versions installed at once that way. Then /usr/bin/ contains scripts that pass control to the appropriate version binary based upon environment variables.
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On 11 August 2014 16:21, Randal L. Schwartz mer...@stonehenge.com wrote: Toby == Toby Wintermute t...@wintrmute.net writes: Why the heck would people put bin stuff under a *lib* directory? That's just... insane. Toby Well, you can have multiple versions installed at once that way. Then Toby /usr/bin/ contains scripts that pass control to the appropriate Toby version binary based upon environment variables. Yeah, but lib is for ... libraries. Not bins. *throws hands in air* I'm not trying to defend the concept! you'd have to ask the Debian developers what they were thinking. Also, picking bins based on env is about as silly as writing #!/usr/bin/env perl. *My* env is not necessarily *yours*. Put the right path there, please. Maybe, but you have to admit that it is handy to have all the different postgres instances (on varying ports and PG versions) all listed and managed by single commands. (On Debian/Ubuntu boxes, there are meta commands that operate over all the instances, which I imagine is why they are split out of the path and then proxied back in)
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
Toby == Toby Wintermute t...@wintrmute.net writes: Toby *throws hands in air* I'm not trying to defend the concept! you'd have Toby to ask the Debian developers what they were thinking. Part of why I steer far clear from Linux. Why use a pretend Unix when you can use a real one? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On 11 August 2014 07:37, Randal L. Schwartz mer...@stonehenge.com wrote: Toby == Toby Wintermute t...@wintrmute.net writes: Toby *throws hands in air* I'm not trying to defend the concept! you'd have Toby to ask the Debian developers what they were thinking. Part of why I steer far clear from Linux. Why use a pretend Unix when you can use a real one? Because a real Unix would never have an binary executable under a lib directory. Certainly nothing like /usr/lib/sendmail! ;-) -- 4096R/EA75174B Steve Mynott steve.myn...@gmail.com
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On 11 August 2014 03:56, Toby Wintermute t...@wintrmute.net wrote: Hi, I took over Test::PostgreSQL a while back. I still get a lot of test failures from OpenBSD and FreeBSD users on CPANTS, and I think it's simply down to the postgres binaries being installed in different locations. If you run either of those systems, would you be able to tell me the path to the executables? On most Linux distros, they are in /usr/lib/postgresql/$VERSION/bin I wouldn't have asked London PM this question, mainly because it just wouldn't have occurred to me to do so*. Luckily you got the answer you wanted fairly quickly, despite the noise. London PM, still providing value after 16 years. :-) *My way of answering that question would have wasted a massive amount of time, because although web searches would have told me the answer, I wouldn't stop there. No, I would have thoroughly shaved this yak by installing one (or more) BSDs in VMs, installing PG, then testing the proposed changes in them. If my attention span had held out long enough.
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On Sun, Aug 10, 2014 at 11:37:35PM -0700, Randal L. Schwartz wrote: Why use a pretend Unix when you can use a real one? Because more stuff Just Works. HTH. -- David Cantrell | semi-evolved ape-thing Planckton: n, the smallest possible living thing
Re: Open/Free BSD users -- help needed to fix Test::PostgreSQL
On 11 August 2014 07:37, Randal L. Schwartz mer...@stonehenge.com wrote: Toby == Toby Wintermute t...@wintrmute.net writes: Toby *throws hands in air* I'm not trying to defend the concept! you'd have Toby to ask the Debian developers what they were thinking. Part of why I steer far clear from Linux. Why use a pretend Unix when you can use a real one? On that logic, why ActiveState or Strawberry Perl at all? Because people will insist on using these OSes, and it's worth at least trying to make sure your code works in as many environments as practical. Which is why CPANTS exists Dominic -- And a big Hiya goes out to the fun crew from GCHQ.
CPANTS and CPAN Testers (Was: Open/Free BSD users -- help needed to fix Test::PostgreSQL)
On Mon, Aug 11, 2014 at 03:08:40PM +0100, Dominic Thoreau wrote: Because people will insist on using these OSes, and it's worth at least trying to make sure your code works in as many environments as practical. Which is why CPANTS exists I hope this comes across as informative rather than picky, but I often see people confuse CPANTS and CPAN Testers. They're quite different. CPANTS looks at CPAN distributions from the outside using several heuristics to guess their quality: http://cpants.cpanauthors.org/ CPANTS is a centralised system that runs under the complete control of its maintainer(s). CPAN Testers collates the test output from CPAN distributions produced by a distributed set of volunteers who configure their systems to submit these reports: http://www.cpantesters.com/ If you run an unusual version of Perl, an unusual operating system or an unusual hardware platform, it's especially helpful if you can submit the output of any tests you run: http://wiki.cpantesters.org/wiki/QuickStart Sometimes people describe CPAN Testers as a competition to see who can submit the most test reports. Whilst this encourages the more prolific testers, the database also benefits from lots of people running tests on lots of different systems. It's worth considering whether you want to run it on your development system or a build machine: it's not just for high volume automated smokers. Tom
Ansible (was: Deploying perl code)
On Fri, 2014-07-25 at 12:08 +0200, James Laver wrote: On 25 Jul 2014, at 11:54, Andrew Beverley a...@andybev.com wrote: The main problem is that it seems to be a victim of its own success: there is a huge backlog of merge requests. I'd like to provide some simple patches to a couple of modules to make them work better for me, but have little hope that they'd be merged this side of Christmas. I provided a really simple patch a while ago - it's not been touched and now no longer merges cleanly. I won’t even try and submit a patch after my experience reporting a documentation bug. [...] So, I'm now fed-up with the way Ansible is being developed. However, I do like it as a tool, so wondered whether anybody has any interest in developing a Perl equivalent? Probably a layer on top of Tak to create a higher level playbook-type environment. Or does something similar already exist? Andy
Re: Ansible (was: Deploying perl code)
does [a Perl equivalent to Ansible] already exist? I think Rex fits the bill:http://blog.kablamo.org/2013/11/22/rex/ -- Pierre Masci
Re: Ansible (was: Deploying perl code)
Have you looked at Rex? They have pretty good docs: http://rexify.org Its a deployment type tool vaguely like ansible/puppet/chef/salt/whatever and its written in Perl and it looks pretty nice. I've personally never used Rex for real anywhere though. I wrote up a little intro to using rex (the comments might be interesting too): http://blog.kablamo.org/2013/11/22/rex/ On Mon, Aug 11, 2014 at 9:37 AM, Andrew Beverley a...@andybev.com wrote: On Fri, 2014-07-25 at 12:08 +0200, James Laver wrote: On 25 Jul 2014, at 11:54, Andrew Beverley a...@andybev.com wrote: The main problem is that it seems to be a victim of its own success: there is a huge backlog of merge requests. I'd like to provide some simple patches to a couple of modules to make them work better for me, but have little hope that they'd be merged this side of Christmas. I provided a really simple patch a while ago - it's not been touched and now no longer merges cleanly. I won't even try and submit a patch after my experience reporting a documentation bug. [...] So, I'm now fed-up with the way Ansible is being developed. However, I do like it as a tool, so wondered whether anybody has any interest in developing a Perl equivalent? Probably a layer on top of Tak to create a higher level playbook-type environment. Or does something similar already exist? Andy
Re: Ansible (was: Deploying perl code)
On Mon, 2014-08-11 at 10:43 -0500, Eric Johnson wrote: Have you looked at Rex? They have pretty good docs: http://rexify.org Thanks Eric (and Pierre) - no, I hadn't come across that. I'll have a play with it and see how it is - looks very promising though. Its a deployment type tool vaguely like ansible/puppet/chef/salt/whatever and its written in Perl and it looks pretty nice. I've personally never used Rex for real anywhere though. I wrote up a little intro to using rex (the comments might be interesting too): http://blog.kablamo.org/2013/11/22/rex/ Great article - thanks for that. Andy
Re: CPANTS and CPAN Testers (Was: Open/Free BSD users -- help needed to fix Test::PostgreSQL)
Tom Hukins writes: CPAN Testers ... the database also benefits from lots of people running tests on lots of different systems. It's worth considering whether you want to run it on your development system or a build machine: it's not just for high volume automated smokers. Or, if you're a cpanm user, simply run cpanm-reporter shortly after each time you install — or fail to install — a module. cpanm-reporter is very easy to use, even if you know nothing about Cpan Testers or what reporting test results involves. On first run it asks a few easy questions, such as for your email address; thereafter it just works. Install it with: $ cpanm App::cpanminus::reporter Smylers -- http://twitter.com/Smylers2
