[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1091945: org-roam: FTBFS: error: (void-function emacsql-sqlite)



Xiyue Deng <manphiz@gmail.com> writes:

> Hi Ayermic, Sean,
>
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> On Fri 10 Jan 2025 at 02:13pm +01, Aymeric Agon-Rambosson wrote:
>>
>>> Hi,
>>>
>>> Le jeudi 9 janvier 2025 à 02:06, Xiyue Deng <manphiz@gmail.com> a écrit :
>>>
>>>> It looks like the cause is that the current latest release of org-roam
>>>> was too old (released in 2022) and doesn't work with emacsql 4.1.0 (and
>>>> hence also blocking the migration of emacsql).  The latest snapshot of
>>>> org-roam works fine, and I have prepared an update to that, together
>>>> with various other fixes of packaging, e.g. standards version, metadata,
>>>> section, doc-base, etc.  This is also done following the
>>>> dgit-maint-debrebase workflow.  This work is pushed to the
>>>> latest-snapshot-to-fix-1091945 branch[1] and the diff to the master
>>>> branch can be seen at [2] (to make it easier to find, my change starts
>>>> at bce17c63).
>>>
>>> Thank you very much.
>>>
>>>> It would be great if Aymeric or other team members can review it.  Once
>>>> approved I'll merge it and ask for a sponsor for uploading. TIA!
>>>
>>> I've had the chance to review. It looks fine to me, apart maybe for the
>>> changes in the watch file. I have been told that the git mode is quite
>>> demanding of debian infrastructure resources.
>>>
>
> (See below)
>
>>> Nonetheless, I have no strong feelings about this, so I'll upload the package
>>> as soon as you merge to master and add the dch -r commit.
>
> Thanks for confirming, I'll try to sync the master branch and let you
> know.
>

I have now pushed the changes to master.  Please help review and upload
if it looks OK.

>>
>> Yes, if we don't have to use mode=git then we shouldn't.
>>
>> It means our infra clones the whole repo every time, instead of making a
>> simple http request.
>>
>
> Thanks for bringing up this.  I checked the uscan manual and it said
> that the default for "gitmode" is "shallow", so AIUI it shouldn't be
> that costly, right?
>

So it turns out that "origtargz" requires debian/watch to look for a
matching snapshot matching the version string in d/changelog or it won't
work.  "git deborig" still works as it just requires the upstream-tag as
specified in d/gbp.conf, however I almost made the wrong tag if it's not
saved by the the snapshots tracking d/watch: the latest upstream commit
was made in Jan 10 in -5 time zone, and when converting to +0 it becomes
Jan 11, and if d/watch didn't catch this my "2.2.2+git20250110.<hash>"
will always be smaller than the correct snapshot version.

As gitmode defaults to "shallow", I would prefer to keep it this way as
an extra sanity check until upstream tags the next release, and I'll
update the d/watch again to track the upstream tags.  Hope this is
acceptable.

>> -- 
>> Sean Whitton
>
> -- 
> Regards,
> Xiyue Deng

-- 
Regards,
Xiyue Deng

Attachment: signature.asc
Description: PGP signature


Reply to: