Re: autopkgtest and generated files
Xiyue Deng writes: > (I'm not subscribed to the list so please keep me CCed.) > > Hi Debian mentors, > > I encountered a behavior difference between the package test during > building and in autopkgtest. When attempting to fix a emacs-wgrep FTBFS > bug[1], I added a new file through a patch[2] to the package which > should be used during the test phase. This works as expected during > package building[3] phase (which actually uses the dh_elpa_test but else > should behave the same as dh_auto_test). But during autopkgtest it > doesn't find the new file I added and fails[4] even though it was > running the same command as the building test phase. > > It was suggested to me that autopkgtest doesn't take generated files > into account. Is this true? If so this looks like a limitation of > autopkgtest. I wonder whether there is anyway to workaround this > restriction, or to disable autopkgtest that prevents the migration of > the package[5] as this is a false positive. > > TIA. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057559 > [2] > https://salsa.debian.org/emacsen-team/emacs-wgrep/-/commit/62bc99d768bcb290612b834c668f131e9f5b53f0 > [3] https://paste.debian.net/1301172/ (the test phase log) > [4] https://ci.debian.net/packages/e/emacs-wgrep/testing/amd64/41007238/ > [5] https://tracker.debian.org/pkg/emacs-wgrep > > -- > Xiyue Deng > So it turns out that this is not an autopkgtest issue at all, but that the package has a debian/elpa-test file[1] that specifies which files should be kept for autopkgtest, and I should just add the newly generated file to the list and problem solved! And now I feel silly.. [1] https://salsa.debian.org/emacsen-team/emacs-wgrep/-/blob/master/debian/elpa-test -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Sean Whitton writes:
> Hello,
>
> On Sun 10 Dec 2023 at 09:09pm -08, Xiyue Deng wrote:
>
>> So a little further reading from the policy[1] and the lintian bug[2]
>> helped me understand the usage of "Built-Using" a bit better: it's used
>> to include other source package required for building without having to
>> depend on them. So technically it's not mutually exclusive with
>> arch:all as stated in the bug. However, in the case of
>> persp-perspective, I tried with or without it and it doesn't make any
>> difference. What's important is that ${elpa:Depends} correctly added
>> elpa-perspective and elpa-projectile to the dependency list of the
>> binary package. So I think in the end dropping it should be OK.
>>
>> Still, it makes sense to clarify the actual reason to drop it, so I've
>> updated the changelog entry to reflect this fact[3]. PTAL, TIA!
>
> Well, it's more about ensuring that those source package versions aren't
> dropped from the archive by dak, rendering us license-incompliant.
> Thanks for looking into it further. I've made a further change to your
> changelog message. Please take a look.
LGTM. Thanks!
>
> I've also noticed that there has been an upload to the archive,
> 1:0.2.0-4, which is not accounted for in our history. Please merge it
> in. 'gbp import-dsc apt:persp-projectile/sid', and then a manual merge,
> is probably what you want, because of how the patches are unapplied.
Not sure how I missed this, sorry about that. Somehow `apt source`
cannot find persp-projectile, and I see that there is actually a
"debian/1:0.2.0-4" tag created but the change is not merged to master
since I worked on it, so I just merged from the tag and resolved the
conflicts. Also rebuilt and pushed to mentors[1]. PTAL, TIA!
[1] https://mentors.debian.net/package/persp-projectile/
--
Xiyue Deng
signature.asc
Description: PGP signature
