Re: Drop support for libqb?
On Sat, Nov 16, 2019 at 08:34:57AM -0500, Roberto C. Sánchez wrote: > > for jessie, there's no need to go via SRM, *we* are maintaining jessie > > now. > I understand that. My wording above was awkward, but it was intended to > make a distinction that I could just go ahead with the jessie upload at > any point. ah! > > for stretch (and buster) I'm pondering whether we should do another > > upload to unstable first, as I did a commit yesterday marking chromium > > as unsupported in stretch. so I've come to conclude that I'll upload > > this right away (it will just delay buster migration by a day) as this > > change is pretty good to have for stretch. > Oh, OK. Please go ahead. ok, will do. > > so debsnap is buggy? > I think it just reflects that the packages which were uploaded differ > from the corresponding tags in the repository. ah :/ > Since it sounds like you have another updated past mine, would you be > willing to take over from here? yes. > I have attached my draft DLA text so that you can add the chromium bit > to it. Also, feel free to edit my draft text for clarity, consistency, > etc. thank you for your work so far & will do! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Drop support for libqb?
On Sat, Nov 16, 2019 at 08:57:00AM +, Holger Levsen wrote: > Hi Roberto, > > On Fri, Nov 15, 2019 at 08:34:52PM -0500, Roberto C. Sánchez wrote: > > I am hesitant to file the bugs with the SRMs and to do the jessie > > upload. I merged the 2019.11.15 tag into the jessie and stretch > > branches. I also created a new buster branch from that tag. > > cool! > > for jessie, there's no need to go via SRM, *we* are maintaining jessie > now. > I understand that. My wording above was awkward, but it was intended to make a distinction that I could just go ahead with the jessie upload at any point. > for stretch (and buster) I'm pondering whether we should do another > upload to unstable first, as I did a commit yesterday marking chromium > as unsupported in stretch. so I've come to conclude that I'll upload > this right away (it will just delay buster migration by a day) as this > change is pretty good to have for stretch. > Oh, OK. Please go ahead. > > The buster update goes from 2019.06.13..2019.11.15_deb10u1, the stretch > > update from debian/2019.02.01_deb9u1..2019.11.15_deb9u1 and the jessie > > update from debian/2019.02.01_deb8u1..2019.11.15_deb8u1. The git diffs > > look sane. However, after building each of the packages and checking > > the debdiffs (against source packages downloaded with debsnap), the > > stretch and jessie packages I built seem to be inducing many more > > changes than those revealed by git diff. > > so debsnap is buggy? > I think it just reflects that the packages which were uploaded differ from the corresponding tags in the repository. It was unexpected and confused the path forward for me. > and anyway, do we need branches at all? can't you just do commit based > on master with a d/changelog entry and then save this as a tag, but not > as a branch? > Given the way that debian-security-support works, that sounds like a good approach. I used the branches because there were there and appeared to have been in recent use. > > Before I go ahead with pushing changes to salsa, uploading to jessie, > > releasing a DLA, and filing bugs requesting approval to upload to buster > > and stretch, I'd like to make sure that I have gone about all of this in > > the right way. > > Good! :) > > > What is the best way to facilitate this? Should I fork > > debian-security-support and push my proposed changes there for you to > > review? > > if want, you can surely do this. Even without forking, just create a > branch el_cubano/WIP or some such and I can review that. > > > Should I post source packages and debdiffs for review? Let me > > know how I should proceed. > > or that. I'm happy to review basically anything what I can review easily. > Since it sounds like you have another updated past mine, would you be willing to take over from here? It seems like my use of the branches would create opportunity for future complications which could be avoided by the single commit/tag-based approach you propose. The uncertainty that I have surrounding this process makes me think it should be documented. I'll make an attempt at documenting the process on the wiki and then perhaps you can review it for accuracy. I have attached my draft DLA text so that you can add the chromium bit to it. Also, feel free to edit my draft text for clarity, consistency, etc. Regards, -Roberto -- Roberto C. Sánchez From: Roberto C. Sánchez To: debian-lts-annou...@lists.debian.org Subject: [SECURITY] [DLA -1] debian-security-support libqb and mysql-5.5 end of life Package: debian-security-support Version: 2019.11.15~deb8u1 debian-security-support, the Debian security support coverage checker, has been updated in jessie. This marks the end of life of the libqb package in jessie. A recently reported vulnerability against libqb which allows users to overwrite arbitrary files via a symlink attack cannot be adequately addressed in libqb in jessie. Upstream no longer supports this version and no packages in jessie depend upon libqb. We recommend that if your systems or applications depend upon the libqb package provided from the Debian archive that you upgrade your systems to a more recent Debian release or find an alternate and up to date source of libqb packages. Additionally, MySQL 5.5 is no longer supported. Upstream has ended its support and we are unable to backport fixes from newer versions due to the lack of patch details. Options are to switch to MariaDB 10.0 in jessie or to a newer version of MySQL in more recent Debian releases. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS
Re: Drop support for libqb?
Hi Roberto, On Fri, Nov 15, 2019 at 08:34:52PM -0500, Roberto C. Sánchez wrote: > I am hesitant to file the bugs with the SRMs and to do the jessie > upload. I merged the 2019.11.15 tag into the jessie and stretch > branches. I also created a new buster branch from that tag. cool! for jessie, there's no need to go via SRM, *we* are maintaining jessie now. for stretch (and buster) I'm pondering whether we should do another upload to unstable first, as I did a commit yesterday marking chromium as unsupported in stretch. so I've come to conclude that I'll upload this right away (it will just delay buster migration by a day) as this change is pretty good to have for stretch. > The buster update goes from 2019.06.13..2019.11.15_deb10u1, the stretch > update from debian/2019.02.01_deb9u1..2019.11.15_deb9u1 and the jessie > update from debian/2019.02.01_deb8u1..2019.11.15_deb8u1. The git diffs > look sane. However, after building each of the packages and checking > the debdiffs (against source packages downloaded with debsnap), the > stretch and jessie packages I built seem to be inducing many more > changes than those revealed by git diff. so debsnap is buggy? and anyway, do we need branches at all? can't you just do commit based on master with a d/changelog entry and then save this as a tag, but not as a branch? > Before I go ahead with pushing changes to salsa, uploading to jessie, > releasing a DLA, and filing bugs requesting approval to upload to buster > and stretch, I'd like to make sure that I have gone about all of this in > the right way. Good! :) > What is the best way to facilitate this? Should I fork > debian-security-support and push my proposed changes there for you to > review? if want, you can surely do this. Even without forking, just create a branch el_cubano/WIP or some such and I can review that. > Should I post source packages and debdiffs for review? Let me > know how I should proceed. or that. I'm happy to review basically anything what I can review easily. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > > And then it would be ideal to upload the package to unstable and then > file a SRM bug to update the package in stretch, in addition to > uploading to jessie. (Probably this should also result in a DLA, not > 100% sure though. Thoughts & comments definitly welcome.) > Hi Holger, I am hesitant to file the bugs with the SRMs and to do the jessie upload. I merged the 2019.11.15 tag into the jessie and stretch branches. I also created a new buster branch from that tag. The buster update goes from 2019.06.13..2019.11.15_deb10u1, the stretch update from debian/2019.02.01_deb9u1..2019.11.15_deb9u1 and the jessie update from debian/2019.02.01_deb8u1..2019.11.15_deb8u1. The git diffs look sane. However, after building each of the packages and checking the debdiffs (against source packages downloaded with debsnap), the stretch and jessie packages I built seem to be inducing many more changes than those revealed by git diff. Before I go ahead with pushing changes to salsa, uploading to jessie, releasing a DLA, and filing bugs requesting approval to upload to buster and stretch, I'd like to make sure that I have gone about all of this in the right way. What is the best way to facilitate this? Should I fork debian-security-support and push my proposed changes there for you to review? Should I post source packages and debdiffs for review? Let me know how I should proceed. Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On Fri, Nov 15, 2019 at 08:42:59PM +, Holger Levsen wrote: > On Thu, Nov 14, 2019 at 01:51:46PM -0500, Roberto C. Sánchez wrote: > > > I had not yet seen this message so I already submitted a MR. Should I > > > close that and make a direct commit? > > I believe you did this now, but in any case: yes, please. > Yes, that is done. > > - Any feedback on this proposed DLA text? > > a.) very cool! > > > Package: debian-security-support > > Version: 2019.11.15~deb8u1 > > > > > > debian-security-support, the Debian security support coverage checker, > > has been updated in jessie. > > > > This marks the end of life of the libqb package in jessie. A recently > > reported vulnerability against libqb which allows users to overwrite > > arbitrary files via a symlink attack cannot be adequately addressed in > > libqb in jessie. Upstream no longer supports this version and no > > packages in jessie depend upon libqb, thus making it a leaf package. > > b.) I would drop the 'thus making it a leaf package.' half-sentence and > it conveys no relevant information. > I have updated my draft. When I upload to jessie a bit later on tonight I will release the DLA with the updated wording. > & thanks again for taking care of the d-s-s upload! > My pleasure. Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 01:51:46PM -0500, Roberto C. Sánchez wrote: > > I had not yet seen this message so I already submitted a MR. Should I > > close that and make a direct commit? I believe you did this now, but in any case: yes, please. > - Any feedback on this proposed DLA text? a.) very cool! > Package: debian-security-support > Version: 2019.11.15~deb8u1 > > > debian-security-support, the Debian security support coverage checker, > has been updated in jessie. > > This marks the end of life of the libqb package in jessie. A recently > reported vulnerability against libqb which allows users to overwrite > arbitrary files via a symlink attack cannot be adequately addressed in > libqb in jessie. Upstream no longer supports this version and no > packages in jessie depend upon libqb, thus making it a leaf package. b.) I would drop the 'thus making it a leaf package.' half-sentence and it conveys no relevant information. & thanks again for taking care of the d-s-s upload! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Drop support for libqb?
On Fri, Nov 15, 2019 at 02:56:31PM +0100, Emilio Pozuelo Monfort wrote: > On 14/11/2019 19:51, Roberto C. Sánchez wrote: > > > - Any feedback on this proposed DLA text? > > > > Package: debian-security-support > > Version: 2019.11.15~deb8u1 > > > > > > debian-security-support, the Debian security support coverage checker, > > has been updated in jessie. > > > > This marks the end of life of the libqb package in jessie. A recently > > reported vulnerability against libqb which allows users to overwrite > > arbitrary files via a symlink attack cannot be adequately addressed in > > libqb in jessie. Upstream no longer supports this version and no > > packages in jessie depend upon libqb, thus making it a leaf package. > > > > We recommend that if your systems or applications depend upon the libqb > > package provided from the Debian archive that you upgrade your systems > > to a more recent Debian release or find an alternate and up to date > > source of libqb packages. > > Looks fine to me. I have also noticed that we didn't get a > debian-security-support update for the mysql-5.5 EOL, so if you can add a > paragraph about it in the announcement (the changes to the > debian-security-support were already there) that'd be great. Something such > as: > > In addition to that, MySQL 5.5 is no longer supported as upstream ended its > support and we are unable to backport fixes from newer versions due to the > lack > of patch details. Options are to switch to MariaDB 10.0 in jessie or to a > newer > version in more recent Debian releases. > I'll definitely add that. Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On 14/11/2019 19:51, Roberto C. Sánchez wrote: > On Thu, Nov 14, 2019 at 01:31:27PM -0500, Roberto C. Sánchez wrote: >> On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: >>> On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > We usually mark affected CVE as in data/CVE/list and just > add the package to security-support-ended.deb8 in > debian-security-support. We then upload new versions of the package > periodically and announce it via DLA. I believe now is a good time to do > it. Thanks for the information. I will start working on it today. >>> >>> As any DD can commit to debian-security-support.git and also can upload >>> that package, just make sure to call it a team upload in d/changelog to >>> appease lintian and possibly other tools. >>> >> I had not yet seen this message so I already submitted a MR. Should I >> close that and make a direct commit? >> >>> And then it would be ideal to upload the package to unstable and then >>> file a SRM bug to update the package in stretch, in addition to >>> uploading to jessie. (Probably this should also result in a DLA, not >>> 100% sure though. Thoughts & comments definitly welcome.) >>> >> >> Looking at the previous updates, a DLA seems appropriate. I am in the >> process of drafting the text. >> >>> I believe it's fine if the version contraints (package version in >>> unstable higher than testing higher than stable higher than oldstable) >>> are temporarily not met, but I also believe it's important that they are >>> in the long run & most of the time. >>> >>> If doing all this work is too much or tedious to you, please shout and I >>> will be happy to finish this. Please just do at least the initial >>> change in git to security-support-ended.deb8. >>> >> If I close the MR and commit directly, is it then a simple matter of >> build and upload to unstable? That is, no other special steps are >> required? >> > Some additional follow-up: > > - Can I go ahead and mark the CVE in question as in > data/CVE/list even before the update to debian-security-support is > complete? Yeah that should be alright. > - Any feedback on this proposed DLA text? > > Package: debian-security-support > Version: 2019.11.15~deb8u1 > > > debian-security-support, the Debian security support coverage checker, > has been updated in jessie. > > This marks the end of life of the libqb package in jessie. A recently > reported vulnerability against libqb which allows users to overwrite > arbitrary files via a symlink attack cannot be adequately addressed in > libqb in jessie. Upstream no longer supports this version and no > packages in jessie depend upon libqb, thus making it a leaf package. > > We recommend that if your systems or applications depend upon the libqb > package provided from the Debian archive that you upgrade your systems > to a more recent Debian release or find an alternate and up to date > source of libqb packages. Looks fine to me. I have also noticed that we didn't get a debian-security-support update for the mysql-5.5 EOL, so if you can add a paragraph about it in the announcement (the changes to the debian-security-support were already there) that'd be great. Something such as: In addition to that, MySQL 5.5 is no longer supported as upstream ended its support and we are unable to backport fixes from newer versions due to the lack of patch details. Options are to switch to MariaDB 10.0 in jessie or to a newer version in more recent Debian releases.
Re: Drop support for libqb?
Hi I think the text looks good. Not exactly as previous updates but since it is the only change I think it is better to change the default template in the way you did it. Best regards // Ola On Thu, 14 Nov 2019 at 19:52, Roberto C. Sánchez wrote: > On Thu, Nov 14, 2019 at 01:31:27PM -0500, Roberto C. Sánchez wrote: > > On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > > > On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > > > > We usually mark affected CVE as in data/CVE/list and > just > > > > > add the package to security-support-ended.deb8 in > > > > > debian-security-support. We then upload new versions of the package > > > > > periodically and announce it via DLA. I believe now is a good time > to do it. > > > > Thanks for the information. I will start working on it today. > > > > > > As any DD can commit to debian-security-support.git and also can upload > > > that package, just make sure to call it a team upload in d/changelog to > > > appease lintian and possibly other tools. > > > > > I had not yet seen this message so I already submitted a MR. Should I > > close that and make a direct commit? > > > > > And then it would be ideal to upload the package to unstable and then > > > file a SRM bug to update the package in stretch, in addition to > > > uploading to jessie. (Probably this should also result in a DLA, not > > > 100% sure though. Thoughts & comments definitly welcome.) > > > > > > > Looking at the previous updates, a DLA seems appropriate. I am in the > > process of drafting the text. > > > > > I believe it's fine if the version contraints (package version in > > > unstable higher than testing higher than stable higher than oldstable) > > > are temporarily not met, but I also believe it's important that they > are > > > in the long run & most of the time. > > > > > > If doing all this work is too much or tedious to you, please shout and > I > > > will be happy to finish this. Please just do at least the initial > > > change in git to security-support-ended.deb8. > > > > > If I close the MR and commit directly, is it then a simple matter of > > build and upload to unstable? That is, no other special steps are > > required? > > > Some additional follow-up: > > - Can I go ahead and mark the CVE in question as in > data/CVE/list even before the update to debian-security-support is > complete? > - Any feedback on this proposed DLA text? > > Package: debian-security-support > Version: 2019.11.15~deb8u1 > > > debian-security-support, the Debian security support coverage checker, > has been updated in jessie. > > This marks the end of life of the libqb package in jessie. A recently > reported vulnerability against libqb which allows users to overwrite > arbitrary files via a symlink attack cannot be adequately addressed in > libqb in jessie. Upstream no longer supports this version and no > packages in jessie depend upon libqb, thus making it a leaf package. > > We recommend that if your systems or applications depend upon the libqb > package provided from the Debian archive that you upgrade your systems > to a more recent Debian release or find an alternate and up to date > source of libqb packages. > > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 01:31:27PM -0500, Roberto C. Sánchez wrote: > On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > > On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > > > We usually mark affected CVE as in data/CVE/list and just > > > > add the package to security-support-ended.deb8 in > > > > debian-security-support. We then upload new versions of the package > > > > periodically and announce it via DLA. I believe now is a good time to > > > > do it. > > > Thanks for the information. I will start working on it today. > > > > As any DD can commit to debian-security-support.git and also can upload > > that package, just make sure to call it a team upload in d/changelog to > > appease lintian and possibly other tools. > > > I had not yet seen this message so I already submitted a MR. Should I > close that and make a direct commit? > > > And then it would be ideal to upload the package to unstable and then > > file a SRM bug to update the package in stretch, in addition to > > uploading to jessie. (Probably this should also result in a DLA, not > > 100% sure though. Thoughts & comments definitly welcome.) > > > > Looking at the previous updates, a DLA seems appropriate. I am in the > process of drafting the text. > > > I believe it's fine if the version contraints (package version in > > unstable higher than testing higher than stable higher than oldstable) > > are temporarily not met, but I also believe it's important that they are > > in the long run & most of the time. > > > > If doing all this work is too much or tedious to you, please shout and I > > will be happy to finish this. Please just do at least the initial > > change in git to security-support-ended.deb8. > > > If I close the MR and commit directly, is it then a simple matter of > build and upload to unstable? That is, no other special steps are > required? > Some additional follow-up: - Can I go ahead and mark the CVE in question as in data/CVE/list even before the update to debian-security-support is complete? - Any feedback on this proposed DLA text? Package: debian-security-support Version: 2019.11.15~deb8u1 debian-security-support, the Debian security support coverage checker, has been updated in jessie. This marks the end of life of the libqb package in jessie. A recently reported vulnerability against libqb which allows users to overwrite arbitrary files via a symlink attack cannot be adequately addressed in libqb in jessie. Upstream no longer supports this version and no packages in jessie depend upon libqb, thus making it a leaf package. We recommend that if your systems or applications depend upon the libqb package provided from the Debian archive that you upgrade your systems to a more recent Debian release or find an alternate and up to date source of libqb packages. Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > > We usually mark affected CVE as in data/CVE/list and just > > > add the package to security-support-ended.deb8 in > > > debian-security-support. We then upload new versions of the package > > > periodically and announce it via DLA. I believe now is a good time to do > > > it. > > Thanks for the information. I will start working on it today. > > As any DD can commit to debian-security-support.git and also can upload > that package, just make sure to call it a team upload in d/changelog to > appease lintian and possibly other tools. > I had not yet seen this message so I already submitted a MR. Should I close that and make a direct commit? > And then it would be ideal to upload the package to unstable and then > file a SRM bug to update the package in stretch, in addition to > uploading to jessie. (Probably this should also result in a DLA, not > 100% sure though. Thoughts & comments definitly welcome.) > Looking at the previous updates, a DLA seems appropriate. I am in the process of drafting the text. > I believe it's fine if the version contraints (package version in > unstable higher than testing higher than stable higher than oldstable) > are temporarily not met, but I also believe it's important that they are > in the long run & most of the time. > > If doing all this work is too much or tedious to you, please shout and I > will be happy to finish this. Please just do at least the initial > change in git to security-support-ended.deb8. > If I close the MR and commit directly, is it then a simple matter of build and upload to unstable? That is, no other special steps are required? Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > We usually mark affected CVE as in data/CVE/list and just > > add the package to security-support-ended.deb8 in > > debian-security-support. We then upload new versions of the package > > periodically and announce it via DLA. I believe now is a good time to do it. > Thanks for the information. I will start working on it today. As any DD can commit to debian-security-support.git and also can upload that package, just make sure to call it a team upload in d/changelog to appease lintian and possibly other tools. And then it would be ideal to upload the package to unstable and then file a SRM bug to update the package in stretch, in addition to uploading to jessie. (Probably this should also result in a DLA, not 100% sure though. Thoughts & comments definitly welcome.) I believe it's fine if the version contraints (package version in unstable higher than testing higher than stable higher than oldstable) are temporarily not met, but I also believe it's important that they are in the long run & most of the time. If doing all this work is too much or tedious to you, please shout and I will be happy to finish this. Please just do at least the initial change in git to security-support-ended.deb8. Thanks! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Drop support for libqb?
On Wed, Nov 13, 2019 at 12:45:02PM +0100, Markus Koschany wrote: > > Am 13.11.19 um 05:28 schrieb Roberto C. Sánchez: > > On Tue, Nov 12, 2019 at 06:53:19PM +0100, Markus Koschany wrote: > >> Hi, > >> > >> Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: > >> [...] > >>> With that in mind, does this seem like a package for which we should > >>> declare the end of support? > >> > >> That sounds reasonable to me. > >> > > Is it as simple as updating the debian-security-support package? Do we > > customarily send out a DLA when a package is dropped from support? > > We usually mark affected CVE as in data/CVE/list and just > add the package to security-support-ended.deb8 in > debian-security-support. We then upload new versions of the package > periodically and announce it via DLA. I believe now is a good time to do it. > Thanks for the information. I will start working on it today. Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
Am 13.11.19 um 05:28 schrieb Roberto C. Sánchez: > On Tue, Nov 12, 2019 at 06:53:19PM +0100, Markus Koschany wrote: >> Hi, >> >> Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: >> [...] >>> With that in mind, does this seem like a package for which we should >>> declare the end of support? >> >> That sounds reasonable to me. >> > Is it as simple as updating the debian-security-support package? Do we > customarily send out a DLA when a package is dropped from support? We usually mark affected CVE as in data/CVE/list and just add the package to security-support-ended.deb8 in debian-security-support. We then upload new versions of the package periodically and announce it via DLA. I believe now is a good time to do it. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Drop support for libqb?
On Tue, Nov 12, 2019 at 06:53:19PM +0100, Markus Koschany wrote: > Hi, > > Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: > [...] > > With that in mind, does this seem like a package for which we should > > declare the end of support? > > That sounds reasonable to me. > Is it as simple as updating the debian-security-support package? Do we customarily send out a DLA when a package is dropped from support? Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
Hi, Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: [...] > With that in mind, does this seem like a package for which we should > declare the end of support? That sounds reasonable to me. Cheers, Markus signature.asc Description: OpenPGP digital signature
