Re: Aw: Re: Community renewal and project obsolescence

On 2023-12-31 05:22, Mo Zhou wrote: I am not able to develop DebGPT and confess I am not investing my time in learning to do it.  But can we attract the people who want to tinker in this direction? Debian funds should be able to cover the hardware requirement and training expenses even if

Re: Community renewal and project obsolescence

On 2023-12-29 20:13, Andrey Rakhmatullin wrote: As someone who would like to participate more in the development of Debian, my personal experience is that making contributions is like dropping a message in a bottle into the sea. It feels like a complete crap-shot whether I'll even receive a

Re: salsa accounts

On 2022-11-04 20:11, Gunnar Wolf wrote: Before emailing this list I requested account creation three times, read the wiki twice, emailed the admins once, and asked on IRC once too. Now asking on IRC again without response, not counting the emails on this list. Either you point me to a

Re: [External] Re: ThinkPad laptops preinstalled Linux

❦ 4 juin 2020 00:35 +00, Paul Wise: >> Then, we need the SOF firmwares, currently not in Debian. I see >> you have #960788. I just got aware of it through #962134. I am happy to >> help you on this package and get it uploaded. > > Unfortunately SOF firmware, while it has freely licensed source

Re: [External] Re: ThinkPad laptops preinstalled Linux

❦ 3 juin 2020 13:39 +00, Mark Pearson: > As an important example - the X1 Carbon 7 (which is a popular machine) > still doesn't work well with any version of Debian (including > experimental or testing) as the audio is broken. Debian users have to > jump through a few hoops to get it to work.

Re: [Summary] Discourse for Debian

❦ 15 avril 2020 12:45 +01, Neil McGovern: >> Would you be willing to list out which points it is from the given >> "cons" category which you see as positives? > > I'd really rather not at this stage, as I'm already seemingly having to > spend time talking about how Discourse is set up, rather

Re: Debian and Non-Free Services

❦ 4 octobre 2019 16:57 +02, Thomas Goirand : >>> That would just lead to packages using these to no longer including the >>> Vcs-* fields... There are some valid reasons to host packages on >>> services such as GitLab or GitHub such as when they are hosted there as >>> part of the upstream

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

❦ 24 juillet 2019 21:29 +00, Scott Kitterman : >>> This entire discussion feels to me like a small group of developers >>> trying to tell the rest of us "my way or the highway". We are >>> perfectly capable of phasing out obsolete workflows without a hammer >>> like a GR (remember dpatch). >>

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

❦ 24 juillet 2019 12:23 +00, Scott Kitterman : > This entire discussion feels to me like a small group of developers > trying to tell the rest of us "my way or the highway". We are > perfectly capable of phasing out obsolete workflows without a hammer > like a GR (remember dpatch). Without a

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

❦ 24 juillet 2019 17:07 +10, Alexander Zangerl : > well, i do exist. i have a few packages that aren't vc'd, and i don't see > any need to change that. while i don't mind git, but i'd hate to be _forced_ > to use salsa and gbp. > > so, why isn't it enough to recommend those things? Because

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

❦ 23 juillet 2019 19:05 +01, Steve McIntyre : >>3- Mandating using Salsa as a Git repository. >> >>I do believe #1 will pass easily, but that it's useless without #2, and >>there is some kind of uncertainty. For #3, I'm not even sure we should >>vote for that, I probably even prefer it not to be

Re: Are online services also software for Debian's rules?

❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen"  : >> And honestly, I don't have to do a thing. Nothing will change. Free >> software using "non-free services" will stay in main because they meet >> the proper requirements (policy 2.2.1). > > No, it doesn't. 2.2.1 says "None of

Re: Are online services also software for Debian's rules?

❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen"  : >> > That is a disservice to our users. While for many users this is true, >> > those >> > users will have contrib (and probably non-free) enabled in their >> > sources.list. >> > So moving the package to contrib doesn't change

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen"  : > That is a disservice to our users. While for many users this is true, those > users will have contrib (and probably non-free) enabled in their sources.list. > So moving the package to contrib doesn't change anything for them.

Re: Bug#856139: certspotter: long description advertises commercial service

❦ 9 août 2017 19:57 GMT, "Dr. Bas Wijnen"  : > If the free options are limited to a point where it does not make sense to > recommend them to our users, that means the non-free service should be > recommended and IMO that means the program should be in contrib. As a

Re: Debian packages advertising non-free services

❦ 8 août 2017 09:31 +1000, Ben Finney  : >> However, it is easy to find other packages interacting with >> proprietary services without a free implementation. For example, any >> package interacting with Google Cloud (golang-google-cloud package). > > I am in agreement with

Re: [pkg-go] Bug#856139: Bug#856139: certspotter: long description advertises commercial service

❦ 7 août 2017 18:12 GMT, "Dr. Bas Wijnen"  : >> We have all kind of software advertising non-free services. Search for >> "Google" or "Amazon". The comparison is even unfair as the service >> advertised here is available as free software (not the case for most >> services

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

❦ 4 août 2017 20:03 +0200, Jonas Smedegaard  : > Am I alone in finding it wrong to promote commercial services in long > descriptions of packages n Debian main? I agree with Faidon on this one. Just saying that because the way you ask the question is more likely to get the

Re: Formal declaration of weak package ownership in source packages

❦ 12 décembre 2016 01:38 GMT, Scott Kitterman  : > P. S. In case you wonder how maintainerless works, go look at the > dusty corners of the Ubuntu archive. Ubuntu get packages even when nobody ever cared about them. In our case, for each package, we have at least one

Re: Replace the TC power to depose maintainers

❦ 1 décembre 2016 15:46 GMT, Ian Jackson  : > There is a recent case where: > * The maintainer has done nothing to the package for many years, >other than infrequent (and usually short) emails to NAK >contributions from others; > * The package is years

Re: third-party packages adding apt sources

❦ 21 mai 2016 09:40 +0200, Ole Streicher  : >>> Providing a proper Debian source package is also a lot more work than >>> writing some kind of ad-hoc build system that spits out a .deb or >>> three. >> >> Totally agree. Our standards are far too high for many upstreams. > >

Re: third-party packages adding apt sources

❦ 21 mai 2016 10:24 +0200, Martin Steigerwald  : > Still, the turn around time between upstream and debian release would be > quite > high for Debian stable users, but maybe part of such a collaboration could be > to also provide newer releases via backports. Also… if

Re: third-party packages adding apt sources

❦ 21 mai 2016 14:55 +0800, Paul Wise  : >> For some languages, embedded copies are a pattern. Notably Go. But there >> is also the omnibus stance: the embedded copy could not be in the >> source, but could be in the shipped artifact. This includes Go, JS and >> Java (when using

Re: third-party packages adding apt sources

❦ 21 mai 2016 14:07 +0800, Paul Wise  : >> Totally agree. Our standards are far too high for many upstreams. > > I don't understand the disconnect here. Are upstreams not interested > in software quality to the extent we are? Many of them don't consider packaging quality as

Re: third-party packages adding apt sources

❦ 20 mai 2016 08:59 -0300, Antonio Terceiro  : >> testing is not suitable for most people because: >> >> 1. no security support > > That's not true. Proper security fixes will get into testing after 2 > days in unstable if everything goes right as long as the maintainer,

Re: third-party packages adding apt sources

❦ 19 mai 2016 18:04 +0100, Ian Jackson  : >> b) many upstreams appear frustrated about getting their package >> officially supported in Debian. Sometimes there is good reason their >> package doesn't belong in Debian but sometimes it is more about inertia >> in

Re: third-party packages adding apt sources

❦ 19 mai 2016 16:39 GMT, Bas Wijnen  : > Debian stable is for users who want a rock solid system. It is out of date by > the nature of how it is built. Users who want to get the newest versions of > their software should not be running stable; testing is probably better for

Re: vmdebootstrap sprint report

❦ 9 novembre 2015 21:16 GMT, Neil Williams  : > That remains to be seen. The objective was to replace live-build in the > preparation of official Debian live images as well as provide official > Debian VM images (without using live-build). It is also only live-build > which

Re: Repository Link are NOT https://

❦ 3 septembre 2015 17:03 -0700, Russ Allbery  : >> I have discovered that non of the repository links is https:// . Is it >> not safer to use only https:// connections. > >> And as well the download of a debian distro is only http:// . > >> Sorry to say that but nearly all

Re: Why are in-person meetings required for the debian keyring?

❦ 11 février 2015 11:17 -0800, Nikolaus Rath nikol...@rath.org : However, it seems to me that meeting someone in person isn't actually verifying the relevant identity here. My trust in a Debian developer is not based on him holding a particular legal name, it is in his history of