/usr/share/zoneinfo/Europe/Busingen and /usr/share/zoneinfo/Europe/Zurich have exactly the same md5sum: Zurich, Vaduz, Busingen have md5sum = b54a7b1f6e77f2fbdccce79bb64fb32d and so DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile() will return the first of these files it finds while looking into /usr/share/zoneinfo/Europe/. The problem is that DateTime::TimeZone only has data for Vaduz and Zurich, but no data for Busingen. So this command fails: perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "local"); say $a->name' It throws "Cannot determine local time zone" instead of "Europe/Busingen". This makes Bugzilla crash as it depends on this command.
Per http://cpansearch.perl.org/src/DROLSKY/DateTime-TimeZone-1.63/Changes, Europe/Busingen is supported since DateTime::TimeZone 1.57, but Mageia 3 has 1.56 only. :(
Source RPM: (none) => perl-DateTime-TimeZone-1.560.0-2.mga3
CC: (none) => mageiaAssignee: bugsquad => jquelin
Sorry for the time to answer - real life kicked hard. perl-DateTime-TimeZone-1.640.0-1.mga3 now available in mageia 3's core/updates_testing Please test, validate & push. * Testing To test the update, use the following command-line (all on the same line): perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/Busingen"); say $a->name' Before update, it should throw an error message. With update candidate, it should report "Europe/Zurich". * List of s/rpms SRPMs: perl-DateTime-TimeZone-1.640.0-1.mga3.src.rpm RPMs: perl-DateTime-TimeZone-1.640.0-1.mga3.noarch.rpm * Advisory ================ Updated perl-DateTime-TimeZone provides an updated database of timezones. This new version is based on version 2013h of the Olson database and provides new timezones, such as Asia/Khandyga, Asia/Ust-Nera, Europe/Busingen and others. Reference: https://bugs.mageia.org/show_bug.cgi?id=11652 ================
CC: (none) => jquelinAssignee: jquelin => qa-bugs
Whiteboard: (none) => has_procedure
This adds new requires, is that intended Jerome? The bug is fixed with the update though. # urpmi perl-DateTime-TimeZone To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") perl-Test-Fatal 0.10.0 2.mga3 noarch perl-Test-Output 1.10.0 2.mga3 noarch perl-Test-Requires 0.60.0 2.mga3 noarch perl-Test-Tester 0.108.0 2.mga3 noarch (medium "Core Updates Testing") perl-DateTime-TimeZone 1.640.0 1.mga3 noarch 209KB of additional disk space will be used. 387KB of packages will be retrieved. Proceed with the installation of the 5 packages? (Y/n) Before ------ $ perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/Busingen"); say $a->name' The timezone 'Europe/Busingen' could not be loaded, or is an invalid name. Testing with local timezone too.. $ perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/London"); say $a->name' Europe/London After ----- $ perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/Busingen"); say $a->name' Europe/Zurich $ perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/London"); say $a->name' Europe/London $ perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "UTC"); say $a->name'UTC UTC
Whiteboard: has_procedure => has_procedure feedback
That's strange - what you see is the package pulling buildrequires, not requires. I've updated the package to latest version available upstream (there were other timezone updates), and checked that no new runtime deps were added - which is the case: $ rpm -q --requires -p RPMS/noarch/perl-DateTime-TimeZone-1.640.0-1.mga5.noarch.rpm rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 perl-base >= 2:5.18.2 perl(Class::Load) perl(Class::Singleton) >= 1.30.0 perl(Cwd) >= 3.0.0 perl(File::Basename) perl(File::Compare) perl(File::Find) perl(File::Spec) perl(List::Util) perl(Params::Validate) >= 0.720.0 perl(constant) perl(parent) perl(strict) perl(vars) perl(warnings) rpmlib(PayloadIsXz) <= 5.2-1 The perl-Test-* packages are indeed required for *building* the package: $ grep Test: SPECS/perl-DateTime-TimeZone.spec BuildRequires: perl(Test::Fatal) BuildRequires: perl(Test::More) >= 0.880.0 BuildRequires: perl(Test::Output) BuildRequires: perl(Test::Requires) So I don't really understand why there are new deps. Do you had the package installed before urpmi-ing it from updates_testing? Anyway, I propose that we go ahead, even if it's pulling some new deps.
Your results are from Cauldron Jerome but confirmed it's only BuildRequires which have been added in 3. Perhaps this is a bug in urpmi or build system, not sure what to create one against :\ http://svnweb.mageia.org/packages/updates/3/perl-DateTime-TimeZone/current/SPECS/perl-DateTime-TimeZone.spec?r1=418443&r2=596207 $ rpm -q perl-DateTime-TimeZone perl-DateTime-TimeZone-1.640.0-1.mga3 $ rpm -q --requires perl-DateTime-TimeZone rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 perl-base >= 2:5.16.3 perl(Class::Load) perl(Class::Singleton) >= 1.30.0 perl(Cwd) >= 3.0.0 perl(File::Basename) perl(File::Compare) perl(File::Copy) perl(File::Find) perl(File::Spec) perl(List::Util) perl(Params::Validate) >= 0.720.0 perl(Storable) perl(Sys::Hostname) perl(Test::Fatal) perl(Test::More) >= 0.880.0 perl(Test::Output) perl(Test::Requires) perl(base) perl(constant) perl(lib) perl(overload) perl(parent) perl(strict) perl(vars) perl(warnings) rpmlib(PayloadIsXz) <= 5.2-1
Thierry, Thomas, Colin any ideas on this please?
CC: (none) => mageia, thierry.vignaud, tmb
(In reply to Jerome Quelin from comment #4) > Anyway, I propose that we go ahead, even if it's pulling some new deps. I don't see the point to include new deps which should not be there. If the package is bogus, it shouldn't be pushed, IMO.
I'd say it's expected.... as IIRC the perl deps generator is looking at the META.json file # rpmdiff 3/i586/media/core/release/perl-DateTime-TimeZone-1.560.0-2.mga3.noarch.rpm 3/i586/media/core/updates_testing/perl-DateTime-TimeZone-1.640.0-1.mga3.noarch.rpm removed REQUIRES perl-base >= 2:5.16.2 added REQUIRES perl-base >= 2:5.16.3 added REQUIRES perl(File::Copy) added REQUIRES perl(Storable) added REQUIRES perl(Sys::Hostname) added REQUIRES perl(Test::Fatal) added REQUIRES perl(Test::More) >= 0.880.0 added REQUIRES perl(Test::Output) added REQUIRES perl(Test::Requires) added REQUIRES perl(base) added REQUIRES perl(lib) added REQUIRES perl(overload) and a diff on META.json --- DateTime-TimeZone-1.56/META.json 2012-12-01 06:08:04.000000000 +0200 +++ DateTime-TimeZone-1.64/META.json 2014-02-07 23:58:21.000000000 +0200 @@ -4,7 +4,7 @@ "Dave Rolsky <autarch@urth.org>" ], "dynamic_config" : 1, - "generated_by" : "Dist::Zilla version 4.300028, CPAN::Meta::Converter version 2.120921", + "generated_by" : "Dist::Zilla version 5.012, CPAN::Meta::Converter version 2.131560", "license" : [ "perl_5" ], @@ -48,9 +48,12 @@ "File::Copy" : "0", "Storable" : "0", "Sys::Hostname" : "0", + "Test::Fatal" : "0", "Test::More" : "0.88", "Test::Output" : "0", + "Test::Requires" : "0", "base" : "0", + "lib" : "0", "overload" : "0" } } @@ -67,6 +70,7 @@ "web" : "http://git.urth.org/DateTime-TimeZone.git" } }, - "version" : "1.56" + "version" : "1.64", + "x_authority" : "cpan:DROLSKY" }
Expected as in it's desired/ok, or expected as there is a problem with META.json?
Expected and it's desired that we automatically extract deps from the package. It has stated that it needs these new things (although there is certainly some confusion as to why it has an added dep on e.g. added REQUIRES perl(File::Copy) as that's not something that has apparently changed, but either way from the META.json it looks like it should be there - perhaps the perl deps were broken when the original package was built? So if everything works physically as expected that's fine, although I would probably argue that the requirements for some of those bits are likely for the "make check" stage. e.g. I'd guess that it doesn't really need Test::* for runtime, but I could be wrong. Another possibility is that test files are now (accidentally) included in the built package and thus the additional requires are actually extracted from those files? All generic comments made without looking closely!
So likely an upstream bug, if it is indeed a bug. Thankyou both. Testing complete mga3 32 & 64 and confirmed this bug is fixed so I'll validate and allow Jerome to explore upstream.
Whiteboard: has_procedure feedback => has_procedure mga3-32-ok mga3-64-ok
Advisory uploaded. Validating. Could sysadmin please push to 3 updates Thanks
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Thomas, this shouldn't come even if listed in META.json, since they are listed in the test section: "test" : { "requires" : { "File::Copy" : "0", "Storable" : "0", "Sys::Hostname" : "0", "Test::Fatal" : "0", "Test::More" : "0.88", "Test::Output" : "0", "Test::Requires" : "0", "base" : "0", "lib" : "0", "overload" : "0" } } The "runtime" section doesn't list them and the rpm shouldn't therefore have them incorporated. If you look at rpm-setup/perl.req-from-meta you can see: 21 my $requires = $meta->{"meta-spec"}{version} >= 2 22 ? $meta->{prereqs}{runtime}{requires} 23 : $meta->{requires}; Anyway, I wouldn't loose my sleep on this idiosyncracy of the build system for this very package. Forgetting about it now. :-)
(In reply to Jerome Quelin from comment #13) > Thomas, this shouldn't come even if listed in META.json, since they are > listed in the test section: > But still they do :( > "test" : { > "requires" : { > "File::Copy" : "0", > "Storable" : "0", > "Sys::Hostname" : "0", > "Test::Fatal" : "0", > "Test::More" : "0.88", > "Test::Output" : "0", > "Test::Requires" : "0", > "base" : "0", > "lib" : "0", > "overload" : "0" > } > } > > The "runtime" section doesn't list them and the rpm shouldn't therefore have > them incorporated. And yet they get added. > If you look at rpm-setup/perl.req-from-meta you can see: > 21 my $requires = $meta->{"meta-spec"}{version} >= 2 > 22 ? $meta->{prereqs}{runtime}{requires} > 23 : $meta->{requires}; > So theory and reality differs, and we do care about reality > Anyway, I wouldn't loose my sleep on this idiosyncracy of the build system > for this very package. Forgetting about it now. :-) Well, maybe not for this package, but thinking on a larger scale with all perl packages we have, it means bloting inställs with un-needed packages all over... So if our deps generator is broken it needs fixing, atleast in Cauldron so it propagates to all perl packages when we do our next full rebuild (or as soon as they get updated/rebuilt) As for fixing the issue on stable releases, I'm not sure we want it (atleast not until it's properly tested in cauldron) as there is a risk for other breakages ...
Thomas, I agree that we care about it for cauldron. But it works fine in cauldron: $ rpm -q perl-DateTime-TimeZone perl-DateTime-TimeZone-1.640.0-1.mga5 $ rpm -q --requires perl-DateTime-TimeZone rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 perl-base >= 2:5.18.2 perl(Class::Load) perl(Class::Singleton) >= 1.30.0 perl(Cwd) >= 3.0.0 perl(File::Basename) perl(File::Compare) perl(File::Find) perl(File::Spec) perl(List::Util) perl(Params::Validate) >= 0.720.0 perl(constant) perl(parent) perl(strict) perl(vars) perl(warnings) rpmlib(PayloadIsXz) <= 5.2-1 So I was considering ignoring the artefact for this very update.
(In reply to Jerome Quelin from comment #15) > Thomas, I agree that we care about it for cauldron. But it works fine in > cauldron: yeah, and it seems ok in mga4 too, but that brings up another issue... pushing this to mga3 will break upgrade path to mga4 as it has 1.62, and this will push 1.64
Keywords: validated_update => (none)
Good catch!
dammit. I hate updates - can't everyone run cauldron? :-) Ok, so either you remove the 1.64 from updates_testing, and I'll update to 1.62 in mga3, or I update to 1.64 in mga4 too. Here's the relevant changelog 1.64 2014-02-07 - Under taint mode, DateTime::TimeZone->new( name => 'local' ) could die depending on the method used to find the local time zone name. The resulting variable would often be tainted. We now untaint all names before attempting to load them. Reported by Stevie-O. RT #92631. 1.63 2013-10-28 - This release is based on version 2013h of the Olson database. This release includes contemporary changes for Morocco, Librya, and Western Sahara (El Aaiun). 1.64 is not really interesting (taint mode is quite seldom used), but 1.63 has a new update of the database. ==> so, which one do you favor?
(In reply to Jerome Quelin from comment #18) > 1.64 is not really interesting (taint mode is quite seldom used) You are kidding? Taint mode is an important security feature which you should always enable when writing perl code, especially when it accepts user input. Bugzilla has taint mode turned on for this reason.
I'm not saying it's not useful, I'm saying it's seldom used. Also, the bug fixed in 1.64 is not a security one: DT::TZ wasn't un-tainting a variable where it should have. So it's extra paranoid. :-) Therefore the need to update mga4 to 1.64 is less useful, and therefore if qa thinks it's easier for them not to validate 2 updates (one for mga3, one for mga4) then I won't object. Note that we have 2500+ perl rpms in mageia. A lot of them aren't up to date after a new mageia version is issued. And we don't update them unless someone reports a bug here. Now, I can tell you that a lot of the perl module updates that we miss for each mageia release is far more critical than the fact that perl-DateTime-TimeZone could die under taint mode. :-)
It's quick and easy to test Jerome so from QA standpoint you may as well go with 1.64 in mga4. It's already tested in mga3 too. Please make sure Cauldron version is higher than 4 though.
perl-DateTime-TimeZone-1.640.0-1.mga4 now available in updates_testing for mga4
Oh, and cauldron is already at 1.64, so update should be smooth.
Mga4 testers - easy one, procedure is in comment 3 Advisory updated.
Whiteboard: has_procedure mga3-32-ok mga3-64-ok => has_procedure advisory mga3-32-ok mga3-64-ok
Version: 3 => 4Whiteboard: has_procedure advisory mga3-32-ok mga3-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok
Testing complete Mageia 4 i586.
CC: (none) => remiWhiteboard: MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok
In Whiteboard: MGA4-64-OK In VirtualBox, M4, KDE, 64-bit Package(s) under test: perl-DateTime-TimeZone Install perl-DateTime default install of perl-DateTime-TimeZone [root@localhost wilcal]# urpmi perl-DateTime-TimeZone Package perl-DateTime-TimeZone-1.620.0-2.mga4.noarch is already installed [root@localhost wilcal]# perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/Busingen"); say $a->name' Europe/Zurich install perl-DateTime-TimeZone from updates_testing [root@localhost wilcal]# urpmi perl-DateTime-TimeZone Package perl-DateTime-TimeZone-1.640.0-1.mga4.noarch is already installed [root@localhost wilcal]# perl -MDateTime::TimeZone -wE 'my $a = DateTime::TimeZone->new(name => "Europe/Busingen"); say $a->name' Europe/Zurich Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
CC: (none) => wilcal.intWhiteboard: MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok MGA4-64-OK
I don't see a problem here either before or after the update. For me the procedure and update works fine. Lets push it.
Validating then, thanks Bill. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_update
Update pushed: http://advisories.mageia.org/MGAA-2014-0062.html
Status: NEW => RESOLVEDResolution: (none) => FIXED