Adopt Image::JPEG::Size?

[Robert Rothenberg]

Hello,

I'm interested in adopting the Image::JPEG::Size module. If you can 
grant me the privilege I will release the next version.


My CPANID is RRWO.

Regards,
Robert Rothenberg

Issues with JavaScript::Embedded

[Robert Rothenberg]

The Makefile.PL and Changes file refer to JavaScript::Duktape, not 
JavaScript:Embedded. Presumably because it's a fork of the former.


This makes it difficult to submit issues for it, because the metadata is 
referring to a different module.


I have tried to email the author at rene.schickba...@magnapowertrain.com 
but the email seems to be invalid.

Should there be a policy for handling security reports for CPAN modules in general?

[Robert Rothenberg]

Note: sent to modules list but copied to Brian D Foy as author of 
CPAN::Audit.


There isn't a policy or central place for reporting security issues with 
CPAN modules that are not part of the Perl core.


Should there be one?

I have reported a couple of security issues to module authors, and have 
yet to receive replies.


One of them is a well-used module, and I've not received a reply after 
several months.


Another has a CVE associated with a library that it uses, so I've 
reported that separately to CPAN::Audit but that's still not a 
satisfactory way of reporting or handling issues.


Beyond asking around on forums "Is anyone in touch with this module 
author? I need to get in touch with them" I'm unsure where to go.


This feels unsatisfactory.  But I'm not sure what a good alternative is yet.

Re: Adopt Linux::Statm::Tiny?

[Robert Rothenberg]

Apologies for the accidental cc spam.

On 12/02/2022 12:10, Robert Rothenberg wrote:

Hello,

There's been an issue submitted on github 
https://github.com/robrwo/Linux-Statm-Tiny/issues/12


I should probably give your user access to that repo. What is your 
github user id?


On 27/10/2021 00:14, James Raspass wrote:

Hello,

I'm interested in adopting the Linux::Statm::Tiny module. If you can
grant me the privilege I will release the next version.

Thanks

James Raspass

Re: Adopt Linux::Statm::Tiny?

[Robert Rothenberg]

Hello,

There's been an issue submitted on github 
https://github.com/robrwo/Linux-Statm-Tiny/issues/12


I should probably give your user access to that repo. What is your 
github user id?


On 27/10/2021 00:14, James Raspass wrote:

Hello,

I'm interested in adopting the Linux::Statm::Tiny module. If you can
grant me the privilege I will release the next version.

Thanks

James Raspass

Re: Adopt Linux::Statm::Tiny?

[Robert Rothenberg]

Linux-Statm-Tiny is owned by ADOPTME. Please transfer ownership to RAZ.

(I'm assuming GBJK has no problem with that.)

On 27/10/2021 09:30, James Raspass wrote:

Ah sorry, metacpan probably ought to add that to the email template, it's RAZ.

On Wed, 27 Oct 2021 at 09:23, Robert Rothenberg  wrote:

What is your CPANID.

On 27/10/2021 00:14, James Raspass wrote:

Hello,

I'm interested in adopting the Linux::Statm::Tiny module. If you can
grant me the privilege I will release the next version.

Thanks

James Raspass

Re: Adopt Linux::Statm::Tiny?

[Robert Rothenberg]

What is your CPANID.

On 27/10/2021 00:14, James Raspass wrote:

Hello,

I'm interested in adopting the Linux::Statm::Tiny module. If you can
grant me the privilege I will release the next version.

Thanks

James Raspass

Re: Algorithm-SkipList

[Robert Rothenberg]

When I log in to PAUSE, it still shows it as owned by ADOPTME.

On 26/02/2021 10:12, Neil Bowers wrote:

Hi John,

TL;DR: I’ve transferred the first-come permissions on 
Algorithm-SkipList to you.


I’m one of the PAUSE admins.

I was surprised to see Algorithm-SkipList marked as owned by
ADOPTME in

PAUSE, which is not the case in MetaCPAN, where it is owned by Robert

Rothenburg (although it is marked for adoption, see

).


As Dan Book pointed out, when you search for a module on CPAN, by 
default you’re shown the release that’s in the CPAN Index. Usually 
that’s the most recent release, but it might not be (for example 
developer releases don’t go in the index, and if the uploader didn’t 
have any indexing permission(s), then it would also not be indexed). 
And the person listed against it is the person who uploaded it.


What is the process for adoption, assuming that RRWO is amenable?


Given it’s marked as ADOPTME, the process is that you ask the PAUSE 
admins, and it’s polite to ask for the blessing of the previous owner 
(and Robert has given that). If the distribution is depended on by a 
lot of other CPAN modules, then we’ll consider whether you’re the 
right person to take it on, or at least that you’re aware that 
releasing a broken version could result in a cascade of failures. If 
you hover over the bars next to the distribution name, you’ll see that 
two distributions depend on this, which isn’t concerning.


So I’ve transferred first-come from ADOPTME to you, for all the 
modules in the distribution. Thanks for taking this on.


Final point: when you submit requests like these, please include your 
PAUSE id. I hope JGAMBLE was the right John Gamble? ;-)


Cheers,
Neil

Re: Failed: PAUSE indexer report RRWO/Set-Light-0.95.tar.gz

[Robert Rothenberg]

Hello,

I used to have co-maint permissions for Set-Light. They seem to have 
gone away.


Regards,

Robert

On 07/05/2021 13:38, PAUSE wrote:

The following report has been written by the PAUSE namespace indexer.
Please contact modules@perl.org if there are any open questions.

   User: RRWO ()
   Distribution file: Set-Light-0.95.tar.gz
   Number of files: 32
   *.pm files: 1
   README: Set-Light-0.95/README.md
   META-File: Set-Light-0.95/META.json
   META-Parser: Parse::CPAN::Meta 1.4414
   META-driven index: yes
   Timestamp of file: Fri May  7 12:03:20 2021 UTC
   Time of this run: Fri May  7 12:38:39 2021 UTC

ERROR: Database error occurred during index update


This distribution name will only be indexed when uploaded by users with
permission for the package Set::Light. Either someone else has ownership
over that package name, or this is a brand new distribution and that
package name was neither listed in the 'provides' field in the META file
nor found inside the distribution's modules. Therefore, no modules will
be indexed.

Further details on the indexing attempt follow.


The following packages (grouped by status) have been found in the distro:

Status: Permission missing
==

  module : Set::Light
  version: 0.95
  in file: lib/Set/Light.pm
  status : Not indexed because permission missing. Current registered
  primary maintainer is TELS. Hint: you can always find the
  legitimate maintainer(s) on PAUSE under "View Permissions".

__END__

Re: Algorithm-SkipList

[Robert Rothenberg]

I'm fine with it.

Note there's an unfinished development version on CPAN and a github repo 
at https://github.com/robrwo/Algorithm-SkipList


Robert


On 25/02/2021 06:40, John M. Gamble wrote:
I was surprised to see Algorithm-SkipList marked as owned by ADOPTME 
in PAUSE, which is not the case in MetaCPAN, where it is owned by 
Robert Rothenburg (although it is marked for adoption, see 
).


In any event, I'm marked as co-maintainer. What is the process for 
adoption, assuming that RRWO is amenable?


Thanks,
 --john

Re: Adopt MooX::Should?

[Robert Rothenberg]

I'm fine with that.

I no longer have ownership of it (it's ADOPTME), otherwise I'd do it myself.

If you want rights to the git repo, send me your github id.

On 08/02/2021 12:37, Theo Van Hoesel wrote:

Hello,

I'm interested in adopting the MooX::Should module. If you can grant 
me the privilege I will release the next version.


My PAUSE id is VANHOESEL

And already I see a small optimisation possible, something this module 
is all about


Theo




Theo van Hoesel
/Software Developer/
*Perceptyx*
m: +31 624-619-072
e: tvanhoe...@perceptyx.com 
w: www.perceptyx.com 

Re: Adopt Lingua::Conjunction?

[Robert Rothenberg]

I'm happy with that.

(It's owned by ADOPTME, so I no longer have perms to update it.)


On 04/01/2021 16:03, Nigel Horne wrote:

Hello,

I'm interested in adopting the Lingua::Conjunction module. If you can grant me 
the privilege I will release the next version.

Username on CPAN: nhorne

This should help with i18n of my genealogy code.

-Nigel



Sent from my iPhone

Re: Adopt Text::Truncate?

[Robert Rothenberg]

It's owned by ADOPTME so modu...@cpan.org will have to fix that.

On 08/09/2020 19:36, Szymon Nieznański wrote:

Hello,

I'm interested in adopting the Text::Truncate module. If you can grant
me the privilege I will release the next version.

PAUSE id: SNEZ

--
Szymon Nieznański

Re: Adopt Tie::RegexpHash?

[Robert Rothenberg]

Neil,

Thanks for taking care of this.

Rob

On 03/08/2020 10:45, Neil Bowers wrote:

hi Theo,

I'm interested in adopting the Tie::RegexpHash module. If you can
grant me the privilege I will release the next version.


Given it was marked as ADOPTME, that’s fine. I’ve just transferred the 
first-come permission to VANHOESEL.


As an aside, when you make requests like this, it helps if you can 
tell us your PAUSE id.


Thanks for helping fight the CPAN bit rot.

Cheers,
Neil

Fwd: Failed: PAUSE indexer report RRWO/HTML-DeferableCSS-v0.2.1.tar.gz

[Robert Rothenberg]

 Forwarded Message 
Subject:Failed: PAUSE indexer report 
RRWO/HTML-DeferableCSS-v0.2.1.tar.gz
Date:   Fri, 21 Feb 2020 09:20:44 +
From:   PAUSE 
To: rob...@gmail.com, andreas.koenig.gmwojprw+pa...@franz.ak.mind.de



The following report has been written by the PAUSE namespace indexer.
Please contact modules@perl.org if there are any open questions.

User: RRWO ()
Distribution file: HTML-DeferableCSS-v0.2.1.tar.gz
Number of files: 40
*.pm files: 1
README: HTML-DeferableCSS-v0.2.1/README.md
META-File: HTML-DeferableCSS-v0.2.1/META.json
META-Parser: Parse::CPAN::Meta 1.4414
META-driven index: yes
Timestamp of file: Fri Feb 21 09:07:07 2020 UTC
Time of this run: Fri Feb 21 09:20:44 2020 UTC

Status of this distro: Database error
=


The following packages (grouped by status) have been found in the distro:

Status: Database error
==

module : HTML::DeferableCSS
version: undef
in file: lib/HTML/DeferableCSS.pm
status : The PAUSE indexer could not store the indexing result in
the DB due the following error: C< Lock wait timeout
exceeded; try restarting transaction >. Please report the
case to the PAUSE admins at modules@perl.org.

__END__

More spam modules

[Robert Rothenberg]

It looks like we're seeing more spam modules uploaded from fake users.

So I'm thinking that we need some kind of moderation system until we've 
validated the user.

Unfortunately this will require a pool of trusted users who can look over 
modules to make sure their not spam and "approve" uploads. (Approve meaning 
that superficially it looks legit, not that it's been shown to be bug or even 
malware-free.) We might even require the uploaders to send an e-mail to a 
mailing list saying "I've just uploaded this module. Please approve it."

I imagine after a certain number of legit uploads, or some to-be-determined 
validation/verification process, users won't need to be moderated anymore.

Owner of POE::Component::DirWatch::Object is MIA

[Robert Rothenberg]

I've been trying to track down GRODITI regarding bugs in
POE::Component::DirWatch::Object for a while, and have not gotten responses.
(I've also tried contacting him via what seems to be his LinkedIn profile,
with no response.)

I've offered to fix some of the bugs and upload a new version.

I've contacted the co-maintainers of the module, but I gather from the PAUSE
view permissions page that they can't give me the ability to update the module.

So aside from convincing them to make the requested changes, what's the
procedure for getting myself added as a co-maint of a module when the owner
is MIA?

Regards,
Rob (CPANID rrwo)

Re: CPAN Module Adoption: CPAN-Mini-Tested

[Robert Rothenberg]

Hi Barbie,

I'm fine with you taking the module over, but ADOPTME is now the
maintainer, so I can't assign it myself. I've cc'd the modules list.

Regards,
Rob


On Tue, Jul 15, 2014 at 6:33 PM, Barbie  wrote:

> Hi Rob,
>
> I noticed that CPAN-Mini-Tested is currently marked as ADOPTME. As it
> previously uses the now defunct testers.db SQLite database, I'd like to
> take it on and upgrade it to make use of an API from cpantesters.org.
> Potentially it will mean creating new APIs on the server too, extending the
> existing APIs :)
>
> I also note that Andy Armstrong is co-maint, so I didn't know whether he
> was already planning to take it on. If not, would you be okay with me
> looking after it?
>
> Cheers,
> Barbie.
> --
> Birmingham.pm - http://birmingham.pm.org
> CPAN Testers - http://cpantesters.org
> YAPC Surveys - http://yapc-surveys.org
> Perl Jam - http://perljam.info
>

What to call a module that rewrites Perl code

[Robert Rothenberg]

At $work, I've been writing scripts that use PPI to munge massive amounts
of legacy code. So far simple things like changing die/warn to croak/carp,
ensuring all modules specify a minimum version number, or changing print
"foo\n" so say "foo", etc. It seems worthy enough to turn this code into a
CPAN module.

My thoughts are that it would use a plugin system for specific tasks, and a
command-line script that takes plugin names as arguments, so basically
you'd run the script to apply various tasks to a set of modules or scripts
in a directory, perhaps using a configuration file for each of the plugins.

The early version would have simple plugins, but there's no reason why more
complex plugins couldn't be written (e.g. to translate a non-Moose  class
into something Moose-like), or other things like optimize certain kinds of
expressions.

I'm well aware of the limitations of doing this automatically. But the idea
is to get a script that can do the bulk of the tedious rewriting, so that a
human can clean up the mistakes. It's meant to be run by intelligent people
who use things like version control and tests.

So what should it be called? I'm thinking Perl::Rewrite is the best name.

Alternatives are:
- Perl::Refactor - except "refactoring" has a technical meaning that I
don't think applies
- Perl::Modernize - except that one might want a plugin that translates
newer-style code into older code
- Perl::Munge - except that it connotes sloppiness
- Perl::Snorft - no, just kidding I have no idea what that means.
- ?

Thanks,
Rob

Re: Module submission Test::HTML::Spelling

[Robert Rothenberg]

This hasn't been approved yet. Is there a problem with the request?

> 
> From: Perl Authors Upload Server
> Date: November 24, 2012 05:12
> Subject: Module submission Test::HTML::Spelling
> Message ID: 201211241312.qaodcjaa014...@pause.fiz-chemie.de
> 
> 
> The following module was proposed for inclusion in the Module List:
> 
>   modid:   Test::HTML::Spelling
>   DSLIP:   cnphp
>   description: Test the spelling of HTML documents
>   userid:  RRWO (Robert Rothenberg)
>   chapterid:   15 (World_Wide_Web_HTML_HTTP_CGI)
>   communities:
> N/A
> 
>   similar:
> None
> 
>   rationale:
> 
> It's useful to have automated testing suites for web sites check
> the spelling of web pages.
> 
>   enteredby:   RRWO (Robert Rothenberg)
>   enteredon:   Sat Nov 24 13:12:18 2012 GMT
> 
> The resulting entry would be:
> 
> Test::HTML::
> ::Spellingcnphp Test the spelling of HTML documents  RRWO

[Fwd: Re: Module submission List::SkipList]

[Robert Rothenberg]

 Original Message 
Subject: Re: Module submission List::SkipList
Date: Fri, 14 Nov 2003 17:10:45 +
From: Tim Bunce <[EMAIL PROTECTED]>
To: Robert Rothenberg <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Best to tell the modules list and ask someone if they can approve it for 
you.

Tim.

On Fri, Nov 14, 2003 at 11:30:18AM -0500, Robert Rothenberg wrote:
Typo. It is a skip list.

Tim Bunce wrote:
>On Fri, Nov 14, 2003 at 06:17:58AM +0100, Perl Authors Upload Server wrote:
>
>>The following module was proposed for inclusion in the Module List:
>>
>> modid:   List::SkipList
>> description: Implementation of SplitLists (aka Treaps)
>
>
>Maybe this is a bumb question, but
>why call the module *Skip*List if it's about *Split*Lists?
>
>Tim.
>
>

RE: RFC for module name Color::Object.

[Robert Rothenberg]

It's been a (long) while and I've been busy with other projects, so please 
take over Graphics::ColorSpace or Color::Object or whatever you prefer to 
call it. (Though Color::Object does not seem like the best name.)

--Rob

On 23 May 2001, Alfred Reibenschuh wrote:

> >[...]
> >I think Graphics::Colorspace is better than Image::Colorspace since this
> >deals more with computer graphics abstractions than it does with specific
> >images. I am welcome to better name suggestions.
> >
> >(If such a module already exists, please let me know so that I don't 
> >duplicate work.)
> 
> i'd be happy to contribute my Color::Object module to a worthy cause
> since much of its functionality has been integrated into my PDF::API
> 
> 
> -- Alfred Reibenschuh, perl geek
> [...]

RTF::Generator and assorted modules

[Robert Rothenberg]

I'm working on RTF::Generator and would like to 'reserve' module 
namespace for user RRWO (myself) if possible for the following (first two 
have earlier versions on CPAN already):

  RTF::Group
  RTF::ColorTable
  RTF::FontTable
  RTF::StyleSheet
  RTF::Character
  RTF::Paragraph
  RTF::Section

Only RTF::Generator need be on the modules list.

DSLI for Tie::RegexpHash

[Robert Rothenberg]

I would like to edit the metadata for Tie::RegexpHash in the module list:

DSLI: adph
Description:Use regular expressions as hash keys
Module List Chapter: 6) Data Types and Data Type Utilities

PROPOSAL - Font::PANOSE

[Robert Rothenberg]

It seems none of the other Font::* modules have anything for working with
PANOSE numbers. Assuming I don't find anything, I would like to propose 
a module called "Font::PANOSE" for validating and matching PANOSE 
font numbers.

See http://www.w3.org/Printing/stevahn.html for an introduction. 

Win32::EventLog::Carp

[Robert Rothenberg]

I'd like to have Win32::EventLog::Carp be added to the modules list. It's 
been out for over a year and the latest version is relatively 'mature'.

Re: Proposal: Graphics::NamedColors module

[Robert Rothenberg]

On 18 Feb 2001, Johan Vromans wrote:

> [Quoting Robert Rothenberg, on February 17 2001, 15:46, in "Proposal:
> Graphics::"] > > I think a module which has common color names would be
> useful. The > initial version would return RGB codes for a given name. 
> 
> Not a bad idea, I would say.
> Is there some kind of agreed-upon standard for color names to
> coordinate mappings?

Names used in X-Windows. Also HTML/SVG standard names. And there 
are names used in Windows (minor differences with HTML scheme).

> Will there be colour (note the 'u') alternative names for english
> speaking people?

I'm sympathetic to that for functions. It's a simple alias. But along that 
lines we should have French, Spanish, German, and Chinese and various 
sub-dialect names for functions. And it's awkward to have a 
Graphics::ColorNames and separate Graphics::ColourNames module.

[See also a parellel thread about this on comp.lang.perl.modules.]

Proposal: Graphics::NamedColors module

[Robert Rothenberg]

I think a module which has common color names would be useful. The 
initial version would return RGB codes for a given name. There's already 
some duplication of this in various packages... but I see no reason for a 
module or script to require Tk, VRML, ANSI etc, to be installed just 
because one wants to say 'black' instead of (0, 0, 0).

I think 'Gaphics::NamedColors' is a good name for the module.

Comments? Criticisms? Is there already such a module?

Module registration: Tie::RangeHash

[Robert Rothenberg]

I would like to submit the meta-data for the module
Tie::RangeHash.


Name  DSLI  Description Info
    --- -
Tie::RangeHashbdpO  Hashes with 'low,high' ranges as keys   RRWO

Tie::RangeHash or Tie::Range

[Robert Rothenberg]

I have a rudimentary "Range Hash" module I plan on calling 
Tie::RangeHash. It works kind of like this:

  tie %hash, Tie::RangeHash;

  $hash{'2000-01-01,2000-01-31'} = 1;
  $hash{'2000-02-01,2000-02-28'} = 2;
  $hash{'2000-03-01,2000-03-31'} = 3;

  print $hash{'2000-02-14'}; # prints '2'

I may call it Tie::Range and generalize it to tie arrays with numerical 
ranges as well.





--- End of forwarded message ---

Actually, Convert::Color makes the most sense

[Robert Rothenberg]

Come to think of it, a module named Convert::Color that can convert 
between RBB, HSI, CMYK etc. schemes (and for the fun of it translate 
various naming schemes into something useful) is the best name.

[PROPOSAL] Graphics::Colorspace

[Robert Rothenberg]

Since the Image::Colorimetry module is no longer available, and since it
makes sense to have a module that can convert between RGB, HSL, 
CMYK and other color space schemes (as well as translate standard color 
names to useful codes) I'd like to propose a Graphics::Colorspace module
name.

I think Graphics::Colorspace is better than Image::Colorspace since this
deals more with computer graphics abstractions than it does with specific
images. I am welcome to better name suggestions.

(If such a module already exists, please let me know so that I don't 
duplicate work.)