Hi Sylvain
Is it really true that "find-work" order by priority. I know it did so in
the past but the output I get right now looks very much like alphabetical
order.
It could be a coincidence but I find it unlikely that the priority order
would result in alphabetical order.
Do we have a bug in the script?
ola@tigereye:~/git/debian-lts$ ./find-work | grep "^\*"
+ exec bin/package-operations --lts --find-work -f :online
Working directory of
g...@gitlab.com:freexian-lts/debian-lts.git
'/home/ola/freexian/services/deblts/lts/git' is not a git working directory
* ansible
* atril
* bind9
* cacti (Sylvain Beucler)
* composer (rouca)
* curl (rouca)
* dnsmasq (dleidert)
* docker.io
* dogecoin
* edk2
* expat (tobi)
* freeipa (Chris Lamb)
* frr (Abhijith PA)
* gtkwave (Adrian Bunk)
* h2o
* i2p
* imagemagick
* jenkins-htmlunit-core-js
* jetty9
* knot-resolver
* libcommons-compress-java (Markus Koschany)
* libpgjava
* libreswan
* libssh
* libstb
* libvirt (guilhem)
* linux (Ben Hutchings)
* linux-5.10
* lucene-solr
* nodejs (guilhem)
* nova
* nss
* nvidia-cuda-toolkit
* nvidia-graphics-drivers
* nvidia-graphics-drivers-legacy-390xx
* pdns-recursor (dleidert)
* postgresql-11 (Adrian Bunk)
* putty
* python-asyncssh
* rails
* ring
* ruby-rack (Adrian Bunk)
* runc
* samba
* sendmail
* shim
* squid
* suricata (Adrian Bunk)
* thunderbird (Emilio)
* tiff
* tomcat9
* varnish
* wordpress
* zabbix
* zfs-linux
On Fri, 15 Mar 2024 at 12:05, Sylvain Beucler <b...@beuc.net> wrote:
> Hi,
>
> I add here a reminder to use './find-work' (as documented, including at
> the top of dla-needed.txt) to look for work _sorted by priority_.
>
> I triaged a few low, non-sponsored, harmonize-with-point-updates
> packages this week, and I'm a bit surprised that some were claimed and
> even uploaded already.
>
> So, if a package has few users (and likely few/no sponsors) it will be
> sorted as low-priority and worked on only when time is available :)
>
> Cheers!
> Sylvain
>
> On 14/03/2024 23:53, Ola Lundqvist wrote:
> > Hi again
> >
> > One more thing. Should we have a statement about the fact that we do not
> > judge whether to ignore a package based on the number of users?
> > We only ignore in case it is not really feasible to backport without
> > breaking things.
> >
> > Do we have any limit on how difficult it is allowed to be to backport
> > the correction? I mean say it takes 200 hours to fix a package with a
> > fairly minor issue that rarely anyone uses. Should we ignore in
> > such case? Yes I'm taking things to the extreme here, but just to
> > highlight that there are greyzones.
> >
> > Cheers
> >
> > // Ola
> >
> > On Thu, 14 Mar 2024 at 23:39, Ola Lundqvist <o...@inguza.com
> > <mailto:o...@inguza.com>> wrote:
> >
> > Hi Roberto
> >
> > Thank you for the clarifications. I think we should add some more.
> >
> > See below.
> >
> > On Thu, 14 Mar 2024 at 21:37, Roberto C. Sánchez <robe...@debian.org
> > <mailto:robe...@debian.org>> wrote:
> >
> > Hello everyone,
> >
> > After the recent discussions regarding triage decisions and the
> > criteria
> > for keeping packages in dla-needed.txt, I wanted to provide some
> > guidance to help make matters more clear.
> >
> > First, as to the matter of triaging individual CVEs:
> >
> > - we prefer to see all CVEs fixed, absent good technical grounds
> > to the
> > contrary (e.g., minor issue, high risk of regression, too
> > difficult to
> > feasibly backport, etc)
> >
> >
> > I think we should clarify what we mean with "Minor issue". Is it
> > what is typically written as "(Minor issue)" after "<no-dsa>"
> > statement or something else.
> > I'm asking since it seems to be a common view that we should fix all
> > minor issues too. I do not agree to that, but others has expressed
> > that opinion.
> >
> > - if a CVE is 'fixed' in LTS but still 'no-dsa' in (old)stable,
> > then we
> > should do what we can to coordinate uploads to (old)stable so
> > that the
> > issue is fixed in a future point release
> > - if a CVE is 'fixed' in LTS but 'ignored' in (old)stable, then
> the
> > security team should be contacted to see if they would be
> > willing to
> > change to 'no-dsa' so that a point release fix can be made
> > - note that 'fixed' in the above items specifically means "fixed
> > by way
> > of a DLA (or earlier DSA), rather than 'not-affected' (since
> > 'not-affected' renders as 'fixed' in the package-level view)"
> >
> > Second, as to the matter of the criteria for keeping packages in
> > dla-needed.txt:
> >
> > - if a package requires work by the LTS team, then it should
> > remain in
> > dla-needed.txt; this includes if a DLA has already been
> > published and
> > we are working to support an upload to (old)stable
> > - if a package is assigned, it must not be removed without first
> > coordinating with whomever has claimed it (this is to avoid
> > confusion
> > about what work is being done and the state of the package)
> > - just because all CVEs for a package are 'no-dsa' (or even
> > 'postponed')
> > in LTS does not mean that the package must be removed from
> > dla-needed.txt; it may be that there are multiple no-dsa or
> > postponed
> > CVEs and that they collectively merit an update
> >
> >
> > I think we should add that if LTS has an issue as no-dsa/postponed
> > and (old-)stable has it fixed, then we should add/keep the package
> > to dla-needed (or decide to ignore in case it is too invasive) to
> > ensure LTS gets it fixed as well. At least that was the rule I
> > concluded from the discussion and why I re-added a few packages back
> > to dla-needed.
> >
> > I also think we should add that in the typical case (all
> > no-dsa/postponed/ignored/fixed and they are few) this means that the
> > package should be removed from dla-needed.txt. I think it has a
> > merit, just to keep things tidy.
> >
> > In fact I think we should typically remove the package from
> > dla-needed if it should not have been added, with exceptions
> > described above.
> >
> > Best regards
> >
> > // Ola
> >
> >
> >
> > Finally, as to the matter of Go and Rust packages (since
> > golang-go.crypto was among the packages caught in the recent
> > discussion
> > on triaging), please note the following from the Debian release
> > notes
> > [0]:
> >
> > ----------------------------------------
> > 5.2.1.2. Go- and Rust-based packages
> >
> > The Debian infrastructure currently has problems with rebuilding
> > packages of types that systematically use static linking. With
> the
> > growth of the Go and Rust ecosystems it means that these
> > packages will
> > be covered by limited security support until the infrastructure
> is
> > improved to deal with them maintainably.
> >
> > In most cases if updates are warranted for Go or Rust development
> > libraries, they will only be released via regular point releases.
> > ----------------------------------------
> >
> > - in general, we want to be mindful of the fact that updating Go
> and
> > Rust packages can produce a great deal of churn in the
> > distribution
> > (because the pervasive use of static linking can require
> > rebuilding
> > dozens or even more than a hundred packages)
> > - this particular issue is the subject of ongoing work within
> > Freexian
> > (to try to develop tooling to address the limitations
> > expressed by the
> > secteam in the release notes)
> > - for the time being, particularly serious vulnerabilities in Go
> and
> > Rust packages are sufficient to potentially justify listing
> > them in
> > dla-needed.txt, but in general we would prefer to not list
> these
> > packages in dla-needed.txt to avoid the mass number of
> > rebuilds (note
> > that if you are unsure if a CVE rises to the level I have
> > described,
> > you should bring it up for discussion on this list)
> > - if you are specifically intersted in helping to improve the
> > situation
> > for statically linked language ecosystems, then there is an
> > issue [1]
> > in the public lts-extra-tasks project in Salsa
> >
> > Additional information about this particular issue of security
> > updates
> > for ecosystems that use static is available in a recent thread
> > on this
> > list [2].
> >
> > [0]
> >
> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support
> <
> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support
> >
> > [1]
> > https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/60
> > <https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/60>
> > [2] https://lists.debian.org/debian-lts/2023/12/msg00035.html
> > <https://lists.debian.org/debian-lts/2023/12/msg00035.html>
> >
> > Regards,
> >
> > -Roberto
> >
> > --
> > Roberto C. Sánchez
> >
> >
> >
> > --
> > --- Inguza Technology AB --- MSc in Information Technology ----
> > | o...@inguza.com <mailto:o...@inguza.com>o...@debian.org
> > <mailto:o...@debian.org> |
> > | http://inguza.com/ <http://inguza.com/> Mobile: +46
> > (0)70-332 1551 |
> > ---------------------------------------------------------------
> >
> >
> >
> > --
> > --- Inguza Technology AB --- MSc in Information Technology ----
> > | o...@inguza.com <mailto:o...@inguza.com>o...@debian.org
> > <mailto:o...@debian.org> |
> > | http://inguza.com/ <http://inguza.com/> Mobile: +46
> > (0)70-332 1551 |
> > ---------------------------------------------------------------
> >
>
>
--
--- Inguza Technology AB --- MSc in Information Technology ----
| o...@inguza.com o...@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
