Closure of buster-backports (WAS Re: buster-10-backports: I need backported network-manager for buster ASAP.)
On Sun, Mar 26, 2023 at 01:55:28PM +0300, ijaaskelai...@outlook.com wrote: > I absolutely need my Broadcom b43 to be the most advanced "device" in > my home country and for my home country. And for the EU, get the point? > > https://en.wikipedia.org/wiki/B43 > > Kind regards, Ilari Jääskeläinen. > la, 2023-03-25 kello 18:33 +, Andrew M.A. Cater kirjoitti: > > On Thu, Mar 23, 2023 at 07:45:57AM +0200, ijaaskelai...@outlook.com > > wrote: > > > Kind regards, Ilari Jääskeläinen. > > > > I wonder if you could explain *why* you need this so immediately and > > also > > why you asked all the Debian developers at once, please. > > Hi Ilari, It may be that you are unlucky. Buster is now in Long Term Support (LTS) as the oldstable distribution. The decision has been taken to close buster-backports as any updates should be going only through buster-security. See also: https://lists.debian.org/debian-backports/2022/09/msg00020.html My respectful suggestion to you would be to move to Debian 11 (bullseye) which was initially released in August 2021 and should be supported for a year past the release of Debian 12. If updating, please take account of the Bullseye release notes and, in particular, changes to /etc/apt/sources.list See: https://www.debian.org/releases/bullseye/amd64/index.en.html It is anticipated that Debian 12 (Bookworm) will be released later this year. > > There may be a better way to request that Debian developers should > > help you > > but without more details, none of us can tell. > > > > With every good wish, as ever, > > > > Andy Cater > > > > With every good wish, as ever, Andy Cater (amaca...@debian.org)
Re: Closure of buster-backports (WAS Re: buster-10-backports: I need backported network-manager for buster ASAP.)
Thank you for your reply again. I can also build it from source. The HP MINI 10.1" INTEL ATOM N450 battery completely died two days ago so I could not use it instantly anyway since the laptop does not boot now. I wanted it fast-track , faster than I could get the dependencies. I propably run online with bonnell next mid week again. Those ATOM batteries are consumable items and wear into nonexisting in time. My atom battery worked for 7 years + the time the previous owner used it. Bought it for 20€. Kind regards, Ilari Jääskeläinen. su, 2023-03-26 kello 13:46 +, Andrew M.A. Cater kirjoitti: > On Sun, Mar 26, 2023 at 01:55:28PM +0300, ijaaskelai...@outlook.com > wrote: > > I absolutely need my Broadcom b43 to be the most advanced "device" > > in > > my home country and for my home country. And for the EU, get the > > point? > > > > https://en.wikipedia.org/wiki/B43 > > > > Kind regards, Ilari Jääskeläinen. > > la, 2023-03-25 kello 18:33 +, Andrew M.A. Cater kirjoitti: > > > On Thu, Mar 23, 2023 at 07:45:57AM +0200, > > > ijaaskelai...@outlook.com > > > wrote: > > > > Kind regards, Ilari Jääskeläinen. > > > > > > I wonder if you could explain *why* you need this so immediately > > > and > > > also > > > why you asked all the Debian developers at once, please. > > > > > Hi Ilari, > > It may be that you are unlucky. Buster is now in Long Term Support > (LTS) as > the oldstable distribution. The decision has been taken to close > buster-backports as any updates should be going only through buster- > security. > See also: > https://lists.debian.org/debian-backports/2022/09/msg00020.html > > My respectful suggestion to you would be to move to Debian 11 > (bullseye) which > was initially released in August 2021 and should be supported for a > year > past the release of Debian 12. If updating, please take account of > the > Bullseye release notes and, in particular, changes to > /etc/apt/sources.list > > See: https://www.debian.org/releases/bullseye/amd64/index.en.html > > It is anticipated that Debian 12 (Bookworm) will be released later > this year. > > > > There may be a better way to request that Debian developers > > > should > > > help you > > > but without more details, none of us can tell. > > > > > > With every good wish, as ever, > > > > > > Andy Cater > > With every good wish, as ever, > > Andy Cater > (amaca...@debian.org)
Re: Reducing allowed Vcs for packaging?
Hello, On Sat 04 Mar 2023 at 07:25PM +02, Adrian Bunk wrote: > for the contents of packages in the archive the ftp team requires that > everything is in the preferred form of modification. > > It is therefore surprising that you as member of the ftp team declare > that there is no requirement at all that the packages themselves that > get uploaded to the archive are in the preferred form of modification > as long as the preferred form of modification is in salsa. That is not what I meant. We certainly want some mechanism to enforce a correspondence between preferred forms for modification and binary packages, so that we know we have the former for every one of the latter. dgit-repos and dak's archive of source packages both serve this purpose. -- Sean Whitton
Re: Reducing allowed Vcs for packaging?
Hello, On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote: > On 16792 March 1977, Adrian Bunk wrote: > >> for the contents of packages in the archive the ftp team requires that >> everything is in the preferred form of modification. > > Yes. Of course. > > But git or svn or even sccs and rcs is NOT, in any way, preferred for of > modification. Only one way of storage and handling some metadata. This is Debian's official position, but it's debateable. There is the preferred form for modification for an individual *file*, and that probably doesn't include version control. But the preferred form for modifying a *project* arguably does. -- Sean Whitton
Re: Reducing allowed Vcs for packaging?
Sean Whitton wrote: > >On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote: > >> On 16792 March 1977, Adrian Bunk wrote: >> >>> for the contents of packages in the archive the ftp team requires that >>> everything is in the preferred form of modification. >> >> Yes. Of course. >> >> But git or svn or even sccs and rcs is NOT, in any way, preferred for of >> modification. Only one way of storage and handling some metadata. > >This is Debian's official position, but it's debateable. > >There is the preferred form for modification for an individual *file*, >and that probably doesn't include version control. But the preferred >form for modifying a *project* arguably does. I think you're *reaching* here. I know of quite a few projects where they consider their CI setup to be an intergral part of project development. Should we therefore declare that "preferred form of modification" could include all of the github or gitlab infrastructure? -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Reducing allowed Vcs for packaging?
At 2023-03-26T13:56:55-0700, Sean Whitton wrote: > On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote: > > But git or svn or even sccs and rcs is NOT, in any way, preferred > > for of modification. Only one way of storage and handling some > > metadata. > > This is Debian's official position, but it's debateable. > > There is the preferred form for modification for an individual *file*, > and that probably doesn't include version control. But the preferred > form for modifying a *project* arguably does. I wonder if, after twelve years, we have any empirical data regarding whether Red Hat's stance, that change sets (discretized by the process of commits to VCSes) are not constitutive of the "preferred form for modifying a copyrighted work" when that is the form invariably used by those performing the modifications, frustrated Oracle's aims, or whether this deliberately anemic interpretation of the GPL was a perfomative weakening of copyleft to little or no commercial advantage. https://lwn.net/Articles/432012/ Regards, Branden signature.asc Description: PGP signature
