what to do with wrong checksum

what to do with wrong checksum

[Frans Meulenbroeks]

While trying to build xmltv I got this:

NOTE: The MD5Sums did not match. Wanted:
'495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
'68d9a93d507bbf917e1f3ad294fd5727'
NOTE: Task failed: Checksum of
'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed

How should I handle this. Of course I can change the checksum, but i
don't think that is the intention :-)
Is there a version somewhere cached that has the old checksum (so I
can compare).
Or how else should I handle this?

Frans

Re: what to do with wrong checksum

[Holger Hans Peter Freyther]

On Friday 06 November 2009 21:38:40 Frans Meulenbroeks wrote:
> While trying to build xmltv I got this:
> 
> NOTE: The MD5Sums did not match. Wanted:
> '495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
> '68d9a93d507bbf917e1f3ad294fd5727'
> NOTE: Task failed: Checksum of
> 'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed
> 
> How should I handle this. Of course I can change the checksum, but i
> don't think that is the intention :-)
> Is there a version somewhere cached that has the old checksum (so I
> can compare).
> Or how else should I handle this?


Check the angstrom mirror or sources.oe.org and download that version
and then diff it.

z.

Re: what to do with wrong checksum

[Philip Balister]

On 11/07/2009 03:06 AM, Holger Hans Peter Freyther wrote:
> On Friday 06 November 2009 21:38:40 Frans Meulenbroeks wrote:
>> While trying to build xmltv I got this:
>>
>> NOTE: The MD5Sums did not match. Wanted:
>> '495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
>> '68d9a93d507bbf917e1f3ad294fd5727'
>> NOTE: Task failed: Checksum of
>> 'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed
>>
>> How should I handle this. Of course I can change the checksum, but i
>> don't think that is the intention :-)
>> Is there a version somewhere cached that has the old checksum (so I
>> can compare).
>> Or how else should I handle this?
>
>
> Check the angstrom mirror or sources.oe.org and download that version
> and then diff it.

Try asking the xmltwig people what happened.

Philip

>
> z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: what to do with wrong checksum

[Frans Meulenbroeks]

2009/11/7 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Friday 06 November 2009 21:38:40 Frans Meulenbroeks wrote:
>> While trying to build xmltv I got this:
>>
>> NOTE: The MD5Sums did not match. Wanted:
>> '495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
>> '68d9a93d507bbf917e1f3ad294fd5727'
>> NOTE: Task failed: Checksum of
>> 'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed
>>
>> How should I handle this. Of course I can change the checksum, but i
>> don't think that is the intention :-)
>> Is there a version somewhere cached that has the old checksum (so I
>> can compare).
>> Or how else should I handle this?
>
>
> Check the angstrom mirror or sources.oe.org and download that version
> and then diff it.

Hm. Did that.
Apparently version control is not very strong for Twig.
The diff for the changes file:

diff -r old/XML-Twig-3.33/Changes new/XML-Twig-3.33/Changes
13a14
> added: indented_close_tag pretty_print option (suggested by H.Merijn Brand)
14a16,23
> fix:  xml_grep bug: warning when --count is used and no match is found
>       https://rt.cpan.org/Ticket/Display.html?id=33269
>       found by Hermann Peifer
> fix:  xml_split bug when using an XML declaration and a utf8 encoding. Spotted
>       by Chris Price.
> fix:  xml_pp bug, pod2text command to display help was not properly quoted.
>       Spotted by Chris Price.
> fix:  failing tests when LWP::UserAgent is not available

Reluctantly updated checksums.ini

Frans

Re: what to do with wrong checksum

[Holger Hans Peter Freyther]

On Saturday 07 November 2009 10:06:57 Frans Meulenbroeks wrote:

> > Check the angstrom mirror or sources.oe.org and download that version
> > and then diff it.
> 
> Hm. Did that.
> Apparently version control is not very strong for Twig.
> The diff for the changes file:

bump the PR of the package too

Re: what to do with wrong checksum

[Frans Meulenbroeks]

2009/11/7 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Saturday 07 November 2009 10:06:57 Frans Meulenbroeks wrote:
>
>> > Check the angstrom mirror or sources.oe.org and download that version
>> > and then diff it.
>>
>> Hm. Did that.
>> Apparently version control is not very strong for Twig.
>> The diff for the changes file:
>
> bump the PR of the package too

Of course.
Forgot to do it, done now. Thanks.

Frans

Re: what to do with wrong checksum

[Mike Westerhof]

Frans Meulenbroeks wrote:
...
> 
> Reluctantly updated checksums.ini
> 
> Frans

But of course there's no magic that will remove the old cached tarball
out of one's downloads directory when this sort of thing happens.
(Busybox has been known to do this, too)

What do folks think we should do about that when it occurs?
a) support two entries (old and new) in checksums.ini
b) do nothing (leave as is)
c) add some sort of support so that the user gets additional information
   with the new checksum match failure explaining that the checksum was
   updated and they need to manually remove the old (bad) tarball

-Mike (mwester)

Re: what to do with wrong checksum

[Holger Hans Peter Freyther]

On Saturday 07 November 2009 14:23:01 Mike Westerhof wrote:
> Frans Meulenbroeks wrote:
> ...
> 
> > Reluctantly updated checksums.ini
> >
> > Frans
> 
> But of course there's no magic that will remove the old cached tarball
> out of one's downloads directory when this sort of thing happens.
> (Busybox has been known to do this, too)
> 
> What do folks think we should do about that when it occurs?
> a) support two entries (old and new) in checksums.ini
> b) do nothing (leave as is)
> c) add some sort of support so that the user gets additional information
>    with the new checksum match failure explaining that the checksum was
>    updated and they need to manually remove the old (bad) tarball


Good question... currently we only check the checksum after download, a first 
start would be to do it before unpack... this would create an error and we 
could implement c) later... (e.g. by creating a old_checksums.ini)

z.

Re: what to do with wrong checksum

[Koen Kooi]

On 06-11-09 21:38, Frans Meulenbroeks wrote:
> While trying to build xmltv I got this:
>
> NOTE: The MD5Sums did not match. Wanted:
> '495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
> '68d9a93d507bbf917e1f3ad294fd5727'
> NOTE: Task failed: Checksum of
> 'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed
>
> How should I handle this. Of course I can change the checksum, but i
> don't think that is the intention :-)
> Is there a version somewhere cached that has the old checksum (so I
> can compare).
> Or how else should I handle this?

 From my previous run in with twig:

checksums.ini: update entry for libxml-twig-perl
The Twig people are idiots because they keep replacing the tarball, a 
snippet from diffing the two:

diff -Nurd XML-Twig-3.33.old/Changes XML-Twig-3.33.new/Changes
--- XML-Twig-3.33.old/Changes	2009-05-18 14:13:23.000000000 +0200
+++ XML-Twig-3.33.new/Changes	2009-10-11 09:52:38.000000000 +0200
@@ -12,7 +12,11 @@
  added: better error message if find_nodes or get_xpath are called instead
        of findnodes when using XML::Twig::XPath (suggested by Zed Pobre)
  added: indented_close_tag pretty_print option (suggested by H.Merijn 
Brand)
-
+added: RT #49692 xml_split test on win 32 systems. Patch sent through RT
+       http://rt.cpan.org/Ticket/Display.html?id=49692
+fix:  RT #48616 handler condition of foo/* crashed the module
+      reported by Osfameron
+      http://rt.cpan.org/Public/Bug/Display.html?id=48616
  fix:  xml_grep bug: warning when --count is used and no match is found
        https://rt.cpan.org/Ticket/Display.html?id=33269
        found by Hermann Peifer
@@ -46,7 +50,9 @@
        Viebrock (fix is to explicitely return null from the character 
handler,
        instead of the text already parsed... a few hundred thousand times)
        http://rt.cpan.org/Ticket/Display.html?id=35672
-
+fix:  RT #47257, minor doc bug, spotted by David Steinbrunner
+      http://rt.cpan.org/Ticket/Display.html?id=47257
+improved: speed, somewhat

Re: what to do with wrong checksum

[Koen Kooi]

On 07-11-09 14:23, Mike Westerhof wrote:
> Frans Meulenbroeks wrote:
> ...
>>
>> Reluctantly updated checksums.ini
>>
>> Frans
>
> But of course there's no magic that will remove the old cached tarball
> out of one's downloads directory when this sort of thing happens.
> (Busybox has been known to do this, too)
>
> What do folks think we should do about that when it occurs?
> a) support two entries (old and new) in checksums.ini
> b) do nothing (leave as is)
> c) add some sort of support so that the user gets additional information
>     with the new checksum match failure explaining that the checksum was
>     updated and they need to manually remove the old (bad) tarball

d) rename the tarball slighty and mirror in on a known good server (e.g. 
angstrom sourcemirror) and have OE use that.

regards,

Koen

Re: what to do with wrong checksum

[Otavio Salvador]

Hello,

On Sat, Nov 7, 2009 at 12:42 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 07-11-09 14:23, Mike Westerhof wrote:
>>
>> Frans Meulenbroeks wrote:
>> ...
>>>
>>> Reluctantly updated checksums.ini
>>>
>>> Frans
>>
>> But of course there's no magic that will remove the old cached tarball
>> out of one's downloads directory when this sort of thing happens.
>> (Busybox has been known to do this, too)
>>
>> What do folks think we should do about that when it occurs?
>> a) support two entries (old and new) in checksums.ini
>> b) do nothing (leave as is)
>> c) add some sort of support so that the user gets additional information
>>    with the new checksum match failure explaining that the checksum was
>>    updated and they need to manually remove the old (bad) tarball
>
> d) rename the tarball slighty and mirror in on a known good server (e.g.
> angstrom sourcemirror) and have OE use that.

IMO (d) is the safest and the right thing to do; this avoids more core
to be written and avoids also we use changed versions without
noticing.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: what to do with wrong checksum

[Frans Meulenbroeks]

2009/11/7 Otavio Salvador <otavio@ossystems.com.br>:
> Hello,
>
> On Sat, Nov 7, 2009 at 12:42 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> On 07-11-09 14:23, Mike Westerhof wrote:
>>>
>>> Frans Meulenbroeks wrote:
>>> ...
>>>>
>>>> Reluctantly updated checksums.ini
>>>>
>>>> Frans
>>>
>>> But of course there's no magic that will remove the old cached tarball
>>> out of one's downloads directory when this sort of thing happens.
>>> (Busybox has been known to do this, too)
>>>
>>> What do folks think we should do about that when it occurs?
>>> a) support two entries (old and new) in checksums.ini
>>> b) do nothing (leave as is)
>>> c) add some sort of support so that the user gets additional information
>>>    with the new checksum match failure explaining that the checksum was
>>>    updated and they need to manually remove the old (bad) tarball
>>
>> d) rename the tarball slighty and mirror in on a known good server (e.g.
>> angstrom sourcemirror) and have OE use that.
>
> IMO (d) is the safest and the right thing to do; this avoids more core
> to be written and avoids also we use changed versions without
> noticing.

Ok, I'll leave it to someone with better access so e.g. the
sourcemirror to change things.
BTW I've exchanged an email with the author of twig. He stated that
the version on CPAN (3.22) is the official version and that the
version we use is the current development version and subject to
change.
He proposed to move the 3.33 version to CPAN (which I encouraged).
Guess we should then move to the cpan version which is the fixed one.

Frans

PS: and I did not think of cached versions of the files, otherwise I
would probably taken somewhat more caution before upgrading
checksums.ini

Re: what to do with wrong checksum

[Otavio Salvador]

Hello,

On Sat, Nov 7, 2009 at 4:00 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
>>> d) rename the tarball slighty and mirror in on a known good server (e.g.
>>> angstrom sourcemirror) and have OE use that.
>>
>> IMO (d) is the safest and the right thing to do; this avoids more core
>> to be written and avoids also we use changed versions without
>> noticing.
>
> Ok, I'll leave it to someone with better access so e.g. the
> sourcemirror to change things.
> BTW I've exchanged an email with the author of twig. He stated that
> the version on CPAN (3.22) is the official version and that the
> version we use is the current development version and subject to
> change.
> He proposed to move the 3.33 version to CPAN (which I encouraged).
> Guess we should then move to the cpan version which is the fixed one.

Even better; I fully agree with it.

If he can do it, it would avoid problems to us.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: what to do with wrong checksum

[Frans Meulenbroeks]

2009/11/7 Otavio Salvador <otavio@ossystems.com.br>:
> Hello,
>
> On Sat, Nov 7, 2009 at 4:00 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>>>> d) rename the tarball slighty and mirror in on a known good server (e.g.
>>>> angstrom sourcemirror) and have OE use that.
>>>
>>> IMO (d) is the safest and the right thing to do; this avoids more core
>>> to be written and avoids also we use changed versions without
>>> noticing.
>>
>> Ok, I'll leave it to someone with better access so e.g. the
>> sourcemirror to change things.
>> BTW I've exchanged an email with the author of twig. He stated that
>> the version on CPAN (3.22) is the official version and that the
>> version we use is the current development version and subject to
>> change.
>> He proposed to move the 3.33 version to CPAN (which I encouraged).
>> Guess we should then move to the cpan version which is the fixed one.
>
> Even better; I fully agree with it.
>
> If he can do it, it would avoid problems to us.

I hope he can. The 3.33 version has changed again :-(

Frans

Re: what to do with wrong checksum

[Koen Kooi]

On 06-11-09 21:38, Frans Meulenbroeks wrote:
> While trying to build xmltv I got this:
>
> NOTE: The MD5Sums did not match. Wanted:
> '495fd8c320f67a0c8e0b90ccb060f0ea' and Got:
> '68d9a93d507bbf917e1f3ad294fd5727'
> NOTE: Task failed: Checksum of
> 'http://xmltwig.com/xmltwig/XML-Twig-3.33.tar.gz' failed
>
> How should I handle this. Of course I can change the checksum, but i
> don't think that is the intention :-)
> Is there a version somewhere cached that has the old checksum (so I
> can compare).
> Or how else should I handle this?

I implemented option 'd':

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7e8f2afa6fb064aaa3b477456c60f64b20caedeb

And I have to repeat that the twig upstream are idiots for behaving like 
this. May the fleas of a thousand camels infest their sensitive regions!

regards,

Koen

Re: what to do with wrong checksum

[Otavio Salvador]

Hello Koen,

On Sat, Nov 7, 2009 at 8:02 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> I implemented option 'd':
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7e8f2afa6fb064aaa3b477456c60f64b20caedeb
>
> And I have to repeat that the twig upstream are idiots for behaving like
> this. May the fleas of a thousand camels infest their sensitive regions!

Simple and fast :-)

BTW, please, use a shorter first line commit message since it is
easier to read and also shows properly in the week log.

Cheers,

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: what to do with wrong checksum

[Michael 'Mickey' Lauer]

Koen,

I usually ignore your pick of language, but I think using such a
language in a commit -- visible to all potential users or contributors
to OpenEmbedded -- is damaging the reputation of the project as a whole.

:M:

Re: what to do with wrong checksum

[Koen Kooi]

On 08-11-09 13:23, Michael 'Mickey' Lauer wrote:
> Koen,
>
> I usually ignore your pick of language, but I think using such a
> language in a commit -- visible to all potential users or contributors
> to OpenEmbedded -- is damaging the reputation of the project as a whole.

Which part of the commit message in 
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7e8f2afa6fb064aaa3b477456c60f64b20caedeb 
did you find damaging?

Re: what to do with wrong checksum

[Frans Meulenbroeks]

Without making a comment on the commit message:

As stated before the 3.33 version is clearly mentioned as "latest
development version" on http://xmltwig.com/xmltwig/
The last stable version is 3.32
This project decided to provide snapshots (or whatever you want to
call it) of the new version. In this case 3.33. Their choice.

IMHO OE should have used the latest stable version.

Frans

Re: what to do with wrong checksum

[Philip Balister]

On 11/08/2009 01:19 PM, Koen Kooi wrote:
> On 08-11-09 13:23, Michael 'Mickey' Lauer wrote:
>> Koen,
>>
>> I usually ignore your pick of language, but I think using such a
>> language in a commit -- visible to all potential users or contributors
>> to OpenEmbedded -- is damaging the reputation of the project as a whole.
>
> Which part of the commit message in
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7e8f2afa6fb064aaa3b477456c60f64b20caedeb
> did you find damaging?

Making remarks about the upstream maintainers is not helpful.

Philip

>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: what to do with wrong checksum

[Koen Kooi]

On 08-11-09 15:08, Frans Meulenbroeks wrote:
> Without making a comment on the commit message:
>
> As stated before the 3.33 version is clearly mentioned as "latest
> development version" on http://xmltwig.com/xmltwig/
> The last stable version is 3.32
> This project decided to provide snapshots (or whatever you want to
> call it) of the new version. In this case 3.33. Their choice.

3.33 is a version. A version is a point, not a distance. If it's a 
snapshot than you should call is twig-snapshot, twig-3.33rc1 or whatever.
Replacing a versioned tarball weekly is *bad*, since you (as upstream 
maintainer) don't know what the "3.33" is your users are complaining about.
And note that *nowhere* on that page it is stated that the development 
version keeps getting updated. And for that matter it also doesn't say 
3.32 is any better.

regards,

Koen

Re: what to do with wrong checksum

[Frans Meulenbroeks]

2009/11/8 Koen Kooi <k.kooi@student.utwente.nl>:
> On 08-11-09 15:08, Frans Meulenbroeks wrote:
>>
>> Without making a comment on the commit message:
>>
>> As stated before the 3.33 version is clearly mentioned as "latest
>> development version" on http://xmltwig.com/xmltwig/
>> The last stable version is 3.32
>> This project decided to provide snapshots (or whatever you want to
>> call it) of the new version. In this case 3.33. Their choice.
>
> 3.33 is a version. A version is a point, not a distance. If it's a snapshot
> than you should call is twig-snapshot, twig-3.33rc1 or whatever.
> Replacing a versioned tarball weekly is *bad*, since you (as upstream
> maintainer) don't know what the "3.33" is your users are complaining about.
> And note that *nowhere* on that page it is stated that the development
> version keeps getting updated. And for that matter it also doesn't say 3.32
> is any better.

Note that I am only relaying what the dev told me and that it by no
means reflect my personal opinion.

And indeed they do not mention that the unstable version can change,
nor that the stable won't change.
It might be that cpan has some rules for not updating stable versions
so it might be that pulling from cpan is better. I don't know cpan and
its way of working well enough to make a statement about that.

--- My personal $ 0.02:
If I want to reuse something from the web, I'm happy that I can get
it, as it saves me work.
If it is not fully the way I want it, I try to convince or educate
them to do things differently.
If they won't, either I have to live with it or avoid that specific
piece of software.
Making snide remarks in a public area only creates irritation and
frustration and does not help./
--- End of my $ 0.02 (and someday I'll learn how to insert a euro
symbol in my emails :-) )

Frans.

Re: what to do with wrong checksum

[Otavio Salvador]

Hello,

On Sun, Nov 8, 2009 at 12:08 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Without making a comment on the commit message:
>
> As stated before the 3.33 version is clearly mentioned as "latest
> development version" on http://xmltwig.com/xmltwig/
> The last stable version is 3.32
> This project decided to provide snapshots (or whatever you want to
> call it) of the new version. In this case 3.33. Their choice.
>
> IMHO OE should have used the latest stable version.

I fully agree and I didn't notice it was state on their website; In
this case the only wrong side here is OE (not upstream).

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: what to do with wrong checksum

[Otavio Salvador]

Hello Koen,

On Sun, Nov 8, 2009 at 12:20 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> 3.33 is a version. A version is a point, not a distance. If it's a snapshot
> than you should call is twig-snapshot, twig-3.33rc1 or whatever.
> Replacing a versioned tarball weekly is *bad*, since you (as upstream
> maintainer) don't know what the "3.33" is your users are complaining about.
> And note that *nowhere* on that page it is stated that the development
> version keeps getting updated. And for that matter it also doesn't say 3.32
> is any better.

If it is bad or not it is up to them (it is their project). If it is
stated that it is a development version in their website then we ought
not take it.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: what to do with wrong checksum

[Koen Kooi]

On 08-11-09 15:55, Otavio Salvador wrote:
> Hello,
>
> On Sun, Nov 8, 2009 at 12:08 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com>  wrote:
>> Without making a comment on the commit message:
>>
>> As stated before the 3.33 version is clearly mentioned as "latest
>> development version" on http://xmltwig.com/xmltwig/
>> The last stable version is 3.32
>> This project decided to provide snapshots (or whatever you want to
>> call it) of the new version. In this case 3.33. Their choice.
>>
>> IMHO OE should have used the latest stable version.
>
> I fully agree and I didn't notice it was state on their website; In
> this case the only wrong side here is OE (not upstream).

Except if you want to read the docs, because the website states that you 
should read the docs of the development version. That fact coupled with 
no obvious signs on that page that the development version shouldn't get 
used, I wouldn't say OE is wrong to use the 3.33 version. Heck, the 
development version is the top item on that page.

Either way, xmltwig is now on "the list".

regards,

Koen

Re: what to do with wrong checksum

[Graham Gower]

I'm with you on this one, Koen. Changing a versioned tarball is just
dumb - it goes against common sense and long standing convention in
release engineering.

As for choosing the 3.32 version, who's to say they won't add a bugfix
and update that tarball too?

-Graham

Re: what to do with wrong checksum

[Przemyslaw Wesolek]

Graham Gower wrote:
> I'm with you on this one, Koen. Changing a versioned tarball is just
> dumb - it goes against common sense and long standing convention in
> release engineering.
> 
> As for choosing the 3.32 version, who's to say they won't add a bugfix
> and update that tarball too?

Beacuse that's not the way the whole CPAN (Perl's packages repository)
works. Version 3.32 is there, version 3.33 is not.

Przemek