i will look but i think this can go on backports in the next few days.

CC: (none) => dmorganec

Why backports? Backports from what? There isn't any Mageia 2.
And the current calibre package is *very* obsoleted as it is. 
Why not just releasing an updated version?
Is there any process to decide what can go into backports and what can be updated as a regular update?

>Why not just releasing an updated version?
Because that was the way in mandriva, new version of a program should go
on backports, but in some exceptions.

>Is there any process to decide what can go into backports and what can be
>updated as a regular update?
That is under discussion in mageia-dev ML, feel free to add your proposals.

CC: (none) => anaselli

(In reply to comment #2)
[...]
> Is there any process to decide what can go into backports and what can be
> updated as a regular update?

Generally, yes; if the current version of package "foo" in Mageia 1 meets any of the following criteria then a new version should go to updates:
- crashing/segfaulting
- causing kernel oopses
- a major feature is broken (in calibre's case e.g. corrupts ebooks/reading-device)

Otherwise a new version goes to backports. FWIW, calibre upstream seem to release a new version twice a month, that's too often to go to updates, IMHO.

When an application (this one) releases 32 times in 6 months (THIRTY-TWO TIMES IN SIX MONTHS), and when it's over 5-months old and 31 releases BACK when Mageia 1.0 is released, please DON'T come with such a NARROW-MINDED argument!

Now, Calibre upstream does NOT release a new version twice a month, it releases a new version every 6 days on average!

As I explained on mageia-dev, calibre is indeed too dynamic, part of it because of adding new features, keeping the pace with new e-reader devices, etc, but also because each and every version fixes some bugs! Therefore, royally saying that "it releases too often to be taken into account" would rather persuade people to go for other distros that can follow that pace (e.g. Fedora) or, why not, to Windows.

Sorry about my tone.

Suggestion: suppose an account and some credentials (rights) are given to me, I could maintain this package -- I have built RPMs at some point in the past, in 2009, see:
http://odiecolon.lastdot.org/
or
http://odiecolon.lastdot.org/el5/repoview/

However, building a newer calibre poses no technical problem IMHO, there are usually no differences for the builder from a release to another one. It's more of a "political decision" and something like some time wasted every now and then.

(In reply to comment #5)
> When an application (this one) releases 32 times in 6 months (THIRTY-TWO TIMES
> IN SIX MONTHS), and when it's over 5-months old and 31 releases BACK when
> Mageia 1.0 is released, please DON'T come with such a NARROW-MINDED argument!
> 

Shouting won't help, I think.

> Now, Calibre upstream does NOT release a new version twice a month, it releases
> a new version every 6 days on average!
> 

I've not touched that package in a long time, so if the upstream releases has become more frequent, I wouldn't know.

> As I explained on mageia-dev, calibre is indeed too dynamic, part of it because
> of adding new features, keeping the pace with new e-reader devices, etc, but
> also because each and every version fixes some bugs! Therefore, royally saying
> that "it releases too often to be taken into account" would rather persuade
> people to go for other distros that can follow that pace (e.g. Fedora) or, why
> not, to Windows.

- I didn't say we're not gonna take it into account, we're gonna provide backports for it. Look at wine, it gets updated a lot too, but new versions _always_ go to backports and not updates. That's a packaging rule, because any new version could provide new features, yes, but can also have regressions.

> 
> Sorry about my tone.

(In reply to comment #6)
> Suggestion: suppose an account and some credentials (rights) are given to me, I
> could maintain this package -- I have built RPMs at some point in the past, in
> 2009, see:
> http://odiecolon.lastdot.org/
> or
> http://odiecolon.lastdot.org/el5/repoview/
> 

Feel free to ask for a mentor on the ML (there's now a mentoring coordinator, as per the thread on the dev ML).

> However, building a newer calibre poses no technical problem IMHO, there are
> usually no differences for the builder from a release to another one. It's more
> of a "political decision" and something like some time wasted every now and
> then.

See my previous comment.

Wine is a bad example. It's difficult to know what regressions can bring a new version -- I don't even know what WINE version I _want_ to run because of that!

Calibre -- for the last 2 years, I have been _using_ it almost every day to adjust ePub files, to convert e-books, etc. 

Mentoring: I'm not sure if this is the best option, to get involved for a single package only. I'll think over it. For the time being, I'm investigating a bug that I can't report because, although it constantly happens on Mageia, and it happens slightly rarely on Fedora 15, it doesn't happen at all on Kubuntu 11.04, and I have checked with the way Mageia builds it, there's nothing wrong. So it must be something more general, about some other KDE library, and I am trying to get familiar with building KDE (it's huge). So for the time being I'd say I'm kinda busy.

(In reply to comment #4)
> Generally, yes; if the current version of package "foo" in Mageia 1 meets any
> of the following criteria then a new version should go to updates:

You forgot to mention security fixes. :)

(In reply to comment #10)
> (In reply to comment #4)
> > Generally, yes; if the current version of package "foo" in Mageia 1 meets any
> > of the following criteria then a new version should go to updates:
> 
> You forgot to mention security fixes. :)

That's a given any time of the day, doesn't need mentioning... :)

If I may add my comment, according to the process that's being defined, each update must go throw QA testing to try to ensure that there's no regression. Doing it once per 6 days would be a huge burden in the shoulders of QA Team. 

That being said, there's one strong argument in favor of doing an update (maybe not all subsequent updates) : hardware compatibility. Maybe instead trying to make calibre considered differently that other pieces of software (which from packager's point of view starts with a negative feeling, because we prefer that rules be clear and with as little exceptions as possible), showing why having the current version in core/release + latest version in core/backports (soon) is blocking for users could help.

I am not sure that a packager must perform regression tests on such a package. It's actually impossible, you don't have the proper use cases, test scenarios, etc., you might not have the proper knowledge on how to test generated or converted ePub and Mobi files, and so on.

This is not like packaging a new KDE version for a new release of Mageia. The main responsibility resides with the upstream. Upstream for a large project can have dozens of testers and a lot more time.

For such a generic application, normally the packager has to test on 32 and 64 bits the application like in using it for 15 minutes with basic operations. 

Is there a document (even inherited from Mandriva) that really says that downstream has to check on regressions for _every_ package?!

This is, again, an impossible task. If any distro were able to do that, we would have like zero-bugs distros.

One more word. 

Fedora 15 has for the time being stopped updating calibre tp 0.8.0 (it was released with 0.7.56, but 0.8.0 was pushed into updates). 

Only Rawhide has 0.8.4.

As a user who knows calibre quite well, I can see a logic in this: after each and every calibre release, the package maintainer would parse the upstream Changelog and make a judgment by balancing:
-- announced bug-fixes
-- announced new features
-- announced new hardware supported
-- ad-hoc assessment of the risk brought by the new features (a heuristic process based mainly on experience as a user, experience as a software developer, and common-sense).

I am currently using the latest version, but I could have stopped with 0.8.0 or 0.8.1 for a while. However, the version provided by Mageia...

This is a major problem with _all_ Linux distros, and I don't see how this is freedom: the regular user should obey to the decisions taken by some packagers as in "you don't need this upgrade", whereas in Windows the end-user is sovereign on _what_ version exactly to use, and even downgrading is easier.

The fixes and support for new hardware are arguments for pushing an update.

The bad point is the amount of new features (yes it is :)), because they can (and probably do) bring regressions. The rule is clear : we can't introduce regressions in updates. I'm sorry, but we can't just trust upstream. Experience shows that there ARE almost always regressions when new releases mix features and bugfixes. The amount of bugfixes (including regression fixes) in each release in itself indicates that we must be careful. See for example release 0.7.56 which fixes a big regression introduced by 0.7.55. Had we shipped 0.7.55 automatically (supposing that Mageia would have been ready at the time), we would have shipped a buggy version to our users, which we can't.

However, concerning a tool such as calibre, maybe we could take the risk of version updates, provided enough testing is done.

That's said, I'm not the one to decide :)

A last question : why would be providing the latest versions in backports media not OK ? Users wanting the new version will just have to search for in the rpmdrake and install it.

CC: (none) => stormi

Samuel, I am not sure that Fedora really pushes the latest version of calibre right away. Maybe they wait a couple of days. You see, in the case of serious regressions, calibre would release again quickly.

Not trusting the upstream is a generous idea, yet an absurd one. Does any distro really test for regressions when incorporating a new KDE, XFCE, GNOME or LibreOffice release? _Really_?

When upgrading a widely-used library or something of the kind, one can not trust upstream, because this would break important parts of the distro, but when comes to an application whose upgrade won't affect anything else, I don't see why you should be more Catholic than the Pope.

OTOH, Windows users have the _freedom_ to install the _exact_ calibre release of their choice -- downgrading is much easier than in Linux. Maybe Mageia should address this by making easier for the end-user to downgrade a package, but this is a solution that (I believe) is never going to be solved.

Had you be shipping 0.7.55, you could then push 0.7.56 in updates right away. _Any_ distro releases with major bugs, and this package is not a crucial one.

Keeping a _severely old_ package in a distro just because "this is the right thing to do, for user's safety" makes me feel that Windows is more democratic -- price and licensing aside.

As for "backports", I never liked this concept. I need a stable release of a distro, plus updates. Most distros do this. In other distros, "backports" means backporting from Release+1, not from Unstable, which makes much more sense to me.

(In reply to comment #16)
> Not trusting the upstream is a generous idea, yet an absurd one. Does any
> distro really test for regressions when incorporating a new KDE, XFCE, GNOME or
> LibreOffice release? _Really_?

Yes :) There's testing, that's why there are users using Cauldron and a freeze period before the release : to be able to catch and solve as much bugs as possible, including regressions. It's not perfect, but it's done.

> Had you be shipping 0.7.55, you could then push 0.7.56 in updates right away.

Had we pushed 0.7.55 in updates, we would have introduced new regressions in a stable release, even if for a short time. 

> As for "backports", I never liked this concept. I need a stable release of a
> distro, plus updates. Most distros do this. In other distros, "backports" means
> backporting from Release+1, not from Unstable, which makes much more sense to
> me.

But, why ? Maybe we should rename updates as "stability updates" and backports as "feature updates" ? A backport is not just an unstable version from the development branch, we try to ensure it works well. Plus, in Mageia with have special backports_testing media from which testers can install and test the backports candidates.

backports are simply backports. They can be either patches to add to the version
shipped by stable release, pathces from where? from upstream svn/git/cvs... repositories, or from new upstream programs.
That requires a skilled packager/maintainer, he, for the most, should know the 
program its code and should test his changes and put the new package in testing and if it passes QA / end-users tests it can be put in updates.

But with the term backports we can also talk about program backports, e.g from
upstream or from a newer distro version repository, newer can be either  a followed stable - harder if we think that a often a distro has only one stable 
behind- or the developer one -e.g. mandriva's cooker, mageia's cauldron-.

Googling a bit, i've realized that Ubuntu does exactly the same. I don't know fedora since they tend do release often all, but googling again they refer to redhat backport policy... and there I'm sure they don't upgrade any version for updates if not as last solution.

Than i don't want to spend too many words in a subject we're discussing in ml,
and neither i want to loose users. So a good compromise is as usual case by case 
decision, if someone asks for a backport/upgrade -whichever the final repository 
is it will be an upgrade and not an update imo- and the maintainer is able to do
it than new package could pass through testing repository and if *users* -not
just one- can say there aren't regressions, than it could go to updates.

Angelo, in theory, what you say makes sense. In practice though...

Until *several* users will say that there aren't regressions, calibre will have another release.

Fedora has a simple way: it keeps a newer calibre packages in updates/testing for 1 week, and if no user complains about regressions, it goes into updates. This is because calibre is a "leaf" package -- no other package depends on it, so it only impacts those who are using it. 

I have not used Mandriva very much in the past, because I hate the concept of "backports" -- yes, Ubuntu does them too, but Ubuntu backports are totally unsupported, so you can imagine their "quality"... 
I'd rather stick to "updated" -- this is also the reason I stopped using Debian, because the morons (yes, morons) were only pushing tzdata updates in "volatile", not in "updates", whereas ALL the other distro were pushing tzdata updates in "updates".

If Mageia considers that a 6-7 months old package (for an application that released 32 times in the meantime) only deserves updates in "backports", then I will probably stop reporting any possible bugs with this distro -- as a protest.

It is indeed a matter of principle. I am personally using the latest calibre installed in /opt, not the official one, but again, it's a matter of principle.

I will never use backports. Also as a matter of principle. Whatever is important and comes from upstream must go into updates IMHO. Backports, in my view, only make sense if they're coming from Release N+1 and if they represent a major version bump -- such as FF4 over FF3.6, etc.

first of all i don't think fedora is the right example for us, but that is my opinion. Said that:

>Fedora has a simple way: it keeps a newer calibre packages in updates/testing
>for 1 week, and if no user complains about regressions, it goes into updates.

That's wrong. At least who opened the bug should say yes it works well and i got
no regressions in my testing.
Adding that at least packager/maintainer should have tested it for a while before
submitting... That *could* be a test (maybe not good enough but passed).
Again case by case we can decide to put programs in updates and maybe this could be just the case. 
But couldn't we do that for all the projects?
Not easy, you know, for a lot reasons (dependencies, etc).

I'm a developer and i do like to release early and release often, but often means that only developers have tested for the most so... shit happens.

>Backports, in my view, only make sense if they're coming from Release N+1 and if 
>they representa major version bump -- such as FF4 over FF3.6, etc.
But it seems not to be the point of view of most distros ;)
N+1 anyway is also the next release e.g. the one we're developing on.

BTW i use backports in all the mandriva installations i have, i got trouble in very little cases, that since 2001 up today... i was lucky? maybe... :D

Forgot to say, if calibre, as you said, has not any problems to bu updated - no deps and noone needs it- than an easy way to get it not in /opt is:

urpmi URL-to-backport-mirror/calibre-X.Y.Z.rpm

And you don't need to have backports enabled :)

That's not the same for me... I'm used to get last digikam version instead ;)

(In reply to comment #20)

> That's wrong. At least who opened the bug should say yes it works
> well and i got no regressions in my testing.

No, Sir. In Fedora (I know, not the best example), nobody opens a bug each and every time calibre is too old.

> Adding that at least packager/maintainer should have tested it for a while
> before submitting... That *could* be a test (maybe not good enough but 
> passed).

For our case, calibre 0.8.0 ... 0.8.4 work well, I cannot tell yet for 0.8.5. As per upstream, since there is no Mageia package.

> Again case by case we can decide to put programs in updates and maybe 
> this could be just the case. 
> But couldn't we do that for all the projects?
> Not easy, you know, for a lot reasons (dependencies, etc).

I guess I'll have to paste again that part from Fedora's Update Policy that speaks about "The package is a "leaf" node. Nothing depends on it or requires it."

Calibre is a "leaf" node app.


> I'm a developer and i do like to release early and release often, but often
> means that only developers have tested for the most so... shit happens.


The problem is when the distro maintainers try to be Gods and take decisions for the user. The user has decided to use Calibre. Calibre's developer has decided to release. The user would like to upgrade, but the distro makers say: "Nyet!"

No, in Windows it's easy to downgrade in case of significant regressions. Everyone can do that. Not that easy in Linux though. If I remember correctly from the times when I was using Synaptic with Ubuntu, it was possible from a menu to choose, for each package, what version to install -- this way, downgrades were easy. Mandriva does not offer such a possibility.

Either way, knowing that some major distros released with Linux _kernels_ that brought major regressions, and that _ALL_ the distros release every now and then X.Org with Intel/Nvidia/ATI drivers that _break_ (i.e. major regressions), I feel that so much fuss for a "leaf" applications (that only breaks some features from itself, when this happens) is... too much fuss.

I won't answer to this any more, 
i could argue all your sentences, first of all the
availability to get your old version application back in mandriva, or the availability to install a package into your home using another application that
could make your life easier like you think is in another SO....

But one point is almost irritating, and you seem not to want to find a common 
-open- solution but your, sorry:

>The problem is when the distro maintainers try to be Gods and take decisions
>for the user.
Who's trying to be God, me? or all the other distro contributors? 
Mageia is an *open* distro, all of us are deciding which is the best way to 
go on, nothing has been written, our destiny is in our hands, 
you can propose your ideas, as well as other people.
So who's trying to be God?

(In reply to comment #23)
> first of all the availability to get your old version 
> application back in mandriva

90% of the Linux users don't know how to do that by using the official package management tools.

90% of the Windows users can do that by uninstalling the current version and installing the desired one. No need to prevent an automated update for that application.

> availability to install a package into your home 

90% of the Linux users don't know how to do that (the target group for Ubuntu, openSUSE, Mandriva, Mageia). There is no GUI tool to assist with that. Hey, MCC doesn't even allow me to edit a GRUB entry and add a "chainloader +1"! (extremely limited edited allowed in GUI)

> >The problem is when the distro maintainers try to be Gods and take decisions
> >for the user.
> Who's trying to be God, me? or all the other distro contributors? 
> Mageia is an *open* distro, all of us are deciding which is the best way to 
> go on, nothing has been written, our destiny is in our hands, 
> you can propose your ideas, as well as other people.
> So who's trying to be God?

If you were using your brain, not your pride, you would have noticed that this isn't about a particular distro.

ALL the distros are doing this when they decide what new version of an application to go or NOT to go into "updates" (or "backports", if this makes you happy).

Maintainers of all the distros are too busy to _disallow_ the end-user to use updated applications that would incorporate _some_ regressions, while at the same time being totally impotent when comes to upstream major regressions: KDE 4.0 over 3.5.x, GNOME 3.0 over 2.32, kernels that include regressions, X.Org intel/nvidia/ati drivers that are totally broken for half of the video cards, etc.

Small Gods, if you prefer. Make sure "calibre" is not broken, when there is no way to refuse to incorporate the latest kernel, the latest X.Org, the latest KDE/GNOME, etc.

FYI, I just updated calibre to 0.8.6 in cauldron.
If I have enough return about it, I will see how to update it (backport or not) for 1.

CC: (none) => mageia
Assignee: bugsquad => mageia

Damien,

Cool! ...but I can't find your package on the mirrors! Is it in updates, updates_testing?

I was trying to loon into the .spec, and here's why. 

I have built myself calibre-0.8.6 for cauldron a couple of days ago, and I was just using it.

I had though to adjust and patch as follows:
-- In order to have the e-mail functionality working (yes, it works), I had to add as a dependency python-dnspython, which was lacking, so I had to build it too.
-- I had to adjust a patch so that calibre would still check for updated plugins (rather safe, they're installed in ~/.config/calibre/plugins/), but installing a plugin or checking for an updated plugin would raise an error with the traditional patch that inhibits the automated update checks.
-- There is no python2 symlink to python2.7, but just python, as opposed to python3, so a patch addresses the fact that calibre calls python2.
-- Another tiny patch fixes an import, it should be from QtNetwork, not Qt.
-- 0.8.6 was rushed in and reports to be 0.8.5 in src/calibre/constants.py (the upstream binaries are ok, the sources are not).
-- Localization is now in locales.zip (in %{_datadir}/%{name}/localization/locales.zip), so the old patch is moot.
-- Tiny bug not visible easily, I had to fix the location of liberation default font in 3 py files plus recipes/*_ke.recipe (it's not P('fonts/liberation/LiberationSerif') but ('%{_datadir}/fonts/TTF/liberation/LiberationSerif')).

Have you had the same issues?

I am currently building a few other packages for cauldron and I'll upload in a couple of hours somewhere, so I could ask on the ML whether any of them could be reviewed and accepted.

Should I still fail to see your package, I'll post here the URL to my SRPM, maybe you could look over it. (The binary works fine from what I could test in the last 4 days.)

On cauldron i586 system here, trying to start calibre I get ...
$ calibre
/usr/bin/env: python2: No such file or directory

If i then create a symlink, /usr/bin/python2->python, it fails with ...
$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 18, in <module>
    from calibre.gui2.main import main
  File "/usr/lib/calibre/calibre/__init__.py", line 19, in <module>
    from calibre.startup import winutil, winutilerror
  File "/usr/lib/calibre/calibre/startup.py", line 58, in <module>
    from calibre.utils.localization import set_translators
  File "/usr/lib/calibre/calibre/utils/localization.py", line 65
    allow_user_override=False))
                       ^
SyntaxError: invalid syntax

CC: (none) => davidwhodgins

Dave, just wait for about 1 hour until I upload somewhere my own build -- it addresses a number of issues related to the many changes happened between 0.7.32 and 0.8.6.

But I still can't see that RPM. What mirror are you using?

The hosting I wanted to use has some intermittent problems, so for the time being I've uploaded here:

http://www.mediafire.com/?pdk6pxkc62ks5

the files:

calibre-0.8.6-1.mga2.src.rpm
calibre-0.8.6-1.mga2.i586.rpm
python-dnspython-1.9.4-1.mga2.src.rpm
python-dnspython-1.9.4-1.mga2.noarch.rpm

I hope they have uploaded correctly.

python-dnspython is required for the e-mail functionality. It had been tested. Mageia lacks it (Mandriva had it). 

Not that this would mean much, but I'll attach the public key used to sign the packages (it's an older key I've used in the past for packages for an EL5 repo; the e-mail is not valid anymore, but the domain is).

(I also hoped I haven't forgot to sign them!)

Created attachment 600 [details]
GPG key used to sign the packages previously mentioned

Created attachment 601 [details]
Screenshot of my own build (also testing FR localization).

Just attach diff output of the spec and the rediffed patches (if any).

(In reply to comment #26)
[..]
> -- There is no python2 symlink to python2.7, but just python, as opposed to
> python3, so a patch addresses the fact that calibre calls python2.

We nuke the shebang altogether, no symlinks.

[...]

The initial nuking of the shebang does not fix the issue. It's still added a call to python2.

Everyone can extract the .spec and patches from the SRPM.

I'll attach them after this.

Created attachment 602 [details]
Proposed spec

Proposed spec (except for my name, but I offer to maintain this package)

Created attachment 603 [details]
calibre-no-update-0.8.6.patch

calibre-no-update-0.8.6.patch

Created attachment 604 [details]
calibre-web-control.patch

calibre-web-control.patch

Created attachment 605 [details]
calibre-python2-env-fix.patch

calibre-python2-env-fix.patch

Created attachment 606 [details]
calibre-0.7.38-pyPdf-fix.patch

calibre-0.7.38-pyPdf-fix.patch

Created attachment 607 [details]
calibre-manpages.patch

calibre-manpages.patch (unchanged)

Created attachment 608 [details]
calibre-mount-helper

calibre-mount-helper (unchanged)

i added your changes in our package, tested and it works OK.

I will push this new version in mageia 1 core/update_testing soon.

If you don't add python-dnspython to Mageia, the e-mail sending by calibre won't work.

yes, this is already in cauldron and planned in my update.

Thank you very much, dmorgan, everything seems to be ok, at least in cauldron!

I also noticed the package in Mageia 1, updates_testing, I've checked its spec too.

Unless the mirror I checked was not sync'ed, I didn't notice a python-dnspython package in Mageia 1, but only in Cauldron.

Check again in a few hours...it is propagating to the mirrors now. Note that some mirrors sync only once a day.

CC: (none) => remco

it have been "late" to come because of my connections issues. but now it should be OK.

As soon as QA validate it in mageia 1 it will be pushed in core/updates

I've tested it on my i586 Mageia 1 install, from updates testing, and it looks
ok to me.

(In reply to comment #34)
> The initial nuking of the shebang does not fix the issue. It's still added a
> call to python2.
> 

Sure, that's why the sed command needs to be adapted to the new version of the package

> Everyone can extract the .spec and patches from the SRPM.
> 

But not everyone can easily download a 27MB+ .src.rpm when he only wants to see the spec and patches (given he/she probably already has an SVN checkout of calibre from the Mageia SVN).

[...]

(In reply to comment #38)
> Created attachment 605 [details]
> calibre-python2-env-fix.patch
> 
> calibre-python2-env-fix.patch

We don't use '/usr/bin/env python' at all, either remove the whole line or use '/usr/bin/python' , which is always a symlink to the default version of python in each Mageia release.

No ofense, Ahmad, but are you going to "fix" maybe hundreds of packages whose developers have chosen to use an underoptimal yet working '/usr/bin/env python'?

Fedora doesn't do that. RHEL doesn't do that. As long as it is not broken, one shouldn't try to rewrite 3rd party code.

Just my opinion, but I usually don't like to be "more Catholic than the Pope", as they say.

So, in this punctual case, 
-- if the developer decided to use '/usr/bin/env python2' after he has used '/usr/bin/env python' in previous versions;
-- and '/usr/bin/env python' actually works;
-- and Mandriva leaves it as is;
-- and Fedora leaves it as is;
-- and Ubuntu leaves it as is;
then why "should" Mageia try to "fix" something that is not actually broken?

Patching '/usr/bin/env python2' into '/usr/bin/env python' was done to revert calibre to the way it has been in dozens of previous versions. And it works.

Minimal patching, I'd say.

But again, I have no authority, I'm an intruder almost.

(In reply to comment #51)
> No ofense, Ahmad, but are you going to "fix" maybe hundreds of packages whose
> developers have chosen to use an underoptimal yet working '/usr/bin/env
> python'?
> 

Exactly. We already do that, fix the sheband of every package, and rpmlint should help spot such issues. And it can be fixed with a single sed command, that takes about 1-2min. to type :)

> Fedora doesn't do that. RHEL doesn't do that. As long as it is not broken, one
> shouldn't try to rewrite 3rd party code.
> 

FWIW, the calibre spec in Mandriva was originally imported from Fedora (IIRC), and they do nuke the python shebang. c.f. http://pkgs.fedoraproject.org/gitweb/?p=calibre.git;a=blob;f=calibre.spec

This isn't just about calibre, but through out all the Fedora specs that I've seen (as I usually check them out for patches, improvements... etc).

> Just my opinion, but I usually don't like to be "more Catholic than the Pope",
> as they say.

There're packaging guidelines and rules, they're not there to make packagers' lives harder, but to ensure the quality of packaging in the distro.

Of course, python-dnspython is needed, as it's mentioned by Bug #1882.

But as we're at testing, version 0.8.7 is available upstream, and it includes fixing of a regression.

It can be tested in Cauldron (it might currently work with Mageia 1 too, but it was not tested) from my _unofficial_ repo:
http://mageia.beranger.org/mageia/
http://mageia.beranger.org/mageia/2/repoview/calibre.html

...which is now 11 versions _behind_ the current one, 0.8.18.

Well, one of the people interested in packaging it left... :)

...because the degree of bureaucracy, endless (and useless) discussions, and inactivity was far beyond reasonable expectations :-(

I don't understand how a Linux distro ever gets built with such a hectic organization.

Thanks for the kind words, I'm glad you appreciate the amount of work we put daily into Mageia, it's always too to see one's work appreciated.

Maybe you should disable the mailing lists and IRC. It's depressing to see the level of verbosity out there. Sorry if I've vexed you.

(In reply to comment #59)
> Maybe you should disable the mailing lists and IRC. It's depressing to see the
> level of verbosity out there. Sorry if I've vexed you.

Well, I am also subscribed to the changelog@, and bugs@ ans qa-bugs@ mailing lists, and I see much work being done, do maybe that's why I'm not depressed :)

calibre is in updates

Status: NEW => RESOLVED
Resolution: (none) => FIXED