Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Hi, Ole Streicher a écrit le 03/12/2018 à 11:02 : > About 30-40 of those are mine, BTW. And I am still unsure whether hdf5 > is not really the cause of the problem yet, since it is the HDF5 test > case in gnudatalanguage is the only one where I don't see a reason for > the failure yet. Just "let us migrate" is the wrong way here -- the CI > migration delays are to find out where the problem is before. Please read the bugreport: I've done my homework and rebuilt gnudatalanguage against HDF5 1.10.0 and netcdf 4.6.1 to check whether the current HDF5 transition could be the cause of the failures. The answer is no: autopkgtest still fails in that case. BTW test_hdf5 is in d/tests/test-gdl.xfail. It is not the cause of the current autopkgtest failure. About the bug severity, I don't care actually, as soon as it doesn't block the HDF5 transition. Thanks, _g.
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
On 03.12.18 10:02, Sebastiaan Couwenberg wrote: > On 12/3/18 9:54 AM, Ole Streicher wrote: >> On 03.12.18 09:41, Sebastiaan Couwenberg wrote: >>> hdf5 is unable to migrate to testing because gnudatalanguage >>> autopkgtests fail. Test failures indicate that the package is broken, >>> and not suitable for release. It should be removed from testing until >>> the test failures are fixed, which also allows hdf5 and its rdeps to >>> migrate to testing. >> >> That is currently in the decision of the package maintainer. Neither the >> policy nor the RC document you cited list CI test failures or migration >> delays as a possible cause for severity "serious". >> >>> As announced the autopkgtest delay is increased exponentially which will >>> block packages from getting into buster before the final freeze. We do >>> not want that to happen, but your package is not allowing hdf5 and its >>> rdeps to migrate even though there is nothing else preventing this part >>> of the transition. >> >>> Fix your failing autopkgtests or remove them. Not fixing failing >>> autopkgtests in your package that prevent its dependencies from (timely) >>> testing migration is very unfriendly (to phrase it very mildly). >> >> I totally agree, I am affected as well, and I am working on it. You >> shouldn't think that an "important" bug does not get attention. But this >> also does not reason the severity "serious". > > Yes, it is. Your package is broken and needs to be removed from testing > as soon as possible, as it negatively affects its dependencies. The package works well, with a few things that do not work. This is what we call "normal" or "important" bugs. "negative effects" is not "breaks". Migration delays are not breakages. > important severity does not trigger autoremoval, serious does. Sure, so what? > The RC policy hasn't been updated for autopkgtests yet, but I expect > failing tests to become an official reason for RC severity as that > removal from testing of that package will be the only way to let its > dependencies migrate to testing (without release team hints). Unless this is the case you can't cite that as an argument for being RC. Also not the policy. > If a fix is forthcoming, why not let gnudatalanguage be autoremoved from > testing, and let it migrate again when it has been fixed? > Do you think that keeping your package in testing is more important than > all the other ~100 packages involved in the hdf5 transitions? According > to popcon it's not. About 30-40 of those are mine, BTW. And I am still unsure whether hdf5 is not really the cause of the problem yet, since it is the HDF5 test case in gnudatalanguage is the only one where I don't see a reason for the failure yet. Just "let us migrate" is the wrong way here -- the CI migration delays are to find out where the problem is before. Best regards Ole
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
On 12/3/18 9:54 AM, Ole Streicher wrote: > On 03.12.18 09:41, Sebastiaan Couwenberg wrote: >> hdf5 is unable to migrate to testing because gnudatalanguage >> autopkgtests fail. Test failures indicate that the package is broken, >> and not suitable for release. It should be removed from testing until >> the test failures are fixed, which also allows hdf5 and its rdeps to >> migrate to testing. > > That is currently in the decision of the package maintainer. Neither the > policy nor the RC document you cited list CI test failures or migration > delays as a possible cause for severity "serious". > >> As announced the autopkgtest delay is increased exponentially which will >> block packages from getting into buster before the final freeze. We do >> not want that to happen, but your package is not allowing hdf5 and its >> rdeps to migrate even though there is nothing else preventing this part >> of the transition. > >> Fix your failing autopkgtests or remove them. Not fixing failing >> autopkgtests in your package that prevent its dependencies from (timely) >> testing migration is very unfriendly (to phrase it very mildly). > > I totally agree, I am affected as well, and I am working on it. You > shouldn't think that an "important" bug does not get attention. But this > also does not reason the severity "serious". Yes, it is. Your package is broken and needs to be removed from testing as soon as possible, as it negatively affects its dependencies. important severity does not trigger autoremoval, serious does. The RC policy hasn't been updated for autopkgtests yet, but I expect failing tests to become an official reason for RC severity as that removal from testing of that package will be the only way to let its dependencies migrate to testing (without release team hints). If a fix is forthcoming, why not let gnudatalanguage be autoremoved from testing, and let it migrate again when it has been fixed? Do you think that keeping your package in testing is more important than all the other ~100 packages involved in the hdf5 transitions? According to popcon it's not. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Processed: Re: Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Processing control commands: > forwarded -1 https://github.com/gnudatalanguage/gdl/issues/537 Bug #915207 [src:gnudatalanguage] gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip Set Bug forwarded-to-address to 'https://github.com/gnudatalanguage/gdl/issues/537'. -- 915207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915207 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Control: forwarded -1 https://github.com/gnudatalanguage/gdl/issues/537 Hi Sebastiaan, On 03.12.18 09:41, Sebastiaan Couwenberg wrote: > hdf5 is unable to migrate to testing because gnudatalanguage > autopkgtests fail. Test failures indicate that the package is broken, > and not suitable for release. It should be removed from testing until > the test failures are fixed, which also allows hdf5 and its rdeps to > migrate to testing. That is currently in the decision of the package maintainer. Neither the policy nor the RC document you cited list CI test failures or migration delays as a possible cause for severity "serious". > As announced the autopkgtest delay is increased exponentially which will > block packages from getting into buster before the final freeze. We do > not want that to happen, but your package is not allowing hdf5 and its > rdeps to migrate even though there is nothing else preventing this part > of the transition. > Fix your failing autopkgtests or remove them. Not fixing failing > autopkgtests in your package that prevent its dependencies from (timely) > testing migration is very unfriendly (to phrase it very mildly). I totally agree, I am affected as well, and I am working on it. You shouldn't think that an "important" bug does not get attention. But this also does not reason the severity "serious". Best regards Ole
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
On 12/3/18 8:59 AM, Ole Streicher wrote:
>>> autopkgtests for 0.9.9-1 still fail [0], and since it's blocking the
>>> migration of hdf5 it makes the package unsuitable for release
>>> justifying the RC severity [1].
>>
>> Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
>> IMO that a package that worked before does not work anymore -- but hdf5
>> still works nicely, right?), and it also does not block the transition.
>>
>> As far as I know, CI tests are currently setup in a non-blocking way.
>> And when I look into the maintainer page of hdf5, it says
>>
>> "Required age increased by 30 days because of autopkgtest".
>>
>> This is not a block, this is just a delay. There never was a statement
>> that failing CI tests are RC (or would become so before buster).
>>
>> So, you you please be a bit more explicit how the RC policy applies here?
hdf5 is unable to migrate to testing because gnudatalanguage
autopkgtests fail. Test failures indicate that the package is broken,
and not suitable for release. It should be removed from testing until
the test failures are fixed, which also allows hdf5 and its rdeps to
migrate to testing.
As announced the autopkgtest delay is increased exponentially which will
block packages from getting into buster before the final freeze. We do
not want that to happen, but your package is not allowing hdf5 and its
rdeps to migrate even though there is nothing else preventing this part
of the transition.
Fix your failing autopkgtests or remove them. Not fixing failing
autopkgtests in your package that prevent its dependencies from (timely)
testing migration is very unfriendly (to phrase it very mildly).
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Oops, I am deeply sorry that I have sent this under the wrong email
address. Especially sorry to you, Gilles. I have no idea how this
happened (Thunderbird with virtual_identity; I probably mixed up
something there), and it was not intentional.
Best
Ole
> Hi Sebastian,
>
> On 03.12.18 00:15, Sebastiaan Couwenberg wrote:> Unfortunately the
> autopkgtests for 0.9.9-1 still fail [0], and since> it's blocking the
> migration of hdf5 it makes the package unsuitable for> release
> justifying the RC severity [1].
> Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
> IMO that a package that worked before does not work anymore -- but hdf5
> still works nicely, right?), and it also does not block the transition.
>
> As far as I know, CI tests are currently setup in a non-blocking way.
> And when I look into the maintainer page of hdf5, it says
>
> "Required age increased by 30 days because of autopkgtest".
>
> This is not a block, this is just a delay. There never was a statement
> that failing CI tests are RC (or would become so before buster).
>
> So, you you please be a bit more explicit how the RC policy applies here?
>
> Best regards
>
> Ole
>
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Hi Sebastian,
On 03.12.18 00:15, Sebastiaan Couwenberg wrote:> Unfortunately the
autopkgtests for 0.9.9-1 still fail [0], and since> it's blocking the
migration of hdf5 it makes the package unsuitable for> release
justifying the RC severity [1].
Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
IMO that a package that worked before does not work anymore -- but hdf5
still works nicely, right?), and it also does not block the transition.
As far as I know, CI tests are currently setup in a non-blocking way.
And when I look into the maintainer page of hdf5, it says
"Required age increased by 30 days because of autopkgtest".
This is not a block, this is just a delay. There never was a statement
that failing CI tests are RC (or would become so before buster).
So, you you please be a bit more explicit how the RC policy applies here?
Best regards
Ole
Processed: Re: Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Processing control commands:
> reopen -1
Bug #915207 {Done: Ole Streicher } [src:gnudatalanguage]
gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl,
test_point_lun, test_save_restore, test_zip
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions gnudatalanguage/0.9.9-1.
> notfixed -1 gnudatalanguage/0.9.9-1
Bug #915207 [src:gnudatalanguage] gnudatalanguage: autopkgtests fail:
test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Ignoring request to alter fixed versions of bug #915207 to the same values
previously set
> severity -1 serious
Bug #915207 [src:gnudatalanguage] gnudatalanguage: autopkgtests fail:
test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Severity set to 'serious' from 'important'
> block 913837 by -1
Bug #913837 [release.debian.org] transition: hdf5
913837 was blocked by: 914493
913837 was not blocking any bugs.
Added blocking bug(s) of 913837: 915207
--
913837: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913837
915207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915207
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Processing control commands: > severity -1 important Bug #915207 [src:gnudatalanguage] gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip Severity set to 'important' from 'serious' -- 915207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915207 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Control: severity -1 important Hi Gilles, I think that failing CI tests are not a reason for severity "serious", and your test build should have succeeded independently of the tests. GDL has quite a lot of tests failling, and I disable the known one in the CI tests (only). So, CI test failure here shows that there were unexpected failures. Concidently, however, there was a new version of GDL published today, which addresses a number of failures. Again, the failures known upstream are xfailed in the CI tests. I'll upload the new version and close this bug with the upload. Cheers Ole
Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip
Source: gnudatalanguage Version: 0.9.8-7 Severity: serious Justification: Block HDF5 and netcdf transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Autopkgtest fails for gnudatalanguage [1]. This is not due to HDF5 nor netcdf transitions, because I've rebuilt gnudatalanguage on unstable against HDF5 1.10.0 and netcdf 4.6.1 and I observ the same failures: The following tests FAILED: 69 - test_bug_n000720.pro (Failed) 93 - test_fft_leak.pro (Failed) 96 - test_file_delete.pro (Failed) 103 - test_fix.pro (Failed) 106 - test_formats.pro (Failed) 114 - test_hdf5.pro (Failed) 116 - test_idlneturl.pro (Failed) 129 - test_make_dll.pro (Failed) 140 - test_n_tags.pro (Failed) 142 - test_obj_isa.pro (Failed) 144 - test_parse_url.pro (Failed) 150 - test_point_lun.pro (Failed) 166 - test_resolve_routine.pro (Failed) 168 - test_rounding.pro (Failed) 171 - test_save_restore.pro (Failed) 190 - test_total.pro (Failed) 201 - test_zip.pro (Failed) Unfortunately I don't have the knowledge to dig further into this issue. Thanks, _g. [1] https://ci.debian.net/packages/g/gnudatalanguage/unstable/amd64/ - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlwCyh4ACgkQ7+hsbH/+ z4NHOgf/WRRJMYmvqXncFMwNPW0hdXaB/MBsbWXUog8K62QL4ZVBqBZxGihtGkL3 Iv/sLSG3sX1/INS921cwEUnLztR8pe3JnX9WOp8+V1ko9lTsVD5Qs8IFqV+Ex8p0 CqWGzVBkSpUNL4k9AMCyAvAW+B4J8vp1HdxUr3HcsLn7Yets1DoImTwepZX+RPwI XABz5u9hAgrzWcVLz3CVLZXQP25yo46u3K6dNzLmPQ7bKz5voe8WUYKnLf/DEX7g nI8HLzHUTGbdbIKE+9lkSBr6CkrjsG8iglEVERyg40GQRVvwoaP8+bj2lP+JVnDF 4y/6QRpWJSSPMXxibmvh8kdgOCvphg== =xVNn -END PGP SIGNATURE-
