Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-05 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Mar 04, 2022 at 01:16:15PM +0100, Kevin Kofler via devel wrote:
> Michael J Gruber wrote:
> > and I have to live with that non-descriptive changelog entry (due to
> > %autochangelog).
> 
> That's why %autochangelog is such a bad idea. A manually maintained 
> %changelog can easily be edited in a followup commit.

$ rpmautospec generate-changelog >changelog
$ $EDITOR changelog
  (Here you want to remove the first entry for "Uncommitted changes",
   and adjust the entries for the rebuild,
   and remove the spurious empty line at the end.)
$ git commit -a -m 'Clarify changelog entries'

Since this commit touches 'changelog' file, rpmautospec will only start
generating %autochangelog entries for commit after this one.

%autochangelog has it's warts, but it certainly can be edited.

Best,
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-05 Thread Sandro Mani


On 03.03.22 17:23, Michael J Gruber wrote:



On 2022-03-03 15:47, Sandro Mani wrote:


On 03.03.22 15:30, Michael J Gruber wrote:
> So, I explicitely asked what your plan was and got no response.
>
> I suggested to fix the problem at the root package and you went
ahead rebuilding depending packages.
>
> I asked you to use proper commit messages/changelog if you do
and got  a series of "Rebuild (leptonica)", "Bump as F36 needs
another rebuild" and what not.
>
> I asked you to at least reference the bz entries and you did not.
>
> While I'm typing this a buildroot override comes along.
>
> We do have an "unresponsive maintainer" process. Do we have an
"unresponsive irreponsible proven packager" process, too?

To be honest I'm saddened by such hostility. I maintain a pretty
large
number of packages mostly in my free time, and I think it's fair
to say
that I maintain most of the mingw and stack alone. I undertook a
pretty
large effort to merge some mingw specs into the native specs
reduce my
workload in the future, often working late into the night. At one
point
I did 197 commits in one day, and for as much effort and
concentration I
put into it, mistakes do happen - I am only human. But I think I've
always been responsive and taken care to address any issues in a
timely
matter. So honestly, rather than attacking people for commit messages
and attacking me for "the problems I caused last time", you might
might
consider using a more friendly tone.

Sandro



Hi Michael


I completely agree with you that communication is key. That is 
actually my point, and that's why the guidelines require or 
strongly suggest communication when a library change affects dependent 
packages or when a proven packager commits into "someone 
else's" packages (I know nobody "owns" a package). And I'm not 
insisting on any points literally here - I'm completely fine with a 
push from which I can tell what's going on, even without prior 
communication or coordination. We have pull requests, we have bugzilla 
entries, we have commit messages to support communication in many 
ways, it does not have to be by e-mail.


What offends me is complete "non-communication": if, as a proven 
packager, you push "Rebuild (tesseract)" to mupdf.git I have to find 
out myself why you can even push to that repo, why you are doing that, 
and I have to live with that non-descriptive changelog entry (due to 
%autochangelog). Plus I have to close the non-referenced bugs. That's 
what happened "last time" (december), and even though it bothered me 
quite a bit I didn't complain.


Uhm, I wouldn't classify [1] as non-communication. As I believe is 
pretty standard procedure, the change was announced to fedora-devel, 
indicating the steps which will be taken and if any action by others is 
required - in this case, I wrote that I'd take care of rebuilding all 
affected packages. A commit message of the form "Rebuild (xxx)" is 
actually pretty common as far as my experience over the past 10+ years 
packaging goes, if you prefer to see "Rebuild for XXX soname bump", well 
I suppose why not. But classifying this as "complete non-communication" 
is I believe pretty unfair.


Another point: to a certain degree, as a packager, you are always 
trusting upstream to ship a working product. What happened later is that 
it turned out that the cmake build scripts of tesseract were pretty much 
broken. The issue was pointed out and, as documented in [1], I promptly 
reacted to fix up the package (delayed a bit while trying to figure out 
an armv7hl build failure due to incorrect cflags ordering, hurray 
debugging build scripts).




Now, since we're having the same with leptonica, I *asked* you to do 
it differently. What I got in response was no response but the same 
kind of pushes. I consider that inappropriate, and the tone of my last 
posting was a desperate attempt to get some form of communication going.


This one was a combination is things: When working on merging native and 
mingw packages (change which I announced), I opted for cmake whenever 
support is available, since it leads to cleaner packaging. So also for 
leptonica, I opted to switch to cmake, with the intention of providing 
compat symlinks to avoid any effect for other packages. As I wrote, I 
forgot the symlink for the versioned library. I judged that most robust 
way forward was to just rebuild the small number of affected packages. 
In the space of a couple of hours all was done, except, blame running to 
fix the problem, I didn't notice that in the meantime bodhi was 
activated for F36 and some packages were build against the old leptonica 
package. So I needed a second rebuild to ensure that NVR in F37 was >= 
NVR in F36.


Pehaps a general request here: it would be useful if fedpkg could give 
you a note when bodhi is active for the build target.


