Re: Making Debian available
Steve McIntyre writes: > Marc Haber wrote: >> >>I was not aware of that feature. It is good to have that, but I would >>be embarrassed to seriously suggest this way because we can't manage >>to get WLAN working in the installer for political reasons. > > Are we seriously just going to describe our Free Software goals as > "political reasons"? Should we just abandon them? FWIW, I did not read Marc that way. Somehow, the Free Software goals have been interpreted to mean that there is a difference in "free" between firmware on device internal flash and firmware on host ssd. This makes no sense from a technical point of view. Which makes the interpretation political if we assume that the decision is made by otherwise sane people ignoring technical arguments. No one has described the Free Software goals as "political reasons". Perosnally, I believe the current Debian handling of firmware works against the Free Software goals. That should worry those who care more about those goals than the political reasons for disliking some types of hardware. Bjørn
Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote: > On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote: > > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the > > algorithm for use is similar: if it is in the environment then use it, if > > not, > > fall back to the previous behaviour. > > Yes! And as this was triggered by reproducible builds, and as you > mention due to the similarities, it would nice to publish a “spec” > once we reach some agreement, given that would end up being part of > a neutral project, with more chances for upstream adoption. One problem that I can see with SOURCE_BASE_DIR (compared with, for example, what GLib does) is: what is "the package"? Many codebases get used both as an independent package in their own right, and as a bundled/vendored subproject in larger projects. Even if *in Debian* we don't like vendoring projects that have their own independent releases, *outside Debian* people do this all the time. There is explicit support for this in at least Autotools and Meson, and it's used both for vendoring subprojects that are released independently and for dealing with subprojects that are logically separate but never actually released separately. For instance, in Debian we think of gcc-10 as a single, monolithic source package, but it's really made up of three upstream tarballs (gcc, gm2 and newlib) containing 35 Autotools build systems (estimated by counting files named configure.ac). Obviously it isn't reasonable to expect dpkg or debhelper to know that they should somehow set a different SOURCE_BASE_DIR when recursing into the content of each upstream tarball, or when recursing into each of those 35 Autotools build systems. Similarly, we think of gnome-shell as a single monolithic package, but as of 3.38.3 it consists of a top-level Meson project with 4 subprojects (that do not have any independent existence as source releases, although I think at least one of them is a non-API-stable "copylib" that exists in more than one GNOME package). We also think of GTK as a single package, but when built in non-Debian contexts, it supports building external dependencies like GLib and Cairo as subprojects instead of using a system copy. In Debian, by policy we don't do this, but people who are building GTK apps for Windows absolutely do want to take this approach, and GTK upstream needs to support both. In the case of a vendorable dependency like GLib, this means that when you're building GLib, SOURCE_BASE_DIR might be set to the top of GLib (when building it as a package in its own right), or it might be set to the top of GTK (in which GLib is a subprojects/glib subdirectory). The thing I would always want to know, as a GLib developer who wants to load a resource into my unit test, is the top of GLib. GLib's G_TEST_SRCDIR/G_TEST_BUILDDIR sidestep this by being defined in terms of the current directory, rather than some top-level package. This means it isn't really feasible for dpkg to implement them - they have to be something that the upstream build system provides, because it's the upstream build system that does the recursion. Constructs like Autotools' $(top_srcdir), $(abs_builddir), etc. and Meson's meson.project_source_root(), meson.current_build_dir() etc. are very suitable for implementing things like G_TEST_SRCDIR/G_TEST_BUILDDIR, and they are defined in ways that make sense for that upstream build system, taking into account how it deals with subprojects. smcv
Bug#980452: ITP: aiohttp-retry -- Simple aiohttp retry client
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: aiohttp-retry Version : 2.3 Upstream Author : Dmitry Inyutin * URL : https://github.com/inyutin/aiohttp_retry * License : Expat Programming Lang: Python Description : Simple aiohttp retry client This library add retrying feature to aiohttp HTTP client and provides an API being exactly the same as original ClientSession object. . You can define your own timeouts logic or use: - ExponentialRetry with exponential backoff - RandomRetry for random backoff - ListRetry with backoff you predefine by list I intend to maintain this package within the Debian Python Modules Team.
Bug#980454: ITP: golang-github-prometheus-exporter-toolkit-dev -- Go library for Prometheus exporters
Package: wnpp Severity: wishlist Owner: Daniel Swarbrick * Package name: golang-github-prometheus-exporter-toolkit-dev Version : 0.5.1 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/exporter-toolkit * License : Apache-2.0 Programming Lang: Go Description : Go library for Prometheus exporters Go library for implementing features commonly required in Prometheus exporters, such as command line flag parsing, HTTP TLS options and authentication. This package is a new build-dep in Prometheus 2.24.0, and will be required in upcoming versions of Prometheus pushgateway and node_exporter. I will maintain this package with the assistance of the Debian Go packaging team, particularly those involved with other Prometheus packages. Benjamin Drung (bdrung) has kindly offered to sponsor me.
Bug#980462: ITP: oidc-agent -- Commandline tool for obtaining OpenID Connect Access tokens on the commandline
Package: wnpp Severity: wishlist Owner: Marcus Hardt X-Debbugs-Cc: debian-devel@lists.debian.org, mar...@hardt-it.de * Package name: oidc-agent Version : 4.0.2 Upstream Author : Gabriel Zachmann * URL : https://github.com/indigo-dc/oidc-agent * License : MIT Programming Lang: C++ Description : Commandline tool for obtaining OpenID Connect Access tokens on the commandline oidc-agent consists of five programs: - oidc-agent that handles communication with the OIDC provider - oidc-gen that generates config files - oidc-add that loads (and unloads) configuration into the agent - oidc-token that can be used to get access token on the command line - oidc-keychain that re-uses oidc-agent across logins The package is useful for using distributed infrastructures that make use of OpenID Connect (such as the European Federated Cloud, the Worldwide LHC Computing Grid). The package depends on a set of other packages: fakeroot, devscripts, libcurl4-openssl-dev (>= 7.35.0), libsodium-dev (>= 1.0.14), help2man (>= 1.46.4), libseccomp-dev (>= 2.1.1), libmicrohttpd-dev (>= 0.9.33), check (>= 0.10.0), pkg-config (>= 0.29), libsecret-1-dev (>= 0.18.4), libcjson-dev (>= 1.7.14), Other packages that depend on oidc-agent are not (yet) shipped via debian. Those include the unicore commandline client, udocker, and the watts client. I am not aware of other packages providing OpenID Connect Access Tokens on the commandline. Maintenance plan is that I can do it during my office hours at work. The same currently holds for the upstream developer. I am not looking for co-maintainers. I have looked for a sponsor, Micha Lenk is helping us a lot.
Re: About lintian
Hi, On Mon, 18 Jan 2021, Antonio Terceiro wrote: > FWIW, The ci.debian.net infrastructure is mostly independent from > autopkgtest, so we could have different types of jobs there. This could > be used for lintian, but also for on-demand rebuilds, and other types of > checks that needs to be done to packages in the archive. the debci > codebase has seen a lot of work to properly handle stuff like this in > the last 6 years, and it would be a win if we can reuse that for other > use cases, instead of someone having to start from scratch having to > learn again everything that I did in the last 6 years working on ci.d.n. Can you expand on the kind of features that ci.debian.net offers and what kind of mistakes we would likely avoid by reusing it? From my (relatively remote) point of view, ci.debian.net seems really very basic in terms of features related to scheduling of jobs. From my own usage in Kali (autopkgtest.kali.org), I noticed you can't even request to test a specific version of a package... you get whatever version is available in the specific mirror that you are using for your test, even if it's not (yet) in sync with the one used by the code that requested that job. There's also no possibility to have differentiated workers (qemu vs lxc-based) and have the jobs dispatched to appropriate workers. Scheduling features might not be important for lintian processing but I believe it's a must have if we want to consolidate more jobs in a single place. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: About lintian
On Tue, Jan 19, 2021 at 12:27:31PM +0100, Raphael Hertzog wrote: > Hi, > > On Mon, 18 Jan 2021, Antonio Terceiro wrote: > > FWIW, The ci.debian.net infrastructure is mostly independent from > > autopkgtest, so we could have different types of jobs there. This could > > be used for lintian, but also for on-demand rebuilds, and other types of > > checks that needs to be done to packages in the archive. the debci > > codebase has seen a lot of work to properly handle stuff like this in > > the last 6 years, and it would be a win if we can reuse that for other > > use cases, instead of someone having to start from scratch having to > > learn again everything that I did in the last 6 years working on ci.d.n. > > Can you expand on the kind of features that ci.debian.net offers and what > kind of mistakes we would likely avoid by reusing it? To name a few: - distributed processing - data retention policies - web interface - monitoring > From my (relatively remote) point of view, ci.debian.net seems really > very basic in terms of features related to scheduling of jobs. > > From my own usage in Kali (autopkgtest.kali.org), I noticed you can't > even request to test a specific version of a package... you get whatever > version is available in the specific mirror that you are using for your > test, even if it's not (yet) in sync with the one used by the code that > requested that job. autopkgtest does not support that, so debci doesn't offer it as well. > There's also no possibility to have differentiated workers (qemu vs > lxc-based) and have the jobs dispatched to appropriate workers. > > Scheduling features might not be important for lintian processing but I > believe it's a must have if we want to consolidate more jobs in a single > place. I didn't say it was ready for it now, but that it could be done. My hope is that this, and other use cases, could be enabled by collaborating on existing infrastructure, instead of creating yet another one. signature.asc Description: PGP signature
Re: About lintian
Hi, On Tue, 19 Jan 2021, Antonio Terceiro wrote: > > Can you expand on the kind of features that ci.debian.net offers and what > > kind of mistakes we would likely avoid by reusing it? > > To name a few: > > - distributed processing > - data retention policies > - web interface Thanks for your answer! > - monitoring What do you monitor? > > From my own usage in Kali (autopkgtest.kali.org), I noticed you can't > > even request to test a specific version of a package... you get whatever > > version is available in the specific mirror that you are using for your > > test, even if it's not (yet) in sync with the one used by the code that > > requested that job. > > autopkgtest does not support that, so debci doesn't offer it as well. I see where you are coming from but I consider autopkgtest as the backend and you feed it the packages and you get the results. You can feed the packages directly or you can tell it to fetch them from a mirror, IMO it's still the responsibility of the caller (debci) to feed the right package to test. > I didn't say it was ready for it now, but that it could be done. Ok. > My hope is that this, and other use cases, could be enabled by > collaborating on existing infrastructure, instead of creating yet > another one. In general I agree with the need to collaborate more and not redo everything but to be honest, at least for me, the fact that it's written in Ruby and not Python makes it unlikely that I will contribute to it. For better or worse, the amount of Debian infrastructure built around Python is growing and I think it would be best if such a core part could be Python-based too. I really believe it's a "core" part because it ought to be able to handle package building too... At while ago, I started to draft a specification in this project: https://salsa.debian.org/hertzog/debusine Unfortunately, it's vaporware as I don't have time to invest into it. Though I'm considering to put money towards its development through https://salsa.debian.org/freexian-team/project-funding Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Making Debian available
Hello, Debian world! [larval contributor delurking] On 18 Jan 2021, at 11:29, Steve McIntyre wrote: > > There's a major difference here - do we want Debian's *official* media > to include non-free stuff? We've had this discussion a few times, > including in person back at DC15 at least. Back then, the overwhelming > response was *no*. We can change that, but it's not something to do > lightly. > I might be reading this in, but I'm hearing this as asking "Debian's [one] official [install] media". That prompts reframing your question as "Does Debian want no Debian official install media to contain non-free stuff". If yes, then no installs happen on hardware requiring a non-free blob, and Debian knowingly loses potential install-base. (I wonder if we've data on how much this actually happens ) If no, then have official "free-only" install-media and official "has non-free" install-media, available side-by-side. Suggest people use the former, and fall back to the latter if their hardware forces that. (I speculate that realizing this might require some sort of proposal and/or policy decision?) [relurking] Thanks for suffering with my lack of clarity! Joseph —— Joseph Beckenbach
Re: Making Debian available
On Mon, 18 Jan 2021 17:51:25 +, Stefano Rivera wrote: > Unable to find an Internet connection. > You may have a network interface that requires non-free firmware to > operate. > If you have a mobile phone connected to WiFi try plugging it in with a > USB cable and enabling "USB tethering" to share its internet > connection. You can use this to get Debian installed and then install > the non-free firmware package your network interface requires. > ... or go to ubuntu.com for a Linux OS that does work out of the box. Which is what the vast majority of users presented with this dialog will do. 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
Bug#980463: ITP: scil -- Scientific Compression Library (SCIL)
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: scil Version : 0.1 Upstream Author : Julian Kunkel * URL : https://github.com/JulianKunkel/scil * License : LGPL-3 Programming Lang: C Description : Scientific Compression Library (SCIL) The Scientific Compression Library (SCIL) is a meta-compressor that allows users to set various quantities that define the acceptable error and the expected performance behavior. The library aims to choose the appropriate chain of algorithms to yield the users requirements (this feature is still under development). This approach is a crucial step towards a scientifically safe use of much-needed lossy data compression, because it disentangles the tasks of determining scientific ground characteristics of tolerable noise, from the task of determining an optimal compression strategy given target noise levels and constraints. Future algorithms are used without change in the application code, once they are integrated into SCIL. SCIL also comes with a pattern library to generate various relevant synthetic test patterns. Further tools are provided to plot, add noise or to compress CSV and NetCDF3 files. Internally, support functions simplify the development of new algorithms and the testing. This is then an optional dependency of ESDM, also being packaged.
Re: Making Debian available
Marc Haber wrote: >On Mon, 18 Jan 2021 16:35:01 +, Steve McIntyre >wrote: >>Marc Haber wrote: >>>I was not aware of that feature. It is good to have that, but I would >>>be embarrassed to seriously suggest this way because we can't manage >>>to get WLAN working in the installer for political reasons. >> >>Are we seriously just going to describe our Free Software goals as >>"political reasons"? Should we just abandon them? > >No, we shouldn't, but we should drop the double standards that we >obviously apply towards docs and firmware. Sorry, I'm not following you on that. Can you expand on that please? How are we treating docs differently? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Making Debian available
Bjørn wrote: >Steve McIntyre writes: > >> Marc Haber wrote: >>> >>>I was not aware of that feature. It is good to have that, but I would >>>be embarrassed to seriously suggest this way because we can't manage >>>to get WLAN working in the installer for political reasons. >> >> Are we seriously just going to describe our Free Software goals as >> "political reasons"? Should we just abandon them? > >FWIW, I did not read Marc that way. Fair enough. >Somehow, the Free Software goals have been interpreted to mean that >there is a difference in "free" between firmware on device internal >flash and firmware on host ssd. This makes no sense from a technical >point of view. Which makes the interpretation political if we assume >that the decision is made by otherwise sane people ignoring technical >arguments. To a simple end user, there might not be a difference. They have firmware for their device. However, in the latter case Debian has shipped non-free stuff. That is a big shift in our position. Don't get me wrong: I'm not saying this is an impossible place for us to go to. But before we do that we should have an open and honest debate about it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Making Debian available
Steve McIntyre writes: > However, in the latter case Debian has shipped non-free stuff. That is > a big shift in our position. Don't get me wrong: I'm not saying this > is an impossible place for us to go to. But before we do that we > should have an open and honest debate about it. I absolutely 100% agree to that! Bjørn
Re: Making Debian available
On Tue, 19 Jan 2021 16:46:30 +, Steve McIntyre wrote: >Marc Haber wrote: >>No, we shouldn't, but we should drop the double standards that we >>obviously apply towards docs and firmware. > >Sorry, I'm not following you on that. Can you expand on that please? >How are we treating docs differently? I apologize. It doesn't help the current debate to open a different battlefield here. 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: Making Debian available - patch for webwml v2
Hi, Thomas Lange wrote: > > On Mon, 18 Jan 2021 12:37:37 +0100, Holger Wansing > > said: > > >> debian-www team: what do you think about adding some more hint/warning > >> banners pointing to firmware-including installation images? > I really like to have a hint, but warning is a too negative word. > Having those non-official images can help our users. > > > First patch attached. > I would use admon-important.png or admon-tip.png, but not admon-warning.png. > > Please let us treat non-free firmware as something positive, that our > users need for certain hardware and not use FUD when talking about > non-free firmware. Sounds good. I would vote for the 'important' class (the exclamation mark attracts more attention IMO). Patch updated. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/english/CD/http-ftp/index.wml b/english/CD/http-ftp/index.wml index d23e1c87bc8..9006f3e8bc6 100644 --- a/english/CD/http-ftp/index.wml +++ b/english/CD/http-ftp/index.wml @@ -28,6 +28,9 @@ download: Official CD/DVD images of the stable release + Unofficial CD/DVD images for stable with + non-free firmware included + https://cdimage.debian.org/cdimage/weekly-builds/";>Official CD/DVD images of the testing distribution (regenerated weekly) @@ -104,6 +107,26 @@ walkthrough of the installation process. Other useful documentation includes: +Unofficial CD/DVD images with non-free firmware included + + + +If any of the hardware in your system requires non-free firmware to be +loaded with the device driver, you can use one of the +https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/buster/current/";>\ +tarballs of common firmware packages or download an unofficial image +including these non-free firmwares. Instructions how to use the tarballs +and general information about loading firmware during an installation can +be found in the Installation Guide. + + +https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/";>unofficial +installation images for stable with firmware included + + + + + Registered mirrors of the debian-cd archive Note that some mirrors are not up to date — diff --git a/english/CD/torrent-cd/index.wml b/english/CD/torrent-cd/index.wml index e3e5e260432..5175bab8734 100644 --- a/english/CD/torrent-cd/index.wml +++ b/english/CD/torrent-cd/index.wml @@ -74,3 +74,19 @@ walkthrough of the installation process. Other useful documentation includes: If you can, please leave your client running after your download is complete, to help others download images faster! + + + +If any of the hardware in your system requires non-free firmware to be +loaded with the device driver, you can use one of the +https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/buster/current/";>\ +tarballs of common firmware packages or download an unofficial image +including these non-free firmwares. Instructions how to use the tarballs +and general information about loading firmware during an installation can +be found in the Installation Guide. + + +https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/";>unofficial +installation images for stable with firmware included + + diff --git a/english/devel/debian-installer/index.wml b/english/devel/debian-installer/index.wml index ef00806e51c..d531f47b4fa 100644 --- a/english/devel/debian-installer/index.wml +++ b/english/devel/debian-installer/index.wml @@ -172,14 +172,28 @@ available version of installer components. + -If any of the hardware in your system requires firmware to be +If any of the hardware in your system requires non-free firmware to be loaded with the device driver, you can use one of the https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/";>\ -tarballs of common firmware packages. Instructions how to use the tarballs +tarballs of common firmware packages or download an unofficial image +including these non-free firmwares. Instructions how to use the tarballs and general information about loading firmware during an installation can -be found in the Installation Guide (see Documentation below). +be found in the https://d-i.debian.org/manual/";>Installation Guide. + +https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/";>unofficial +images with firmware included - daily builds + + +https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/";>unofficial +images with firmware included - weekly builds + + + + + Notes diff --git a/english/distrib/index.wml b/english/distrib/index.wml index 527725adb23..317409e845d 100644 --- a/english/distrib/index.wml +++ b/english/distrib/index.wml @@ -109,3 +109,19 @@ And, the release notes can be found he + + + +If any of the hardware in your system requires non-free firmware to be +loaded with the device driver, you can use one
Re: Making Debian available
Incidently now that this is under discussion - whomever is supplying the non-free live images should know that the torrents of the stable version aren't seeded. I was attempting to download them all to help with seeding, and there isn't one seeder. Could somebody pass the word along? Thanks!
