Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
Hi, I'd like to point to a discussion on the Debian Med mailing list which was caused by a "fails to migrate to testing for too long" bug. I fully agree that these bugs should be filed. However, the bugs are immediately set to "Done" later by the issuer of the bug. I discussed this with Paul before and he said reasons for this - but I think its wrong since the issue vanishes from BTS and becomes invisible for the maintainers which is not helpful IMHO. My suggestion is to not set those bugs to Done to keep the red flag for the package raised. Kind regards Andreas. On Tue, Dec 08, 2020 at 08:46:04PM -0800, tony mancill wrote: > Hi Diane, > > On Tue, Dec 08, 2020 at 10:14:24AM -0800, Diane Trout wrote: > > My coworker noticed cluster3 dropped out of testing and I'm confused > > why. > > > > https://tracker.debian.org/pkg/cluster3 > > says that "cluster3 has no binaries on any arch", and there are no logs > > at buildd https://buildd.debian.org/status/package.php?p=cluster3 for > > it > > > > However if I grab either the source package for 1.59+ds-2 or the > > current main branch from salsa and try building, I get a package with > > binaries. > > > > The only mildly annoying thing is when I build in unstable, it ends up > > with a dependency on python3 (<< 3.10), python3 (>= 3.9~) which doesn't > > install on testing. > > > > But the package seems to be fine, so any thoughts why it was held back? > > Sometimes you can find this information in the PTS [1] in the News > section [2]. In this case cluster3 failed to migrate from unstable to > testing before a fixed deadline [3]. (Although I don't know exactly why > *that* happened.) > > I am preparing a new upload to unstable now and expect it to transition > successfully. > > Cheers, > tony > > [1] https://tracker.debian.org/pkg/cluster3 > [2] https://tracker.debian.org/news/1175882/cluster3-removed-from-testing/ > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968436 > > -- http://fam-tille.de
CentOS and Debian/Ubuntu release cycles
Hi all, maybe you already have heard it, CentOS is basically dead now. It used to be an exact RHEL clone, but now it's kind of an RHEL beta [1]. Now what does that have to do with Debian? When we look into why people use CentOS, the reason is pretty simple: it is (or was) binary-compatible with RHEL, just without the support [2]. I was reading comments from people that use RHEL on their production, but CentOS at home or for testing, because you don't need to pay for it. These use cases now don't work anymore, forcing them into either paying for RHEL, or moving to a different ecosystem. The more I started thinking about it, the more I wondered about why Debian Stable and Ubuntu LTS are *not* binary-compatible. It just doesn't make sense to me. Both Debian Stable and Ubuntu LTS provide a more "long term" approach than let's say Fedora. And while Ubuntu LTS is based on Debian, it is not based on Debian Stable, even though they have release cycle of two years. It would seem kinda obvious that Debian and Ubuntu have a common freeze period and work on LTS maintenance together. Does anyone know why this is not the case? I suspect some historical reasons, but I couldn't find anything quickly. - Stephan [1] https://blog.centos.org/2020/12/future-is-centos-stream/ [2] It's easy to find comments on various blogs or social media, but for sake of completeness let me just mention that CERN [3], [4]. [3] https://linux.web.cern.ch/centos/ [4] https://linux.web.cern.ch/other/
Re: CentOS and Debian/Ubuntu release cycles
Hello Stephan, Am 09.12.20 um 17:25 schrieb Stephan Lachnit: > Hi all, > > maybe you already have heard it, CentOS is basically dead now. It used to be > an exact RHEL clone, but now it's kind of an RHEL beta [1]. > > Now what does that have to do with Debian? > > When we look into why people use CentOS, the reason is pretty simple: it is > (or was) binary-compatible with RHEL, just without the support [2]. > I was reading comments from people that use RHEL on their production, but > CentOS at home or for testing, because you don't need to pay for it. > These use cases now don't work anymore, forcing them into either paying for > RHEL, or moving to a different ecosystem. > > The more I started thinking about it, the more I wondered about why Debian > Stable and Ubuntu LTS are *not* binary-compatible. > It just doesn't make sense to me. Both Debian Stable and Ubuntu LTS provide a > more "long term" approach than let's say Fedora. > And while Ubuntu LTS is based on Debian, it is not based on Debian Stable, > even though they have release cycle of two years. > It would seem kinda obvious that Debian and Ubuntu have a common freeze > period and work on LTS maintenance together. > > Does anyone know why this is not the case? I suspect some historical reasons, > but I couldn't find anything quickly. IMO one difference is that Debian supoorts all packages in stable main for the release cycle of about 2 years and one year after, Ubuntu supports only packages in main not in universe. so Ubuntu only supports a small part of the repo as LTS. Kind regards Mechtilde > > - Stephan > > [1] https://blog.centos.org/2020/12/future-is-centos-stream/ > [2] It's easy to find comments on various blogs or social media, but for sake > of completeness let me just mention that CERN [3], [4]. > [3] https://linux.web.cern.ch/centos/ > [4] https://linux.web.cern.ch/other/ > -- Mechtilde Stehmann ## Apache OpenOffice ## Freie Office Suite für Linux, MacOSX, Windows und OS/2 ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature Description: OpenPGP digital signature
Re: CentOS and Debian/Ubuntu release cycles
On 2020-12-09 16:25:54 + (+), Stephan Lachnit wrote: [...] > The more I started thinking about it, the more I wondered about > why Debian Stable and Ubuntu LTS are *not* binary-compatible. It > just doesn't make sense to me. Both Debian Stable and Ubuntu LTS > provide a more "long term" approach than let's say Fedora. > And while Ubuntu LTS is based on Debian, it is not based on Debian > Stable, even though they have release cycle of two years. It would > seem kinda obvious that Debian and Ubuntu have a common freeze > period and work on LTS maintenance together. > > Does anyone know why this is not the case? I suspect some > historical reasons, but I couldn't find anything quickly. [...] A (perhaps slightly glib) answer is that Ubuntu is just one Debian derivative, albeit a rather popular one. Should the Debian release process give Ubuntu special privilege in deciding how Debian's contributors do that work? Should Debian expect to take all the derivatives here into account during freeze? https://wiki.debian.org/Derivatives/Census This is really more of a question for Canonical and the Ubuntu community, honestly. Ubuntu is derived from Debian, if Ubuntu wanted its LTS series to be byte-compatible with certain Debian stable releases then they would have designed their release process to make that possible. Since they didn't, it was probably for a good reason, but ultimately you should be asking them. -- Jeremy Stanley signature.asc Description: PGP signature
Re: CentOS and Debian/Ubuntu release cycles
On Wed, Dec 09, 2020 at 04:25:54PM +, Stephan Lachnit wrote: > Hi all, > > maybe you already have heard it, CentOS is basically dead now. It used to be > an exact RHEL clone, but now it's kind of an RHEL beta [1]. > > Now what does that have to do with Debian? > > When we look into why people use CentOS, the reason is pretty simple: it is > (or was) binary-compatible with RHEL, just without the support [2]. > I was reading comments from people that use RHEL on their production, but > CentOS at home or for testing, because you don't need to pay for it. > These use cases now don't work anymore, forcing them into either paying for > RHEL, or moving to a different ecosystem. > > The more I started thinking about it, the more I wondered about why Debian > Stable and Ubuntu LTS are *not* binary-compatible. > It just doesn't make sense to me. Both Debian Stable and Ubuntu LTS provide a > more "long term" approach than let's say Fedora. > And while Ubuntu LTS is based on Debian, it is not based on Debian Stable, > even though they have release cycle of two years. > It would seem kinda obvious that Debian and Ubuntu have a common freeze > period and work on LTS maintenance together. > > Does anyone know why this is not the case? I suspect some historical reasons, > but I couldn't find anything quickly. > > - Stephan > > [1] https://blog.centos.org/2020/12/future-is-centos-stream/ > [2] It's easy to find comments on various blogs or social media, but for sake > of completeness let me just mention that CERN [3], [4]. > [3] https://linux.web.cern.ch/centos/ > [4] https://linux.web.cern.ch/other/ > Two different distributions: two different approaches. Ubuntu support a small subset of packages in their main distribution (as opposed to multiverse/universe). Ubuntu packages are often pulled from Debian stable and testing at the same time, brought together and then released. Ubuntu changes significantly every six months and publishes an LTS once every two years. Debian releases when it's ready. Support is generally two years plus a year after the next version. There is now an LTS extended support after that period for a further two years and maybe even ELTS after that. That's support provided by Debian developers who are paid for their time. Ubuntu and Debian may be >90% compatible but have a subtly different approach to bundling non-free firmware / compilation options or other differences. Derivative distributions diverge further, of course. Ubuntu questions are often considered off-topic on Debian lists - we may not have exact expertise - and vice versa. Hope this helps Andy C.
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, Dec 09, 2020 at 10:17:56AM +0100, Andreas Tille wrote: > I'd like to point to a discussion on the Debian Med mailing list which > was caused by a "fails to migrate to testing for too long" bug. I > fully agree that these bugs should be filed. However, the bugs are > immediately set to "Done" later by the issuer of the bug. I discussed > this with Paul before and he said reasons for this - but I think its > wrong since the issue vanishes from BTS and becomes invisible for the > maintainers which is not helpful IMHO. > > My suggestion is to not set those bugs to Done to keep the red flag > for the package raised. I'm instead convinced that closing those bugs directly is right. The reason the packages are not migrating has nothing to do with the bug, and keeping it open adds to the confusion as then it's reported as a "regression" when really it isn't. > On Tue, Dec 08, 2020 at 08:46:04PM -0800, tony mancill wrote: > > Hi Diane, > > > > On Tue, Dec 08, 2020 at 10:14:24AM -0800, Diane Trout wrote: > > > My coworker noticed cluster3 dropped out of testing and I'm confused > > > why. > > > > > > https://tracker.debian.org/pkg/cluster3 > > > says that "cluster3 has no binaries on any arch", and there are no logs > > > at buildd https://buildd.debian.org/status/package.php?p=cluster3 for > > > it > > > > > > However if I grab either the source package for 1.59+ds-2 or the > > > current main branch from salsa and try building, I get a package with > > > binaries. > > > > > > The only mildly annoying thing is when I build in unstable, it ends up > > > with a dependency on python3 (<< 3.10), python3 (>= 3.9~) which doesn't > > > install on testing. > > > > > > But the package seems to be fine, so any thoughts why it was held back? > > > > Sometimes you can find this information in the PTS [1] in the News > > section [2]. In this case cluster3 failed to migrate from unstable to > > testing before a fixed deadline [3]. (Although I don't know exactly why > > *that* happened.) Because you seem to not be aware of how non-free works. Non-free is not autobuilt, so when Andreas uploaded 1.59+ds-2 without any binaries then "cluster3 has no binaries on any arch". Since there are no binaries associated with the source, britney refuses to migrate it. Indeed, one could just do a binary-only build of it, upload it, and it would migrate stright the next day. Or one could ask for an exception to the non-free buildds as docuemnted on https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable As you can see, nothing relating to that bug. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Intel SOF audio firmware packaging
My Dell Inspiron 7591 2n1 required the SOF audio firmware, so I did a quick packaging for my own purposes, to be sure I had the latest. See https://github.com/barak/sof-bin branch: debian Works for me, and of course my packaging scripts are free for use in whole or in part etc (I hereby place them in the public domain.) Cheers, --Barak.
DebDelta Package Broken by Python3.9
Hi all, I just wanted to note the breakage, and ask for an NMU. I have prepared and uploaded a patch, both to Salsa and to the BTS, and it has been a few days without any response. The patch is very simple: just replace all occurences of isAlive() with is_alive(), and the package works. I am not a debian developer, and would appreciate it if someone could do an NMU to fix it. Thanks! Calum signature.asc Description: This is a digitally signed message part
Re: DebDelta Package Broken by Python3.9
On Wed, Dec 09, 2020 at 12:52:30PM -0500, Calum McConnell wrote: > Hi all, > I just wanted to note the breakage, and ask for an NMU. I have prepared > and uploaded a patch, both to Salsa and to the BTS, and it has been a few > days without any response. The patch is very simple: just replace all > occurences of isAlive() with is_alive(), and the package works. I am not > a debian developer, and would appreciate it if someone could do an NMU to > fix it. You can prepare a NMU yourself and ask for sponsorship as usual. -- WBR, wRAR signature.asc Description: PGP signature
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, 2020-12-09 at 18:27 +0100, Mattia Rizzolo wrote: > Because you seem to not be aware of how non-free works. Non-free is > not > autobuilt, so when Andreas uploaded 1.59+ds-2 without any binaries > then > "cluster3 has no binaries on any arch". Since there are no binaries > associated with the source, britney refuses to migrate it. Indeed, > one > could just do a binary-only build of it, upload it, and it would > migrate > stright the next day. > > Or one could ask for an exception to the non-free buildds as > docuemnted > on > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable > > As you can see, nothing relating to that bug. > Could we add a note to tracker or excuses for non-free packages on what the developer needs to do to get it to migrate? My understanding of your explanation is that we need to do a binary upload for non-free because it's not auto-built. It's a difference from how main is handled and and it seems like putting documentation for the difference would help prevent confusion in the future. Diane signature.asc Description: This is a digitally signed message part
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, Dec 09, 2020 at 09:44:25AM -0800, Diane Trout wrote: > Could we add a note to tracker or excuses for non-free packages on what > the developer needs to do to get it to migrate? IMHO, that's inappropriate. That would mean artificially adding into britney something that is really a nuance of how the archive and buildd system is currently set up. Alright that's definitely doable, but I consider this something that the maintainer of a non-free package ought to know (it's clearly written in the devref, for starters). There are quite a few more details of how non-free is different from any other suite, starting from how little testing of it there is. Though I guess in the past years the britney report on tracker changed enough to be more and more friendly to developers, so I guess the release team (which is the team that would be in charge on the content of the "testing migrations" box) would do it if talked to appropriately… Even then, the message says that "cluster3 has no binaries on any arch" - from there why can't one try to figure why there are no binaries? I'm positive that dumping the tracker link and that message in debian-mentors@ would yield the reason why it's stuck quite quickly. (note that the thread Andreas started on -devel@ is about the how people seems to notice first the "failed to migrate to testing" bugs, not about why cluster3 is not migrating). > My understanding of your explanation is that we need to do a binary > upload for non-free because it's not auto-built. Rather, I encourage you to read the devref part on how to enable auto-building. The package seems to have XS-Autobuild: yes in d/control even in oldoldstable, so I guess it means nobody sent the request to the buildd admins. > It's a difference from how main is handled and and it seems like > putting documentation for the difference would help prevent confusion > in the future. I insist that such doc belongs to devref. If that is lacking, devref should be improved. The current devref maintainer is very open to patches :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: CentOS and Debian/Ubuntu release cycles
On Wed, 09 Dec 2020 16:25:54 +, Stephan Lachnit wrote: >When we look into why people use CentOS, the reason is pretty simple: it is >(or was) binary-compatible with RHEL, just without the support [2]. >I was reading comments from people that use RHEL on their production, but >CentOS at home or for testing, because you don't need to pay for it. >These use cases now don't work anymore, forcing them into either paying for >RHEL, or moving to a different ecosystem. I know of at least two companies where the techies were quite happy with Debian (and delivered low cost and high availability with it), and then the non-technical management decided to move to Red Hat (because there is no support for Debian [meaning "no support with the official Debian label on it", disregarding the fact that you can buy superior Debian support all over the globe]), did the migration, fainted over the first Red Hat bill and promptly migrated over to CentOS (which has the same support situation as Debian). Never expect any kind of reasonable decision from enterprise IT management. You can only earn disappointment. >The more I started thinking about it, the more I wondered about why Debian >Stable and Ubuntu LTS are *not* binary-compatible. >It just doesn't make sense to me. Both Debian Stable and Ubuntu LTS provide a >more "long term" approach than let's say Fedora. >And while Ubuntu LTS is based on Debian, it is not based on Debian Stable, >even though they have release cycle of two years. >It would seem kinda obvious that Debian and Ubuntu have a common freeze period >and work on LTS maintenance together. > >Does anyone know why this is not the case? I suspect some historical reasons, >but I couldn't find anything quickly. Ubuntu never cared about Debian. They just take our work and the praise. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: CentOS and Debian/Ubuntu release cycles
On Wed, Dec 09, 2020 at 05:02:50PM +, Andrew M.A. Cater wrote: > Two different distributions: two different approaches. Ubuntu support a > small subset of packages in their main distribution (as opposed to > multiverse/universe). Ubuntu packages are often pulled from Debian stable > and testing at the same time, brought together and then released. Ubuntu > changes significantly every six months and publishes an LTS once every two > years. A minor correction: Ubuntu pulls from Debian unstable, not from testing or stable. -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Invitation to QUOTE 09/12/2020
I've invited you to fill out the following form: Untitled form To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLSdjJfZ8yHQbN6PxooA8S-WLESfo6wP5FJtNk1duVDuUMWr-mg/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link Dear Ladies and Gentlemen, Please let us have your best quotation and delivery time for the following items: 1.Self Priming High Head Centrifugal Pump HT8301-80 Qty=30pcs Parts Number: HT8301-80 Kindly send your offer/quotation to email: purchas...@unilevgroup.nl For further questions please do not hesitate to contact us. We look forward to receive your offer. Best Regards, Ibrahim Bakker Procurement Manager Tel:+31(0)108082036 Fax:+31(0)108082037 Google Forms: Create and analyze surveys.
Re: CentOS and Debian/Ubuntu release cycles
On Wed, Dec 9, 2020 at 7:17 PM Marc Haber wrote: > Ubuntu never cared about Debian. That is probably not entirely correct, there are parts of the Ubuntu community, including Canonical employees, that definitely care about Debian, to the point that they are Debian members and fairly core contributors. Over the years Debian has had lots of new members/contributors who came from Ubuntu, especially due to the policy Ubuntu put in place a long while ago of sending new packages to Debian first. I myself only came to Debian because of another derivative, Knoppix. I think it is important for Debian to have healthy relationships with our derivatives and to involve them in Debian as much as possible. -- bye, pabs https://wiki.debian.org/PaulWise
Re: CentOS and Debian/Ubuntu release cycles
On Thu, Dec 10, 2020 at 5:42 AM Stephan Lachnit < stephanlach...@protonmail.com> wrote: > Hi all, > > maybe you already have heard it, CentOS is basically dead now. It used to > be an exact RHEL clone, but now it's kind of an RHEL beta [1]. > > Red Hat'er here. CentOS is certainly not dead. This is basically badly timed a) Signalling ;the original announcement signaling this was going to happen was back in August and went pretty much unnoticed/reported due to the Pandemic. And b) Bad timing with the SKU changes and programmes being developed inside RH to make this seem less jarring. Right now those SKU and Programme announcements are still baking and are scheduled for sometime in the first Quarter of next year and really should have been concurrent to the announcement around CentOS8 having a reduced support window. I really hope however those announcements get hurried along by the gathering storm of Stunt media reactions happening. There is also https://rockylinux.org/ - which is now live and will follow efforts by the one of the original CentOS community peeps. My guess is that it will be more fork-like than what is baking internally at RH right now. When we look into why people use CentOS, the reason is pretty simple: it is > (or was) binary-compatible with RHEL, just without the support [2]. > I was reading comments from people that use RHEL on their production, but > CentOS at home or for testing, because you don't need to pay for it. > These use cases now don't work anymore, forcing them into either paying > for RHEL, or moving to a different ecosystem. > Streams is currently being used by several very large orgs, and it makes sense to make it really a RHEL-next+ project, which is effectively what it is. Binary compat is mostly a thing of the past in modern Rhel due to containerization. Container tooling in userspace is one of the reasons RH is aligning with this approach. It is becoming hard to introduce things into RHEL base without breaking the CentOS model - so in effect CentOS Stream is really an honest approach. Yes you can debate wether it would have been better to wait until Rhel9 to do this, but the reality is RH has Cadence which is out of alignment with the build and support model of CentOS. I think for now it is going to be received badly due to a) and b) factors no-matter what unless those announcements get rushed along. -Joel
Bug#977019: ITP: golang-golang-x-term -- Go terminal and console support
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-golang-x-term Version : 0.0~git20201207.ee85cb9-1 Upstream Author : Go * URL : https://github.com/golang/term * License : BSD-3-clause-Google Programming Lang: Go Description : Go terminal and console support This repository provides Go terminal and console support packages. Why packaging: this is a new build dependency of docker.io 20.10.0
Re: Bugs "fails to migrate to testing for too long" (Was: cluster3 dropped out of testing)
On Wed, 2020-12-09 at 19:31 +0100, Mattia Rizzolo wrote: > > Even then, the message says that "cluster3 has no binaries on any > arch" > - from there why can't one try to figure why there are no binaries? > I'm > positive that dumping the tracker link and that message in > debian-mentors@ would yield the reason why it's stuck quite quickly. > (note that the thread Andreas started on -devel@ is about the how > people > seems to notice first the "failed to migrate to testing" bugs, not > about > why cluster3 is not migrating). After learning of the issue I went with asking the debian-med team since I thought I was missing something, I hadn't thought asking debian-mentors. I do think it would've saved everyone's time if excuses included a suggestion to go read 5.10.5 https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable for non-free packages in that state. It is not uncommon to forget a detail that one doesn't use frequently. Thank you for explaining the problem though. Diane signature.asc Description: This is a digitally signed message part
Re: CentOS and Debian/Ubuntu release cycles
On Dec 10, Joel Wirāmu Pauling wrote: > is. Binary compat is mostly a thing of the past in modern Rhel due to > containerization. Container tooling in userspace is one of the reasons RH Cool narrative, but the reality is a bit more complex than that. Fibre Channel users need very specific kernels or else the hardware vendors will refuse support (and their vendor drivers will not compile). -- ciao, Marco signature.asc Description: PGP signature
