Showing posts with label mandriva. Show all posts
Showing posts with label mandriva. Show all posts

2011-06-27

cpan2pkg: prettier gui, ready for mageia!

remember cpan2pkg? this is the tool built around cpan2dist to create a native linux package, taking dependencies into account, and integrated with linux distribution repository + buildsystem.

it used to be mandriva only, and curses-based. now that mageia is in full swing mode, i had to port cpan2pkg to support it. and it was a perfect opportunity to clean up the module, and prettify the interface.

here's the result:

on the left, you can see the modules currently being processed, with their status both locally and on the build-system. green means available, and here you can see that moosex::alwayscoerece is being built locally (orange) and is not yet available on mageia (yellow).

note that mageia is fully supported: cpan2pkg will poll the buildsystem status page to follow a module build, and make sure a module is ready before submitting those depending on it.

it is still using poe underneath, but this time with tk. adding support for a platform can be done quite easily - patches welcome!

2010-09-18

good-bye mandriva, hello mageia!

word is spreading fast: mandriva developers & contributors are forking mandriva. the new distribution is named mageia - read the full announce on http://mageia.org. my name being on the announce, no need to say that i fully support this move... :-) more news will be available in the coming days.

2010-07-29

perl's state in mandriva cooker

some time after mandriva 2010.1 has been released, i'm now pleased to report that perl has been updated to 5.12.1, all cpan modules are up-to-date (including padre 0.68) or bugs have been reported upstream... and parrot 2.6.0 is currently building.

the perl 5.12.0 - 5.12.1 upgrade was really smooth: no patch to rediff, reapply, etc. that's definitely a good thing for perl maintainers to have a stable series with only critical fixes going in. i've already said it, but thanks again to p5p!

2010-05-05

perl status for mandriva 2010.1 (version freeze)

it's that time of the year: next mandriva version is due beginning of june, which means all updates are on hold - unless they solve a bug or any other problem worth fixing.

on the perl front, mandriva 2010.1 will therefore ship:
as always, if you miss a perl module, just drop a note (in the comments, or a mail, or on mandriva bugzilla) and i'll package it for you.

2010-04-20

no perl 5.12 in mandriva 2010.1

as announced previously, i did some further testing wrt perl 5.12.0 and mandriva. after having installed it, i've been able to use urpmi and compile various binary perl modules against 5.12.

however, decision has been taken not to push perl 5.12 in spring release. potential for havoc is too important - especially since it's used by many core tools. it'll have to wait after 2010.1 is out... but since all bits & pieces are ready to be pushed, it's now just a matter of time...

2010-04-16

perl 5.12.0 in mandriva?

final perl 5.12.0 is now available. i updated our spec file in mandriva, and it builds ok both on my machine and mandriva's buildsystem - so i pushed it to main/testing. however, i did not manage to rebuild packages having a dep on perl, for an obscure reason having to do with testing media, bad karma or not enough chicken blood - i don't know exactly which reason is the good one.

i now need to have more thorough testing, in order to see if urpmi & other tools still works with new perl. i don't know if i'll have time before mandriva 2010.1 freeze date. not counting the fact that we'll have to create a c-wrapper to replace suidperl used in one of the draktools.

so, back to the question: perl 5.12.0 in mandriva? yep, "soon" - but maybe "soon" will mean "after 2010.1". note that if you can help testing, "soon" may revert to a true "soon" meaning...

2010-03-31

dzil activity

of course, you are aware that dzil v2 is out, with lots of exciting new features, brought to you by rjbs and the perl foundation.

but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.

here's a list of new plugins landed on cpan... first some additional author tests:

some plugins to complete meta-data:
  • Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
  • HomePage - http://search.cpan.org/dist/xxxx
some plugins to customize your build process:

some plugins to generate additional files:

some plugins to compute your next version number:

and finally some bundles:

you can install all of them in one go via task-dist-zilla.

they are also available in mandriva, and suggested when installing dist-zilla...

2010-01-27

stats about cpan modules shipped by mandriva

adam and gabor asked me about some information on what cpan modules are shipped as rpm packages by mandriva... i finally found some time to work on it and produced ordb::cpan::mandriva.

this module is basically a sqlite database replicated automatically by orlite::mirror. using it is very simple - for example, couting the cpan dists shipped by mandriva is achieved by the following snippet:

(fyi, the result is 1899 as of writing, +1 since i just imported the module itself)

at module use time, it will automatically download (and cache for a week) the sqlite database. and one can then use the module as an ordb for this db... the module does not however produces the stats for you - so alias & gabor, now is your turn to work! :-) i'm waiting for your top-100 most wanted mandriva or whatever crazy stats you'll want to produce.

the database itself is generated by module::packaged::generator. this module uses different drivers depending on the current linux distribution (but nothing prevents *bsd to also have a driver) it runs on. only mandriva is supported currently, but ryan will work on a debian driver. all other contributions are most welcome - the code is on github: fork it and send me pull requests!

2010-01-07

cpan task for dist-zilla

dist-zilla has a lot of prereqs. and even when you have installed it, you may need to install other plugins manually. therefore, i just uploaded task::dist::zilla that pulls in all dzil plugins and plugin bundles.

it still takes time to install all those modules, but at least you can do it in one go with cpan or cpanplus: no need to install them one by one manually.

of course, if you're on mandriva, running:
urpmi perl-Dist-Zilla
will install the package perl-Dist-Zilla and all its deps while also suggesting to install all the dzil plugins...

2010-01-04

retrospective 2009

2009's over, but the year was quite a busy one for me on the perl front:
  • i finally took the time to investigate moose, and decided to port some of my code to use it.
  • i discovered dist::zilla, and definitely plan to use it in all my dists.
  • i discovered some other cool new perl modules (thanks guys).
  • i uploaded some new dists on cpan, including games::pandemic (which i'm quite proud of, even if i need to continue hacking on it).
  • i updated & released some of my existing dists.
  • i contributed to other projects such as padre, dist-zilla, etc. sending patches is a good way to thank the author for their work.
  • it's even easier to contribute with github, which i'm using more and more for my projects (and it's no more slow by now, woohoo!). of course, git is the master piece allowing this easy sharing.
  • on mandriva's front, i resurrected parrot rpm, and finally shipped rakudo.
  • 2009 was also the year of the great migration to %perl_convert_version
  • ... with lots of new perl modules available as rpm (i am managing 450 of them).
  • ... and finally i took ownership of perl rpm. (thank you perl5 porters btw for 5.10.1 and the push for next stable version!)
so, busy indeed 2009 was... i just hope that 2010 will be as fruitful on the perl front for me, and for the perl ecosystem by large.

2009-12-29

helping perl packagers package perl modules (for real this time)

chromatic posted a long rant (who would have guessed? :-) ) about perl modules shipped by linux distributions. however, he doesn't have all the answers... nor the experience needed for this rant. since i'm a perl author and mandriva packager for perl and lots of perl modules, i think i have more enlightened information about this topic.

first, let me state that using system perl is fine, but i really discourage it for your enterprise application. the perl version will change from time to time, ditto for the perl modules you are relying upon. so if you want to be in control your software foundation for your app (and you should) - compile your perl and your modules yourself.

second thing: i also discourage mixing using perl modules installed by your package system and by running cpan as root. you'll end up with a mix of files in /usr/perl5 that either belong or not to a system package, which sucks. installing packages in a local lib of yours is fine, which is made quite easy with local::lib by now.

if you're comfortable with those rules, then you're welcome to using the system perl and the modules shipped by your distribution. after all, we packagers are going through this work in the hope of being useful to others - that is, you!

but back to chromatic post. if you want to install cpan modules as system packages, there's already a tool that does it for you: it's called cpan2dist, and is part of cpanplus. it works as long as a backend for your distribution exists. there's currently one for debian, mandriva (that i wrote), fedora and gentoo. it's not that difficult to write, and allows you to write:
# cpan2dist --format CPANPLUS::Dist::Mdv --install Foo::Bar
this will automatically download foo::bar, check its dependencies (and build & install them if needed recursively), build the module as a mandriva package and install it. what else exactly do you want/need? (as a cpanplus backend writer, i do have some things that i'd like cpan2dist to have, but none as a regular user). and if you're a packager and want to integrate cpan2dist with your linux distribution build system, cpan2pkg can help you (even if it's currently stalled due to sthg missing in cpanplus).

however, if you want to help perl packagers package your modules for a distribution, here's a list of thing that you should not do. this is a list of real, practical things to do as a module author - not some generic hand-waving towards the perl community out there. this comes from my experience as packager for mandriva of more than 400 modules, and makes me curse the module author everytime i'm encountering one of those problems...

  • test your dist before shipping. really, i'm not kidding. lots of dists just fail their tests. and not just on linux, on all the platforms. so if you make an update that "just can't fail" (yeah, right) to your dist just before shipping, please run your test suite nevertheless. just in case, you know, it might fail.
  • if you're shipping pod tests that are skipped depending on the presence of test::pod and test::pod::coverage, make sure you have those modules installed, so you are running those tests, too. even better: skip those tests unless RELEASE_TESTING or AUTHOR_TESTING is set. after all, it's nice for you to know you still have some documentation work to do, but i don't care as a packager... and, you know, it's now the standard & recommended way of shipping those tests.
  • those 2 items lead me to another easy thing for module authors to do to help us: check the cpantester status of your dist. investigate all the fails that you have. if you see a fail that is your fault, fix it and upload a new version. it helps us because this prevents us from having to report a bug against your dist. i generally wait 3 or 4 days before reporting a bug on a dist that has some failure reports, hoping (what a fool) that the author will notice by herself that sthg is going wrong.
  • speaking of bug reports, if we take the time to open a report for your dist (very often with a patch attached)... please read it. and act. or at least answer us. either apply the patch, or explain why you don't want to apply it like that... and ship a new version of your dist, with the fix included.
  • but of course, before reporting a bug, we should find the bug tracker. so, by using rt.cpan.org, you really help us to have a single unified point of contact. i know that rt is kind of slow, not very intuitive, has some problems and could be cleaned out a bit... but it is here, bestpractical is providing & administering it for us for free, and has this nice feature of having a queue for every perl dist on cpan. if you don't want to use it, there are some more polite ways of saying it... and giving the url of your tracker helps, too. oh, and if i took the pain to play by your rules and report a bug to your non-standard bug tracker, i would greatly appreciate that you act on my ticket. or at least, you know, just acknowledge the fact that you received the report.
  • if you want to really piss off a packager, a simple but effective way is to change your versioning scheme every now and then, by (ab-)using your knowledge of perl way of understanding versions. in the same major version, of course. going from version 1.470 to 1.50 is not funny. if you want to change your versioning scheme, you can change the major number to. after all, i'm pretty sure that you're not paying any extra money per major number used in your dist. this is what caused us to mangle the version of perl modules shipped in mandriva.
  • speaking of regular changes, it's irritating to have to follow you through your use of makefile.pl to build.pl to makefile.pl to build.pl to... well, you understand what i mean. even to use this shiny replacement that is module::build, or this oh-so-marvelous module::install, oh no finally module::build way of working fits me better in retrospective... it's ok for you to change from time to time, but changing at every version of your dist - just make up your mind dammit!
  • speaking of it, i hate module::install. and especially its feature that prompts and tries to handle the deps itself coz-it's-so-cool-it-can-do-it-for-real. sorry, but that's not your job in the tool chain. just report that you miss some deps. i know that there's a flag to make this feature go away while launching makefile.pl. but i don't want to bother and would rather expect that the whole stuff has sane defaults...
  • oh, and in case you're wondering - every prompting in the configure phase (makefile.pl or build.pl) sucks and should be banned.
  • having clear and up-to-date dependencies would be fine, too. i know it's not always easy to have them correctly, but you can change your tools and adopt one that extract your prereqs for you.
  • try to avoid dependency on modules that are known to fail. even if it works in your setup, trust cpantesters if they tell you that it fails 95% of its reports: it might not be a good idea to depend on it.
  • trying to support old perl versions and old releases of modules is fine, but update your modules and see if your code work. some functions may become deprecated, or you were relying on a buggy behaviour, or whatever. we update the perl packages as we see new versions, not only your modules. so a linux dist will usually have latest & greatest version of all the modules - you'd better be sure that your code work with them, hmm?
  • finally, if you're developping under macosx, make sure that you don't ship resource files, or textmate temp files. having ._Foo.pm in the dist is not fun: automatic compile tests will fail, unless that's your manicheck or signature check. and even if everything in perl dist is fine, things may bork in the repackaging of the system package due to a file not listed. so, be extra careful when shipping your dist - or change platform and burn your shiny toy that calls itself a computer (careful & clever readers may have guessed from previous sentence that i don't like macosx - but that's not a reason to ditch this post and not to follow the advices i'm reporting).
there, i think that's a pretty good start. i've encountered each and every item of this list at least once (i stopped counting exactly how much a long time ago). don't take it personally if you made some of those mistakes - i have done almost all of them by myself as module author (except of course using module::install and using a mac, but you could have guessed for at least the last part). what's important is to realize that those behaviours are annoying for packagers, and that changing those habits is quite easy to do (except for the burning your mac part, because i agree that it's not very environmental-friendly - see, i'm not that stubborn! ;-) ).

if you're following all those advices, packagers of your modules will love you. (or at least, not hate you - which is still a win :-) ). i know i will...

2009-12-16

parrot 1.9.0 available in mandriva

since parrot 1.9.0 is officially out, it landed quite quickly in mandriva cooker. next rakudo version will soon follow.

2009-12-09

rakudo available in mandriva

after some chat with parrot-porters, i finally undertood that what's get installed in /usr/src/parrot (and that i was trimming during installation) is not parrot full source, but intermediate forms of pmc, needed if high-level languages want to subclass them. they are thus now shipped in parrot-src package - and this is enough for rakudo to be compiled.

therefore, rakudo 2009-11 is now (finally) available in mandriva...

2009-12-05

mojomojo now available in mandriva

after struggling quite some time with its dependencies, and then some other prereqs not mentioned deep in the dependency chain, i'm happy to report that mojomojo, the catalyst powered wiki, is now available in mandriva.

2009-11-09

cpan activity

with mandriva linux 2010.0 out, it's time to have a look at cpan activity once again.

version freeze happened on october 1st for mandriva, at which point it wasn't possible to upload new version - unless to fix a bug preventing usage. since we know that cpan modules don't have such bugs[0], it means that almost no perl package was updated till cooker[1] reopening (which happened on november 6th).

so, how many dists needed an update after ~40 days? around 150. yes, 150. on 1685 distributions shipped by mandriva. and some of those were updated more than once...

that's ~10%. a bit less than what was reported in april for mandriva 2009.1, but:
  • this time it's for whole mandriva, not only the packages i'm responsible for
  • freeze was a bit longer for 2009.1
yet another proof of perl community's health.

[0] :-)
[1] cooker is mandriva's development version

