1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Package marked for autoremoval due to closed bug?

    From Scott Kitterman@21:1/5 to Steven Robbins on Fri Mar 15 06:10:01 2024
    On March 15, 2024 3:54:05 AM UTC, Steven Robbins <steve@sumost.ca> wrote: >According to the "action needed" section for nifticlib [1], it is:

    Marked for autoremoval on 31 March: #1063178

    But that bug is fixed for the version in unstable.
    Why does that cause the package to be removed?

    [1] https://tracker.debian.org/pkg/nifticlib

    Because the bug still exists in Testing. Once the package in Unstable migrates, all is well.

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steven Robbins@21:1/5 to All on Thu Mar 14 22:54:05 2024
    According to the "action needed" section for nifticlib [1], it is:

    Marked for autoremoval on 31 March: #1063178

    But that bug is fixed for the version in unstable.
    Why does that cause the package to be removed?

    [1] https://tracker.debian.org/pkg/nifticlib

    Thanks,
    -Steve

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

    iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmXzxl0ACgkQyeVeL63I 9LmBxBAAp6l7ZfQt3YsFJ/3WmVnfTyyKeEcZwqfEQskJ0YgnNGmpNdl8Mloi6Uk6 8WdwnWyOCjRCzQUPGLZ6y9wGfGcCn06zhW7ymEPi7vBLEL37nadZBZprc4UEWNbK dmOWrD3gHVvUjvI+Vwyj8rOiu6wzCBkTd73IWvzNSn7vD63JdrHW5C8fLoNQAUvC TIIuTNSotbgpNHuCi8b5kIVjEtcpVkhkAy0WU6IF2NMKE7jvPb+87mDXkvnZv4Sl 8cCGXBwI7XBVW4CQfte7TrqJtjE7n7rxaNGu/n5VYdv0O/VF+Z79MtqtM34aOfvA Nboo+T6AbLm1yjyPnOGn8jOerpGtpsdrHQish6o9EkJqiZVkMGw8SwwqBgBLvvfy aWDKkrpYJYm52B6gKE3SPB0GNtzUk4b14ljCmVehL+t2x+Zy/HS63SI/ztCYJuGy N0XbWZXH0/8oRKi3Xxr2i0b/p0mPeO8Qb0bnTv95BTCskU96AzusGb/hCuN6R3aS +rHZonbj5wLLgu52T7y6Dhn5gE7ad0N6d9JKMDkXLzjRPthpdwaQWLD9KwajgWoe +CwjWbj85z6Q8MhFXXSu+OGD9HrRfuwiHI/HhG1k7icUvmcsnWoDeiefMbVIcAod pMf7AL6jef/8Nh88nKMdGBjMrwb7vwedBdnpeLBQXZQbhyfzFjo=
    =RgRt
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to Scott Kitterman on Fri Mar 15 06:20:01 2024
    On Fri, Mar 15, 2024 at 05:03:55AM +0000, Scott Kitterman wrote:
    On March 15, 2024 3:54:05 AM UTC, Steven Robbins <steve@sumost.ca> wrote: >According to the "action needed" section for nifticlib [1], it is:

    Marked for autoremoval on 31 March: #1063178

    But that bug is fixed for the version in unstable.
    Why does that cause the package to be removed?

    [1] https://tracker.debian.org/pkg/nifticlib

    Because the bug still exists in Testing. Once the package in Unstable migrates, all is well.

    Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity?

    --
    Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

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

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXz2WYACgkQVo0w8yGy Ez2Q/hAAnWd0SaB9tsJU7E8VTW2nN6xpdz5Iowx6Tjz00YrdnwKqis9GUPic2bUB KFsk4977fJxvcLKKKkcTNPNBcfJTPVHGLsggLymBhhpkw0ZyQJ1mo6J4RsElfFig bSwicynRBVJXNKFl7zwOvmHEY1LOs2cnnpg5l9mgR256Wj6dusf3mWaovc6TRdyA GrF3q+yachIhdCPrAzhpO5CyodPMjUthOMuQ7zaJtRxalDeHCk5vNpxFIXLCnPPh O0jsKwC/Ozg7z2yRZ6VUtrIt7ujKE0FprZ69JmVnsfKCxwy3oDAK3tMorFEcBg3s e3nY0e+eMc7058P220W7l/EEkOga78M5V8/YXf6FbbGwDf7AnGAacAYstR6XFFgP dgC8O+uwW1Y9x/PZPr4VFGidI3Kcl/nPEb0iqQnSLae/ezAHcBt7ESWz2QUz8cgn ajGrSmo31RFVOOhJQQ6ocS/SoVmNfLmTxKnUpfe3Se1068F5oYlKqm0q+nc7MClQ Uxa7fVVdTLJAnrLgt7ZHEkX9wnEhFestOUL5hoEPOc9YQhRQk2/173IbCwEYLtMa ArRxxNP/Sjm5V4a9c57l
  • From Andreas Tille@21:1/5 to All on Fri Mar 15 07:20:01 2024
    Am Thu, Mar 14, 2024 at 10:15:18PM -0700 schrieb Steve Langasek:

    Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity?

    I'm in favor of important severity for those bugs maintainer can't do
    anything about. It creates a lot of noise with testing removal
    warnings. I simply remove all those testing removal warnings in my
    mailbox to cope with this and by doing so I'm probably missing real
    issues I should rather care about.

    Thanks to all who are involved in this complex migration
    Andreas.

    --
    http://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Gevers@21:1/5 to All on Fri Mar 15 22:00:01 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------B7VheTAyIF80z0taTdBOm2mj
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGksDQoNCkRpc2NsYWltZXI6IGV4Y2VwdGlvbiBvbmx5IHZhbGlkIHdoaWxlIHRoZSB0aW1l X3QgdHJhbnNpdGlvbiBpcyBvbmdvaW5nLg0KDQpPbiAxNS0wMy0yMDI0IDY6MTUgYS5tLiwg U3RldmUgTGFuZ2FzZWsgd3JvdGU6DQo+IE1pZ3JhdGlvbiB0byB0ZXN0aW5nIGlzIGxhcmdl bHkgb3V0IG9mIGNvbnRyb2wgb2YgdGhlIG1haW50YWluZXJzIGF0IHRoaXMNCj4gcG9pbnQs IGl0J3MgdmVyeSBtdWNoIGRlcGVuZGVudCBvbiBmb2xrcyByZWJvb3RzdHJhcHBpbmcgYXJt ZWwgYW5kIGFybWhmDQo+IGFnYWluc3QgdGhlIG5ldyBsaWJyYXJ5IG5hbWVzLiAgU2hvdWxk IHRoZXNlIGJ1Z3MgYmUgZG93bmdyYWRlZCBhZ2FpbiB0bw0KPiBpbXBvcnRhbnQgc2V2ZXJp dHk/DQoNCkFzIEknbSBub3JtYWxseSB3YXRjaGluZyBvdXQgZm9yIG91dC1vZi1zeW5jIHBh Y2thZ2VzLCBJJ20gZmluZSAod2l0aCBteSANClJlbGVhc2UgVGVhbSBoYXQgb24pIHdpdGgg bWFpbnRhaW5lcnMgZG93bmdyYWRpbmcgUkMgYnVncyBpbiB0ZXN0aW5nIA0KdGhhdCBoYXZl IGJlZW4gZml4ZWQgaW4gdW5zdGFibGUgYW5kIHRoYXQgZG9uJ3QgcmVxdWlyZSBhIHF1aWNr IHVwZGF0ZSANCmluIHRlc3RpbmcgKGUuZy4gc2VjdXJpdHkgaXNzdWVzIHByb2JhYmx5IHdh cnJhbnQgZGlzY3Vzc2luZyB0aGUgdHB1IA0KcGF0aCB3aXRoIHRoZSBSVCkuIE9uY2UgdGlt ZV90IDY0IGJpdCBpcyBkb25lLCBJJ2xsIGJlIGZpbGxpbmcgYnVncyBmb3IgDQpwYWNrYWdl cyB0aGF0IGRvbid0IG1pZ3JhdGUgYWdhaW4sIHNvIHRoZSBsYWNrIG9mIHRoZSBmaXggaW4g dGVzdGluZyANCndvbid0IGdvIHVubm90aWNlZC4NCg0KRm9yIGJvb2trZWVwaW5nIHB1cnBv c2VzLCBwbGVhc2UgdXNlcnRhZyBkb3duZ3JhZGVkIGJ1Z3Mgd2l0aCB1c2VyIA0KcmVsZWFz ZS5kZWJpYW4ub3JnQHBhY2thZ2VzLmRlYmlhbi5vcmcgYW5kIHVzZXJ0YWcgdGltZV90LWRv d25ncmFkZS4NCg0KUGxlYXNlIGJlIGNhcmVmdWwgd2l0aCBkb3duZ3JhZGluZyBSQyBidWdz Lg0KDQpQYXVsDQo=

    --------------B7VheTAyIF80z0taTdBOm2mj--

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

    wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmX0tPcFAwAAAAAACgkQnFyZ6wW9dQo5 BwgAvejKB0KtmqIzXGSDNU7QYNiHuqSVUcMzJoNIrL7/rxHugz2FNCDy6AAlBxH7Lldp2OXpMipe /TYcfCUOnonIWWsp5a4ttbQLQuCcHQ2pDcuvrkmx2KOzbS4LuY/p2uMIW/uBWzvj4vPYjpbPMtPU +ssSwiGhqqo5BtDGC4aFRg2EEKlsC5bbeNAq+BVrmy6jPm+ECpP+LxdE8/OX6ERvBUJEwb8c/GpN CnJqzAjF0XKuI7DtMxg+Jf+CzCnqALlAlXxsgYlo5hgx5yQZAsws6ri2+POhcbbbwvMvQHIjFltF YTqHGb+m/ixjVfMN+/cSTXKg98y0Mg43IrAFHjmSWA==
    =80B+
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Gevers@21:1/5 to Thomas Goirand on Sat Mar 16 13:10:01 2024
    To: debian-devel@lists.debian.org

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9oRbQGoRaZW5M3sBxUoFnbGn
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGkgemlnbywNCg0KT24gMTYtMDMtMjAyNCAxMjozMSBhLm0uLCBUaG9tYXMgR29pcmFuZCB3 cm90ZToNCj4gQnV0IHdoZW4gdGhlIEFVVE9STSBwZXJpb2Qgd2FzIGFubm91bmNlZCBhcyBy ZWR1Y2VkLCBJIHRob3VnaHQgDQo+IGxpa2UgaXQgd2FzIHByb2JhYmx5IGEgYmFkIGNhbGws IGFuZCB0aGF0IHRoZSBwcmV2aW91cyBBVVRPUk0gd2FzIA0KPiBhZ2dyZXNzaXZlIGVub3Vn aC4NCg0KSSdtIG5vdCBhd2FyZSB0aGF0IHdlIHJlZHVjZWQgYXV0b3JlbW92YWwgdGltZXMg aW4gcmVjZW50IGhpc3RvcnkuIEFyZSANCnlvdSBtYXliZSBjb25mdXNpbmcgaXQgd2l0aCB0 aGUgdGltZSBuZWVkZWQgZm9yIHBhY2thZ2VzIHRvIGJlIA0Kb3V0LW9mLXN5bmMgWzFdPyBU aGF0IHN0aWxsIHJlcXVpcmVzIHNvbWVvbmUgKG1lKSB0byBmaWxlIFJDIGJ1Z3MgYW5kIEkg DQpoYXZlIHN0b3BwZWQgZG9pbmcgdGhhdCBkdXJpbmcgdGhpcyB0cmFuc2l0aW9uIGV4YWN0 bHkgdG8gYXZvaWQgDQphdXRvcmVtb3ZhbCB3aGlsZSB0aGUgdHJhbnNpdGlvbiBpcyBpbiBw cm9ncmVzcy4NCg0KUGF1bA0KDQpbMV0gaHR0cHM6Ly9saXN0cy5kZWJpYW4ub3JnL2RlYmlh bi1kZXZlbC1hbm5vdW5jZS8yMDIzLzA2L21zZzAwMDAxLmh0bWwNCg==

    --------------9oRbQGoRaZW5M3sBxUoFnbGn--

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

    wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmX1i8QFAwAAAAAACgkQnFyZ6wW9dQpi mgf/V0eynxR8pH5JNxX+LES9L1EGG30RXhbGF7s1AMKprqwvzWFct2iAP7u5iiNvacEySpbMl+fg 9L1GRZRf5SkJBttRd9RpIDRxFRlwA6L70a9op6hN0w0LSwKVKPW6JSbtO8Jp2CdN1h7Wn1Cg+xl5 hBgOp9gdN4b2vEDj/xA/cWInTFz/QsMdApJOhilHO3aQAqq1N1G5IwxGx6T489rnl9WN9XOS0FYL ElbwGN0Npsty+8+uPmP+U2rc2l9LEej30ARaqRAXgXx/Y+hPnfZ/9Fo9hA4HXm+WUiilQFYvyTs5 Wdqsc3WMIPfax/qUlPmDNg7hyNcRgALK/SUcVY6PhA==
    =K/U7
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ian Jackson@21:1/5 to Steve Langasek on Tue Mar 19 12:20:01 2024
    Steve Langasek writes ("Re: Package marked for autoremoval due to closed bug?"):
    Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity?

    Yes.

    It seems we have consensus on this.

    Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
    For bookkeeping purposes, please usertag downgraded bugs with user release.debian.org@packages.debian.org and usertag time_t-downgrade.

    Rather than every maintainer affected by unactionable autoremoval warnings[1][2] doing this by hand:

    Steve, could you please do this for *all* the time_t transition RC
    bugs?

    That will reduce the scope for individual slips and mistakes,
    fulfilling Paul's request:

    Please be careful with downgrading RC bugs.


    [1] IMO unactionable autoremoval warnings are extremely undesirable.

    The autoremoval system has two purposes: one is to get rid of things
    that are in the way of other work, or just rotten. Another is to spur
    action where action is needed. Action by a responsible maintainer, or
    failing that by anyone else.

    An unactionable autoremoval warning represents, at best, a robot
    shouting at a human to do something that cannot be done. That can
    lead to many humans from afar all turning up being confuseed at the
    same problem trying to "help" (or at least, to try to stop the
    screaming). If the autoremovals were to actually occur, it would be
    automated destruction of non-broken stuff.

    To preserve autorm's usefulness, unactionable autoremoval warnings
    must be very rare. In this situation, Debian's processes have failed
    to ensure this, and there hasn't been an effective backstop.

    I suggest that when a widely-applicable problem is generating
    unactionable autoremovals, the whole autoremoval system should be
    suspended.


    The problem is particularly severe when an underlying cause is that
    some package, which contains the underlying RC bugfix, isn't
    migrating. This seems to be becoming more common.


    [2] In my case src:dgit depends on git-buildpackage. The autoremoval
    robot wants to remove git-buildpackage because of the time_t bugs
    against rpm, xdelta, and pristine-tar. One root cause is that
    src:dpkg isn't migrating because of #1066952.

    The logic of the autoremoval system is that as an affected maintainer
    I ought to go and involve myself with #1066952.

    And all of this is nonsense since surely we're not going to autorm git-buildpackage, but right now we have a giant klaxon saying that's
    what's going to happen.

    Ian.

    --
    Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

    Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
    that is a private address which bypasses my fierce spamfilter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Tue Mar 19 16:20:01 2024
    Hi Paul,

    Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers:
    For bookkeeping purposes, please usertag downgraded bugs with user release.debian.org@packages.debian.org and usertag time_t-downgrade.

    Please be careful with downgrading RC bugs.

    I agree with Ian that it might make sense that Steve, who probably has a complete list of the bugs, can do this more safely than individual
    maintainers. (BTW, thanks again to Steve for doing all the work.)

    I think this migration has shown another problem which was not yet
    dicussed here. In Debian Med and R pkg team we identified packages
    where a time_t transition would be
    a) complex (there was no patch provided by time_t people)
    b) not helpful for users since usage on 32bit is probably zero

    Thus we considered it a good idea to remove 32bit architectures of those packages and its dependencies. This has shown that removing packages is
    a similarly time consuming way of dealing with this. The method to file individual bug reports for every single package on the side of the
    maintainer as well as dealing with the actual removal done by ftpmaster
    is quite inefficient. The removal bug for emboss[1] was filed six weeks
    ago (1 Feb 2024) and countless testing removal warnings were sent to
    the maintainer list since it is not fixed until now. Even worse for r-bioc-rhtslib[2] which had quite a tree of rdepends and kept several
    people (including ftpmaster) busy.

    Please understand me correctly: It is not blaming ftpmaster to be slow
    with ROM requests. Maybe I could have adjusted severity somehow - I
    just don't know any documentation what is appropriate or not. I made
    mistakes myself when filing ROM bugs against rdepends.

    My point is: I as a maintainer have control about what is inside the
    pool. But once a package is there I have a hard time to get it removed
    again. This does not make sense. We have tools who can generate a
    dependency tree. So filing separate bugs on one hand and deal with
    separate bugs on the other hand is somehow a rudiment from last century.
    I wished we could solve this more elegantly.

    Kind regards
    Andreas.

    [1] https://bugs.debian.org/1062371
    [2] https://bugs.debian.org/1063376

    --
    http://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Gevers@21:1/5 to All on Tue Mar 19 20:30:01 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6kJ2D27Fw2GZJIw3MjUsiGUF
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGksDQoNCk9uIDE5LTAzLTIwMjQgMTE6MzIgYS5tLiwgSWFuIEphY2tzb24gd3JvdGU6DQo+ IFBhdWwgR2V2ZXJzIHdyaXRlcyAoIlJlOiBQYWNrYWdlIG1hcmtlZCBmb3IgYXV0b3JlbW92 YWwgZHVlIHRvIGNsb3NlZCBidWc/Iik6DQo+PiBGb3IgYm9va2tlZXBpbmcgcHVycG9zZXMs IHBsZWFzZSB1c2VydGFnIGRvd25ncmFkZWQgYnVncyB3aXRoIHVzZXINCj4+IHJlbGVhc2Uu ZGViaWFuLm9yZ0BwYWNrYWdlcy5kZWJpYW4ub3JnIGFuZCB1c2VydGFnIHRpbWVfdC1kb3du Z3JhZGUuDQoNCkkgd2FzIGluZm9ybWVkIHRoYXQgdGltZV90LWRvd25ncmFkZSBpc24ndCBh IHZhbGlkIHVzZXJ0YWcuIFBsZWFzZSB1c2UgDQp0aW1lLXQtZG93bmdyYWRlIGluc3RlYWQu DQoNClBhdWwNCg==

    --------------6kJ2D27Fw2GZJIw3MjUsiGUF--

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

    wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmX55g0FAwAAAAAACgkQnFyZ6wW9dQrz 5wf/SJWVeoQPBJcVFLR2lMu1ZNZe18o+xVSNgn1OUkduQNf8flkdJ6FCjO19GEHwIFy3Qxr37rgX K+QrbrMOdAk1VyqqABSKHjLS09DKqNuaoZGfFQ/7Qp1LSdbhU83BzhGnI5Y2fAdaNaArT2Slgheh TRNnvXHbGt+6EcoivPVAM4CqHIqItXzLQ6HMUZPu2PZ3rciaDCVKNPuH0usgOTzaitcR/ThWU3qA 2TI93e0zZWqqf1b+o/k4C5PCDdjO5gZ/U0FfvRivGgDVrdE8enIsyF+JcOmJChgHPS76boEhZSPc lhvSWDzw2MwqAD06qgCSc2o3DIxqv2jnLQNjVmDZBA==
    =kcoo
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Ian Jackson on Wed Mar 20 00:30:01 2024
    Hi!

    On Tue, 2024-03-19 at 10:32:04 +0000, Ian Jackson wrote:
    [2] In my case src:dgit depends on git-buildpackage. The autoremoval
    robot wants to remove git-buildpackage because of the time_t bugs
    against rpm, xdelta, and pristine-tar. One root cause is that
    src:dpkg isn't migrating because of #1066952.

    Just to clarify, I've now closed that report as I mentioned I'd be
    doing, but this will have no effect, because dpkg and gcc-* are not
    migrating primarily because they are being used by the release team
    to gate the transition, to avoid having them get into testing and
    potentially then getting things to build with the wrong ABI there

    The logic of the autoremoval system is that as an affected maintainer
    I ought to go and involve myself with #1066952.

    Perhaps the release team blocks should be listed more prominently at
    the beginning of the tracker page and perhaps be somewhat linkified
    (I'll file a report)? (Or maybe you got this information from somewhere
    else, which lacks that information or is also listed at the end?)

    Regards,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ian Jackson@21:1/5 to Ian Jackson on Thu Mar 21 11:50:01 2024
    Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and 1 more messages]"):
    Steve, could you please do this for *all* the time_t transition RC
    bugs?

    IMO things are currently ON FIRE.

    If no-one else has put this fire out by 24h from now, I will attempt
    to find which are the relevant bugs and downgrade them all.

    Ian.

    --
    Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

    Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
    that is a private address which bypasses my fierce spamfilter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Ian Jackson on Thu Mar 21 12:20:02 2024
    On Thu, Mar 21, 2024 at 10:47:21AM +0000, Ian Jackson wrote:
    Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and 1 more messages]"):
    Steve, could you please do this for *all* the time_t transition RC
    bugs?
    IMO things are currently ON FIRE.

    I'd rather call it a very large smoldering fire, so far. ;)

    If no-one else has put this fire out by 24h from now, I will attempt
    to find which are the relevant bugs and downgrade them all.

    I've sent a few contentless pings today to some of those bugs today,
    which will keep the smoldering fire smoldering (=delay autoremovals
    further). I agree that is far from ideal, but as I understand things,
    it's better than possibly letting such buggy packages migrate *to* testing.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    I don't want to see your smile.
    I want to see your intelligence, compassion, integrity, and consideration. (@1goodtern)

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

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmX8Fo4ACgkQCRq4Vgaa qhxephAAsNxWzgO3b+Nn24IfX3NSCzlFs6O5jGaTdf+7S1grrtoqHiM61kOEaz+S cGnskz27XReX+Mjgs3aCh87QRoxWZ/UgvfmNMlI3LJZHwHT81Gye52wWAFv0laJ1 95rtD8QrU7VxP7/CYMDhIkyeOd/IHEiHS3BM4dks2REgh+ESzm3tUmMIc03Di/IX dxK9J4t/78TboM45C7RUnnVkyXk3Z+m0xMZ0bfjsxsU9SVQtc0lz8NCDOFpDrd3R XKGI91M2tR9UR8/WvZDY4GSHtq7zVpLKEYRSFJAMdYdnZyHjE7+xbOI/03N8szRV 0eCDf42TCcjYpaHoXDHe5OlPU3Z2QJvdPjcBAxGnC+D3/qOFt1t1yrOhHKZuVqL2 itvYOJSLAbbwUbIEyDQ4U/3rcPKvjy5UtH6W2YR0JTKF7Hv6U3aDGhRAO6I2e59m YZdW2T57t1o+dMSOMjXtoGop+6vKbNq2qrDDemk/NYCp41zQbwge/CvycNLXwy9S bmeFKjjEmhgmJdTyG8dooM4YvKEHTSfzvIWPMnLamoJrKhpHpMhft1CYM