I

Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-04 Thread Kevin Kofler via devel
Michael J Gruber wrote:
> and I have to live with that non-descriptive changelog entry (due to
> %autochangelog).

That's why %autochangelog is such a bad idea. A manually maintained 
%changelog can easily be edited in a followup commit.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-03 Thread Michael J Gruber
On 2022-03-03 15:47, Sandro Mani wrote:

>
> On 03.03.22 15:30, Michael J Gruber wrote:
> > So, I explicitely asked what your plan was and got no response.
> >
> > I suggested to fix the problem at the root package and you went ahead
> rebuilding depending packages.
> >
> > I asked you to use proper commit messages/changelog if you do and got  a
> series of "Rebuild (leptonica)", "Bump as F36 needs another rebuild" and
> what not.
> >
> > I asked you to at least reference the bz entries and you did not.
> >
> > While I'm typing this a buildroot override comes along.
> >
> > We do have an "unresponsive maintainer" process. Do we have an
> "unresponsive irreponsible proven packager" process, too?
>
> To be honest I'm saddened by such hostility. I maintain a pretty large
> number of packages mostly in my free time, and I think it's fair to say
> that I maintain most of the mingw and stack alone. I undertook a pretty
> large effort to merge some mingw specs into the native specs reduce my
> workload in the future, often working late into the night. At one point
> I did 197 commits in one day, and for as much effort and concentration I
> put into it, mistakes do happen - I am only human. But I think I've
> always been responsive and taken care to address any issues in a timely
> matter. So honestly, rather than attacking people for commit messages
> and attacking me for "the problems I caused last time", you might might
> consider using a more friendly tone.
>
> Sandro
>
>
Ciao Sandro

First of all, I appreciate your taking the time to clarify this (and also
the time you invest into Fedora).

I completely agree with you that communication is key. That is actually my
point, and that's why the guidelines require or strongly suggest
communication when a library change affects dependent packages or when a
proven packager commits into "someone else's" packages (I know nobody
"owns" a package). And I'm not insisting on any points literally here - I'm
completely fine with a push from which I can tell what's going on,
even without prior communication or coordination. We have pull requests, we
have bugzilla entries, we have commit messages to support communication in
many ways, it does not have to be by e-mail.

What offends me is complete "non-communication": if, as a proven packager,
you push "Rebuild (tesseract)" to mupdf.git I have to find out myself why
you can even push to that repo, why you are doing that, and I have to live
with that non-descriptive changelog entry (due to %autochangelog). Plus I
have to close the non-referenced bugs. That's what happened "last time"
(december), and even though it bothered me quite a bit I didn't complain.

Now, since we're having the same with leptonica, I *asked* you to do it
differently. What I got in response was no response but the same kind of
pushes. I consider that inappropriate, and the tone of my last posting was
a desperate attempt to get some form of communication going.

Let me point out that I don't blame you for packaging mistakes. Everybody
makes mistakes. Communication can help avoid some of them, though, and
sometimes even the time it takes to communicate helps avoiding some
mistakes such as the rush of build-build again. To emphasize: if you "mess
up" (everybody does) you don't have to clean up all by yourself, just get
the process started and everyone involved.

So, please reconsider your communication strategy as a proven packager.

Freedom friends first!

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-03 Thread Sandro Mani


On 03.03.22 15:30, Michael J Gruber wrote:

So, I explicitely asked what your plan was and got no response.

I suggested to fix the problem at the root package and you went ahead 
rebuilding depending packages.

I asked you to use proper commit messages/changelog if you do and got  a series of "Rebuild 
(leptonica)", "Bump as F36 needs another rebuild" and what not.

I asked you to at least reference the bz entries and you did not.

While I'm typing this a buildroot override comes along.

We do have an "unresponsive maintainer" process. Do we have an "unresponsive 
irreponsible proven packager" process, too?


To be honest I'm saddened by such hostility. I maintain a pretty large 
number of packages mostly in my free time, and I think it's fair to say 
that I maintain most of the mingw and stack alone. I undertook a pretty 
large effort to merge some mingw specs into the native specs reduce my 
workload in the future, often working late into the night. At one point 
I did 197 commits in one day, and for as much effort and concentration I 
put into it, mistakes do happen - I am only human. But I think I've 
always been responsive and taken care to address any issues in a timely 
matter. So honestly, rather than attacking people for commit messages 
and attacking me for "the problems I caused last time", you might might 
consider using a more friendly tone.


Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-03-03 Thread Michael J Gruber
So, I explicitely asked what your plan was and got no response.

I suggested to fix the problem at the root package and you went ahead 
rebuilding depending packages.

I asked you to use proper commit messages/changelog if you do and got  a series 
of "Rebuild (leptonica)", "Bump as F36 needs another rebuild" and what not.

I asked you to at least reference the bz entries and you did not.

While I'm typing this a buildroot override comes along.

