Re: Problems while searching for a new upstream version
On 4/8/20 8:54 AM, Mechtilde Stehmann wrote: > How can I solve it? Run uscan on your own system to check for new upstream releases. This is a known issue due to the high number of packages that are checked by the QA servers, see: #955268. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Re: Problems while searching for a new upstream version
Le 08/04/2020 à 08:54, Mechtilde Stehmann a écrit : > Hello, > > for most of my packages I get the following message at > tracker.debian.org (e.g. for tbsync) > > > uscan had problems while searching for a new upstream version: > > In watchfile debian/watch, reading webpage > https://github.com/jobisoft/TbSync/releases/ failed: 429 too many requests > > > > How can I solve it? > > Kind regards Hi, BTS: https://bugs.debian.org/955268 Fix: https://salsa.debian.org/debian/devscripts/-/merge_requests/181 (waiting for review) signature.asc Description: OpenPGP digital signature
429 too many requests Re: Problems while searching for a new upstream version
This is an issue with the checking system, not a bug in your package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955268
Re: What to do when DD considers policy to be optional? [kubernetes]
On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote: >On 2020-04-05 21:15 +0200, Marc Haber wrote: >> having an obsolete version of the software distributed >> with/through Debian is (rightfully) seen a liabilty by some upstreams, >> not as an asset. > >I think a more interesting/important question is whether users like >it, rather than whether upstreams like it. I think it is also important to have our users be taken seriously by upstreams. There is software that doesn't move as fast any more. Using a two years old version of those is often fine. Kubernetes, docker etc, however, are fast moving targets. Nobody in the uptream community is willing to even consider answering a question about a version that is two years old. The dialog will inevitably be "well, first you update to our latest version and verify whether your question still applies, then come back with your question" "but I am using the version in Debian stable!" "well, Debian is stupid! Use ". This is not doing our users a favor. And it hurts the Project. >Quite a lot of users just want to use stuff and so long as it works >for their purposes they really don't know or care if it is 2 years >old. And if it doesnt they want to be able to google for their issues or ask the upstream community. You cannot ask the kubernetes community a question about a kubernetes version that is two years old. >I quite often find myself in this situation. Quite a lot of >software is not something you want to care about - you just want to >use it. Quite a lot, yes. But there is software that doesn't work that way. >Now of course things get sticky when the old version _doesn't_ work >for the user's purpose (which happens sometimes) and they to go to bug >upstream about the issue (rather than bugging debian). Yes. >So long as most users will find it works for them, then I think it's >still really useful for us to package stuff, That is not going to happen with kubernetes, docker, node.js et al at this current time. >because it's good for our >users, whatever upstreams would prefer. What proprtion of users are >likely to find a 2-yr old version satisfactory is a judgement for >packagers (who will be left with the resulting bugs). Agreed. >In cases like this its also good to document that bugs should go to >debian, not upstream, although of course not many people read docs so >that won't work as well as one might like. They don't. I remember when exim was still popular and people kept coming to the upstream mailing list with their questions about Debian's split config, not having read our docs. I stil cringe at the thought. 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: Announcing Debian Social
On Mon, 23 Mar 2020 08:49:44 +0100, Enrico Zini wrote: >On Mon, Mar 23, 2020 at 08:10:18AM +0100, Marc Haber wrote: >> While we're at thiss, what is the tracker.d.o authenticating against? >> Since Firefox has removed the point-and-drool interface to client >> certificates, one needs to manually meddle around with OpenSSL to be >> able to log in. > >You can find extensive and up to date documentation on how to make it >work here: https://wiki.debian.org/DebianSingleSignOn That answers my first question, what tracker.debian.org is authenticating against. I might have forgotten, but the error message about my certificating being expired comes well before anything belonging to tracker.d.o coming up, so I am cut off from the actual web page that might contain the information. This said, Firefox in unstable doesn't allow certificate enrollment any more, it just says that is not supported any moe. The wiki page doesn't give enough information for me to understand how to continue. I'd rather have the page saying more explicitly "sorry, you have do use OpenSSL on the command line to use Firefox here", if I interpret the evidence correctly. I still hope that I'm wrong. >This said, I would prefer not to see this kind of attitude in any of the >places I use to work with others. Can you please explain that? I didn't mean to attack anybody but Mozilla. 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: What to do when DD considers policy to be optional? [kubernetes]
On 4/8/20 6:14 PM, Marc Haber wrote: > On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote: >> On 2020-04-05 21:15 +0200, Marc Haber wrote: >>> having an obsolete version of the software distributed >>> with/through Debian is (rightfully) seen a liabilty by some upstreams, >>> not as an asset. >> >> I think a more interesting/important question is whether users like >> it, rather than whether upstreams like it. > > I think it is also important to have our users be taken seriously by > upstreams. There is software that doesn't move as fast any more. Using > a two years old version of those is often fine. > > Kubernetes, docker etc, however, are fast moving targets. Nobody in > the uptream community is willing to even consider answering a question > about a version that is two years old. The dialog will inevitably be > "well, first you update to our latest version and verify whether your > question still applies, then come back with your question" "but I am > using the version in Debian stable!" "well, Debian is stupid! Use > ". > > This is not doing our users a favor. And it hurts the Project. I don't agree with this *at all*. It is not in the interest of our users to be forced to update the software they use for their infrastructure every few months. They don't want that. If upstream think that this is what users want, well upstream is wrong then. And the stability of Debian (understand: not a moving target, rather than bug free) is one of our very good point. Also, the docker world is not the only one to be this way. It used to be like this in OpenStack too. In the OpenStack world, they haven't changed the way they release (ie: every 6 months), but the user survey has shown that almost every user is lagging 4 or 5 versions behind, because upgrading the infrastructure is both difficult and time consuming. Over time, they became very helpful for back-porting fixes to EOL versions too. The main issue is that upstream wants to be able to do fast development, and focus on the development rather than on their users. Taking care of a long term release is time consuming. Taking care of multiple old release is very annoying (backporting fixes may not be always obvious). So yeah, probably upstream will reply with "Debian is stupid". Let them say it if they want to: that doesn't make them right. It only shows they are completely ignorant of what their users want, and the need of downstream distributions. The more there's going to be users going at them asking them about a 2 year old release, the more they will realize that Debian isn't stupid, and that this is the way the final users want to consume their work. So it's good for us, and beneficial to the project. It's doing our users a favor, and it doesn't hurt us. >> Quite a lot of users just want to use stuff and so long as it works >> for their purposes they really don't know or care if it is 2 years >> old. > > And if it doesnt they want to be able to google for their issues or > ask the upstream community. You cannot ask the kubernetes community a > question about a kubernetes version that is two years old. Of course you can! If they choose to not answer, or say bad things about Debian, that doesn't make them smarter and us stupid. It just shows how careless upstream is. >> I quite often find myself in this situation. Quite a lot of >> software is not something you want to care about - you just want to >> use it. > > Quite a lot, yes. But there is software that doesn't work that way. Could you please explain why any software would be different? It's just upstream that has a super ego and think they are different. Nothing more, nothing less. >> So long as most users will find it works for them, then I think it's >> still really useful for us to package stuff, > > That is not going to happen with kubernetes, docker, node.js et al at > this current time. Like many other software stack, hopefully they will learn by this mistake and the release management will change. Cheers, Thomas Goirand (zigo)
Re: What to do when DD considers policy to be optional? [kubernetes]
doesn´t this whole discussion just mean that k8 should just not be in Debian? It should be a third party package, perhaps with a third party repo, and just not be in Debian at all. If any means of packaging for a Debian release results in a package that is essentially unsupported by upstream... what is the value of including it? For stuff that moves too quickly... perhaps a different repo like *forever-sid.d.o* could be set up... and have it built against releases, so people have current software for Debian... without it being part of Debian. That repo would have different rules for it... that loosens things up for this kind of hairball package that isn´t stable enough to benefit from Debian stability. On Wed, Apr 8, 2020 at 4:36 PM Thomas Goirand wrote: > On 4/8/20 6:14 PM, Marc Haber wrote: > > On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote: > >> On 2020-04-05 21:15 +0200, Marc Haber wrote: > >>> having an obsolete version of the software distributed > >>> with/through Debian is (rightfully) seen a liabilty by some upstreams, > >>> not as an asset. > >> > >> I think a more interesting/important question is whether users like > >> it, rather than whether upstreams like it. > > > > I think it is also important to have our users be taken seriously by > > upstreams. There is software that doesn't move as fast any more. Using > > a two years old version of those is often fine. > > > > Kubernetes, docker etc, however, are fast moving targets. Nobody in > > the uptream community is willing to even consider answering a question > > about a version that is two years old. The dialog will inevitably be > > "well, first you update to our latest version and verify whether your > > question still applies, then come back with your question" "but I am > > using the version in Debian stable!" "well, Debian is stupid! Use > > ". > > > > This is not doing our users a favor. And it hurts the Project. > > I don't agree with this *at all*. It is not in the interest of our users > to be forced to update the software they use for their infrastructure > every few months. They don't want that. If upstream think that this is > what users want, well upstream is wrong then. And the stability of > Debian (understand: not a moving target, rather than bug free) is one of > our very good point. > > Also, the docker world is not the only one to be this way. It used to be > like this in OpenStack too. In the OpenStack world, they haven't changed > the way they release (ie: every 6 months), but the user survey has shown > that almost every user is lagging 4 or 5 versions behind, because > upgrading the infrastructure is both difficult and time consuming. Over > time, they became very helpful for back-porting fixes to EOL versions too. > > The main issue is that upstream wants to be able to do fast development, > and focus on the development rather than on their users. Taking care of > a long term release is time consuming. Taking care of multiple old > release is very annoying (backporting fixes may not be always obvious). > > So yeah, probably upstream will reply with "Debian is stupid". Let them > say it if they want to: that doesn't make them right. It only shows they > are completely ignorant of what their users want, and the need of > downstream distributions. > > The more there's going to be users going at them asking them about a 2 > year old release, the more they will realize that Debian isn't stupid, > and that this is the way the final users want to consume their work. So > it's good for us, and beneficial to the project. It's doing our users a > favor, and it doesn't hurt us. > > >> Quite a lot of users just want to use stuff and so long as it works > >> for their purposes they really don't know or care if it is 2 years > >> old. > > > > And if it doesnt they want to be able to google for their issues or > > ask the upstream community. You cannot ask the kubernetes community a > > question about a kubernetes version that is two years old. > > Of course you can! If they choose to not answer, or say bad things about > Debian, that doesn't make them smarter and us stupid. It just shows how > careless upstream is. > > >> I quite often find myself in this situation. Quite a lot of > >> software is not something you want to care about - you just want to > >> use it. > > > > Quite a lot, yes. But there is software that doesn't work that way. > > Could you please explain why any software would be different? It's just > upstream that has a super ego and think they are different. Nothing > more, nothing less. > > >> So long as most users will find it works for them, then I think it's > >> still really useful for us to package stuff, > > > > That is not going to happen with kubernetes, docker, node.js et al at > > this current time. > > Like many other software stack, hopefully they will learn by this > mistake and the release management will change. > > Cheers, > > Thomas Goirand (zigo) > >
Re: What to do when DD considers policy to be optional? [kubernetes]
On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote: I don't agree with this *at all*. It is not in the interest of our users to be forced to update the software they use for their infrastructure every few months. Isn't that the user's decision, when they decided to adopt a tool that requires this deployment model? Or, if they're not clear about what adopting this tool means, I agree that isn't in their interest for them to see that there's a debian package and be fooled into thinking it doesn't require this deployment model just because there's a zombie package in debian stable which will be essentially unsupported and will completely cut them off from the tool's community. Putting it into debian provides zero benefit, and they could get the same "stability" guarantee by just keeping a copy of a two year old third party .deb and never updating it.
Re: What to do when DD considers policy to be optional? [kubernetes]
On 2020-04-08 22:36:17 +0200 (+0200), Thomas Goirand wrote: [...] > Also, the docker world is not the only one to be this way. It used to be > like this in OpenStack too. In the OpenStack world, they haven't changed > the way they release (ie: every 6 months), but the user survey has shown > that almost every user is lagging 4 or 5 versions behind, because > upgrading the infrastructure is both difficult and time consuming. Over > time, they became very helpful for back-porting fixes to EOL versions too. > > The main issue is that upstream wants to be able to do fast development, > and focus on the development rather than on their users. Taking care of > a long term release is time consuming. Taking care of multiple old > release is very annoying (backporting fixes may not be always obvious). > > So yeah, probably upstream will reply with "Debian is stupid". Let them > say it if they want to: that doesn't make them right. It only shows they > are completely ignorant of what their users want, and the need of > downstream distributions. > > The more there's going to be users going at them asking them about a 2 > year old release, the more they will realize that Debian isn't stupid, > and that this is the way the final users want to consume their work. So > it's good for us, and beneficial to the project. It's doing our users a > favor, and it doesn't hurt us. [...] To be fair, the OpenStack community as a whole never suggested it was stupid for distros to carry older versions of the software (many folks there have experience packaging for and in LTS GNU/Linux distributions too, so understand the pain). What was said is that it's hard to find enough people with sufficient time to maintain years-old versions of the software, thus the community looks to the distributions' package maintainers to help shoulder some of that burden, coordinate with each other on backporting fixes they need to the versions they're carrying, and so on. What has typically been laughed off as impractical is suggestions like not developing as much software so quickly. The OpenStack community also doesn't tell users who have questions about 2+ year old versions of the software to go away until they upgrade to the bleeding edge. However, it's only natural that if users ask questions about old tech, they may find that the number of folks still around who remember how it worked (beyond what's already in the older versions of the software's documentation) will be vanishingly small. -- Jeremy Stanley signature.asc Description: PGP signature
Re: What to do when DD considers policy to be optional? [kubernetes]
On 3/25/20 11:45 PM, Marc Haber wrote: On Tue, 24 Mar 2020 20:37:16 +, Jeremy Stanley wrote: If this represents the actual state of building Kubernetes, it's unclear to me why Debian would package it at all. I don't see the value to users in consuming Kubernetes from a Debian package if the result is compromising on Debian's vision and values so that they can get the exact same thing they'd have if they just used the Kubernetes community's recommended tooling to install it instead. I'm all for using the best tool for the job, and while I've been a die-hard Debian user for more than two decades I also don't install every last bit of software from its packages. Some software ecosystems have chosen to focus on tools and workflows which are incompatible with Debian's, but that doesn't mean that either one is inherently bad nor that they need to be integrated at all costs. Software packages like kubernetes, docker, and many of the other "hip tools of the day" are moving way too fast for our release scheme. Additionally, many communities and developers stop caring for their software once it has cleared the door and laugh upon people who are using anything but their latest release. I think we're not doing the world a favor packaging those software and releasing it with our stable release [...] Docker release cycle is not that fast anymore. The current 19.03 branch has been maintained by upstream for 10 months now. Not that bad. I think it makes it a valuable package for Debian stable. https://www.docker.com/blog/extending-support-cycle-docker-community-edition/ https://docs.docker.com/engine/release-notes/#version-1903
Re: What to do when DD considers policy to be optional? [kubernetes]
On Mi, 08 apr 20, 16:44:22, Peter Silva wrote: > doesn´t this whole discussion just mean that k8 should just not be in > Debian? > > It should be a third party package, perhaps with a third party repo, and > just not be in Debian at all. > If any means of packaging for a Debian release results in a package that is > essentially unsupported by upstream... what is the value of including it? > For stuff that moves too quickly... perhaps a > different repo like *forever-sid.d.o* could be set up... and have it built > against releases, so people > have current software for Debian... without it being part of Debian. > > That repo would have different rules for it... that loosens things up for > this kind of hairball package that isn´t stable enough to benefit from > Debian stability. You mean something like http://fasttrack.debian.net ? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#956263: ITP: onemkl -- oneAPI Math Kernel Library (oneMKL) Interfaces
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: onemkl * URL : https://github.com/oneapi-src/oneMKL * License : Apache-2 Programming Lang: C++, OpenCL (maybe SYCL) Description : oneAPI Math Kernel Library (oneMKL) Interfaces It looks like intel is starting a brand new MKL implementation to incorprate OpenCL (GPU acceleration). I don't know how Intel will deal with its intel-mkl (proprietary) and oneMKL (apache-2) which provide quite similar functionality. So I'm keeping an eye on this.
Bug#956264: ITP: onedal -- oneAPI Data Analytics Library (oneDAL)
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: onedal * URL : https://github.com/oneapi-src/oneDAL * License : Apache-2 Programming Lang: C++, SYCL Description : oneAPI Data Analytics Library (oneDAL) This is possibly previously known as intel DAAL, a proprietary machine learning library with good performance. I'm not quite sure whether intel changed the proprietary license of DAAL to Apache-2, or created a new implementation.
Re: What to do when DD considers policy to be optional? [kubernetes]
On 4/8/20 10:44 PM, Peter Silva wrote: > doesn´t this whole discussion just mean that k8 should just not be in > Debian? IMO no. It means that if we have enough packaging resources (which probably we don't, I can't tell), then we may just as well ignore an upstream who's basically saying we should never package what they do, or package the way they want, rather than the we we should. > It should be a third party package, perhaps with a third party repo, and > just not be in Debian at all. > If any means of packaging for a Debian release results in a package that > is essentially unsupported by upstream... what is the value of including > it? For stuff that moves too quickly... perhaps a > different repo like *forever-sid.d.o* could be set up... and have it > built against releases, so people > have current software for Debian... without it being part of Debian. > > That repo would have different rules for it... that loosens things up > for this kind of hairball package that isn´t stable enough to benefit > from Debian stability. As a user, I'd prefer Kubernets to be in Stable if possible. I'd be one of these users who don't care about the latest shiny feature, and prefer something stable, supported for YEARS to come, not just 3 months. Cheers, Thomas Goirand (zigo)
