Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
> Therefore, in the current situation, the Debian Project is unable to > collaborate both with the FSF and any other organisation in which Richard > Stallman has a leading position. Hi Santiago, I know this is more of a question about the original FSFE statement with this phrasing, but since you're amending it anyway I was wondering if you could expand upon the scope of this collaboration? preferably in the amendment text, but I understand if a list reply is more suitable. I'm not aware of any project level (i.e. funding, hardware or emails) interaction with the FSF, given the minor disagreement over the non-free archive. What about the GNU project? Are you asking DDs to only communicate and submit patches in a personal capacity? "unable to collaborate" implies there was collaboration before, so what exactly would the Debian project stop doing? -- Phil Morrell (emorrp1) signature.asc Description: PGP signature
Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
On Tue, Mar 30, 2021 at 04:10:38PM +0200, Zlatan Todoric wrote: > On 3/30/21 14:15, Phil Morrell wrote: > > > Therefore, in the current situation, the Debian Project is unable to > > > collaborate both with the FSF and any other organisation in which Richard > > > Stallman has a leading position. > > Hi Santiago, > > > > I know this is more of a question about the original FSFE statement with > > this phrasing, but since you're amending it anyway I was wondering if > > you could expand upon the scope of this collaboration? preferably in the > > amendment text, but I understand if a list reply is more suitable. > > > > I'm not aware of any project level (i.e. funding, hardware or emails) > > interaction with the FSF, given the minor disagreement over the non-free > > archive. What about the GNU project? Are you asking DDs to only > > communicate and submit patches in a personal capacity? "unable to > > collaborate" implies there was collaboration before, so what exactly > > would the Debian project stop doing? > > Good question, we could probably amend that part with: > > "Therefore, in the current situation, the Debian Project discourages > collaboration both with the FSF and any other organisation in which Richard > Stallman has a leading position." Excellent, thank you for listening and I hope this weaker version provides a nice option for those who want to say *something* but not require any specific action of either FSF or their fellow contributors. signature.asc Description: PGP signature
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
On Thu, 1 Apr 2021, Niels Thykier wrote: > Assuming that the letter from https://rms-support-letter.github.io/ is > signed by Debian, could we please have clarified up front how the above There are evidently some who wish that there was more up front clarity about https://rms-open-letter.github.io/ too. Both letters have been added to the ballot completely unedited for the same reason - consistency of Debian's message with the wider ecosystem is of greater importance than precision. If you prefer different wording, I suggest you propose it as an amendment. > Notably, if it implies that Debian Developers some developers (e.g. > those who signed the open letter or voted certain elements on the ballot > higher than FD, etc.) would no longer be able to participate in DPL > votes, then I see this ballot as a change of our current constitutional > power (§4.1). > > Accordingly, I think this ballot should require a constitutional change > and a 3:1 majority or the text should explicitly state that no current > or future Debian Developer is considered a part of the "ambush mob". This GR is being made within the scope of §4.1.5 "They may also include position statements about issues of the day". I think you're reading more into this than the letter contains. If that was the implication then the proposer would have needed to specify a different section of the consitution for the resolution to be interpreted under. -- Phil Morrell (emorrp1) signature.asc Description: PGP signature
Re: "rms-open-letter" GR choice 2: sign https://rms-support-letter.github.io/
On Thu, 1 Apr 2021 at 21:29:27 +0200, Kurt Roeckx wrote: > The option is now on the website. Hi, I was wondering if anyone would mind explaining a point of procedure to me here. I understand that the discussion period is normally 2 weeks, and that the DPL confirmed a request to reduce it to 1 week. Measured from the 5th second, this would have expired at 2021-03-31 21:10 UTC. On Wed, 24 Mar 2021 at 17:09:34 -0400, Sam Hartman wrote: > Seconded. On Thu, 1 Apr 2021 at 09:43:36 +0200, Erik Schanze wrote: > Seconded. Do the additional proposals made in that week mean the discussion period has automatically been extended? Is the Secretary simply being pragmatic here, executing discretion before announcing the start of the voting period? Or perhaps the DPL has likely requested another alteration? signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 5
On Fri, 2 Apr 2021, Craig Sanders wrote: > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. Hi, please can you explain how this is significantly different from Proposal A "will not issue a public statement" and Proposal E "ambush mob"? Thanks. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 05:38:52PM +0200, Simon Josefsson wrote: > "Andrew M.A. Cater" writes: > > On Tue, Aug 23, 2022 at 10:53:46AM +0200, Simon Josefsson wrote: > >> "Andrew M.A. Cater" writes: > >> > In practice, the free installer is useless on its own. > >> > >> That is not my experience -- I'm using Debian through its installer on a > >> number of laptops, desktops and servers, and for my purposes it works > >> fine and in general I have not needed to enable non-free/contrib for > >> hardware support. > > > > I don't think you quite picked up on my meaning. The free installer is > > absolutely useless _because_ you are already using a machine containing a > > bunch > > of firmware (that you may or may not know anything about) - disk drives, > > basic > > drivers for graphics cards. If the free installer works, it's because you > > already have firmware. > > Hi Andrew. Ah, thanks for explaining what you meant. I have no problem > with builtin non-upgradeable firmware -- see > https://ryf.fsf.org/about/criteria for rationale. So I still disagree > with you, but now for a different reason. Just be aware that this rationale can have the opposite of its intended effect in the long term: https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/ Purism Librem 5 pursued RYF and as a result its users are unable to exercise Freedom 1. Novena open laptop required non-free-firmware upon release, but users are now able to enable previously proprietary features using libre software. On Mon, 22 Aug 2022 at 07:22, Simon Josefsson wrote: > Ansgar writes: > > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: > >> Do we need to update the Debian Social Contract for that? > >> Specifically paragraph 1, which currently reads > >> > >> Debian will remain 100% free > > > > No. Just like we don't need to update the Debian Social Contract for > > having https://deb.debian.org/debian/pool/non-free/: we just ship > > additional files that might be useful for people having specific > > hardware. > > I disagree -- what is being proposed here is to replace our current > DSC-compatible free software installer images with non-free. That goes > significantly further than what the spirit of DSC§5 suggests. Yours is certainly the historical consensus, but the entire point of this GR is to re-examine if that's the current interpretation. It might well be, which is why even its supporters have been keen to second a wording for the status-quo - the DebConf22 talk was quite clear they don't want to be blindsided by their social bubble. I find that if I assume the DSC points are unordered, and numbered only for reference, then there's sentences in there that support the offering of official images including firmware by default, even while considering the iso as a Debian component. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 07:57:36PM +0200, Simon Josefsson wrote: > Phil Morrell writes: > > > Just be aware that this rationale can have the opposite of its intended > > effect in the long term: > > > > https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/ > > My reading of that is that the FSF RYF program does not meet the needs > of people who do not care about having a fully free software system. I > don't see how that is unexpected. I'm not following the double negative here. I specifically mentioned Freedom 1 (study & change) because RYF's encouragement of secondary processors explictly blocks this. As pabs says, reverse engineering efforts described in the link I shared means that one can *only* achieve a fully free software system by rejecting the use of secondary processors. > > I find that if I assume the DSC points are unordered, and numbered only > > for reference, then there's sentences in there that support the offering > > of official images including firmware by default, even while considering > > the iso as a Debian component. > > Interesting, can you explain quoting the text supporting that? Apologies for the bait and switch, but I've been trying to word this for a while - I don't think it's possible (for me) to convey the nuance in async text, but I'd be happy to jump on Jitsi/Mumble to achieve shared understanding. Perhaps these points are enough for you to get the gist: > Our priorities are our users and free software Steve's Debconf22 talk points out both are *equally* important. Therefore it could be acceptable to provide a compromise to get our users started towards their free software endgame. > We encourage CD manufacturers to .. distribute the packages Treat "CD manufacturers" as "Debian Images Team" and you get the conclusion that there's nothing wrong with Official Debian media containing nonfree bits inside. > We will support people who ... use ... non-free works on Debian. > We will never make the system require the use of a non-free component. Emphasis on the *we* here, Debian is not adding any intermediary blockers between the user and their hardware. The hardware in question is either 0% functional from cold boot, or is *already* running non-free code as soon as it receives power that you simply can't interact with without loading the firmware. This GR isn't about hardware feature enhancement or optional user experience peripherals, this is about *core functionality* that d-i needs to support before the user can even express any libre choices. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
From absorbing this lengthy thread, my impression is that most folks are considering the nature of "officialness", therefore I'd like to ask any proposed text to elaborate on intentions for what "Official Debian" means such that voters can express their opinions on this aspect. * Images are officially produced by DDs via Debian infrastructure * Software that officially meets our highest policy ideals and standards * The officially recommended way to end up with a Debian install * Officially supporting humanitarian aid and accessibility because those who don't need it are already capable of meeting their needs in Debian --- I hope this kind of email is ok here, even though I'm not able to directly interact with the GR process (proposing/seconding etc.). If not, sorry for adding to the 138 messages. signature.asc Description: PGP signature
Re: General resolution: non-free firmware
On Sun, Aug 28, 2022 at 12:56:43AM +, Thorsten Glaser wrote: > Debian Project Secretary - Kurt Roeckx dixit: > > >it are available at: https://www.debian.org/vote/2022/vote_003 > > Is there support for something like A but not enabled by default? > That is, you have to actively select a nōn-default option I don't believe so, because that doesn't solve the problem at hand. How exactly do you select a non-default option if you cannot see or hear it? > More and more graphics adapters now also want firmware uploads to provide any > non-basic functions. A simple basic (S)VGA-compatible framebuffer is not > enough for most users these days; modern desktops expect 3D acceleration, and > a lot of current hardware will not provide that without extra firmware. > Current generations of common Intel-based laptops also need firmware uploads > to make audio work (see the firmware-sof-signed package). https://blog.einval.com/2022/04/19#firmware-what-do-we-do https://peertube.debian.social/w/gpdBYkAuxJ5D8V9DmsTvJS signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Thu, Sep 08, 2022 at 08:00:09AM +0200, Didier 'OdyX' Raboud wrote: > Le jeudi, 8 septembre 2022, 07.14:09 h CEST Russ Allbery a écrit : > > Didier 'OdyX' Raboud writes: > > > While we're at updating the Social Contract's article 5, what about a > > > more invasive cleanup, to reflect reality ? > > > > > Going *way* out on a limb (and to be honest I'm leaning hard against > > proposing this because I think this level of change would require more > > than a week's worth of discussion) > > > > 5. Works that do not meet our free software standards > > > > We acknowledge that some of our users require the use of works that > > do not conform to the Debian Free Software Guidelines. We have > > created areas in our archive for these works. These packages have > > been configured for use with Debian and we provide some > > infrastructure for them (such as our bug tracking system and mailing > > lists), but they are not part of the Debian system. We encourage > > distributors of Debian to read the licenses of the packages in these > > areas and determine if they can distribute these packages on their > > media. The Debian official media may include firmware from these > > areas that is otherwise not part of the Debian system to enable use > > of Debian with hardware that requires such firmware. > > As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one very > simple way to express the change we (some of us) want. The "statement of the > day" is a nice addition, but can risk being nitpicked-upon. I'd definitely > second a ballot option that would propose just this. In that spirit, some more wording suggestions and justification below. 5. Works that do not meet our free software standards We acknowledge that our users may require the use of works that do not conform to the Debian Free Software Guidelines. Such packages are not part of the Debian system, but we provide the enabling infrastructure as a convenience to our users. This includes the bug tracking system, installation media, mailing lists and separate archive areas. * "some of" implies a minority, but the GR was raised due to a lack of available new hardware meeting this except via ROM * "configured for use" always seemed like strange wording to me * "enabling" rather than supporting to avoid endorsing * "convenience to our users" shows up in some Disclaimers * "separate" applies to the archive areas, but not the install media? * "archive areas" to allow e.g. renaming contrib to non-free-depends * by mentioning installation media as infrastructure, shipping it ourselves with firmware, it becomes superfluous to "encourage" others to follow our recommendation in our own Social Contract (it's my understanding that was there back in the day so CDs wouldn't just limit to main out of paranoid safety, doing a disservice to users) * focussed on being short rather than mentioning every consequence - it's supposed to be a guiding mission statement, not Policy I'd like to include something around "otherwise meets all our other high standards" and "anything including these works will always remain clearly identified" (like non-free Disclaimer, sadly our ISO needs to include non-free firmware etc.) but I couldn't find a good wording. > From my sparse reading of the discussion so far, it now seems clear that the > SC needs amending; not doing so and finding convoluted ways to interpret its > actual version risks creating more confusion and misunderstandings than it > solves. Having contributed to some of those convoluted interpretations, I think you're right that there's enough support for change. I haven't seen much in the way of actual objections to the Images Team intention beyond the existence of Proposal D and complaining it's a breach of the SC. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Thu, Sep 08, 2022 at 11:38:09AM +0200, Simon Josefsson wrote: > Kurt Roeckx writes: > > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: > >> Thereby re-inforcing the interpretation that any installer or image with > >> non-free software on it is not part of the Debian system > > > > As you indicate yourself, this is an interpretation of the SC. I would > > really prefer that such a question was not open to interpretation and > > that the SC was changed to make it more clear what we mean. > > > > I don't actually understand what this part of your text is saying. Are > > you saying that an image with non-free software on it is non-official > > because it's not part of the Debian system? That is not something I read > > in that text. > > I don't think the word "official" is defined or used in any foundational > document, nor that its meaning is well agreed on or actually helps the > discussion. It seems easier to talk about what is considered part of > the Debian system or not: the foundation documents imply (to me) that > anything not following DFSG is not part of Debian. Therefor, an > installer that includes non-free content would not be part of Debian. > That does not prevent the project from distributing it, we do that today > and we distribute non-free/contrib today too without trouble. > > For me it helps to think that what the Debian project ships is a > superset of what is considered to be the Debian system. Policy on the other hand is very explicit (perhaps unintentionally): > The Debian system is maintained and distributed as a collection of packages. > The main archive area forms the Debian distribution. By that definition, no installation media are part of the Debian system and so are already permitted to use non-free components? Obviously Policy is "lower" in interpretation value that Constitution or Social Contract. It also has a note about "component", and I'd point out the term "section" is often used too (see rewording of Proposal C). > The Debian archive software uses the term “component” internally and > in the Release file format to refer to the division of an archive. The > Debian Social Contract simply refers to “areas.” This document uses > terminology similar to the Social Contract. signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Thu, Sep 08, 2022 at 11:55:43AM +0200, Jonathan Carter (highvoltage) wrote: > On 2022/09/08 11:27, Phil Morrell wrote: > > 5. Works that do not meet our free software standards > > > > We acknowledge that our users may require the use of works that do > > not conform to the Debian Free Software Guidelines. Such packages > > are not part of the Debian system, but we provide the enabling > > infrastructure as a convenience to our users. This includes the bug > > tracking system, installation media, mailing lists and separate > > archive areas. > > bug fixes and security updates depend entirely on their upstream developers This is definitely not *universally true*, think of e.g. GFDL invariants or packages that are "merely" non-commercial. Debian package maintainers can make absolutely any technical improvements they wish to these packages, the only thing they can't do is change the license to be DFSG-free. There's probably less motivation to work on non-free software, and there may not even be any remaining upstream, but I assume you were primarily thinking of non-free-firmware when drafting this phrase. > We > encourage software vendors who make use of non-free packages to carefully > read the licenses of these packages to determine whether they can distribute > it on their media or products. I deliberately removed mention of software vendors and their media as our Social Contract wouldn't bind them anyway. #5 should be relevant for all our users, third party redistributors are just a subset. > An added goal I'm trying to achieve with this change is to explain some > practical consequences of redistributing non-free software. It's not like we > provide the non-free archives and it's *wink* *wink* kind of official > because Debian people provide it but it's not, instead it's the case that > everything that makes Debian great really doesn't apply to these packages. It'd be nice having a fourth sentence that is a bit more negatively worded to put people off non-free where feasible. How about: We encourage careful review of the licensing for your use-case and how they put limits on our packaging efforts. Disclaimer: I'm not a DD (yet) so cannot formally propose any of this and please take with a lump of salt. signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Fri, Sep 09, 2022 at 09:04:37AM -0700, Russ Allbery wrote: > We probably do need to say something about how you need to review the > licenses for non-free software before using or distributing it. This is > true for users as well. > > How about: > > We encourage careful review of the licensing of these packages before > use or redistribution, since the guarantees of the Debian Free > Software Guidelines do not apply to them. You've gone back to specifics again with "use or redistribution" and I really don't think a third mention of our standards/DFSG in the same paragraph/heading will make any difference. I now think that any further wording should make some novel, specific, important point about the relationship between Debian and its users: On 2022/09/09 18:37, Bdale Garbee wrote: > We should work REALLY hard to have the SC capture the commitments we're > making to our users, and then stop. signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Fri, Sep 09, 2022 at 08:13:23PM +0200, Jonathan Carter (highvoltage) wrote: > > If we were to include any non-free software/firmware on something that's > called official Debian installer media that is said to conform to our > standards That's exactly the point of changing the wording - by including the two words "installation media" as examples of infrastructure in #5 they are permitted to *not* meet our free software standards. The Images team is then trusted to determine how to achieve "a convenience to our users", thus supporting the original GR intent and making those images official (by the definition of the Images team). signature.asc Description: PGP signature
Re: How is the original tarball obtained in tag2upload
On Fri, Jun 14, 2024 at 12:26:50PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("How is the original tarball obtained in tag2upload"):
> > In many teams we keep the metadata about the
> > orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases
> > this works flawlessly but I've observed some exceptions and read about
> > potential problems with pristine-tar.
>
> Firstly, if there is an orig in the archive, the t2u robot will use
> that. Failing that, it will use "git-deborig" which will call
> "git-archive". Currently there isn't any support for pristine-tar;
> that would be possible in principle.
(risking doing design on debian-vote, but it's a bit late for that)
It's been my impression [citation needed] that pristine-tar/lfs still
exists mainly out of inertia and simple tooling around it that makes it
more of a why not. If we're gaining a mostly git-native upload workflow
out of this, I think it would be wise to second-guess if this support is
even needed in tag2upload.
You're already using the archive to obtain the orig.tar where available,
which neuters one of pristine-tar's purposes: to get everything needed
to build past releases from just a git clone [1]. New upstream versions
*for likely users of tag2upload*, I believe the git-archive generated
tarball would be a sufficient incidental artifact to be uploaded -
making tag2upload the authoritative one-off source instead of
(presumably) upstream's forge generator.
--
emorrp1
[1]: speaking of which, and the answer might be "just learn to use dgit",
but it'd nice to have whatever mechanism is doing this built into e.g.
`gbp buildpackage` in the same way pristine-tar currently is.
signature.asc
Description: PGP signature
