Hi Maximiliano,
On Tue, 9 Jun 2015 10:13:41 Maximiliano Curia wrote:
> El 2015-06-09 a las 12:52 +1000, Dmitry Smirnov escribió:
> > Just to let you know about some progress with packaging of calligra_2.9.5.
> > I've spent a day working on it and committed my changes to repository.
>
> Nice.
Thank you.
> > New version introduced some new build dependencies; changed paths to many
> > .desktop files etc.
>
> I see that you made a lot of changes in your last commit, that's wrong and
> evil, much worse than not having a dep3 header in the patches, please do
> independent commits for each change.
Noted. No worries, will do. Last commit is consistent with upstream changes.
"Lots of changes" are compartmentalised into one commit because they are all
related to upstream changes. There is no harm in packaging new upstream
release by making one bundle commit and then make smaller changes if
necessary. If you changing installed library names would you do it in one or
two commits -- one to change .install files and another to adjust lintian-
overrides? Either way is not "right" or "wrong" but just a matter of taste. I
have no problems making smaller commits (and I usually do it except when it is
a "new upstream release" commit) but on this particular instance I see little
benefit from chunking commit bringing new upstream version into several
smaller ones. I apologise if you find it inconvenient and I'll remeber your
preferences for the future.
> > Since I'm not yet familiar/confident with calligra packaging I'm not sure
> > what to do about changes in "gemini" and "krita-sketch".
>
> I havent followed the changes made by upstream, can you explain what are the
> changes that you are refering to?
As I've mentioned in TODO.Debian, it seems that "krita-sketch" disappeared and
"krita-gemini" was renamed to "calligragemini". I have no further details as I
was not following upstream changes either. Hopefully somebody knows better
what happened...
> > I summarised remaining issues in TODO.Debian. Namely there are still some
> > "not installed to anywhere" files that we probably need to ship;
>
> Most certainly, the easier way to decide to which part it belongs is to
> identify the CMakeLists.txt that installs them.
Nice idea, thank you.
> > auto-generated copyright is rubbish and very inaccurate
>
> It's not a good idea to start participating in a team and call rubbish to
> the previous work, please, avoid that attitude.
I'm not exactly new to the team although I'm not too active either.
I meant no disrespect but please let's be honest and straightforward.
I call it "rubbish" because it is. :( I'm not happy to admit it but I've said
so because it is true. There are too many mistakes, BSD-3-clause files
identified as GPL-2, incorrect copyrights and even non-free file which was
missed because somebody did a very sloppy work reviewing copyrights and
licenses.
Usually first thing I do when I package new version is compare current and new
release tarballs file by file to identify and document changes. With calligra
that was useless because original copyright have little relevance. So far I've
never seen "debian/copyright" as inaccurate as the one calligra have. I'm
happy to work on it as soon as I manage to allocate some time. Current
"automated" approach to "copyright" file in "calligra" is not maintainable and
too prone to mistakes.
> I'm counting more than 25k files, I'm sure there is room for improvement in
> the checks that we do on them, but I wouldn't discard an automatic tool that
> helps you with that.
Automated tool that produces so many errors and can't even generate
maintainable file compliant with copyright format specification is not
helpful. I tend to see it as harmful because it encourages laziness. Usually
it takes only few hours at most to review differences and document upstream
changes, if copyright file is accurate. So now we are facing a lot more hours
for this task because somebody did not do the job properly...
> > I left some patches commented in "debian/patches/series" -- it would be
> > nice if someone could double-check them to confirm that they are safe to
> > remove.
> channelFlags_logic_change.patch
> tests-temporarily_disable_failing_tests.patch
> and
> tests-disable_convolution_failling_tests.patch
>
> are related to the autopkgtests tests. Have you run the autopkgtests?
Not yet, sadly I did not have time for this. I think I'd like to take care of
copyright first. Besides I'm not familiar with those tests so I'm not sure if
those patches are still relevant to version 2.9.5. Tests-related patches seems
to be obsolete but I'd like to confirm that with somebody involved to calligra
maintenance.
> cmake-do_not_install_removed_files.patch
>
> is related to the prune-non-free (now excluded-files in debian/copyright),
> does the install phase works?
Of course it does. I wouldn't push changes that break build...
> > From now on please let's tag all patches as per DEP-3 recommendation,
> > shall we?
>
> DEP3 is overrated,
No it is not. As (new) maintainer I need to see whether patch was forwarded,
its origin and what problem it addresses. DEP-3 headers are very useful.
> currently git commit headers are more useful,
Well, I'd argue with that because git commit headers do not include references
to Debian and upstream bug reports etc. But of course _any_ headers are more
useful than none and in calligra all patches are undocumented... It is wrong
that I have to dig history to find when and how a patch was introduced and
what for...
> allow a
> simpler patch submission, and can be used with a patch queue manager. I
> agree that we need to document our patches better. A simple way to promote
> this is to ask about the patches, if someone else is interested in the
> patches then the patch creator is more inclined to write a better
> description.
We're all agreed that some documentation in patch headers is useful. Any
documentation really and I'm not too concerned about particular format. It is
all about best practice and documenting patches should not be that hard even
when there is only one maintainer. I'd say documenting patches is a must for
team-maintained packages.
--
Regards,
Dmitry Smirnov.
---
Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill
Attachment:
signature.asc
Description: This is a digitally signed message part.