Hello Aymeric,

On Tue, Jul 09, 2024 at 01:35:07PM +0000, Debian FTP Masters wrote:

Changes:
org-roam (2.2.2-2) unstable; urgency=medium
.
* Adopt the package from Sean Whitton.
* Bump standards version to 4.6.2 (no changes required).
* Stop rebuilding texi documentation, use upstream provided version
(Closes: #1074742).

Hmm, was this the only option to fix this?

If we don't rebuild the docs, it's hard to be confident that it *can* be rebuilt with only tools in main. And if it can't be rebuilt with only tools
in main, it's not DFSG-free.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you for your contribution to Debian.



Accepted:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Tue, 09 Jul 2024 14:47:42 +0200
Source: org-roam
Architecture: source
Version: 2.2.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Emacsen team <[email protected]>
Changed-By: Aymeric Agon-Rambosson <[email protected]>
Closes: 1074742
Changes:
org-roam (2.2.2-2) unstable; urgency=medium
.
* Adopt the package from Sean Whitton.
* Bump standards version to 4.6.2 (no changes required).
* Stop rebuilding texi documentation, use upstream provided version
(Closes: #1074742).
Checksums-Sha1:
772fdf1d528894481f34adeadc5732edcd3c632c 2311 org-roam_2.2.2-2.dsc
7b5d396655373bbc49585580445af1ddfe88595c 4000 org-roam_2.2.2-2.debian.tar.xz Checksums-Sha256:
53ff920c64391adf378260858098b7fc1e5af9eae33a19371779f32e98f94bcb 2311 org-roam_2.2.2-2.dsc
b875b775e5ba2492ed0261924d0e1bd0f8818d499eca0814c351f35f1dc878d7 4000 org-roam_2.2.2-2.debian.tar.xz
Files:
ff3c2b2d2e14022139564f5e95fba24f 2311 editors optional org-roam_2.2.2-2.dsc
0c4ca5d6c79c9ffce0a271e399dfed93 4000 editors optional org-roam_2.2.2-2.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQJMBAEBCgA2FiEEn7AKhFUciKVyzk7dN19hUwLeWCgFAmaNNx4YHGF5bWVyaWMu YWdvbkB5YW5kZXguY29tAAoJEDdfYVMC3lgoI9oP/2rnNYv2QBNyDLdV8Ry6NvWG rXJKOCEVb85vV8Ow/9YGapj1vrQtCDFh0KZWB0XOf4RK5Y1U1nTJipLQ5yQeS8n+ lZthe9ndoXKZZoTbbnNJZOKRkZk9i8CRow3j4OIISNNEamIH10x7P4U7z+G514n/ GSkvNTugAdo/vLZV38biYTvIgrdjI1w/yv++CX40Zx7pVbcfJKkGgIYmNTUULxi4 jQscSFckk8iyKyI6sfIuFDpkR9yCA79sIiMcc7IVU1p6BsHo+cRe7WnC6SzHThWo 4L8MYiVoTeSb4bDMoyBsD1iOIoHl+MmbZ/Y+uYSj1Rb/dq3HnZuJ15Ap85cuYk6y UBDAmYQMRNi2fBx8ASyGsIfYCC8HITHzNMRYwiDBF739S/u6JDqHTSlkLyZY18Uc zk4MTbUJCN2NFW3hMRfo0kQCavxD9ZlAOS+5DzIoQaj4FxD7Cn2tFBc4Di08CCng 40yrwpkWGNzU4vlCJkpEnQPfMC1JAsWPC0vd29U13S6WPqhDMtZvXTaY2Tqa+UUJ iEPHOzGWrb5YqxC4++V0rMJUoTdL16yJvmGOoFD3PASeXQMwJY/s56fT3/q1nNA8 CcRw536uq1q1YER07yKn85ykxrHYTG/Lz761tXZ4TtPCBaiwVkxe7IfMwYMpKH4x OHM60DcQE0aU4KeLnUW/
=3qfq
-----END PGP SIGNATURE-----


--==============i11723595665178895=Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQTziqJOuF8J+ZI8pJSb9qggYcy5IQUCZo08iwAKCRCb9qggYcy5 IVeWAP0cdqH65VJp2HhBAWwVOBF8k+DLGrBdwXg9FDfJ9UNvQgD/RqY3pWyPZHVF r409ewpqtWqAtnOiBY7+HNj4Rf1DJA0=xl7N
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Wed 10 Jul 2024 at 02:38am +02, Aymeric Agon-Rambosson wrote:

Hi Sean,

Le mardi 9 juillet 2024 à 21:56, Sean Whitton <[email protected]> a écrit :

If we don't rebuild the docs, it's hard to be confident that it *can* be
rebuilt with only tools in main. And if it can't be rebuilt with only tools >> in main, it's not DFSG-free.

I should have been clearer in the message. The docs that we are shipping are the info and html versions, and those we still build (from the upstream-provided texi file). They are not provided by upstream, so we have to
build them. We can be confident that we can build them only with tools in main
(in fact, only texinfo is needed), because we do.

What we are not doing anymore is rebuilding the texi file from the org file, despite the fact that both are provided by upstream and we ship none of them to our users. This rebuilding of the texi file was the cause of the bug and a hassle, to be honest (upstream uses extra features in the texinfo backend that
forced you to package ox-texinfo-plus only for this in 2020, a package that has now been obsoleted by upstream). My thinking was that if upstream is nice enough to provide the source code documentation in two different languages (org and texi), we are free to use the most practical one.

Unfortunately this isn't how DFSG works. Whether or not we ship the
files to users is not relevant.

We must be able to rebuild the files from the preferred source for modification. If we don't know that we can rebuild the .texi from the
.org using only what's in Debian, then it would be an RC bug.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmaN3pMZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQEiaD/0QzeP0AeTyiBGRbQlLjGEv wZApH4xbqLeHy7oxB+7+dEePUGU53demieyM44GN/Z8uEESll2Hed9nxGVnWkSFV HeY6Ao4xxfKUagUl6ueSdDSiAhT141gr2EHL4t4TkhW9LYme2/6Zkk3MZ4F0bGEe AmEoy0AthQs3Q3E3b/T2ClsZP7keygKdyR4J2/RvVmQLN5KmLQm62w3iuUbt/mPe 4C+8oC825XKDjHK26fDG0UK+OceI1wD3EoxfGLarYwGDhgdZFRoFGkajV1DCfN34 8nA6NWmZEA5AXu0fmSP8kJPU07v0iYsAp79Ma0WAZS46GblNPt+FpGPm4LLnhUsP rfnm/p7vlyuV+Glrt5WyzTgkPSJaWWgHH5LqngijhitbHIUg++rgmQ0Md3uqEdNw xd878oDgBVDDs1gVdPZaQiaDCm6CfS0wbTbQev8XMalv96/DQBQwKO8pJTRNRgwR Rf8PX0nfsPVscc2bI8e5PAlfoRR1V9dg6HwyMdFlTFddyeDTM5R+nXHRwBvTEaQI DDSxj2AoHJKQKHstLgjEzmygXWUscNALKE9Qa5VZvwggbKXMuqIq9aYhQFOMjGdz 6wB4KWj2wW00cH2VXvoeULp7Y5s1ZRdB8JpePGZCJ3ZgG7I5cWx5PrMdEEukYs5b DGulXg0Pw2Sq9Q2TJCwgow==JRXi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hi Sean,

Le mardi 9 juillet 2024 à 21:56, Sean Whitton
<[email protected]> a écrit :

If we don't rebuild the docs, it's hard to be confident that it
*can* be
rebuilt with only tools in main. And if it can't be rebuilt
with only tools
in main, it's not DFSG-free.

I should have been clearer in the message. The docs that we are
shipping are the info and html versions, and those we still build
(from the upstream-provided texi file). They are not provided by
upstream, so we have to build them. We can be confident that we
can build them only with tools in main (in fact, only texinfo is
needed), because we do.

What we are not doing anymore is rebuilding the texi file from the
org file, despite the fact that both are provided by upstream and
we ship none of them to our users. This rebuilding of the texi
file was the cause of the bug and a hassle, to be honest (upstream
uses extra features in the texinfo backend that forced you to
package ox-texinfo-plus only for this in 2020, a package that has
now been obsoleted by upstream). My thinking was that if upstream
is nice enough to provide the source code documentation in two
different languages (org and texi), we are free to use the most
practical one.

Hmm, was this the only option to fix this?

Probably not.

Best,

Aymeric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le mercredi 10 juillet 2024 à 09:06, Sean Whitton
<[email protected]> a écrit :

We must be able to rebuild the files from the preferred source
for
modification. If we don't know that we can rebuild the .texi
from the
.org using only what's in Debian, then it would be an RC bug.

I was not aware of this idea of preferred source for modification. Nonetheless, I do not think it is that obvious that the .org file
is the preferred source for modification. If it was, why ship the
.texi file at all ?

Most commits that modify one file also modify the other in the
same way. When they don't, sometimes you have typos corrected
first in the .org file, then in the .texi file in a later commit,
but sometimes also the opposite.

Do we absolutely have to declare one or the other exclusively the
preferred source for modification ?

But if we insist on declaring the .org file the preferred source
for modification, I could also solve the .texi regeneration bug,
but only later(TM).

Best,

Aymeric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Wed 10 Jul 2024 at 06:45pm +02, Aymeric Agon-Rambosson wrote:

I was not aware of this idea of preferred source for
modification. Nonetheless, I do not think it is that obvious that the .org file is the preferred source for modification. If it was, why ship the .texi file at all ?

Because regenerating the .texi is hard and many upstreams care much less
than Debian about rebuilding everything than source.

Most commits that modify one file also modify the other in the same
way. When they don't, sometimes you have typos corrected first in the
.org file, then in the .texi file in a later commit, but sometimes
also the opposite.

Do we absolutely have to declare one or the other exclusively the preferred source for modification ?

But if we insist on declaring the .org file the preferred source for modification, I could also solve the .texi regeneration bug, but only later(TM).

We don't have to make a declaration: we have to determine the truth.
If you were going to make complex edits you would always fix it in the
.org and regenerate the .texi, right? You wouldn't manually edit both.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmaPItUZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQA29D/9pTduMI7ZMt20bnaUkYgoY nT9tJuOerkeU3xEPFjzCzbiMj0Sb0LOsQQrBk3J1U7Xpwxm+xhbLdB+5mgHHDuIl RNUSnUuANTUBk9u7BvKt9M8VNo3q5hgHqFau/HabgMit4qE3VOnOzzDmPSrqW/nh f+kVgIVhPIQYfhNWSmGfTsYTDCUiBxXuoRaOhramnFJ+X+dY6QofarMFT55kXoNW LSAVmyrrQldAQSXd2wYL6Czd8izsj5ZuuMeX7ZXpF2TdV63ddSUu8pEMarnv2Ems r2+VG+gCejhFT2q8g7sGYsnBiXZON3/FYml4bxkPQvwl3JkDoAjyWaqsOjQzctTB BmJnqaItVj8h/hK8+MfHGsxJK+YpAQDUsDOI1ylBpkvYR8KgHWkjjS09yqY41n1e 2NeQ06oCgWC1iI1l59wDZCNfhAu+n6EVzpuCFVKWPyGgLoY0CXo5VBV9BF+CvGrU oxSjQKFD8XldrckLTfOqqm1I5ptLkzaZ/P1ANgCCbbcKWw5dhQ7tq0Ztwp2Zidq0 ltImvKQIDinxgsecbsg8lO7wDDyaqPHd8jLd2wU9VicJpmfnCeSfpoiaCwDPFQ3O tpR1rR6raIdPU9/vuFLszQBa9x4BrulQKR617/t+db5T6DHtdXOGJCgmxUsuA5uC Z822xUCRDDN+kk5N2T16Fg==V37w
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hi,

Le jeudi 11 juillet 2024 à 08:09, Sean Whitton
<[email protected]> a écrit :

If you were going to make complex edits you would always fix it
in the
.org and regenerate the .texi, right?

That would indeed be my own preference, yes.

I just did not think that I could deduce from it that it was
upstream's preference too. I still think it has to be established
according to how upstream actually works.

Which we can beyond doubt, in this case. I thought there was a
commit (fee008c) that seemed to indicate the opposite (that
sometimes modifications to .texi predate the equivalent
modifications in .org), but I was wrong.

Sorry about the noise.

It turns out that repairing the regeneration of the .texi file is
simpler than expected, it should be done shortly.

Best,

Aymeric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Thu 11 Jul 2024 at 03:14pm +02, Aymeric Agon-Rambosson wrote:

Hi,

Le jeudi 11 juillet 2024 à 08:09, Sean Whitton <[email protected]> a écrit :

If you were going to make complex edits you would always fix it in the
.org and regenerate the .texi, right?

That would indeed be my own preference, yes. I just did not think that I could
deduce from it that it was upstream's preference too. I still think it has to be established according to how upstream actually works.

I agree, I just don't think it's their typo-fixing practices that
matter, but rather their substantive changes.

Sorry about the noise.

No problem, you learned something :)

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)