2009-11-03

the state of perl in mandriva 2010

mandriva linux 2010 is out... this is thus a good time to have a look at the state of perl in this release.

adelie (mdv 2010 codename) ships perl 5.10.1 with threads[0], which allowed me to drop half the patches carried within mandriva[1]. and since perl 5 porters hope to make perl 5 releases more often, it means that (hopefully) i'll be able to trim down those patches even more!

on the modules front, mandriva is shipping plenty of them. padre 0.47 (and lots of plugins), moose, poe framework (and lots of components), devel modules, dbi drivers, gui (tk, wx, gtk) and various lib bindings, you name it... using book's pearl of wisdom, this gives us[2]:
12117 installed modules
including 11016 from cpan (15.65% of cpan)
that is 1685 distributions (8.88% of cpan)
that's not half of cpan, but a good deal nevertheless. chances are that you will find the module you need - and if you don't, drop me a mail or open a request and i'll package it for you.

but the biggest change that you will see in mandriva 2010 regarding perl (well, maybe you won't even notice it), is the new standardized version scheme forced upon all perl modules. for example, dist-zilla version 1.092680 is shipped for mandriva 2010 in rpm perl-Dist-Zilla-1.92.680. yes, i know, it means that the mandriva version might differ from upstream version. yes, i am aware that this sucks. yes, i am also aware that there's no real way to get upstream version back from mandriva rpm version. and no, i don't plan to roll back this change - unless you have another miracle solution that deals with rpm not understanding cpan modules changing their versioning scheme without bumping their major (grrr!).

however, note that previous mandriva version (and fedora too) already mangled some modules version, but not all of them - which is even worse imo. since i agree with david that version numbers should be boring, all modules now have their version mangled. no ifs, no buts, we're mangling it. and it makes life easier for us packagers...

of course, the modules' code is not affected by this change. it's only the packaging that changed a bit. to check which version is installed, just check the $VERSION of this package. that's always been, and remains, the only safe way to be sure. eg:
$ perl -E 'for (@ARGV){eval "require $_"; say "$_\t",$_->VERSION if !$@}' Dist::Zilla
Dist::Zilla 1.092680
on the parrot front, we're shipping 1.6.0 (1.7.0 was too late to be included). and rakudo is still not present, since it cannot use an installed parrot.

all in all, that's a quite a good release on the perl front. if you add all the work that went in all other areas, mandriva 2010 will be quite a solid release. i invite you to test it out - who knows, you might even like it so much that you'll switch to it permanently! :-)

[0] no need to complain, rgs - i know your feelings about it.
[1] yup, i took the ownership of the perl package - silly me...
[2] why, yes, i install all perl modules available as rpm on my box :-)

2009-10-05

mandriva 2010 coming - which perl modules do you miss?

mandriva's next version (2010.0) is now in version freeze, for a release date in early november. this means that current packages are not allowed to be upgraded to latest version, unless there's a compelling reason to do so (security update, crash or big regression).

there is still, however, the possibility to ship new packages. so if you miss some perl modules in mandriva and you really want them available as rpm packages in 2010.0 version, now is the time to speak up! just add your request as comment to this post, and i'll do my best to fulfill it.

2009-08-24

perl 5.10.1 has hit cooker

perl 5.10.1 is out, so i just built it for mandriva cooker - after fighting the build system which seems to be broken very often those days. :-(

it's currently propagating on mirrors, and should hit your machines soon... lots of other packages will need to be rebuilt, so you may want to run urpmi with the --keep flag.

in other news, parrot 1.5.0 is also available on cooker since yesterday.

2009-08-09

perl 5.10.1-rc1 available on mandriva

perl 5.10.1-rc1 has been released 3 days ago, so i packaged it for mandriva. the good thing is that a lot of patches that we were adding to our perl are now merged upstream.

the new perl (perl-5.10.1-0.rc1.2mdv at the time of writing) rpms are available in mandriva testing media. you can install them with:
# urpmi perl perl-base --media "Main Testing"
please report any problem to either mandriva cooker mailing list, or to perl 5 porters if that's a perl related bug.

2009-08-01

converting & rebuilding mandriva perl modules rpm

as time went by, the %perl_convert_version[0] macro in rpm has proven useful to convert perl version number to something that rpm will (should) always be able to parse. i also patched mandriva's perl.prov and perl.req (that automatically extracts requires & provides for perl in rpm packages) to use %perl_convert_version also.

the last step happened this week, when guillomovitch has converted youri checks to also compare newer cpan version with %perl_convert_version. therefore i'm currently migrating the not-yet converted mandriva perl rpm package to use %perl_convert_version also[1]...

expect some problems during installation till all modules are converted. this should be solved soon.


[0] so that eg 1.54 is understood as 1.540.0, and thus greater than 1.470 - as on cpan.
[1] when the build system works! :-)