We do have an "unresponsive maintainer" process. Do we have an "unresponsive 
irreponsible proven packager" process, too?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-25 Thread Petr Pisar
V Fri, Feb 25, 2022 at 07:37:35PM +0900, Mamoru TASAKA napsal(a):
> Petr Pisar wrote on 2022/02/25 19:10:
> > V Fri, Feb 25, 2022 at 10:46:15AM +0900, Mamoru TASAKA napsal(a):
> > > On f37 / f36 leptonica made some packaging change:
> > > https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide
> > > 
> > > This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which 
> > > I guess is unexpected.
> > > 
> > There was no soname change:
> > 
> > leptonica-1.81.1-2.fc35.aarch64.rpm provides liblept.so.5()(64bit).
> > "dnf repoquery --whatrequires 'liblept.so.5.4.0()(64bit)'" returns
> > no results in F36 and F37. Where can you see libleptonica.so.5.4.0?
> > 
> > -- Petr
> > 
> 
> 
> leptonica-1.82.0-6.fc37
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1924153
> 
I see. I overlooked liblept changing to leptonica.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-25 Thread Michael J Gruber
> On 25.02.22 11:37, Mamoru TASAKA wrote:
> 
> Apologies, my mistake, upstream uses different library names depending 
> on whether you build with autotools or cmake, and when switching to 
> cmake I accidentally only provided the compat symlink for the 
> unversioned link library, but not for the versioned library. I'll 
> rebuild affected packages.
> 
> Sandro

So, is your plan to create the "lept" compat symlink both versioned and 
unversioned? No need to rebuild affected packages then. They have been rebuilt 
during the mass rebuild successfully and FTI now (not FTBFS).

Also, if you do decide to rebuild as a proven packager:
May I ask you to use more descriptive commit messages than "Rebuild 
(tesseract)" and close bugs that you caused (referencing them in the bodhi 
update could help) and maybe correspond with maintainers of affected packages 
in some way (i.e. do it better than the last time this happened)?

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-25 Thread Sandro Mani


On 25.02.22 11:37, Mamoru TASAKA wrote:

Petr Pisar wrote on 2022/02/25 19:10:

V Fri, Feb 25, 2022 at 10:46:15AM +0900, Mamoru TASAKA napsal(a):

On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide 



This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , 
which I guess is unexpected.



There was no soname change:

leptonica-1.81.1-2.fc35.aarch64.rpm provides liblept.so.5()(64bit).
"dnf repoquery --whatrequires 'liblept.so.5.4.0()(64bit)'" returns
no results in F36 and F37. Where can you see libleptonica.so.5.4.0?

-- Petr




leptonica-1.82.0-6.fc37
https://koji.fedoraproject.org/koji/buildinfo?buildID=1924153


Apologies, my mistake, upstream uses different library names depending 
on whether you build with autotools or cmake, and when switching to 
cmake I accidentally only provided the compat symlink for the 
unversioned link library, but not for the versioned library. I'll 
rebuild affected packages.


Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-25 Thread Mamoru TASAKA

Petr Pisar wrote on 2022/02/25 19:10:

V Fri, Feb 25, 2022 at 10:46:15AM +0900, Mamoru TASAKA napsal(a):

On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide

This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I 
guess is unexpected.


There was no soname change:

leptonica-1.81.1-2.fc35.aarch64.rpm provides liblept.so.5()(64bit).
"dnf repoquery --whatrequires 'liblept.so.5.4.0()(64bit)'" returns
no results in F36 and F37. Where can you see libleptonica.so.5.4.0?

-- Petr




leptonica-1.82.0-6.fc37
https://koji.fedoraproject.org/koji/buildinfo?buildID=1924153

Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-25 Thread Petr Pisar
V Fri, Feb 25, 2022 at 10:46:15AM +0900, Mamoru TASAKA napsal(a):
> On f37 / f36 leptonica made some packaging change:
> https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide
> 
> This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I 
> guess is unexpected.
>
There was no soname change:

leptonica-1.81.1-2.fc35.aarch64.rpm provides liblept.so.5()(64bit).
"dnf repoquery --whatrequires 'liblept.so.5.4.0()(64bit)'" returns
no results in F36 and F37. Where can you see libleptonica.so.5.4.0?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

2022-02-24 Thread Mamoru TASAKA

Hello, all:

On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide

This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I 
guess is unexpected.

$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires 
"liblept.so.5()(64bit)" | cat -n
 1  leptonica-1.82.0-2.fc36.src.rpm
 2  mupdf-1.19.0-5.fc36.src.rpm
 3  python-PyMuPDF-1.19.4-2.fc36.src.rpm
 4  tesseract-5.0.1-2.fc36.src.rpm
 5  zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm

$ dnf repoquery --quiet --repo=koji-37 --qf '%{sourcerpm}' --whatrequires 
"liblept.so.5()(64bit)" | cat -n
 1  mupdf-1.19.0-5.fc36.src.rpm
 2  python-PyMuPDF-1.19.5-1.fc37.src.rpm
 3  zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm

(Some of the package were rebuilt on f37 due to another reason, so depending 
packages' number
 differs here)

Currently I am not sure if we can just revert the above change.

Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure