Bug#980440: ITP: dde-control-center -- The control panel of Deepin Desktop Environment
Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dde-control-center Version : 5.3.0.82 Upstream Author : linuxdeepin * URL : https://github.com/linuxdeepin/dde-control-center License : GPL-3+ Programming Lang: C++ Description : The control panel of Deepin Desktop Environment. DDE Control Center is the control panel of Deepin Desktop Environment.
Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
Hi!
On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> Sune Stolborg Vuorela wrote:
> > Can you provide some kind of hook in the environment so we at least can work
> > around it in the users, so that the internal functions (where the output of
> > __FILE__ is forwarded to) can glue e.g. the content of an environment
> > variable in front of the usage of the __FILE__ content to try to
> > reconstruct it at runtime, so that all packages doesn't need to do export
> > SOURCE_BASE_DIR=`pwd`; make test, but it will just work if we patch Qt and
> > similar libraries ?
Sure, that sounds doable, but as always given that we have not yet
decided to obsolete supporting debian/rules as a build entry point,
any such support would either need to be conditional from the upstream
or packaging side, or something like debhelper would also need to
guarantee it is set up. :/
> 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.
> At its crudest level, a package's debian/rules could include SOURCE_BASE_DIR=
> $(shell pwd); however, putting this into the build environment saves source
> changes in multiple packages, sets us up for future use across the entire
> ecosystem, signals to upstreams that this is a broad standard and not a mere
> hack in d/rules, and also saves maintainers from thinking about nasty corner
> cases to do with current directories with makefile invocation.
>
> Looking to the future, tests using SOURCE_BASE_DIR to locate test data would
> allow build-time tests to be repurposed as autopkgtest tests too, as the
> autopkgtest could tell the tests where the test input data is to be found.
> This would be a substantial improvement on the current situation where the
> tests can only be run at build time and not on ci.debian.net.
>
> By dpkg making SOURCE_BASE_DIR 'real', there is a distinct prospect of Debian
> carrying Qt5 patches to use it (thanks Sune!) and for Qt6 to include them
> upstream.
I agree with all of this, barring my initial comment above. I guess I
need to go back to the thread proposing to obsolete debian/rules as a
supported build entry point. :)
I think Simon's remark might be worth having a thought about too. But
as a starting point I prepared the attached patch, which sets the
variable from dpkg-buildpackage and pkg-info.mk. Once there's
agreement on the variable(s), I'm fine merging this, but whether to
include this for bullseye would need release-team approval at this
point I guess.
Thanks,
Guillem
From 33f7213e34dad402d5159b3a82bf2efc9454222f Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Sat, 16 Jan 2021 14:23:55 +0100
Subject: [PATCH] dpkg-buildpackage: Add SOURCE_BASE_DIR support
This is a generic variable that can be used by upstream projects wanting
to get at the source root directory, independently of out tree builds,
and in a portable way in contrast to making assumptions about for
example the content of the C __FILE__ preprocessor macro.
Proposed-by: Sune Stolborg Vuorela
---
man/dpkg-buildpackage.pod | 5 +
scripts/dpkg-buildpackage.pl | 3 +++
scripts/mk/pkg-info.mk| 4
scripts/t/dpkg_buildpackage.t | 8
t-func/atlocal.in | 3 +++
5 files changed, 23 insertions(+)
diff --git a/man/dpkg-buildpackage.pod b/man/dpkg-buildpackage.pod
index e648a8063..d6bf58749 100644
--- a/man/dpkg-buildpackage.pod
+++ b/man/dpkg-buildpackage.pod
@@ -668,6 +668,11 @@ B.
This variable is set to the Unix timestamp since the epoch of the
latest entry in I, if it is not already defined.
+=item B
+
+This variable is set to the absolute pathname of the unpacked source
+directory, if it is not already defined (since dpkg 1.20.8).
+
=back
=head1 FILES
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index aacb83118..dbff851ce 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -23,6 +23,7 @@
use strict;
use warnings;
+use Cwd;
use File::Temp qw(tempdir);
use File::Basename;
use File::Copy;
@@ -460,6 +461,8 @@ if ($changedby) {
#
Re: Making Debian available
On Mon, Jan 18, 2021 at 6:27 PM Marc Haber wrote: > Imagine the catastrophal message we're sending by "here is our > official image, but that one is unlikely to work on your laptop, > better use this here." As this thread shows the current situation wrt hardware and software freedom is pretty catastrophic, I think we owe it to our users to not keep them in the dark about these issues. Probably a better way to do this is a set of "Debian Installer Launcher" apps in the various app stores that can detect your hardware, check if it needs the non-free ISO, copy any needed non-redistributable non-free drivers[1]/firmware from the original OS, warn about all the non-freeness found and the consequences of that while not offering any solution to that*, but offering to use only free software if the non-free parts are for hardware the user does not plan to use, detect what software you have already installed and the free alternatives in Debian and then download/verify/launch the appropriate Debian installer CD image with the appropriate preseeding, possibly via virtual machine interfaces so that you can do the install whilst continuing to browse the web and research better hardware options and the reasons for preferring free software. * because lets face it, there is no-one attempting to reverse engineer and replace non-free WiFi firmware any more, although there used[2] to be at least Prism54 and OpenFWWF working on that, neither of which are in Debian though and probably they and carl9170fw/ath9k_htc.fw aren't useful to have in Debian either since they are for very old WiFi chips and standards. AFAIK the only firmware reverse engineering going on is nouveau with nvidia GPUs and I believe they are now blocked by nvidia signing their blobs. Even Intel's Open Sound Firmware project doesn't allow software freedom on most devices as OEMs require Intel signatures. 1. ala ndiswrapper 2. https://wiki.debian.org/Firmware/Open -- bye, pabs https://wiki.debian.org/PaulWise
Bug#980433: ITP: buf --
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: buf Version : 0.33.0-1 Upstream Author : Buf Technologies, Inc. * URL : https://github.com/bufbuild/buf * License : Apache-2.0 Programming Lang: Go Description : Better way to work with Protocol Buffers Buf’s long-term goal is to enable schema-driven development: a future where APIs are defined consistently, in a way that service owners and clients can depend on. . Defining APIs using an IDL (Interface Description Language) provides a number of benefits over simply exposing JSON/REST services, and today, Protobuf is the most stable, widely-adopted IDL in the industry. . However, as it stands, using Protobuf is much more difficult than using JSON as your data transfer format. . Enter Buf: We’re building tooling to make Protobuf reliable and easy to use for service owners and clients, while keeping it the obvious choice on the technical merits. This is needed to build latest version of nomad (https://www.nomadproject.io).
Bug#980432: ITP: golang-github-jhump-protoreflect -- Reflection (Rich Descriptors) for Go Protocol Buffers
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-jhump-protoreflect Version : 1.8.1-1 Upstream Author : Joshua Humphries * URL : https://github.com/jhump/protoreflect * License : Apache-2.0 Programming Lang: Go Description : Reflection (Rich Descriptors) for Go Protocol Buffers Reflection APIs for protocol buffers (also known as "protobufs" for short) and gRPC. The core of reflection in protobufs is the descriptor. A descriptor is itself a protobuf message that describes a .proto source file or any element therein. So a collection of descriptors can describe an entire schema of protobuf types, including RPC services. This package is needed as a build-depends of buf (https://buf.build), which is itself needed to build the latest versions of nomad (https://www.nomadproject.io).
Bug#980430: ITP: r-cran-nanotime -- nanosecond resolution date and time calculations for R
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-nanotime Version : 0.3.2 Upstream Author : Dirk Eddelbuettel and Leonardo Silvestri * URL or Web page : https://github.com/eddelbuettel/nanotime * License : GPL-2+ Description : nanosecond resolution date and time calculations for R Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#980416: ITP: jquery-i18n-properties -- lightweight jQuery internationalization plugin
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org, debian-edu-pkg-t...@lists.alioth.debian.org * Package name: jquery-i18n-properties Version : 1.2.7 Upstream Author : Adrian Fish * URL : https://github.com/jquery-i18n-properties/jquery-i18n-properties * License : Expat Programming Lang: Javascript Description : lightweight jQuery internationalization plugin Lightweight jQuery plugin for providing internationalization to JavaScript from ‘.properties’ files, just like in Java Resource Bundles. It loads and parses resource bundles (.properties) based on provided language and country codes (ISO-639 and ISO-3166) or language reported by browser. . This jQuery plugin is a required dependency for the already uploaded OpenBoard (at the time of testing and packaging, jquery-i18n-properties had been in Debian, however, it got removed some months ago which did not catch my intention). . Thus, re-uploading (with a much newer upstream version).
Re: Making Debian available
On Jan 18, Marc Haber wrote: > Imagine the catastrophal message we're sending by "here is our > official image, but that one is unlikely to work on your laptop, > better use this here." Yes, it would be bad marketing. But at least we could show users something that works, so that's still better than the current situation if the self-harm faction will keep fighting for that. -- ciao, Marco signature.asc Description: PGP signature
Re: Making Debian available - patch for webwml
> 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. -- regards Thomas
Re: Making Debian available
On Mon, 18 Jan 2021 16:29:52 +, 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. Imagine the catastrophal message we're sending by "here is our official image, but that one is unlikely to work on your laptop, better use this here." People will shake their heads in disbelief and install Ubuntu. One more Ubuntu install does not do zilch for Free Software, it just helps us to hold our nose high being holier than the pope. 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
On Mon, 18 Jan 2021 14:05:09 +0200 (EET), Timo Lindfors wrote: >On Mon, 18 Jan 2021, Marc Haber wrote: >> I remember installing Debian once from a live image because the only >> network I had available was using 802.1x. Must have been a rather >> painless experience, since I don't remember much trouble about it. > >I've also used it a couple of times. The only worry I have is that I end >up with an installation that is different from d-i installations in some >subtle way that will cause me to hit some weird bug in the future. Yes, that was also my concern, but it was the easiest way to do it in that rather rescrictive network. I still guess that they were trying to test me as it was on my very first day with a new customer. I was however unlikely to need my workstation installation as reference as they used to be a CentOS shop anyway. 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
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. 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
Firmware awareness Was: Making Debian available
On Mon, Jan 18, 2021 at 04:35:01PM +, 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? Those are two rhetorical questions. We should find a better way to deal with firmware blobs. (Surely not abandon the reasons why we have this project.) We, the Debian project, are fully aware of how odd firmware blobs are. What to do with the awareness is yet unknown. Regards Geert Stappers -- Silence is hard to parse
Re: Making Debian available
Hi Andrey (2021.01.17_13:16:04_+) > On Sun, Jan 17, 2021 at 11:33:28AM +0100, Marc Haber wrote: > > My workaround is to plug in a network cable for installation. But > > alas, I have up to now been able to avoid hardware without built-in > > Ethernet. I guess that many USB Ethernet interfaces will work out of > > the box without non-free, right? > I think people on Reddit usually recommend USB-tethering the cell phone. This is a useful trick to know, and has served me well for many years. But, assuming this is the best option we can provide for a user, it should be more than a trick - the installer should probably suggest it. Something along the lines of: 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. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Making Debian available
On 2021-01-18 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? Some (and I would argue the most cumbersome) challenges around WLAN support are governmental. Countries where "software radios" cannot legally allow the consumer to alter their frequencies, for example. I would also refer to those as "political reasons" even if they're not directly tied to the politics of software freedom within Debian. And yes, governments telling vendors that they're breaking the law and can be fined or put out of business for allowing their users to alter the way a device functions is still a software freedom concern, just one over which Debian may hold little sway. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Making Debian available
On Mon, Jan 18, 2021 at 04:35:01PM +, Steve McIntyre 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"? Well, "free software is inherently political", isn't it? > Should we just abandon them? If nothing useful comes from them then you indeed need to decide. -- WBR, wRAR signature.asc Description: PGP signature
Re: Making Debian available
[ Catching up on this thread a little late... ] Ansgar wrote: >On Fri, 2021-01-15 at 15:30 +, Jeremy Stanley wrote: >> On 2021-01-15 12:11:06 +0100 (+0100), Emanuele Rocca wrote: >> [...] >> > So the current situation is that we make an active effort to >> > produce two different types of installation media: one that works >> > for all users, and one broken for most laptops. >> [...] >> >> The one you say "works for all users" doesn't "work" for me because >> it contains proprietary closed-source software I don't want. > >Then don't install them? > >Debian's Social Contract states "We encourage CD manufacturers to read >the licenses of the packages in these areas [non-free & contrib] and >determine if they can distribute the packages on their CDs." Maybe we >should do that for the CD images we manufacture? :) 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. We *can* do a better job of pointing people at the media with non-free firmware included. I've added a few more links in various places, but IMHO we desperately need a better set of download (etc.) pages rather than just bodging changes in to the existing inadequate pages. See #819664, for example. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Making Debian available
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? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: About lintian
On Mon, Jan 18, 2021 at 02:00:22PM +0100, Pierre-Elliott Bécue wrote: > Le lundi 18 janvier 2021 à 11:31:35+0100, Lucas Nussbaum a écrit : > > Hi, > > > > On 17/01/21 at 22:00 +0900, Norbert Preining wrote: > > > On the infrastructure side, you mentioned on #debian-qa that in your > > > opinion, lintian is best run in a CI pipeline instead of on the > > > lintian.d.o service. While this is certainly true, do you plan to keep > > > the functionality on your rework of lintian.d.o? > > > > > > As part of this rework and the ongoing development, you said you have > > > plans > > > to set up a test version of the Lintian web application on non-Debian > > > infrastructure. How is that going, Felix? Please if you need help or > > > support, > > > don't hesitate to reach out. > > > > I agree that a service that provides an overview of the status regarding > > lintian for the whole archive would be useful (for example, to identify > > packages that need some area of work inside a team). > > > > If there's a lack of interest/motivation to redesign lintian.d.o as a > > standalone service, maybe a simpler architecture to explore would be to > > build it on top of UDD (with lintian runners feeding a table in UDD > > directly). That would make it possible to simplify most of the web stuff > > (and of course would still allow exporting to other services that need > > the data). I would be quite motivated to work on that. > > Hey all, > > Last time me and Felix discussed about lintian, his motivation to have a > fresh and new lintian.d.o seemed, to me, to be high, and I recall he was > mostly dealing with questions about how to do it, in particular about > infrastructure. As I said on that time, I'd be glad to provide help and > support should Felix feel the need for some. I'm quite not the best > developer, but I think I could be useful nevertheless! > > That very topic about an archive-wide Lintian ran on already uploaded > packages did not occur, though, and I'd be really interested in helping > keeping this feature around, if such help is needed! 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. I don't have a lot of free time to do this myself, but would be willing to guide someone who wants to work on it, as a good part of the time I currenly spend on Debian is already on ci.d.n anyway. signature.asc Description: PGP signature
Re: Making Debian available
On Mon, 18 Jan 2021, Marc Haber wrote: My understanding is that the live images are primarily intended for the typical "live system" use-case descended from things like Knoppix (boot machine from USB stick or optical media; use machine with OS from RAM, USB stick or optical media; shut down machine; no trace is left), with permanent installation via Calamares being considered somewhat experimental. Ah indeed. My comment was a more abstract observation: if you can run the installer in a more familiar environment it is easier for users. I did not intend to say anything about the current state of any package or team. I remember installing Debian once from a live image because the only network I had available was using 802.1x. Must have been a rather painless experience, since I don't remember much trouble about it. I've also used it a couple of times. The only worry I have is that I end up with an installation that is different from d-i installations in some subtle way that will cause me to hit some weird bug in the future. I had similar problems with virt-install. I had to add all sorts of extra hacks to produce installations that were as identical to manual installations as possible. https://lindi.iki.fi/lindi/debian10/server has my notes on how to do this with a server and https://lindi.iki.fi/lindi/debian10/ is an attempt to do it for desktop as well. Basically I first installed debian manually. Then I automated it and tweaked preseed and a custom shell script until the filesystem difference was minimal.
Re: Making Debian available
On Mon, 18 Jan 2021 11:38:59 +, Simon McVittie wrote: >On Mon, 18 Jan 2021 at 09:39:05 +, Andrew M.A. Cater wrote: >> The pointers to the Debian image on the Debian front page (and the >> discussion >> about standard/installer with firmware) relate to the non-live Debian >> installer. >> >> If we want the Calamares image to include firmware - that's a matter for >> debian-live, I think. > >https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ >seems to include both d-i images and live images that have the non-free >firmware included, if I'm reading correctly. > >My understanding is that the live images are primarily intended for >the typical "live system" use-case descended from things like Knoppix >(boot machine from USB stick or optical media; use machine with OS from >RAM, USB stick or optical media; shut down machine; no trace is left), >with permanent installation via Calamares being considered somewhat >experimental. I remember installing Debian once from a live image because the only network I had available was using 802.1x. Must have been a rather painless experience, since I don't remember much trouble about it. 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: About lintian
Le lundi 18 janvier 2021 à 11:31:35+0100, Lucas Nussbaum a écrit : > Hi, > > On 17/01/21 at 22:00 +0900, Norbert Preining wrote: > > On the infrastructure side, you mentioned on #debian-qa that in your > > opinion, lintian is best run in a CI pipeline instead of on the > > lintian.d.o service. While this is certainly true, do you plan to keep > > the functionality on your rework of lintian.d.o? > > > > As part of this rework and the ongoing development, you said you have plans > > to set up a test version of the Lintian web application on non-Debian > > infrastructure. How is that going, Felix? Please if you need help or > > support, > > don't hesitate to reach out. > > I agree that a service that provides an overview of the status regarding > lintian for the whole archive would be useful (for example, to identify > packages that need some area of work inside a team). > > If there's a lack of interest/motivation to redesign lintian.d.o as a > standalone service, maybe a simpler architecture to explore would be to > build it on top of UDD (with lintian runners feeding a table in UDD > directly). That would make it possible to simplify most of the web stuff > (and of course would still allow exporting to other services that need > the data). I would be quite motivated to work on that. Hey all, Last time me and Felix discussed about lintian, his motivation to have a fresh and new lintian.d.o seemed, to me, to be high, and I recall he was mostly dealing with questions about how to do it, in particular about infrastructure. As I said on that time, I'd be glad to provide help and support should Felix feel the need for some. I'm quite not the best developer, but I think I could be useful nevertheless! That very topic about an archive-wide Lintian ran on already uploaded packages did not occur, though, and I'd be really interested in helping keeping this feature around, if such help is needed! Thanks Norbert for opening that thread! Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: Making Debian available
On Mon, 18 Jan 2021 at 09:39:05 +, Andrew M.A. Cater wrote: > The pointers to the Debian image on the Debian front page (and the discussion > about standard/installer with firmware) relate to the non-live Debian > installer. > > If we want the Calamares image to include firmware - that's a matter for > debian-live, I think. https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ seems to include both d-i images and live images that have the non-free firmware included, if I'm reading correctly. My understanding is that the live images are primarily intended for the typical "live system" use-case descended from things like Knoppix (boot machine from USB stick or optical media; use machine with OS from RAM, USB stick or optical media; shut down machine; no trace is left), with permanent installation via Calamares being considered somewhat experimental. smcv
Re: Making Debian available - patch for webwml
[ Now added debian-boot to CC, since a page included in the attached patch is ] [ under their responsibility ] Holger Wansing wrote: > [ Adding debian-www to the loop ] > > Hi, > > Marc Haber wrote: > > On Sun, 17 Jan 2021 01:53:24 +, Paul Wise wrote: > > >On Sat, Jan 16, 2021 at 11:52 PM Russell Stuart wrote: > > > > > >> Testing doesn't produce netinst with non-free firmware > > > > > >There are both daily and weekly testing netinsts with firmware: > > > > > >https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/ > > >https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-cd/ > > > > We should really at least mention them somewhere. We're losing > > installations each day because they are so hard to find. > > So, to turn this discussion into a real change: > > debian-www team: what do you think about adding some more hint/warning > banners pointing to firmware-including installation images? > > We already have one at > https://www.debian.org/releases/stable/debian-installer/ > > So we could also add it to other pages (and re-use the translations as well): > https://www.debian.org/distrib/ > https://www.debian.org/distrib/netinst > https://www.debian.org/CD/http-ftp/ > https://www.debian.org/CD/torrent-cd/ > > Of course it's not optimal to be forced to add it to so many pages, > but the restructuring of the download / "getting-debian" section is > already on the agenda, so in the long term we can hopefully reduce the amount > of pages with that warning back to a low number like 2 or 3? > > The above is for stable. > We could also do similar for the testing firmware-including images > (that's probably the more important part, since there is no mention of such > images at all on the website). > > > Should I try to work out a proposal/patch? First patch attached. For an easy overview of how that might look like, I have uploaded some patched html pages to people.debian.org: https://people.debian.org/~holgerw/webwml_non-free-firmware/english/distrib/index.en.html https://people.debian.org/~holgerw/webwml_non-free-firmware/english/distrib/netinst.en.html https://people.debian.org/~holgerw/webwml_non-free-firmware/english/CD/http-ftp/index.en.html https://people.debian.org/~holgerw/webwml_non-free-firmware/english/CD/torrent-cd/index.en.html https://people.debian.org/~holgerw/webwml_non-free-firmware/english/devel/debian-installer/index.en.html (relative links inside of debian.org do not work there) 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..c535a0dfe07 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..78d174ada22 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-i
Re: About lintian
Hi, On 17/01/21 at 22:00 +0900, Norbert Preining wrote: > On the infrastructure side, you mentioned on #debian-qa that in your > opinion, lintian is best run in a CI pipeline instead of on the > lintian.d.o service. While this is certainly true, do you plan to keep > the functionality on your rework of lintian.d.o? > > As part of this rework and the ongoing development, you said you have plans > to set up a test version of the Lintian web application on non-Debian > infrastructure. How is that going, Felix? Please if you need help or support, > don't hesitate to reach out. I agree that a service that provides an overview of the status regarding lintian for the whole archive would be useful (for example, to identify packages that need some area of work inside a team). If there's a lack of interest/motivation to redesign lintian.d.o as a standalone service, maybe a simpler architecture to explore would be to build it on top of UDD (with lintian runners feeding a table in UDD directly). That would make it possible to simplify most of the web stuff (and of course would still allow exporting to other services that need the data). I would be quite motivated to work on that. Lucas
Re: Making Debian available
On Mon, Jan 18, 2021 at 09:57:31AM +0100, Holger Wansing wrote: > Hi, > > Timo Lindfors wrote: > > > > On Sun, 17 Jan 2021, Marc Haber wrote: > > > Absolutely. The Installation Experience is one of the first contacts > > > with the distribution for most people¹, and since we all know that the > > > > Yep. I think using the live environment for installation could be more > > user-friendly as the user is already familiar with how to use e.g. USB > > drive or > > browser during the installation if they need to search for help or copy > > some additional firmware files. The number of people who know how to do > > this in the current d-i images is much lower since you'd need to use the > > command-line with a really restricted set of tools. > > Hmm, AFAICS the calamares installer does not include functionality to > pull non-free firmware. > At least I cannot see a checkbox or similar, where to activate/deactivate > such feature / where to enable non-free... > *The* Debian installer is the original text/gtk installer, if you will and is the installer most of us use to install Debian. The debian images team maintain this on Debian images and it's the installer updated with every point release. The Calamares installer is a cross-distro installer. It is maintained by the debian-live team (currently highvoltage and others, I think).We know that the Calamares installer can be problematic for low memory installs. The pointers to the Debian image on the Debian front page (and the discussion about standard/installer with firmware) relate to the non-live Debian installer. If we want the Calamares image to include firmware - that's a matter for debian-live, I think. Andy C > Or did I miss something? > > > Holger > > > -- > Holger Wansing > PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 >
Re: Making Debian available
Hi, Timo Lindfors wrote: > > On Sun, 17 Jan 2021, Marc Haber wrote: > > Absolutely. The Installation Experience is one of the first contacts > > with the distribution for most people¹, and since we all know that the > > Yep. I think using the live environment for installation could be more > user-friendly as the user is already familiar with how to use e.g. USB drive > or > browser during the installation if they need to search for help or copy > some additional firmware files. The number of people who know how to do > this in the current d-i images is much lower since you'd need to use the > command-line with a really restricted set of tools. Hmm, AFAICS the calamares installer does not include functionality to pull non-free firmware. At least I cannot see a checkbox or similar, where to activate/deactivate such feature / where to enable non-free... Or did I miss something? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
