Re: [Pkg-clamav-devel] LTS update of clamav and call for advice
Great! Thank you. Sent from a phone Den mån 1 apr. 2019 15:13Scott Kitterman skrev: > I believe you've misunderstood. > > The version in stable is 0.100.3 and does not have a soname bump (nor does > it > need one). You should be able to update the LTS with that package with > little > more (maybe no more) than an updated changelog. > > Scott K > > On Monday, April 01, 2019 02:46:34 PM Ola Lundqvist wrote: > > Hi Scott and LTS team > > > > Thank you. I'll see if I can backport the required fixes. That may solve > > the library issue. > > > > Alternatively we state that clamav is not supported. Maybe someone in the > > LTS team can advice on that. > > > > Best regards > > > > // Ola > > > > On Sun, 31 Mar 2019 at 22:35, Scott Kitterman > wrote: > > > Comments inline. > > > > > > On Sunday, March 31, 2019 09:37:46 PM Ola Lundqvist wrote: > > > > Hi > > > > > > > > I missed to include the clamav maintainers. Sorry about that. > > > > > > > > // Ola > > > > > > > > On Sun, 31 Mar 2019 at 21:21, Ola Lundqvist wrote: > > > > > Dear maintainers, LTS team and Debian Secutiry team > > > > > > > > > > I have started to look at the clamav package update due to > > > > > CVE-2019-1787 > > > > > CVE-2019-1788 > > > > > CVE-2019-1789 > > > > > (the other three vulnerabilities are not affecting jessie or > stretch > > > > > > as I > > > > > > > > understand it) > > > > > > That's correct. > > > > > > > > I have understood that the clamav package is typically updated to > the > > > > > latest version also in stable and oldstable. However when doing so > I > > > > > encountered quite a few things that I would like to ask your advice > > > > > on. > > > > > > > > > > First of all to the maintainers. Do you want to handle also LTS > > > > > (oldstable) and regular security (stable) upload of clamav? > > > > > > Stable is already done through stable proposed updates (which is the > > > normal > > > path for clamav). We leave the LTS releases to the LTS team. Base > your > > > work > > > on what's in stable. > > > > > > > > Question to maintainers and Security team. Should we synchronize > the > > > > > efforts here and have you already started on the stable update? > > > > > > > > > > If not I have a few questions: > > > > > 1) Do you know the binary compatibility between libclamav7 and > > > > > > libclamav9? > > > > > > > > I have noticed that the package in sid produces libclamav9 while > the > > > > > > one > > > > > > > > in jessie provides libclamav7. Do you think this can be an issue? > > > > > > Yes. It's guaranteed to be an issue. We have a stable transition > > > prepared > > > and will do it (once the srm blesses) after the next point release in > > > April. > > > Note that the security team doesn't support clamav. > > > > > > > > 2) Do you think backporting the package in sid is better than > simply > > > > > updating to the latest upstream while keeping most scripts in > > > > > > oldstable? I > > > > > > > > had to copy over the split-archive.sh to be able to generate a > proper > > > > > > orig > > > > > > > > tarball. > > > > > > No. Use what's in stable proposed updates. > > > > > > > > - I personally think the package in sid have a little too much > updates > > > > > > to > > > > > > > > make that safe, especially since it produces new library packages. > > > > > > Agreed. That would definitely be a bad idea. > > > > > > > > - On the other hand, I had to do some modifications already to make > > > > > > allow > > > > > > > > the package to be generated and I have not even started building > yet. > > > > > There > > > > > may be many fixes needed to make this package work in oldstable... > > > > > > I suspect that what's in stable will work in oldstable, but I haven't > > > tried > > > it. It'll certainly take less work than what's in sid. > > > > > > > > I guess we cannot generate new library package version, or? > > > > > > Generally one does not, but for clamav you kind of have to at some > point. > > > Note that for libclamav7 -> libclamav9 there are also API changes, so > > > libclamav-dev reverse builld-depends need patching in addition to > > > rebuilding. > > > Once we've done that in stable, it should be easy enough to adapt for > > > oldstable when the time comes. Don't worry about it now. > > > > > > Scott K > >
Re: jessie-updates gone
On 4/2/19 12:59 PM, Andy Smith wrote: Hi Miroslav, On Tue, Apr 02, 2019 at 11:53:50AM +0200, Miroslav Skoric wrote: On 4/1/19 8:14 PM, Andy Smith wrote: I do understand that re-adding an empty jessie-updates directory will silence a lot of warnings from apt update, and thus would avoid the questions from end users that I have seen in a lot of places, but… I can't help thinking that although it is bad that these users were confused, at least they now understand that the level of support has changed. -1 Programmers' decision that led thousands of users to ask themselves what was wrong with their apt update was a very bad marketing for Debian. The alternative is that those users continue using Debian without realising that their packages stopped being supported by the maintainers and security team and are now supported by LTS alone. Is that a better outcome? Cheers, Andy IMHO, that alone (realising that some packages stopped being supported) doesn't help much anyway. Various software stopped being supported by their originators in the past. Sooner or later the users get aware of that fact. But many continue using that 'old' software if they do not have better alternatives. But in this very case, 'apt-get update' started returning an "error" msg that looked as if something went terribly wrong with Debian repositories (that did work fine just a day before), and that confused the users - at least myself. Regards, Misko
Re: jessie-updates gone
Hi Ben, On Wed, Apr 03, 2019 at 03:32:10PM +0100, Ben Hutchings wrote: > On Wed, 2019-04-03 at 00:02 +, Andy Smith wrote: > > Personally I'm not bothered either way about whether > > "-updates" remains something that can be in sources.list > > without causing update errors, but I am more concerned that a lot of > > users may have ended up transitioning to LTS without realising that, > > and wonder if there is any good way to help reduce that. > > I don't think this is the big problem that you think it is. I'm not sure how big of a problem it is especially when I'm not the one who would make any changes, and whoever does will have a list of other things they want to work on. As I say I was just wondering if there is anything simple that can be done to help reduce the number of these users. But I gather that you either don't feel it is a problem or else it's not one that justifies making any changes, and I accept you will know better than I so I will stop going on about it now! Cheers, Andy
Re: jessie-updates gone
Le mer. 3 avr. 2019 à 12:44, Jonas Meurer a écrit : > Informing users about ending security support (e.g. by local > notifications) could definitely be improved - but that's a separate topic. > We should definitely fork this discussion into a new subject. However I wonder if it should be created into debian-lts's mailing list or if it exists a more appropriate list for discussing about this kind of conceptual improvement of Debian packaging subsystem and life-cycle handling ? In the meanwhile, here are some of my thoughts and comments. Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas a écrit : > On 03.04.19 09:54, Jan Ingvoldstad wrote: > > c 3) when requesting installation of unsupported packages, provide a > >warning > > > >For c 3), this could be similar to when e.g. apt/apt-get pauses to ask > >due to dependencies, and overridable with the same options. > > > >However, as Pierre says, this is quite a bit of extra work for package > >system developers/maintainers. > > I hope that's what we discuss here ;-) Yes, precisely. I admit I went over the current situation of Jessie, who's already part of a past situation in my mind, and started to look forward at where we could head to for next (next) time. I was at first very enthusiastic at adding a "not to remove stretch-updates/" mention to the procedure when Stretch will enter LTS, but I now fell some more could be devised to better handle the situation. I usually look far ahead, then work backward to connect the dots. My thoughts was directed for Debian Bulleyes at best, and maybe to the next one. Currently Debian Stretch is stable and thus (almost) settled in stone (to be clear, this is not a criticism but relate a fact about a feature I truly appreciate). Buster, for his own, has entered the freeze state, so we can also consider it almost settled in stone. So thinking about improving how Debian handle all this fast bring us to Debian Bulleyes or Bookworm. With this scope in mind, and thinking far ahead with something like a blank page, and the opportunity to add code where required, I believe theses actual considerations would deserve a well thought design to support spot on all the conceived edge cases. Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas a écrit : > >On 2019-04-03 02:02, Andy Smith wrote: > > c 2) a transition into LTS should probably be accompagnied with a > >default run of check-support-status > > maybe create new point release where base-files depend on > debian-security-support If the maintainers (or the LTS team) would accept to modify the dependency tree, this could help on the already stable and frozen releases. Nonetheless, if I understand how packages are upgraded, wouldn't it requires the download and reinstall of theses essential packages (because of the version-number bump). This doesn't seems very elegant. And I must add that I'm not very found of this as it would change dependencies on the base packages. I would tick at seeing such kind of essential packages being updated. Moreoever this would be not for technical reasons but for organisational reasons. Would I stumble upon this notification, I would wonder what have happened to the base package being modified during the course of the life-cycle of a released and stable version of Debian. IMO, this doesn't fit much with the philosophy of Debian not to touch anything in the release once being tagged stable. Except of course for security updates and other very important updates. Would this kind of update you suggest, it probably would have brought me to post something on debian-user's mailing list to try to understand what have happened. Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas a écrit : > > >On 2019-04-03 02:02, Andy Smith wrote: > > > >>c) if getting warnings from "apt update" does seem to be an > >>effective final way to reach such users, would it be a good idea > >>to find a way to have apt tell them about their transition into > >>LTS? > > On 03.04.19 09:54, Jan Ingvoldstad wrote: > >So, sort of a variant on Pierre Fourès's suggestion? > > > >I like that. > > I agree. > It's better to warn than error, better when LTS starts than year later. > > Just note that expiring the archive is something to consider - people who > put 'Acquire::Check-Valid-Until "0";' into their configs may forget it > there, so they will miss such warnings within next release cycle. To my view, I think the best could be to add meta-informations into the packaging subsystem, and this on two level of scope. One would be repository based, the other would be package based (but wouldn't be stored in the packages but as per-package meta-informations in the repositories). For the package-based meta-information, for the Debian Team (might it be the mainteners team, the security team, the LTS team), or for the not affiliated ELTS team, or for any organisation running a repository compatible with Debian distributions, it would be nice to add some kind of flag to s
Re: jessie-updates gone
On Wed, 2019-04-03 at 00:02 +, Andy Smith wrote: > Hi Ben, > > On Wed, Apr 03, 2019 at 12:23:46AM +0100, Ben Hutchings wrote: > > Debian LTS is a team within Debian. It's separate from the main > > security team and the stable release managers, but it is no less > > part > > of Debian. > > Sure, I do understand that. My employer is one of the LTS sponsors. > > However what I am saying is, there are clearly quite a few users of > Debian who were surprised and confused about jessie-updates going > away. I think that means those users also did not know that they > transitioned from relying on the security team and release managers > to the LTS team. > > Clearly the LTS team cannot provide the same level of support, I don't think this is clearly the case. > so > wouldn't you agree that it is important that users realise when they > go from one state to another? Yes, but that doesn't mean that if some users don't realise it is a failure on our part. > > The transition to extended support by the LTS team has always been > > announced, in any case: > > Absolutely, but these users did not read those announcements, or > else I think they wouldn't have been so confused by jessie-updates > going away. If users don't read announcements then the EOL will come as a surprise too! [...] > Personally I'm not bothered either way about whether > "-updates" remains something that can be in sources.list > without causing update errors, but I am more concerned that a lot of > users may have ended up transitioning to LTS without realising that, > and wonder if there is any good way to help reduce that. I don't think this is the big problem that you think it is. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: jessie-updates gone
Hey Andy, Andy Smith: > Clearly the LTS team cannot provide the same level of support, so > wouldn't you agree that it is important that users realise when they > go from one state to another? I don't think I follow here. In my eyes, it's perfectly fine if Debian users who don't follow any announcements (which - unfortunately - is true for the majority of users) keep using a release even after its security support was taken over by the LTS team. Informing users about ending security support (e.g. by local notifications) could definitely be improved - but that's a separate topic. Cheers jonas signature.asc Description: OpenPGP digital signature
Re: jessie-updates gone
On 2019-04-03 02:02, Andy Smith wrote: c) if getting warnings from "apt update" does seem to be an effective final way to reach such users, would it be a good idea to find a way to have apt tell them about their transition into LTS? On 03.04.19 09:54, Jan Ingvoldstad wrote: So, sort of a variant on Pierre Fourès's suggestion? I like that. I agree. It's better to warn than error, better when LTS starts than year later. Just note that expiring the archive is something to consider - people who put 'Acquire::Check-Valid-Until "0";' into their configs may forget it there, so they will miss such warnings within next release cycle. Additionally: c 2) a transition into LTS should probably be accompagnied with a default run of check-support-status maybe create new point release where base-files depend on debian-security-support unfortunately that won't help users who only use unattended-upgrades for security upgrades. c 3) when requesting installation of unsupported packages, provide a warning check-support-status should do that. For c 3), this could be similar to when e.g. apt/apt-get pauses to ask due to dependencies, and overridable with the same options. However, as Pierre says, this is quite a bit of extra work for package system developers/maintainers. I hope that's what we discuss here ;-) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: "Let God Debug It!".
Re: jessie-updates gone
On 2019-04-03 02:02, Andy Smith wrote: c) if getting warnings from "apt update" does seem to be an effective final way to reach such users, would it be a good idea to find a way to have apt tell them about their transition into LTS? So, sort of a variant on Pierre Fourès's suggestion? I like that. Additionally: c 2) a transition into LTS should probably be accompagnied with a default run of check-support-status c 3) when requesting installation of unsupported packages, provide a warning For c 3), this could be similar to when e.g. apt/apt-get pauses to ask due to dependencies, and overridable with the same options. However, as Pierre says, this is quite a bit of extra work for package system developers/maintainers. -- Cheers, Jan
