A Tale of Two Taints
You guys both have modules on CPAN called Taint. If I try to install Dan's (0.07, just uploaded) I get Tom's (0.09, from Oct 1997). Tom, if yours is no longer usable (and it fails tests with 5.6.1 & 5.8.0), may I humbly suggest removing it and giving the namespace registration to Dan? Otherwise, Dan, could you change the name of your module? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Please delete DateTime-Locale 0.90 ASAP
I meant to make this a trial release. As is, it will break DateTime's tests, which is bad. I've scheduled it for deletion from PAUSE but deleting it right now would be much better. Thanks, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Don't worry about DateTime::Locale
I realized the best thing to do was just to release a newer version with the breaking changes reverted, so I did that. No need to delete anything. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Oops ...
I gave up primary on Pg::DatabaseManager when I meant to transfer it to ADOPTME. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Oops ...
On Tue, 7 Jun 2016, Neil Bowers wrote: Hi Dave, I gave up primary on Pg::DatabaseManager when I meant to transfer it to ADOPTME. I did the following: 1. dropped your co-maint permissions on Pg::DatabaseManager and Pg::DatabaseManager::TestMigrations 2. forced re-indexing on Pg-DatabaseManager. Because no-one had any permissions, you got first-come permissions back 3. transferred the first-come permissions to ADOPTME for both modules You got co-maint on both. You can give those permissions up if you want. Thanks, I appreciate it! Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Take over request - MooseX::Types::PortNumber
I reported a serious (but trivial to fix) packaging bug 2 years ago with no response. See https://rt.cpan.org/Ticket/Display.html?id=97634 The author's last CPAN upload was in 2013. I haven't written email to him directly, but I could, or I could just fix this distro. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Take over request - MooseX::Types::PortNumber
On Mon, 15 Aug 2016, David Golden wrote: Please email a takeover request directly to the author. That might get noticed in a way a bug report might not. Done. That said, I do think we give original authors a little too much control here. In the case where the author has stopped releasing things to CPAN, insisting that we try to track them down personally outside of using the existing bug reporting mechanisms seems a little much. I'm not sure how we can best have that conversation as a community. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
re: MX::Types::PortNumber takeover
I tried to email Thiago's address per CPAN (thi...@aware.com.br) and got this bounce. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ -- Forwarded message -- Date: Mon, 15 Aug 2016 17:29:49 From: Mail Delivery System To: auta...@urth.org Subject: Undelivered Mail Returned to Sender This is the mail system at host urth.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : Host or domain name not found. Name service error for name=aware.com.br type=: Host not foundReporting-MTA: dns; urth.org X-Postfix-Queue-ID: 31732D654 X-Postfix-Sender: rfc822; autarch@urth.org Arrival-Date: Mon, 15 Aug 2016 22:29:49 + (UTC) Final-Recipient: rfc822; thiago@aware.com.br Original-Recipient: rfc822;thiago@aware.com.br Action: failed Status: 5.4.4 Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error for name=aware.com.br type=: Host not found --- Begin Message --- Hi Thiago, I'd like to maintain this since we use it at work and the current bugs are causing some problems. Please let me know if that's ok with you. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ --- End Message ---
Re: Cleaning up author directories
On Sat, 16 Jul 2016, Neil Bowers wrote: You may have seen my blog post asking people to delete old releases from their author directory: http://blogs.perl.org/users/neilb/2016/07/please-delete-old-releases-from-your-cpan-directory.html Deleting old releases of Code-TidyAll would free up nearly 50M, plus you’ve got a lot of old releases for your other dists. Would you be happy to spring clean your author directory please? You could do it yourself, or you could give me permission to do it on your behalf. I finally remembered I have a script for this, so I ran it and it scheduled 1006 files for deletion. Cheers, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: [lsst-sqre/jenkins-dm-jobs] add "clean" build jobs (#189)
The problem with deploying from Travis is going to be that PAUSE doesn't really have an API, so you would have to store some sort of PAUSE username/pw in a way Travis can access. That means the releases are still tied to an account. Of course, you can make a "Foo group" account and share the credentials, but it's a pretty gross solution. FWIW I've found that using Dist::Zilla has made releases easy enough to not want even think about automating it further. Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch On Fri, Aug 16, 2019 at 6:22 PM Joshua Hoblitt wrote: > Hi Nick, > > Clearly, I've dropped the ball on updating this module. I think it would > be reasonable to add Dave Rolsky as an official co-maintainer, so I am not > a single point of failure. However, what I'd really like to see happen is > someone PR deployment to cpan via travis, upon push of a tag, from > https://github.com/jhoblitt/DateTime-HiRes rather than ping-ponging > around who can actually ship to cpan. I've just added Dave as a github > collaborator as well. > > Are you interested in working on getting CD setup? > > -Josh > > -- > On 8/15/19 3:56 PM, Nick Tonkin wrote: > > Hi there Joshua, > > I'm contacting you again regarding the Perl module DateTime:HiRes which is > broken with newer Perls. I would be happy to become a co-maintainer or take > over the module, is that OK with you? > > Thanks, > > - nick > > On Wed, Oct 4, 2017 at 1:32 PM Joshua Hoblitt wrote: > >> Hi Nick, >> >> I'm just returning from leave. I'll be in touch shortly. >> >> -Josh >> >> -- >> On 10/04/2017 09:29 AM, Nick Tonkin wrote: >> > Hi Josh, >> > >> > I see that you saw and deleted the comment I left on a recent Github >> > commit of yours regarding a failing DateTime::HiRes test, sorry about >> > that; I had tried a few times first to get you by email. >> > >> > I take that my attempts to contact you via email and via Github are >> > not welcome, and also that you are no longer interested in maintaining >> > the CPAN module. Please correct me if I've wrongly interpreted your >> > lack of reply. I know how things are and how things can get busy. But >> > if you're no longer interested in maintaining the module, please let >> > me know and I'll be happy to help or take over. >> > >> > Thanks, >> > >> > Nick >> > >> > >> > >> > On Wed, Oct 4, 2017 at 12:11 PM, Joshua Hoblitt >> > mailto:notificati...@github.com>> wrote: >> > >> > Merged #189 <https://github.com/lsst-sqre/jenkins-dm-jobs/pull/189 >> >. >> > >> > — >> > You are receiving this because you commented. >> > Reply to this email directly, view it on GitHub >> > < >> https://github.com/lsst-sqre/jenkins-dm-jobs/pull/189#event-1278299403>, >> > or mute the thread >> > < >> https://github.com/notifications/unsubscribe-auth/AMNsXfmJWKmvmEsnynL7rX9_aX1YpjGyks5so64cgaJpZM4PoDhM >> >. >> > >> > >> >> >
Re: (fwd) Re: Class::Factory::Util
On Wed, 12 Feb 2003 [EMAIL PROTECTED] wrote: > Please register the module Class::Factory::Util > > If possible, please transfer ownership to DROLSKY as I, TBONE, will not > be maintaining it any longer. Actually, this can be done via PAUSE, with the "Change Permissions" option. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: CPAN - rationalising permissions on MooseX-ClassAttribute
I created this long ago but I guess Karen must've done a release that added a new package. I think it'd make the most sense to give me primary on everything. That said, I'm not using this any more so I'd be happy to give Karen primary if she wants it ;) Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch On Mon, Aug 3, 2020 at 4:07 PM Neil Bowers wrote: > Hi Karen & Dave, > > I’m emailing you wearing my PAUSE admin hat; I’m sorting out situations > where CPAN distributions have split ownership, as it can result in parts of > releases not getting indexed, and then when transferring permissions, > modules get missed. PAUSE tries to not let this happen now, but there are > some historical cases, which I’m working through. MooseX-ClassAttribute is > one such. > > You both have first-come on some of the packages in the dist; Karen has > first-come on the lead module MooseX::ClassAttribute, but Dave seems to > have done all releases of the dist. So I’m guessing the module was > originally part of the Moose distribution, and then split out? > > Given Dave seems to be maintaining the dist, does it make sense to give > him all the first-comes? > > If so, I’ll make the changes for you, though you’re welcome to, of course > :-) > > Cheers, > Neil >
Re: CPAN - rationalising permissions on MooseX-ClassAttribute
Done Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch On Tue, Aug 4, 2020 at 2:28 PM Neil Bowers wrote: > Hi Karen, > > I’ve just given you co-maint on the packages in MooseX-ClassAttribute. > DROLSKY had first-come on all the packages in the most recent release. > > There are four packages which were in previous releases, but now aren’t > part of MooseX-ClassAttribute. Those are the ones where DROLSKY has > co-maint and no-one has first-come: > > MooseX::ClassAttribute::Meta::Method::Accessor > MooseX::ClassAttribute::Role::Meta::Attribute > MooseX::ClassAttribute::Role::Meta::Class > MooseX::ClassAttribute::Trait::Application::ToInstance > > Dave: you can drop co-maint on those if you don’t plan on using them again? > > I’ll add an issue for "You don’t always get co-maint when you transfer > first-come to someone else". > > Cheers, > Neil >
Re: Hello! I' am interested in adopting the Database::Migrator module. If you can grant me the privilege I will release the next version.
I'm happy to see someone else take it over. The primary owner is ADOPTME so the PAUSE admins can give you ownership. It'd also make sense to give you Database-Migrator-Pg and Database-Migrator-mysql at the same time. I don't have any particular ideas for future features. For what it's worth, I'm using Sqitch <https://sqitch.org/> these days myself. Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch On Fri, Aug 6, 2021 at 2:37 AM alex.panteleev wrote: > Are there any ideas what should be included in the new version? > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > >
Re: 2nd request: Params::Validate
On 21 May 2001, Andreas J. Koenig wrote: > But Getargs has one advantage over Params: it pre-existed. Params made > up a new rootleval namespace and I wonder what it might be good for > that cannot be served by Getargs. To which I can only reply "huh?" Getargs:: did not pre-exist. The only module in that namespace is Raphael Manfredi's Getargs::Long, which was released _after_ Params::Validate by about a month! So we both simply made up our own namespaces. The difference is that his has gotten listed and mine has not. Admittedly, both modules may belong in the same namespace. But my opjection to Getargs:: still stands. It is too close to Getopt:: and my module doesn't actually do any 'getting', it only validates. As to the 'what it might be good for' bit. If you're referring to the modules themselves, they are similar in aims but very different in interface and capabilities. They are definitely both useful. If you're referring to the namespace, I do think that both modules should share a namespace, but not Getargs::. -Dave /*== www.urth.org We await the New Sun ==*/
Re: 2nd request: Params::Validate
On 22 May 2001, Andreas J. Koenig wrote: > but are you sure your registration was? > > Your mail was sent Date: Wed, 14 Feb 2001 21:06:13 -0600 (CST) > and Raphael's was sent Date: Thu, 24 Aug 2000 21:52:26 +0200 > > Getargs::Long is listed in the Module list since $Revision: 3.64 > $$Date: 2000/10/27 07:12:33 $ What can I say. I code faster than I email ;) The module went from thought to existence in a matter of a week or two. > I can't make any sensible suggestion here. I'd ask you both to > cross-reference each other's module in your POD so that people can > find the other. Yep, we already do that. > Let's agree to disagree. Fine by me. Fine by me too. I'd like to have it listed in the modules list and I'm willing to consider other names (but not Getargs::...). In theory, future versions of Perl will have some support for this in a core module and maybe mine will be obsolete. -dave /*== www.urth.org We await the New Sun ==*/
Re: Notification from PAUSE
Sorry, Andreas. I goofed up. This does not belong to me. -dave On Wed, 6 Jun 2001, Perl Authors Upload Server wrote: > > DROLSKY (Dave Rolsky) visited the PAUSE > and requested an upload into his/her directory. > The request used the following parameters > > HIDDENNAME [DROLSKY] > CAN_MULTIPART [1] > pause99_add_uri_httpupload [] > pause99_add_uri_uri[] > pause99_add_uri_upload [Apache-AntiSpam-0.03.tar.gz] > SUBMIT_pause99_add_uri_upload [ Upload the checked file ] > pause99_add_uri_sub[pause99_add_uri_httpupload] > > > The request is now entered into the database where the PAUSE Daemon > will pick it up as soon as possible. Allow a few minutes, and be aware > that it may take longer if other requests are running. We proceed only > one at a time. > > During upload you can watch ftp://pause.perl.org/tmp/D/DR/DROLSKY > (temporary upload directory), and > then https://pause.perl.org/pub/PAUSE/authors/id/D/DR/DROLSKY (final upload > directory). The logfile is in > https://pause.perl.org/perl/user/tail_log/2000 > (replace 2000 with any offset from the end). > /*== www.urth.org We await the New Sun ==*/
Re: Namespace for an application?
On Thu, 28 Jun 2001, Elaine -HFB- Ashton wrote: > Does the application have a name? We're just calling it the Mason Tracker. > You could call it HTML::Mason::Tracker or something along those lines if > it's part of Mason. Or you could do it like the Mon dist and use the name > of the application for the namespace http://search.cpan.org/search?dist=Mon > or you could pick a namespace that exists already that it might fit into > and go from there. Its definitely not part of Mason. Simply an app that uses Mason. Last time I proposed a namespace that was simply the name of my app (Alzabo::) one of the people on the modules list objected. > http://www.cpan.org/modules/00modlist.long.html#ID5_NamespaceCo > is a good reference and browsing the list of catgories and namespaces my > be helpful. I'm familiar with the guidelines. If there's no objections I think we're going to use Apps::Tracker. That way other apps can share that top level namespace (Apps::*) and not worry about stepping on other modules. We could, alternatively, use Tracker. I like that cause its less typing. -dave /*== www.urth.org We await the New Sun ==*/
Namespace for an application?
We are currently working on a web based task/bug tracking system that we'd like to publicly release sometime in the near future. The system is mostly Mason components plus some modules. The question is what namespace the modules should occupy. Is there any consensus in the Perl community on a namespace for apps? Perhaps Apps::*? That would make us Apps::Tracker. Thoughts? -dave /*== www.urth.org We await the New Sun ==*/
Alzabo
I finally got around to uploading my Alzabo program/modules to CPAN (alzabo.sourceforge.net). It occupies the Alzabo & Alzabo::* & Alzabo::*::* namespaces. I figure I have a good claim to it (and nobody else wants it). I don't know if this is the kind of thing that would get listed on the modules page anyway since its as much an app as modules. -dave /*== www.urth.org We await the New Sun ==*/
Re: Alzabo
On Tue, 10 Oct 2000, Kurt D. Starsinic wrote: > `Alzabo' doesn't explain what the software is for. Wouldn't you > rather put it under, e.g., DbFramework::, or one of the other top-level > namespaces for databasey stuff? Well, its as much an app as a module. What does Perl do? How about Erwin (a commercial data modelling tool). Not that this is nearly as good as either of those yet. But I'm sure you get the point. The namespace matches the name of the app. Also, CPAN is not really intended as the primary distro mechanism, unlike my modules. In this case, I will still probably point people towards the Sourceforge site since it has docs online and such. I don't know how this type of thing is normally handled. As I said, I don't know that it would even be appropriate to list it on the to page. -dave /*== www.urth.org We await the New Sun ==*/
Re: Alzabo
On Tue, 10 Oct 2000, Kurt D. Starsinic wrote: > Yes, I was suggesting that you change the namespace to > DbFramework::Alzabo or somesuch. How about an alias file. I know we have one for HTML::Mason so that it also shows up as Apache::Mason. > The purpose of the modules list is to advertise software on CPAN. It's > not much of an advertisement if it's not descriptive, or categorized with > similar software. So, if you want to put Alzabo on CPAN, but you want people > to prefer picking it up from Sourceforge, then I recommend that you not > register it in the modules list. I want it in the modules list because any publicity is good for spreading the word. I think putting it in as Alzabo isn't a real problem because I really can't see how it steps on anyone else's toes. If its in the same category as Class::DBI and DbFramework it seems like it'd be obvious what it was. And there will be a description of it there too. That said, I don't mind an alias for it as above. However, I will not change the actual class names. The inheritance hierarchy is already three levels deep and prepending DbFramework to everything seems unappealing from an aesthetic level. Plus there already is a sort of similar module suite called DbFramework. -dave /*== www.urth.org We await the New Sun ==*/
Proposed module: Params::Validate
The above is a very tentative name. Anyway, I'm about to start work on a generic argument validation module. The module will allow you to validate arguments passed to you methods/functions to any arbitrary level of pickiness that you desire. It seems like this would be generically useful, particularly during development of larger projects (I'm going to arrange some sort of magic switch so that you can make the validation a no-op for production). The names I've come up with are various mixture of Param(s), Arg(s) followed by Validate, Validator, Check, Checker and so on. It also occurs to me that perhaps this module belongs in the Devel:: namespace since it is arguably a development support module. Anyway, I'm not too picky. What are your ideas? -dave /*== www.urth.org We await the New Sun ==*/
Params::Validate
erence such as C<\&foo_sub> or C.
=item * GLOB
This one is a bit tricky. A glob would be something like C<*FOO>, but
not C<\*FOO>, which is a glob reference. It should be noted that this
trick:
my $fh = do { local *FH; };
makes C<$fh> a glob, not a glob reference. On the other hand, the
return value from C is a glob reference. Either can
be used as a file or directory handle.
=item * GLOBREF
A glob reference such as C<\*FOO>. See the L entry above
for more details.
=item * SCALARREF
A reference to a scalar such as C<\$x>.
=item * HANDLE
This option is special, in that it just the equivalent of C. However, it seems likely to me that most people interested
in either globs or glob references are likely to really be interested
in whether what is being in is a potentially valid file or directory
handle.
=back
To specify that a parameter must be of a given type when using named
parameters, do this:
validate( @_, { foo => { type => SCALAR },
bar => { type => HASHREF } } );
If a parameter can be of more than one type, just use the bitwise or
(C<|>) operator to combine them.
validate( @_, { foo => { type => GLOB | GLOBREF } );
For positional parameters, this can be specified as follows:
validate( @_, { type => SCALAR | ARRAYREF }, { type => CODEREF } );
=head2 Interface Validation
To specify that a parameter is expected to have a certain set of
methods, we can do the following:
validate( @_,
{ foo =>
{ can => 'bar' } } ); # just has to be able to ->bar
... or ...
validate( @_,
{ foo =>
{ can => [ qw( bar print ) ] } } ); # must be able to ->bar
and ->print
=head2 Class Validation
A word of warning. When constructing your external interfaces, it is
probably better to specify what you methods you expect an object to
have rather than what class it should be of (or a child of). This
will make your API much more flexible.
With that said, if you want to verify that an incoming parameter
belongs to a class (or a child class) or classes, do:
validate( @_,
{ foo =>
{ isa => 'My::Frobnicator' } } );
... or ...
validate( @_,
{ foo =>
{ can => [ qw( My::Frobnicator IO::Handle ) ] } } );
# must be both, not either!
=head2 Callback Validation
If none of the above are enough, it is possible to pass in one or more
callbacks to validate the parameter. The callback will be given the
B of the parameter as its sole argument. Callbacks are
specified as hash reference. The key is an id for the callback (used
in error messages) and the value is a subroutine reference, such as:
validate( @_,
{ foo =>
callbacks =>
{ 'smaller than a breadbox' => sub { shift() < $breadbox },
'green or blue' =>
sub { my $val = shift; $val eq 'green' || $val eq 'blue'
} } } );
On a side note, I would highly recommend taking a look at Damian
Conway's Regexp::Common module, which could greatly simply the
callbacks you use, as it provides patterns useful for validating all
sorts of data.
=head2 Mandatory/Optional Revisited
If you want to specify something such as type or interface, plus the
fact that a parameter can be optional, do this:
validate( @_, { foo =>
{ type => SCALAR },
bar =>
{ type => ARRAYREF, optional => 1 } } );
or this for positional parameters:
validate( @_, { type => SCALAR }, { type => ARRAYREF, optional => 1 } );
By default, parameters are assumed to be mandatory unless specified as
optional.
=head1 LIMITATIONS
Right now there is no way (short of a callback) to specify that
something must be of one of a list of classes, or that it must possess
one of a list of methods. If this is desired, it can be added in the
future.
=head1 SEE ALSO
Carp::Assert and Class::Contract.
=head1 AUTHOR
Dave Rolsky, <[EMAIL PROTECTED]>
=cut
2nd request: Params::Validate
This got absolutely no comment last time so I'm going to try again. The 04pause.html documents says "Generally a lack of response can be taken as acceptance of the module name being proposed" but perhaps that's not the case here because this module still isn't in the index. Name: Params::Validate DSLI: bdpf Author: DROLSKY Description: Validate subroutine parameters based on type, class, or interface Alternate namespace suggestions are welcomed if this does not suit. Thanks, -dave /*== www.urth.org We await the New Sun ==*/
Re: 2nd request: Params::Validate
On Mon, 19 Mar 2001, Johan Vromans wrote:
> Sorry for the delay...
>
> [Quoting Dave Rolsky, on March 18 2001, 10:51, in "2nd request: Params:"]
> > Name: Params::Validate
> > DSLI: bdpf
> > Author: DROLSKY
> > Description: Validate subroutine parameters based on type, class, or
> > interface
>
> Can you indicate the differences between Params::Validate and
> Getargs::Long?
Good question. I didn't even know Getargs::Long existed. It looks like
it was released after Params::Validate so that explains how I missed it.
Anyway, having looked at it, I think I'd probably want to continue using
and maintaining my module. The two do fairly similar things but the
interfaces look quite different, and IMHO mine is significantly more
readable.
For example, doing this in Getargs::Long
my ($port, $server) = getargs( \@_, qw( port=i server=HTTP::Server ) );
would be written this way for my module:
validate( @_, { port => { type => SCALAR },
server => { isa => 'HTTP::Server' } } );
my %params = @_;
There isn't a one hundred percent overlap as there is no way to specify
that a scalar should be an integer vs. being a float or string. I also
don't plan to do this as in Perl I don't feel this can be meaningully
done. However, my module does allow a callbacks interface so the very
anal could do:
validate( @_, { port => { type => SCALAR,
callbacks => { 'is integer' =>
{ sub { shift =~ /^[\d.]$/ } } },
} } );
This, while somewhat ugly, is fairly self-documenting. To me, one of the
main purposes of my module is to help people write self-documenting code,
along with being a sanity checker.
In addition, my module can be used to validate positional arguments as
well (via the validate_pos sub) which is quite useful for me, since I have
code that uses both (positional for very simple methods, named for more
complex).
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: 2nd request: Params::Validate
On Mon, 19 Mar 2001, Johan Vromans wrote: > That's okay. TIMTOWTDI. > > Would you settle for Getargs::Validate? I find Getargs confusingly similar to Getopts, considering that we often refer to 'command line arguments'. Also, it doesn't actually return the parameters the way Raphael's module does, it simply validates them, so there's really no 'getting' happening at all. You're responsible for assigning them to a hash or individual scalars or whatnot. -dave /*== www.urth.org We await the New Sun ==*/
Module takeover request - File::LibMagic
I wrote to the two folks listed as authors, Michael Hendricks and Andreas Fitzner, in early April. Michael replied back immediately saying he wasn't working on it any more and he was happy to give me comaint, but he didn't have PAUSE perms on it. Andreas has never responded. The email associated with his PAUSE account (andreas.fitz...@fv-berlin.de) is dead. I also emailed the one in the File::LibMagic docs and didn't hear back from him. The web page his PAUSE account links to is _also_ dead. I'm not really sure how else to contact him, but based on the fact that the module hasn't been released for 4 years and the list of bugs (including a total failure to install with 5.18+), I think it's safe to say he's no longer working on it. I'd like to at least fix it up enough to keep it working with newer Perls, as I used it with Courriel and other software. And clearly, I need another module to maintain! Thanks, -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Takeover request for Astro::Sunrise and DateTime::Event::Sunrise
Please see below. It seems that Jean has made a good effort to find the original author, and said author has been awol for a long time. It'd be great to give these modules to Jean (or just give him co-maint). Thanks, -dave -- Forwarded message -- Date: Wed, 26 Jun 2013 22:43:21 +0200 From: Jean Forget To: rkh...@cpan.org Cc: datetime Subject: Status of Astro::Sunrise and DateTime::Event::Sunrise Ron Hill, are you still active on the DateTime list? From August 2000 until October 2003, you have released several versions of Astro::Sunrise. From March 2003 to March 2004, you have released several versions of DateTime::Event::Sunrise. Since then, nothing. Yet, rt.cpan has several tickets for these distributions. The oldest ones are just wishlists for the documentation of DT::E::Sunrise, back in October 2004: https://rt.cpan.org/Public/Bug/Display.html?id=7605 https://rt.cpan.org/Public/Bug/Display.html?id=8065 No answer for these tickets. And then, a showstopper bug appeared in both Astro::Sunrise and DT::E::Sunrise: very wrong times for sunrise and sunset on 20th or 21st of March (spring equinox), sometimes even an error "sun never rises" or "sun never sets". In addition, nearly all other days give wrong results (for example, at latitude 60°, the difference can be more than 3 minutes 1/2). The problem with 20th / 21st March was reported independently by several people, including me: https://rt.cpan.org/Public/Bug/Display.html?id=34770 https://rt.cpan.org/Public/Bug/Display.html?id=55762 https://rt.cpan.org/Public/Bug/Display.html?id=75927 https://rt.cpan.org/Public/Bug/Display.html?id=47049 https://rt.cpan.org/Public/Bug/Display.html?id=83394 There was even a patch for DT::E::Sunrise in my ticket. And still no answer. There was one review for DT::E::Sunrise. Did the reviewer say that your module sucks? No. Did he say that your module rocks? No. He just said: Please apply patch from rt.cpan.org/Public/Bug/Display.html?id=34770 And still no answer. There are other tickets of various severities, including another with a patch for DT::E::Sunrise: https://rt.cpan.org/Public/Bug/Display.html?id=36532 When dealing with ticket 83394, someone has tried to reach you, but the message was not delivered. So here is a new attempt, with a copy to the DateTime mailing-list. So, are you still active on the DateTime mailing-list? Could you fix the bugs, especially the bugs for which we provided a patch? Or else, can you share maintenance of these two modules with someone else? I volunteer to be a co-maintener for these modules. Best regards, Jean Forget
Contact info for phishing attack blog post
Hi all, There is a phishing attack against CPAN authors in progress. I want to post something about this on the TPF blog. I wrote this in my draft: > If you've clicked on the link and entered any credentials, you should change the relevant password immediately. If you entered your PAUSE credentials, please check your recent uploads for any suspicious new packages. The easiest way to check this is through your MetaCPAN author page, like [ metacpan.org/author/DROLSKY](https://metacpan.org/author/DROLSKY). If you find something suspicious, please download a copy, delete it from PAUSE, and alert [modules@perl.org](mailto:modules@perl.org). Does having them contact this address make sense? Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch
