Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Quoting Gard Spreemann (2022-08-26 08:49:21) > On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" > wrote: > >PS: To preempt any questions as for why, the background for my decision > >to stop maintaining any packages is this thread, but it's really just > >the straw that broke the camel's back > > > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > > > > A bit off-topic, but I think we really ought to discuss (address?) this > elephant in the room once more. I don't have the answers, but Sebastian's > email yet again clearly illustrates how the status quo is hurting the > project. This clear example comes in addition to worries raised before about > what the status quo does to recruitment of new developers. > > PS: I do not imply that the elephant in the room is the ftpmasters. I'm > thinking of the *process*. The people involved put in admirable work in > carrying out said process. The way I see it, the process is clear: provide *source* to build from. If there is "source" built from another source, then that other source is the true source. If ftpmasters sometimes approve intermediary works as source, then that is not a reason to complain that they are inconsistent - it is a reason to acknowledge that ftpmasters try their best just as the rest of us, and that the true source is the true source regardless of misssing it sometimes. Yes, this is painful. Yes, upstreams sometimes consider us stupid to care about this. Nothing new there, and not a reason to stop do it. If you disagree, then please *elaborate* on what you find sensible - don't assume we all agree and you can only state that the process is an elephant. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) >> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" >> wrote: >> >PS: To preempt any questions as for why, the background for my decision >> >to stop maintaining any packages is this thread, but it's really just >> >the straw that broke the camel's back >> > >> > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html >> > >> >> A bit off-topic, but I think we really ought to discuss (address?) >> this elephant in the room once more. I don't have the answers, but >> Sebastian's email yet again clearly illustrates how the status quo >> is hurting the project. This clear example comes in addition to >> worries raised before about what the status quo does to recruitment >> of new developers. >> >> PS: I do not imply that the elephant in the room is the >> ftpmasters. I'm thinking of the *process*. The people involved put >> in admirable work in carrying out said process. > > The way I see it, the process is clear: provide *source* to build from. > > If there is "source" built from another source, then that other source > is the true source. > > If ftpmasters sometimes approve intermediary works as source, then that > is not a reason to complain that they are inconsistent - it is a reason > to acknowledge that ftpmasters try their best just as the rest of us, > and that the true source is the true source regardless of misssing it > sometimes. > > Yes, this is painful. Yes, upstreams sometimes consider us stupid to > care about this. Nothing new there, and not a reason to stop do it. > > If you disagree, then please *elaborate* on what you find sensible - > don't assume we all agree and you can only state that the process is an > elephant. Apologies, I should have been a lot clearer. I did not mean the exact issue of what is the "true source" of something in a package. Rather, I was referring to the process itself (looking in particular to the last three paragraphs and the PS in Sebastian's linked email [1]). Whatever the correct answer to what a "true source" is, in the current process, a developer has to make an attempt at doing the right thing, and then wait *weeks or possibly months* to know for sure whether it was OK. And if it's deemed not OK, the reasoning may be entirely specific to the exact package and situation at hand, and therefore extremely hard to generalize and to learn from. (Do not construe the above as "ftpmasters should work faster and give more lengthy reasoning!" – adding *more* work to the process would make things even worse in my opinion.) Although I maintain a very small number of packages, and ones that also very rarely have to re-clear NEW, even I feel sapped of motivation from the process. And I read Sebastian's email partly as an expression of the same thing (apologies if I misconstrue your views, Sebastian). I do believe similar points of view have been aired on the list before by others too. As to your last point, elaborating on what I find sensible: I sadly don't have a good suggestion. I do believe it is possible to point out that the status quo is harmful without knowing how to sensibly fix it, though. That's what discussions are for :-) I am presently unable to find the message I'm thinking of, but I seem to recall one proposal being raised in the past: trust that a developer has done everything right, and introduce a class of bugs that can cause complete removal from the archive instead. Afterall, we do assume that the developer does the technical things correctly, until such a time as a bug is filed. Could we not also make the same assumptions for Policy and Social Contract things? [1] https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html Best, Gard signature.asc Description: PGP signature
Converting Debian OpenStack images to btrfs
(I'm not subscribed to the list, please CC me. Thanks!) Hello! I'm using Debian's OpenStack images to deploy buildd hosts for Debian Ports. [1] To workaround a longstanding qemu/glibc compatibility issue [2], I need the images to use btrfs instead of ext4 and I was wondering whether anyone can give me some hints on how to convert the images provided at [1] from ext4 to btrfs. Thanks, Adriam [1] https://cloud.debian.org/cdimage/cloud/OpenStack/ [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Saturation of the FTP Team's available bandwidth processing NEW
On Wed Aug 24 23:20:30 BST 2022, Sean Whitton wrote: > I'm afraid I cannot respond to a message of this length. As I > mentioned previously, all the ftpteam really have the bandwidth to do > is process what's in NEW. * This is more concerning than its indirect effect on uploader motivation * Many thanks for what they do, and a successful decade of recruitment https://web.archive.org/web/201208/https://ftp-master.debian.org/ * That it's still a problem now means the only option left is to do less * Most copyright issues are merely RC bugs, not rejections or need RM * New uploads of existing sources should only have automated checks * Examples: binary splits/hijacks/soname, source clones/renames (other?) * Or this subset of NEW could be exposed as apt repo for manual checks * Somehow implement this without pestering the FTP Team for feedback https://salsa.debian.org/ftp-team/dak/-/merge_requests --- p.s. Sorry Gard for trimming your entire explanation, in the end I wanted to focus on message length rather than linking each point as a paragraph reply. I hope this encourages others to focus on how many times their email will be read. I'm also implicitly referencing all the existing discussions on this topic that end up in *long* threads e.g. https://lists.debian.org/debian-devel/2022/01/msg00360.html signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote: > The way I see it, the process is clear: provide *source* to build from. > > If there is "source" built from another source, then that other source > is the true source. I hope you agree that we are doing this in order to get some desirable properties of building from source, rather than because the rules are the rules and we follow them without any critical thinking? I feel strongly that if our policies are not meeting their goals of advancing Free Software and providing benefit to our users, then we should reconsider whether they are the right policies. I don't think building from the least-derived form is always the right thing to do. For instance, take rust-glib-sys, a package of Rust bindings for the GLib library, which is one of the libraries whose handling prompted this thread. It contains a description of the GLib library's API/ABI, basically the Rust equivalent of a C header file. It could have been written by hand, but that would be tedious and error-prone, so instead its upstream maintainers chose to machine-generate the API/ABI description from GLib. The thing that would be closest to "true source" would presumably be to redo that machine-generation process, from first principles, at build-time. However, if we did that by using the version of GLib in the archive, then the API of the Rust bindings would not be entirely determined by the content of the rust-glib-sys package as tracked by its version number, which seems really bad for library stability: you could take the same version number, build it twice in different environments, and get two different APIs! rust-glib-sys could have a minimum supported GLib version, but then would unpredictably have or not have additional APIs beyond the ones present in that version, depending on the version of GLib that happened to be installed at build-time. If the generation process is not always 100% backwards-compatible, which I suspect it is not, then that just makes it worse: now you can't even rely on a rebuilt version of rust-glib-sys being compatible with the version from before it was rebuilt! If the API description is curated by the upstream maintainers, then they have an opportunity to detect incompatible changes and release them with a suitably changed version number, or even as a separate parallel-installable version, so that dependent projects can migrate at their own pace; but that can't happen if the API description is generated at build time. Or, the other way to generate rust-glib-sys from "true source" would be to bundle a complete copy of GLib source code in it, and generate the API description from that (which, as an implementation detail of the way it was done, requires compiling GLib and then introspecting the binary, and cannot be done while cross-compiling). This is not great from either a technical or social point of view. From a technical point of view, rust-glib-sys' build system would have to be taught to compile GLib, which uses a totally different build system (Meson rather then Cargo) and is quite a large library, resulting in a much slower and less reliable build. From a social point of view, again, GLib is not small, and I don't think either the rust-glib-sys maintainer or the ftp team would welcome the requirement to review another complete copy of GLib, transcribe all its potential copyright holders into debian/copyright and check that it has been done, and so on. Generating the API description in a way that does not arbitrarily vary based on installed software might also require bundling and building a complete copy of GObject-Introspection, which, again, is not small. All of this is for a functional interface description, analogous to a C header file without comments. In other contexts elsewhere in the project, we rely on the functional parts of an interface description as not being strongly protected by copyright (after all, the whole GNU system started as a compatible implementation of the interfaces provided by 1980s Unix, and we have code in Debian that is a compatible reimplementation of Windows interfaces), and we strongly limit the modifications that we are prepared to make to interface descriptions (because Free Software is important to us, we require the technical and legal ability to make modifications, but because API/ABI compatibility is also important to us, we treat many of those modifications as something that we will refuse to do unless there is a really compelling reason). More generally, I don't think it's always useful to talk about "the" source or "the" preferred form for modification, as though there is only one. I think it would be more appropriate to consider whether the form in which some software is provided is suitable for exercising your Free Software rights (as described in the FSF's "four essential freedoms", for example) within the scope of whatever package we're talking about at the time, or whether it's unsuitable for
Re: Current NEW review process saps developer motivation
Le vendredi 26 août 2022, 10:58:28 UTC Simon McVittie a écrit : > On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote: > > The way I see it, the process is clear: provide *source* to build from. > > > > If there is "source" built from another source, then that other source > > is the true source. > > I hope you agree that we are doing this in order to get some desirable > properties of building from source, rather than because the rules are > the rules and we follow them without any critical thinking? > I feel strongly that if our policies are not meeting their goals of > advancing Free Software and providing benefit to our users, then we > should reconsider whether they are the right policies. > > I don't think building from the least-derived form is always the right > thing to do. For instance, take rust-glib-sys, a package of Rust bindings > for the GLib library, which is one of the libraries whose handling > prompted this thread. It contains a description of the GLib library's > API/ABI, basically the Rust equivalent of a C header file. It could > have been written by hand, but that would be tedious and error-prone, > so instead its upstream maintainers chose to machine-generate the API/ABI > description from GLib. The thing that would be closest to "true source" > would presumably be to redo that machine-generation process, from first > principles, at build-time In this case the js team has solved the problem. We use grouped source package, we have the same problem between javascript package and typescript. Javascript is the main source and typescript is often generated. See here https://wiki.debian.org/Javascript/GroupSourcesTutorial In your case, you should group your rust source with the glib source and so no bundle anymore. You need only a little bit coordination with the glib maintenair and accept funny version for glib like 1.0+~1.2 Bastien > > However, if we did that by using the version of GLib in the archive, > then the API of the Rust bindings would not be entirely determined > by the content of the rust-glib-sys package as tracked by its version > number, which seems really bad for library stability: you could take > the same version number, build it twice in different environments, and > get two different APIs! rust-glib-sys could have a minimum supported > GLib version, but then would unpredictably have or not have additional > APIs beyond the ones present in that version, depending on the version > of GLib that happened to be installed at build-time. > > If the generation process is not always 100% backwards-compatible, which > I suspect it is not, then that just makes it worse: now you can't even > rely on a rebuilt version of rust-glib-sys being compatible with the > version from before it was rebuilt! If the API description is curated by > the upstream maintainers, then they have an opportunity to detect > incompatible changes and release them with a suitably changed version > number, or even as a separate parallel-installable version, so that > dependent projects can migrate at their own pace; but that can't happen > if the API description is generated at build time. > > Or, the other way to generate rust-glib-sys from "true source" would be > to bundle a complete copy of GLib source code in it, and generate the > API description from that (which, as an implementation detail of the way > it was done, requires compiling GLib and then introspecting the binary, > and cannot be done while cross-compiling). This is not great from either > a technical or social point of view. From a technical point of view, > rust-glib-sys' build system would have to be taught to compile GLib, > which uses a totally different build system (Meson rather then Cargo) > and is quite a large library, resulting in a much slower and less > reliable build. From a social point of view, again, GLib is not small, > and I don't think either the rust-glib-sys maintainer or the ftp team > would welcome the requirement to review another complete copy of GLib, > transcribe all its potential copyright holders into debian/copyright > and check that it has been done, and so on. > > Generating the API description in a way that does not arbitrarily vary > based on installed software might also require bundling and building a > complete copy of GObject-Introspection, which, again, is not small. > > All of this is for a functional interface description, analogous to a C > header file without comments. In other contexts elsewhere in the project, > we rely on the functional parts of an interface description as not being > strongly protected by copyright (after all, the whole GNU system started > as a compatible implementation of the interfaces provided by 1980s Unix, > and we have code in Debian that is a compatible reimplementation of > Windows interfaces), and we strongly limit the modifications that we > are prepared to make to interface descriptions (because Free Software > is important to us, we
Bug#1018175: ITP: funing -- a simple face recognition GUI
Package: wnpp Severity: wishlist Owner: Bo YU X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: funing Version : 0.2.54 Upstream Author : larryw3i * URL : https://pypi.org/project/funing/ * License : MIT Programming Lang: Python Description : a simple face recognition GUI a simple face recognition GUI. I will maintain it under Python team. -- Regards, -- Bo YU signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
> "Simon" == Simon McVittie writes: Simon> I don't think building from the least-derived form is always Simon> the right thing to do. For instance, take rust-glib-sys, a Simon> package of Rust bindings for the GLib library, which is one Simon> of the libraries whose handling prompted this thread. It Simon> contains a description of the GLib library's API/ABI, Simon> basically the Rust equivalent of a C header file. It could Simon> have been written by hand, but that would be tedious and Simon> error-prone, so instead its upstream maintainers chose to Simon> machine-generate the API/ABI description from GLib. The thing Simon> that would be closest to "true source" would presumably be to Simon> redo that machine-generation process, from first principles, Simon> at build-time. As a general rule, I think that we should require that Debian contain the software necessary to build from the least derived form, even if for good reasons that you outline, we do not always do that. It's possible that there are cases where this rule should be violated. But in most of the cases I've thought about (including this one), user freedom is likely to be impacted if Debian does not contain the necessary software to rebuild the generated components. In this case, it would be reasonable for a user to want to extend glib and to rebuild the rust bindings with those extensions. Such a rebuild would introduce incompatibility, but that's okay in a local context if someone wants to do that. Actually, it's more than okay; it's an important freedom. --Sam
Bug#1018181: ITP: just - Save and run project-specific commands
Package: wnpp Severity: wishlist Owner: Blair Noctis X-Debbugs-Cc: debian-devel@lists.debian.org, n...@sail.ng * Package name: just Version : 1.4.0 Upstream Author : Casey Rodarmor * URL : https://github.com/casey/just * License : CC0-1.0 Programming Lang: Rust Description : Save and run project-specific commands just is a command runner with a configuration file similar to Makefile but can be written in arbitrary languages. It has improvements over make e.g. no .PHONY, is cross-platform, has detailed error output, and comes with command line completions for popular shells. This package provides an alternative to make in daily development, with modern and friendly experience. Also, its author RFP'd it, #971726. The package is a Rust crate, thus fits in the Rust team packaging process. -- Regards, Blair Noctis OpenPGP_0xC21D9AD423A39727.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1018193: ITP: the-foundation -- Opinionated C11 library for low-level functionality
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: the-foundation Version : 1.4.0 Upstream Author : Jaakko Keränen * URL : https://codeberg.org/skyjake/the_Foundation * License : BSD Programming Lang: C Description : Opinionated C11 library for low-level functionality An object-oriented C library whose API is designed for a particular coding style, taking cues from C++ STL and Qt. This is a dependency for Lagrange, a desktop Gemini client: https://codeberg.org/skyjake/lagrange I already maintain both in Fedora, and would be nice to be able to use them as native packages when on Debian.
Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
To be honest, in terms of volunteered reviewing work, waiting for several months is not something new. In academia, it may take several months to years to get a journal paper response. I've ever tried to think of possible ways to improve the process, but several observations eventually changed my mind, and I'm willing to accept the status quo. * there is a trade-off between rigorousness and efficiency. Any change in the process may induce disadvantages, where the most difficult thing is to reach an agreement. * we will add more work for ftp team if we get them involved in the discussion of possible (but unsure) ways to improve NEW. My ultimate opinion on NEW processing is neutral, and my only hope for ftp team is to increase the pace of hiring new members. To be concrete, it is much harder to write a concrete proposal to debian-vote@l.d.o than discussing possibilities. I understand we may have the enthusiasm to sprint on something. However, in terms of the long-term endeavor on Debian development, the negligible popcon number won't be less disappointing than a long-term wait to clear the NEW queue. If one's enthusiasm on working on some package is eventually worn out after a break, then try to think of the following question: Is it really necessary to introduce XXX to Debian? Must I do this to have fun? Strong motivations such as "I use this package, seriously" are not likely to wear out very easily through time. Packages maintained with a strong motivation are better cared among all packages in our archive. Why not calm down, and try to do something else as interesting as Debian development when waiting for the NEW queue? Or simply think of NEW queue as a Debian holiday application. I just realized these over the years, and these are only my personal opinion. On Fri, 2022-08-26 at 09:18 +0200, Gard Spreemann wrote: Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) > > On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" > > wrote: > > > PS: To preempt any questions as for why, the background for my > > > decision > > > to stop maintaining any packages is this thread, but it's really > > > just > > > the straw that broke the camel's back > > > > > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > > > > > > > A bit off-topic, but I think we really ought to discuss (address?) > > this elephant in the room once more. I don't have the answers, but > > Sebastian's email yet again clearly illustrates how the status quo > > is hurting the project. This clear example comes in addition to > > worries raised before about what the status quo does to recruitment > > of new developers. > > > > PS: I do not imply that the elephant in the room is the > > ftpmasters. I'm thinking of the *process*. The people involved put > > in admirable work in carrying out said process. > > The way I see it, the process is clear: provide *source* to build > from. > > If there is "source" built from another source, then that other > source > is the true source. > > If ftpmasters sometimes approve intermediary works as source, then > that > is not a reason to complain that they are inconsistent - it is a > reason > to acknowledge that ftpmasters try their best just as the rest of us, > and that the true source is the true source regardless of misssing it > sometimes. > > Yes, this is painful. Yes, upstreams sometimes consider us stupid to > care about this. Nothing new there, and not a reason to stop do it. > > If you disagree, then please *elaborate* on what you find sensible - > don't assume we all agree and you can only state that the process is > an > elephant. Apologies, I should have been a lot clearer. I did not mean the exact issue of what is the "true source" of something in a package. Rather, I was referring to the process itself (looking in particular to the last three paragraphs and the PS in Sebastian's linked email [1]). Whatever the correct answer to what a "true source" is, in the current process, a developer has to make an attempt at doing the right thing, and then wait *weeks or possibly months* to know for sure whether it was OK. And if it's deemed not OK, the reasoning may be entirely specific to the exact package and situation at hand, and therefore extremely hard to generalize and to learn from. (Do not construe the above as "ftpmasters should work faster and give more lengthy reasoning!" – adding *more* work to the process would make things even worse in my opinion.) Although I maintain a very small number of packages, and ones that also very rarely have to re-clear NEW, even I feel sapped of motivation from the process. And I read Sebastian's email partly as an expression of the same thing (apologies if I misconstrue your views, Sebastian). I do believe similar points of view have been aired on the list before by others too. As to your last point, elaborating on what I find sensible: I sadly don't have a go
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Fri, Aug 26, 2022 at 04:13:43PM -0400, M. Zhou wrote: > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? > Must I do this to have fun? > > Strong motivations such as "I use this package, seriously" are not > likely to wear out very easily through time. Packages maintained > with a strong motivation are better cared among all packages in our > archive. (note that using a package doesn't require uploading it and, indeed, sometimes packaging things for local use is much, much easier than packaging them for the archive) -- WBR, wRAR signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote: > I don't think building from the least-derived form is always the > right thing to do. Personally, I believe that instances of that represent bugs in how the upstream source trees and build processes are organised. > For instance, take rust-glib-sys, a package of Rust bindings > for the GLib library, which is one of the libraries whose handling > prompted this thread. I feel like the right way to organise this upstream is for GLib itself to be building the bindings for itself (as Bastian Roucariès suggests). Alternatively, if the GLib bindings really need to be separate, then GLib could build the XML description of its APIs, include that in a package, then rust-glib-sys build-dep on that, include a Built-Using header and get binNMUed after every GLib update. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Current NEW review process saps developer motivation
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote: > I don't think it's always useful to talk about "the" source or "the" > preferred form for modification, as though there is only one. I see both the licensing and source aspects of the Free Software movement as aspiring to providing a high level of equality of access to a work between both the original author and far downstream recipients. Obviously full and universal equality is impossible because part of the work is only in the author's mind and not everyone can obtain, use and program computers, but approaching that as closely as possible is important and it is important to think about how to achieve a high level of equality for each work in each context. What is the "source" in any given context is a *choice* the author makes about what level of access to a work that they want allow for themselves and others in the future. > I think it would be more appropriate to consider whether the form > in which some software is provided is suitable for exercising your Free > Software rights (as described in the FSF's "four essential freedoms", > for example) within the scope of whatever package we're talking about at > the time, or whether it's unsuitable for that use. If it's suitable, then > it's source, or close enough; if it's unsuitable, then that needs fixing. I have to strongly disagree with this, because of the equality of access issue that that I mentioned above. For example: I use autotools to create a ./configure shell script but ship only the shell script itself. You can run/read/modify that script just fine, but it is incredibly verbose and there is a lot of repetition due to how these scripts are generated. Clearly I have better access than you. I use mrustc to generate a C version of some Rust code, ship the C code to you as source. You can do everything you want with the C code, but you cannot build the Rust code with rustc and get a safer binary nor fix bugs in the code generation etc. I still can do those and more, as well as all the things that you can do with the C code. I write some JavaScript with extensive comments and formatting, then I run a minifier and ship that as the source. You can still run, read, modify the code just fine, but Debian so far doesn't consider it as source. If instead of minifying, I just strip all the comments then the code will be more accessible to you and Debian probably wouldn't be able to tell I stripped it, but I will be able to understand the code much easier than you since I have comments. I create a model in Blender, keep that model private, render it to a PNG file and ship that as source. You have all the essential freedoms for the PNG form of the scene, but you can't easily modify the texture or shape of the model and rerender, but I can still do all of those things. Later I lose the Blender model and now we are equal, both unable to do useful things. At some point an app store flags the game the image is in as inappropriate in some culture and to fix that I need to recreate the model from scratch. This time I learn my lesson and check the Blender model into the git repo. > If we insist on a particularly puritanical view of what is source and > what is the preferred form for modification, then I think there is a > significant risk of producing a distribution which is unquestionably Free > Software, but either is missing useful Free software because it would be > too hard to get that software into a form that meets our self-imposed > policies, or can only contain that software as a result of individual > developers putting a heroic amount of effort into meeting those policies - > particularly if we always go back to the "true source" and generate from > there every time We have the contrib/non-free areas of the archive for situations where we aren't yet meeting our requirements, including around source and build dependencies. I see no reason why we should not use it more often for things that are licensed as Free Software but hard to package according to our principles. > (which I will note that the ftp team specifically do not insist on > unless there is a technical reason to do so, they merely require > source to be *available*). This is slightly incomplete, as I understand it the source has to be available in Debian main *and* the build process must be *possible* using only components from Debian main, but it isn't mandatory to run the build process. Of course the best way to prove those requirements are met is to actually run the build process. Personally, I think our current policies on building from source are not adequate to ensure that Debian and our users can practically exercise our Free Software rights for all source files in future. At minimum, I would like to see a requirement to build-depend on the appropriate build tools, even if those tools aren't yet run during the build process because the build is impractical etc. > If we require contributors to do a considerab
Re: Converting Debian OpenStack images to btrfs
On Fri, 2022-08-26 at 11:05 +0200, John Paul Adrian Glaubitz wrote: > To workaround a longstanding qemu/glibc compatibility issue [2], I need > the images to use btrfs instead of ext4 and I was wondering whether anyone > can give me some hints on how to convert the images provided at [1] from > ext4 to btrfs. The btrfs-convert command from btrfs-progs might be able to help, or you modify the tools used by the Debian cloud team to build the images and rebuild them from scratch, contact their list for help. https://wiki.debian.org/Teams/Cloud -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
