Bug#1071823: console-setup: [Hurd i386] debconf: lsmod: not found
Hello, Martin-Éric Racine, le sam. 25 mai 2024 10:07:45 +0300, a ecrit: > Severity: important Why important? > While upgrading from 1.223 to 1.226 on Hurd i386: > > Fetched 32.4 MB in 23s (1429 kB/s) > > > Extracting templates from packages: 100% > Preconfiguring packages ... > /var/cache/debconf/tmp.ci/console-setup.config.otOVsK: 1196: lsmod: not found What consequence does it have? I don't remember upgrading console-setup getting broken. If it's only a warning, that's completely fine. Samuel
Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
Joseph Carter, le dim. 28 avril 2024 16:21:06 -0700, a ecrit: > Even so, could you try to include a DejaVuSansMonoBold font as well? It's also included in my change. Samuel
Bug#595696: Bug#594817: console-setup should configure the width of the console
Samuel Thibault, le mar. 01 sept. 2015 19:40:30 +0200, a ecrit: > Anton Zinoviev, le Tue 01 Sep 2015 20:31:33 +0300, a écrit : > > On Tue, Aug 25, 2015 at 10:20:46PM +0200, Samuel Thibault wrote: > > > Samuel Thibault, le Sun 29 Aug 2010 21:08:05 +0200, a écrit : > > > > We could even imagine to > > > > rasterize a vector font on the fly for very big sizes. > > > > > > otf2bdf and bdf2psf could be used for that, for instance if the user > > > specifies the width (which will be the most probable use, people usually > > > > I am afraid of such automatic conversion. There are too many > > combinations which can easily lead to many undiscovered bugs... I'd > > prefer if we use otf2bdf and bdf2psf manually in order to add a few new > > fonts in the source package of console-setup. > > Right, that can be enough, indeed. We can add more as screen get more > dpi (and make it simple to change in the package build for users to > build them easily if they need) I just did that :) Up to 64b width, the maximum width that will be allowed by linux 6.9. Samuel
Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels
Control: forcemerge -1 816111 Hello, T. Joseph Carter, le mer. 24 avril 2024 13:25:22 -0700, a ecrit: > Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This > is probably aimed at "more than 4k" monitors, but for accessibility > reasons it would be really useful to have larger sizes available sooner > for those of us already have 4k sorts of screens. Yes, that was the points in adding the support in the kernel :) > Perhaps this might best be done by putting those huge-sized fonts in an > appropriately named -huge fonts package? I'll leave the implementation > details to you, this is just a request for the fonts to be created. We already had the request in #816111, also #595696 was about possibly generalizing to using rasterized fonts. I gave a try at converting terminus.ttf to bdf with otf2bdf: otf2bdf -c C -p 32 -r 72 /usr/share/fonts/truetype/terminus/TerminusTTF-4.46.0.ttf > /tmp/terminus.bdf bdf2psf --fb /tmp/terminus.bdf /usr/share/bdf2psf/standard.equivalents ascii.set 256 /tmp/terminus.psf /tmp/terminus.sfm but the baseline is not coherent. Using DejaVuSansMono seems to be working better: otf2bdf -c C -p 32 -r 100 /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf > /tmp/DejaVuSansMono.bdf bdf2psf --fb --width 32 /tmp/DejaVuSansMono.bdf /usr/share/bdf2psf/standard.equivalents ascii.set 256 /tmp/DejaVuSansMono.psf /tmp/DejaVuSansMono.sfm (I'm adding a new --width parameter to bdf2psf to specify the expected width since AVERAGE_WIDTH as set by otf2bdf doesn't really tell) Samuel
Bug#1065570: Interface border is replaced by ascii chars
Samuel Thibault, le sam. 09 mars 2024 22:02:46 +0100, a ecrit: > x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > > That's all the relevant information I can think of for now. Maybe see if > > your KVM is able to reproduce using the pxelinux.cfg above or removing the > > "VGA=788" parameter from the kernel command line? > > Ahah! That's indeed the trigger. I also have to pass -vga vmware to > qemu, so the linux console stays in pure text mode, no fbcon. > > As I was guessing, it's the console-setup configuration that mangles > everything, we'll be able to have a look. > > I couldn't reproduce it with all other parameters being the default, > I'll dig more. d-i debian-installer/locale string en_US This is the eventual culprit, it should be d-i debian-installer/locale string en_US.UTF-8 Do we actually support non-UTF-8 locales, actually? Samuel
Bug#1065570: Interface border is replaced by ascii chars
Samuel Thibault, le sam. 09 mars 2024 22:42:36 +0100, a ecrit: > Samuel Thibault, le sam. 09 mars 2024 22:02:46 +0100, a ecrit: > > x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > > > That's all the relevant information I can think of for now. Maybe see if > > > your KVM is able to reproduce using the pxelinux.cfg above or removing > > > the "VGA=788" parameter from the kernel command line? > > > > Ahah! That's indeed the trigger. I also have to pass -vga vmware to > > qemu, so the linux console stays in pure text mode, no fbcon. > > > > As I was guessing, it's the console-setup configuration that mangles > > everything, we'll be able to have a look. > > > > I couldn't reproduce it with all other parameters being the default, > > I'll dig more. > > d-i debian-installer/locale string en_US > > This is the eventual culprit, it should be > > d-i debian-installer/locale string en_US.UTF-8 I'm fixing the d-i manual. Samuel
Bug#1065561: console-setup: typos in documentation
Control: tags -1 + pending Applied, thanks!
Bug#1065570: Interface border is replaced by ascii chars
Control: reassign -1 console-setup Control: tags -1 + d-i Hello, x11r, le jeu. 07 mars 2024 02:13:22 +, a ecrit: > That's all the relevant information I can think of for now. Maybe see if your > KVM is able to reproduce using the pxelinux.cfg above or removing the > "VGA=788" parameter from the kernel command line? Ahah! That's indeed the trigger. I also have to pass -vga vmware to qemu, so the linux console stays in pure text mode, no fbcon. As I was guessing, it's the console-setup configuration that mangles everything, we'll be able to have a look. I couldn't reproduce it with all other parameters being the default, I'll dig more. Samuel
Bug#1065570: Interface border is replaced by ascii chars
Hello, x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit: > The mangling does not happen immediately. It happens after the "Installing > the base system" step (not sure what the step after that is supposed to be). > Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu I still cannot reproduce with: mkdir tmp cd tmp wget https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz tar xf netboot.tar.gz wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu dd < /dev/zero > disk.img bs=1M count=1 seek=1 kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive file=disk.img,cache=unsafe -m 1G and appending ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg on the boot kernel command line. It does show up fine up to the reboot step. Any idea what is different with your case? (except the virtualization software) Samuel
Bug#1065570: Interface border is replaced by ascii chars
Hello, x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit: > The machine is PXE booted with the kernel parameters: > initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en > country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" > url=tftp://10.0.0.1/preseed.cfg > > Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a > VGA KVM for the tests on bare metal. I still cannot reproduce with unpacking the tarball and running kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G and passing the kernel parameters. Does the mangling happen right from the first screen, or after some steps? It could be useful to share your preseed.cfg (take care of removing any hardcoded password). Samuel
Bug#1065570: ***UNCHECKED*** Re: Bug#1065570: Interface border is replaced by ascii chars
Hello, Please re-send your mail unencrypted, so everybody can read the information. Samuel
Bug#1065570: Interface border is replaced by ascii chars
x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit: > I've been working with a small team at my college trying to develop a tool to > automate PXE booting and installation. We have targeted Debian as the first > OS we want to get working over PXE boot. On every test we've ran of the > Debian installation process, there's a visual bug that occurs late in the > installation process. Effectively, the border of the progress interface turns > into Çâö repeatedly. You can see an image of it in the issue here > https://github.com/xeluior/genisys/issues/82 That looks like an utf-8 encoding issue. Please tell us exactly how you boot it (kernel parameters and how you access the console). Samuel
Bug#1064974: alsa-lib: Missing libasound2t64 / libasound2-udeb relation
Source: alsa-lib Version: 1.2.10-3.1 Severity: serious Tags: d-i a11y Justification: makes brltty FTBFS User: debian-...@lists.debian.org Usertags: time-t Hello, The t64 change apparently missed adding a relation between the libasound2t64 deb and the libasound2-udeb udeb libraries, to that brltty now ftbfs when checking that brltty-udeb only depends on libraries inside d-i: https://salsa.debian.org/a11y-team/brltty/-/jobs/5377227 I guess --add-udeb=libasound2-udeb needs to be added to the dh_makeshlibs invocation for libasound2t64. Probably other packages producing udeb libraries are affected by the same kind of issue. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: salsa CI
Philip Hands, le mar. 23 janv. 2024 17:52:57 +0100, a ecrit: > Samuel Thibault writes: > > > Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit: > >> Samuel Thibault writes: > >> > >> > Hello, > >> > > >> > The CI on salsa doesn't manage to build the debian-installer package > >> > because the signed linux 6.6.13 package is not available yet. > >> > >> Is the thing you want to: > >> a) be able to build d-i on salsa even when we're in version skew, > >> or > >> b) do you want to be able to test with the latest version, whether it is > >> signed or not? > > > > b) > > > > Normally the bump in debian-installer comes about the same time as the > > linux upload. But there is the period between the linux upload and the > > linux-signed upload during which we don't really know whether we want to > > bump or not. Adding the alternative between non-signed and signed as I > > proposed would allow to be fine with either, while making sure it's the > > signed version which is used on buildds. > > Ah, fair enough. > > I guess in that case I'll need to adjust what I'm doing to detect the > available versions of kernel that I'm looking for in that patch. > > If you're only worried about builds on salsa-CI, same approach as used > in my MR ought to work, Indeed. It however doesn't fix the build on my laptop without some change :) > and then one could perhaps control which kernel > is selected via variables, or perhaps defaulting to the unsigned kernel > (if available) would work for my use-case too, in which case I could > just add that as a feature. > > The MR's here BTW: https://deb.li/3hHY2 > > BTW would it actually cause you a problem for the build to work, despite > the kernel being unavailable (e.g. by falling back to the previous > version)? For me it's fine for CI to fall back to the previous kernel for most jobs of the pipeline. I guess we'd still want a build job in the pipeline that sticks with the requested version, so that we notice in case that's not working, without breaking the entire CI pipeline. Samuel
Re: salsa CI
Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit: > Samuel Thibault writes: > > > Hello, > > > > The CI on salsa doesn't manage to build the debian-installer package > > because the signed linux 6.6.13 package is not available yet. > > Is the thing you want to: > a) be able to build d-i on salsa even when we're in version skew, > or > b) do you want to be able to test with the latest version, whether it is > signed or not? b) Normally the bump in debian-installer comes about the same time as the linux upload. But there is the period between the linux upload and the linux-signed upload during which we don't really know whether we want to bump or not. Adding the alternative between non-signed and signed as I proposed would allow to be fine with either, while making sure it's the signed version which is used on buildds. Samuel
salsa CI
Hello, The CI on salsa doesn't manage to build the debian-installer package because the signed linux 6.6.13 package is not available yet. Perhaps we should turn these build-deps: linux-image-6.6.13-amd64 [amd64], linux-image-6.6.13-arm64 [arm64], linux-image-6.6.13-686 [i386], linux-image-6.6.13-686-pae [i386], into linux-image-6.6.13-amd64 [amd64] | linux-image-6.6.13-amd64-unsigned [amd64], linux-image-6.6.13-arm64 [arm64] | linux-image-6.6.13-arm64-unsigned [arm64], linux-image-6.6.13-686 [i386] | linux-image-6.6.13-686-unsigned [i386], linux-image-6.6.13-686-pae [i386] | linux-image-6.6.13-686-pae-unsigned [i386], ? Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:24:23 +0100, a ecrit: > Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > > > documents a way to keep the pure vga text mode, but this doesn't seem to > > be working any more: vga=normal fb=false doesn't seem to be effective > > any more, vga=normal does indeed keep the textmode vga, but then even > > with fb=false the fbcon still gets triggered. I tried to manually set > > TERM_TYPE=dumb with the same result. > > > > Any idea what nowadays could be triggering the fbcon? > > Note: this is new in bookworm, bullseye doesn't pose the problem. > > I assigned the bug to rootskel, but not much has changed for it between > the two, so probably the bug isn't there, but I don't really know where > to look at otherwise. Could it be udev? Would there be a way to disable that? Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > Source: rootskel > Version: 1.136 > Severity: important > Tags: a11y > > Hello, > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > documents a way to keep the pure vga text mode, but this doesn't seem to > be working any more: vga=normal fb=false doesn't seem to be effective > any more, vga=normal does indeed keep the textmode vga, but then even > with fb=false the fbcon still gets triggered. I tried to manually set > TERM_TYPE=dumb with the same result. > > Any idea what nowadays could be triggering the fbcon? Note: this is new in bookworm, bullseye doesn't pose the problem. I assigned the bug to rootskel, but not much has changed for it between the two, so probably the bug isn't there, but I don't really know where to look at otherwise. Samuel
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Source: rootskel Version: 1.136 Severity: important Tags: a11y Hello, https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 documents a way to keep the pure vga text mode, but this doesn't seem to be working any more: vga=normal fb=false doesn't seem to be effective any more, vga=normal does indeed keep the textmode vga, but then even with fb=false the fbcon still gets triggered. I tried to manually set TERM_TYPE=dumb with the same result. Any idea what nowadays could be triggering the fbcon? Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.6.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1036886: Text input fields very hard to identify in high contrast / dark mode
Hello, Holger Wansing, le lun. 23 oct. 2023 09:15:57 +0200, a ecrit: > Samuel Thibault wrote (Mon, 23 Oct 2023 02:00:25 > +0200): > > I had a hard time getting a border. The simplest might be to just have > > a black background, as attached. Would that be fine enough? (we don't > > actually lose any contrast since it's the same blue as before) > > Any disadvantages in advocating the text installer to those people? Accessibility is about giving choice, not imposing choice ;) Some ideas: - graphical mode allows for even larger fonts - graphical mode allows for more languages - graphical mode allows to take screenshots ... Samuel
Re: installer help screen (Was: Re: installation-guide: simplify RAM/disk space requirements)
Holger Wansing, le jeu. 24 août 2023 08:01:46 +0200, a ecrit: > Holger Wansing wrote (Tue, 8 Aug 2023 00:06:14 +0200): > > amd64:minimum_memory_strict=350 > > amd64:minimum_memory=780 > > > > i386:minimum_memory_strict=285 > > i386:minimum_memory=485 > > Looking at this values (the current ones from lowmem), we have 350MB for > amd64 and 285MB for i386. > The installer help screen F2 has the 285MB value (grabbed from i386 ?) even > on > the amd64 image. > > Should this be sync'ed somehow? They need to be updated when updating the values in lowmem, yes. > (Of course, bumping this value from 285 to 350 means, that the i386 installer > help screen says "350MB needed", which is strictly not correct, but that's > not a blocker IMO ?) I'd say we can as well just put the amd64 values there. Samuel
Re: installation-guide: simplify RAM/disk space requirements
Hello, This looks reasonable, thanks! Samuel Holger Wansing, le mar. 08 août 2023 00:06:14 +0200, a ecrit: > Hi again, > > Samuel Thibault wrote (Sun, 6 Aug 2023 14:32:22 +0200): > > Holger Wansing, le sam. 05 août 2023 20:46:27 +0200, a ecrit: > > > Now looking in the doc source, I see that the "780MB" value from above is > > > architecture-dependent too. > > > > Ah, yes, that's part of the lowmem testing. > > > > > While 780MB seems realistic for amd64 to me, I wonder if the other values > > > can > > > be up-to-date: > > > > > > amd64:minimum_memory=780 > > > arm64:minimum_memory=260 > > > armel:minimum_memory=80 > > > armhf:minimum_memory=190 > > > i386:minimum_memory=485 > > > mips:minimum_memory=85 > > > mips64el:minimum_memory=345 > > > mipsel:minimum_memory=170 > > > ppc64el:minimum_memory=64 > > > s390x:minimum_memory=44 > > > > > > In the most eye-catching case of s390x, my proposal would mean, to change > > > the value in the guide from 44 to 512MB ! > > > That leads to the question, if the new situation after my changing would > > > be > > > wrong, or if the doc was wrong in the past? > > > > The doc probably just ended up wrong by just not getting updated, > > because we don't have people who both care about updating them, and have > > access to the hardware or know the qemu tricks to test all archs. > > > > I see that in the lowmem package, > > bbb4ed4c4da20d585cf30ceba9f0987173d3ac70 raised the default levels from > > 32MB/64MB to 120MB/155MB, that being the minimum numbers that were > > actually seen to work on at least some arch. > > Ok, I have now included those changes into my patch, to get the numbers > up-to-date for all archs. > > That is: > > amd64:minimum_memory_strict=350 > amd64:minimum_memory=780 > > arm64:minimum_memory_strict=245 > arm64:minimum_memory=260 > > armel:minimum_memory_strict=140 > armel:minimum_memory=190 > > armhf:minimum_memory_strict=140 > armhf:minimum_memory=190 > > i386:minimum_memory_strict=285 > i386:minimum_memory=485 > > mips64el:minimum_memory_strict=200 > mips64el:minimum_memory=345 > > mipsel:minimum_memory_strict=160 > mipsel:minimum_memory=170 > > ppc64el:minimum_memory_strict=256 > ppc64el:minimum_memory=500 > > s390x:minimum_memory_strict=120 > s390x:minimum_memory=155 > > See patch. > > > > > And, if a generic value for all archs is realistic and makes sense at all? > > > > Probably not, as seen in the values in the lowmem package. > > I think I found a reasonable solution. > > Current situation is: > > We have two sorts of numbers for RAM size: > > a) some kind of rough values, identical for all archs. These are just >subjective values, rounded up to the next bigger RAM modules you can buy >(current values can be found in >"Table 3.2. Recommended Minimum System Requirements" at >https://d-i.debian.org/manual/en.amd64/ch03s04.html ) >These are only rough recommendations, as in "we **recommend** X MB". >And this chapter 3.4 also mentions, that these recommendations can well be >underrun by the second sort of values: > b) these are values based on meassurements during lowmem testing. They are >different over the archs, and in the current text they are considered as >some kind of strict requirement, as in "you **need** at least X MB" values. >--> Compare this to the "we **recommend** X MB" values from a) ! > > > > > Taking all this as a basis, I would like to propose the following: > > > 1. in chapter 2 > (https://people.debian.org/~holgerw/installation-guide___improve-ram-size-values/amd64/ch02s05.html) >which is about hardware requirements, just mention the minimal rough >recommended values from a) which says something like "512MB" or "1GB", >corresponding to RAM modules available from your favorite hardware store. > > 2. People who want to try to go with lower values, are guided to >chapter 3 > (https://people.debian.org/~holgerw/installation-guide___improve-ram-size-values/amd64/ch03s04.html), >where they find the values from b) based on lowmem tests, which contain >the "absolute minimum values", drawing the baseline that cannot be > underrun. >Note, that this page is different, depending on arch! > > 3. Move all the constraints / advanced infos like > - installer should automatically do memory-saving tricks on
Re: installation-guide: simplify RAM/disk space requirements
Holger Wansing, le sam. 05 août 2023 20:46:27 +0200, a ecrit: > Now looking in the doc source, I see that the "780MB" value from above is > architecture-dependent too. Ah, yes, that's part of the lowmem testing. > While 780MB seems realistic for amd64 to me, I wonder if the other values can > be up-to-date: > > amd64:minimum_memory=780 > arm64:minimum_memory=260 > armel:minimum_memory=80 > armhf:minimum_memory=190 > i386:minimum_memory=485 > mips:minimum_memory=85 > mips64el:minimum_memory=345 > mipsel:minimum_memory=170 > ppc64el:minimum_memory=64 > s390x:minimum_memory=44 > > In the most eye-catching case of s390x, my proposal would mean, to change > the value in the guide from 44 to 512MB ! > That leads to the question, if the new situation after my changing would be > wrong, or if the doc was wrong in the past? The doc probably just ended up wrong by just not getting updated, because we don't have people who both care about updating them, and have access to the hardware or know the qemu tricks to test all archs. I see that in the lowmem package, bbb4ed4c4da20d585cf30ceba9f0987173d3ac70 raised the default levels from 32MB/64MB to 120MB/155MB, that being the minimum numbers that were actually seen to work on at least some arch. > And, if a generic value for all archs is realistic and makes sense at all? Probably not, as seen in the values in the lowmem package. Samuel
Re: installation-guide: simplify RAM/disk space requirements
Holger Wansing, le ven. 04 août 2023 21:03:38 +0200, a ecrit: > So I propose to change chapter 3 values like > > Install TypeRAM (minimum) RAM (recommended) Hard Drive > - No desktop 256 megabytes 512 megabytes 4 gigabytes > + No desktop 512 megabytes 1 gigabytes 4 gigabytes > With Desktop1 gigabytes 2 gigabytes 10 gigabytes > > > > > I would propose to change chapter 2 > like > > - You must have at least 780MB of memory and 1160MB of hard disk space to > - perform a normal installation." > + You must have at least 512MB of memory and 4GB of hard disk space to > + perform an installation." > > > > > Comments? That looks good to me indeed. Samuel
Re: installation-guide upload for bookworm
Hello, Holger Wansing, le dim. 09 juil. 2023 11:04:36 +0200, a ecrit: > Samuel Thibault wrote (Fri, 23 Jun 2023 02:07:01 > +0200): > > Samuel Thibault, le ven. 23 juin 2023 01:15:55 +0200, a ecrit: > > > Holger Wansing, le jeu. 22 juin 2023 22:20:54 +0200, a ecrit: > > > > I have just pushed a change to installation-guide, which I would like > > > > to have > > > > in stable|bookworm: > > > > > > Yes, sure, we can upload that +id in stable once we have it settled in > > > unstable! > > > > I have uploaded it to unstable, let's check how well it goes. > > The new version has migrated into testing, and I see no blockers to get > this into stable, right? Yes. > So I guess, I could file an bookworm-pu bug against release.debian.org, to > get this pushed forward? Yes, I have uploaded the attached change to bookworm, you can submit to release.debian.org. Thanks, Samuel diff -Nru installation-guide-20230508/debian/changelog installation-guide-20230508+deb12u1/debian/changelog --- installation-guide-20230508/debian/changelog2023-05-08 22:47:33.0 +0200 +++ installation-guide-20230508+deb12u1/debian/changelog2023-07-09 15:25:17.0 +0200 @@ -1,3 +1,11 @@ +installation-guide (20230508+deb12u1) bookworm; urgency=medium + + [ Holger Wansing ] + * Add Indonesian (as a recently added new translation) to langlist, to get +this translation into the package. + + -- Samuel Thibault Sun, 09 Jul 2023 15:25:17 +0200 + installation-guide (20230508) unstable; urgency=medium [ Samuel Thibault ] diff -Nru installation-guide-20230508/debian/langlist installation-guide-20230508+deb12u1/debian/langlist --- installation-guide-20230508/debian/langlist 2023-05-08 22:47:33.0 +0200 +++ installation-guide-20230508+deb12u1/debian/langlist 2023-06-23 01:16:32.0 +0200 @@ -12,6 +12,7 @@ #fiFinnish fr French #huHungarian +id Indonesian it Italian ja Japanese #kab Kabyle
Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm
Pascal Hambourg, le mar. 04 juil. 2023 08:09:33 +0200, a ecrit: > but AFAIK manual partitioning does not allow to create a partition > table on a RAID array. Yes, but after creating the RAID array, one can use guided partitioning and point it at the RAID disk, and that'll happily partition it and put an EFI partition there (see #1040266), and then grub-installer just fails and the user is at a loss without understanding why when they don't notice that an EFI partition was added inside the RAID array. > > It's fine to have an EFI partition inside a RAID array. One “just” needs > > to pass --no-nvram and to register it manually. That's not something > > that's achievable via d-i at the moment though (unless recent changes in > > grub-installer, near the end of the bookworm release cycle) made it > > possible indirectly. Ok, but the warning still seems precious to me. And it it might hint that possibility (and the warning won't prevent the user from doing it). Samuel
Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm
Source: partman-efi Version: 101 Severity: normal Tags: d-i Hello, As pointed out in #1040266, when using guided partitioning inside a raid, partman-auto creates an EFI partition there, and then grub-install fails because it can't register it. This error could also happen if a user creates by hand an EFI partition inside the raid by mistake. Just like partman-efi warns when no EFI partition is defined, it should also warn when an EFI partition is defined inside a raid or lvm (thus actually unreachable from EFI). Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Bug#1040266: partman-auto: should not create EFI partition when ran inside software RAID disk
Source: partman-auto Version: 162 Severity: normal Tags: d-i Hello, It took me some time to realize why I was not able to install Debian with software RAID1 system. The reason is that when I was running the Guided partitioning on the whole software RAID disk, partman-auto would create an EFI partition there, and thus even if I had created an EFI partition outside the RAID, grub would try to use the partition inside the RAID. If partman-auto wasn't creating an EFI partition inside the RAID, I wouldn't have had any issue. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Re: installation-guide upload for bookworm
Samuel Thibault, le ven. 23 juin 2023 01:15:55 +0200, a ecrit: > Holger Wansing, le jeu. 22 juin 2023 22:20:54 +0200, a ecrit: > > I have just pushed a change to installation-guide, which I would like to > > have > > in stable|bookworm: > > Yes, sure, we can upload that +id in stable once we have it settled in > unstable! I have uploaded it to unstable, let's check how well it goes. Samuel
Re: installation-guide upload for bookworm
Hello, Holger Wansing, le jeu. 22 juin 2023 22:20:54 +0200, a ecrit: > I have just pushed a change to installation-guide, which I would like to have > in stable|bookworm: Yes, sure, we can upload that +id in stable once we have it settled in unstable! Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hello, Cyril Brulebois, le jeu. 01 juin 2023 21:12:18 +0200, a ecrit: > Do we have other ttys than just tty1 that people might want to switch > to, and that might benefit from a similar adjustment? This script is actually not used for the other consoles, so it has never had any effect on them on any arch anyway. Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Emanuele Rocca, le jeu. 01 juin 2023 15:11:53 +0200, a ecrit: > On 2023-05-31 05:46, Samuel Thibault wrote: > > I'd rather see a patch like > > > > if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then > > # Busybox's init uses a global TERM across all consoles. > > # If the serial console is the default such as on arm64, that > > # will force vt102 on the Linux VT. Fix this back so we get > > # colors, utf-8, etc. > > TERM=linux > > fi > > > > (to be tested etc.) > > The following patch works. I've built a netboot image with patched rootskel, > see attached screenshots for before and after the cure. Thanks for testing! I have uploaded it (with fixed indent) Samuel > diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux > /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux > --- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 > 01:05:16.0 +0100 > +++ > /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux > 2023-06-01 15:05:32.514361854 +0200 > @@ -1,5 +1,13 @@ > export LANG=C > > +if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then > + # Busybox's init uses a global TERM across all consoles. > +# If the serial console is the default such as on arm64, that > +# will force vt102 on the Linux VT. Fix this back so we get > + # colors, utf-8, etc. > + TERM=linux > +fi > + > if [ "$TERM" = linux ] ; then > if [ "$TERM_TYPE" = virtual ]; then > echo -ne "\033[9;0]" # Turn off console blanking.
Re: Upcoming D-I Bookworm RC 4 and pseudo-RC 5
Cyril Brulebois, le sam. 03 juin 2023 20:07:05 +0200, a ecrit: > Unless specifically requested, I don't plan on including the first two > before Bookworm because we don't need it for release architectures. I > /think/ hurd-i386 gets somewhat released from unstable, so that > shouldn't matter… Yes. > not sure about ports architectures. Ports don't have a testing either. Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Emanuele Rocca, le mer. 31 mai 2023 17:29:31 +0200, a ecrit: > > 1. Why is aarch64 special here? > > 2. Where does that difference come from? > > According to Jessica Clarke this is due to busybox using vt102: > https://society.oftrolls.com/@jrtc27@mastodon.social/110459684352427882 Is it not possible to fix TERM after busybox dumbly set it? > > 3. Which other architectures might be impacted if we were to change > > that? > > I'm not sure, and I haven't tested the S40term-linux patch yet. However I can > report that booting the installer by passing console=tty0 to the kernel fixes > the problem (thanks alpernebbi!). > > Which of the two changes (console=tty0 vs S40term-linux patch) is less risky? The problem is that both are frown-prone. I guess there is a reason why on arm the default console is set to the serial port, e.g. for simpler debugging or something like that. And considering vt102 as "ok it's a Linux console" is meaningless. I'd rather see a patch like if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then # Busybox's init uses a global TERM across all consoles. # If the serial console is the default such as on arm64, that # will force vt102 on the Linux VT. Fix this back so we get # colors, utf-8, etc. TERM=linux fi (to be tested etc.) Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Samuel Thibault, le mar. 30 mai 2023 21:21:51 +0200, a ecrit: > Samuel Thibault, le mar. 30 mai 2023 21:16:46 +0200, a ecrit: > > I'm wondering what kind of console aarch64 is using: is that the Linux > > virtual Terminal on an fbdev, or a ttyS console? Something else? The > > kernel boot logs could be useful to determine that. > > Ah, https://openqa.debian.net/tests/151286/logfile?filename=serial0.txt > provides it. > > May 30 06:37:27 init: starting pid 246, tty '/dev/ttyAMA0': > '/sbin/debian-installer' > May 30 06:37:27 init: starting pid 247, tty '/dev/tty1': > '/sbin/debian-installer' > > So it might be "something else" :) Is the shown output from ttyAMA0, or > tty1? Also, to be noted: May 30 06:37:27 kernel: [0.531174] Run /init as init process May 30 06:37:27 kernel: [0.531176] with arguments: May 30 06:37:27 kernel: [0.531177] /init May 30 06:37:27 kernel: [0.531178] --- May 30 06:37:27 kernel: [0.531179] with environment: May 30 06:37:27 kernel: [0.531180] HOME=/ May 30 06:37:27 kernel: [0.531181] TERM=linux May 30 06:37:27 kernel: [0.531181] BOOT_IMAGE=/install.a64/vmlinuz So init does get started with TERM=linux, not vt102. So it's something in-between that seems to be setting that. Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Samuel Thibault, le mar. 30 mai 2023 21:16:46 +0200, a ecrit: > I'm wondering what kind of console aarch64 is using: is that the Linux > virtual Terminal on an fbdev, or a ttyS console? Something else? The > kernel boot logs could be useful to determine that. Ah, https://openqa.debian.net/tests/151286/logfile?filename=serial0.txt provides it. May 30 06:37:27 init: starting pid 246, tty '/dev/ttyAMA0': '/sbin/debian-installer' May 30 06:37:27 init: starting pid 247, tty '/dev/tty1': '/sbin/debian-installer' So it might be "something else" :) Is the shown output from ttyAMA0, or tty1? Samuel
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hello, Cyril Brulebois, le mar. 30 mai 2023 21:08:45 +0200, a ecrit: > Philip Hands (2023-05-30): > > Apparently, this MR fixes the problem: > > > > https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8 > > > > Although this does prompt the question of why aarch64 has TERM set to > > 'vt102' at this point, rather than 'linux'. > > Glancing at the merge request earlier, my first (intertwined) questions > were: > > 1. Why is aarch64 special here? > 2. Where does that difference come from? I'm wondering what kind of console aarch64 is using: is that the Linux virtual Terminal on an fbdev, or a ttyS console? Something else? The kernel boot logs could be useful to determine that. Samuel > 3. Which other architectures might be impacted if we were to change > that? > > > Also, I wonder whether there could be other circumstances when $TERM > > is set to 'vt102' where this change could be problematic (I'm guessing > > that the $TERM_TYPE checks deal with that, but I'm not sure). > > Yeah, that's the same kind of questions one would get by combined my > second and third questions…
Bug#1035854: Bookworm netboot image fails in VM
Cyril Brulebois, le mer. 10 mai 2023 17:34:53 +0200, a ecrit: > Moritz Muehlenhoff (2023-05-10): > > This turned out to be redux of #932149: Bumping the memory of the > > netboot-installed VM to 1536M RAM fixed it. There was anectotal > > evidence of non-netboot installations still succeeding with 1024M, so > > should we reassign to installation-guide to bump the documented > > minimum RAM at least for netboot? > > Both netboot and netboot-gtk's mini.iso, booted as a CD, are just fine > with 1G RAM (modulo cryptsetup OOMKs for a little while, #1028250), and > have been for years. That's how all my VM testing has been done for > years. :) > > If numbers are updated for netboot, maybe make it clear it's for PXE > booting? > > > When debugging the issue is also noticed that > > rootskel/src/lib/debian-installer/menu currently checks how much RAM > > is present and if it's less than 250M it exports > > DEBCONF_DROP_TRANSLATIONS=1 to cdebconf. > > > > Given that we already document 780MB as the minimum requirement for > > Bullseye that seems obsolete, happy to create MRs to remove it from > > rootskel and cdebconf to clean this up. > > Looping in Samuel who has been bumping requirements on a regular basis, > and who is likely to have good ideas in this area. I usually test the netinst image. I'm surprised that netboot use more memory, since it's supposed to fetch only what it really needs. And PXE is supposed not to change much since in the end it's supposed to be the same vmlinuz/initrd as non-pxe. I didn't know about rootskel setting DEBCONF_DROP_TRANSLATIONS, that should probably be coordinated with lowmem's management of low-memory heuristics. And at any rate, 1536M RAM looks really a *lot* to me, it really looks to me like some bug somewhere. Samuel
Re: Upload for installation-guide?
Hello, Holger Wansing, le ven. 28 avril 2023 22:43:17 +0200, a ecrit: > what do you think about a last upload of installation-guide for bookworm? > Maybe in one or two weeks, or similar? I have uploaded it. Samuel
Re: Upload for installation-guide?
Hello, Holger Wansing, le ven. 28 avril 2023 22:43:17 +0200, a ecrit: > what do you think about a last upload of installation-guide for bookworm? > Maybe in one or two weeks, or similar? > > Could you take the time? Yes, sure we can do that! Samuel
Re: Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Diederik de Haas, le lun. 20 févr. 2023 00:38:28 +0100, a ecrit: > On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote: > > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit: > > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote: > > > > Some people on debian-accessibility wanted to install debian in arm64 > > > > under the utm wrapped qemu on Macos. The current installation images > > > > however do not include sound drivers and speakup. > > > > > > Currently working on a MR to achieve that, but ... > > > > > > > ... indeed, it seems these modules are getting built only for > > > > amd64, 686, mips, sh4. > > > > > > ... this architecture list seems rather random? Why not also add it to > > > f.e. > > > armhf, which itself is also a rather random not-previously-enabled-arch? > > > > I don't see why we shouldn't indeed. If some drivers didn't make sense > > on these archs they would rather be disabled by the arch configuration > > anyway. Speakup itself is portable and should be working on any arch, > > provided it has a virtual console. > > > > The only historical reason I can see is that it was enabled only for > > architectures which have a gtk installer image (for which we consider > > that size doesn't matter). > > On https://www.debian.org/devel/debian-installer/ I checked the links under > "other images (netboot, USB stick, etc.)" for the presence of a > "netboot/gtk/" > folder and that turned out to be arm64 and armhf, so I'll only add those. > > If other arches should be added too, that can be done later. I'm just thinking that probably people won't actually do it. That's what happened for arm64: see commit ea37896526075fb9d0f453ec537536149ea97d16 which copied over the gtk configuration, but left speakup/sound commented, most probably just because the package was not available, and only now, 4 years later, we notice the missing feature. Samuel
Re: Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64
Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit: > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote: > > Some people on debian-accessibility wanted to install debian in arm64 > > under the utm wrapped qemu on Macos. The current installation images > > however do not include sound drivers and speakup. > > Currently working on a MR to achieve that, but ... > > > ... indeed, it seems these modules are getting built only for > > amd64, 686, mips, sh4. > > ... this architecture list seems rather random? Why not also add it to f.e. > armhf, which itself is also a rather random not-previously-enabled-arch? I don't see why we shouldn't indeed. If some drivers didn't make sense on these archs they would rather be disabled by the arch configuration anyway. Speakup itself is portable and should be working on any arch, provided it has a virtual console. The only historical reason I can see is that it was enabled only for architectures which have a gtk installer image (for which we consider that size doesn't matter). Samuel
Re: Accepted wxwidgets3.2 3.2.2+dfsg-1 (source) into unstable
Samuel Thibault, le lun. 13 févr. 2023 14:50:33 +0100, a ecrit: > gregor herrmann, le lun. 13 févr. 2023 00:26:54 +0100, a ecrit: > > On Mon, 13 Feb 2023 00:09:20 +0100, Cyril Brulebois wrote: > > > Debian FTP Masters (2023-02-11): > > > > Format: 1.8 > > > > Date: Sat, 11 Feb 2023 13:15:16 -0500 > > > > Source: wxwidgets3.2 > > > > Architecture: source > > > > Version: 3.2.2+dfsg-1 > > > > Distribution: unstable > > > > Urgency: medium > > > > Maintainer: wxWidgets Maintainers > > > > Changed-By: Scott Talbert > > > > Closes: 1028427 > > > > Changes: > > > > wxwidgets3.2 (3.2.2+dfsg-1) unstable; urgency=medium > > > > . > > > >* d/watch: fix download URL when using GitHub API > > > >* Update to new upstream release 3.2.2 > > > >* Add Breaks/Replaces to libwxgtk-gl3.2-1 (Closes: #1028427) > > > > > > This seems to have made libalien-wxwidgets-perl uninstallable, as seen in > > > my devel chroot but also for any systems, as mentioned on tracker: > > > https://tracker.debian.org/pkg/wxwidgets3.2 > > > > If we're lucky, a binNMU of libalien-wxwidgets-perl against > > libwxgtk3.2-dev,libwxgtk-media3.2-dev 3.2.2 (and later of libwx-perl > > against the rebuilt libalien-wxwidgets-perl) might be enough. > > > > A local rebuild of libalien-wxwidgets-perl runs through, including > > autopkgtests. > > > > (I haven't tried the second step with libwx-perl.) > > Building the two packages does fix the dependencies indeed. > > Can these binnmus be scheduled please? So working on d-i doesn't stay > stuck on this. > > nmu libalien-wxwidgets-perl_0.69+dfsg-6 . ANY . unstable . -m "Rebuild > against libwxgtk3.2-dev 3.2.2+dfsg-1" Thanks for this one, now installed :) Now we need that one: nmu libwx-perl_0.9932-8 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.2+dfsg-1" Samuel
Re: Accepted wxwidgets3.2 3.2.2+dfsg-1 (source) into unstable
gregor herrmann, le lun. 13 févr. 2023 00:26:54 +0100, a ecrit: > On Mon, 13 Feb 2023 00:09:20 +0100, Cyril Brulebois wrote: > > Debian FTP Masters (2023-02-11): > > > Format: 1.8 > > > Date: Sat, 11 Feb 2023 13:15:16 -0500 > > > Source: wxwidgets3.2 > > > Architecture: source > > > Version: 3.2.2+dfsg-1 > > > Distribution: unstable > > > Urgency: medium > > > Maintainer: wxWidgets Maintainers > > > Changed-By: Scott Talbert > > > Closes: 1028427 > > > Changes: > > > wxwidgets3.2 (3.2.2+dfsg-1) unstable; urgency=medium > > > . > > >* d/watch: fix download URL when using GitHub API > > >* Update to new upstream release 3.2.2 > > >* Add Breaks/Replaces to libwxgtk-gl3.2-1 (Closes: #1028427) > > > > This seems to have made libalien-wxwidgets-perl uninstallable, as seen in > > my devel chroot but also for any systems, as mentioned on tracker: > > https://tracker.debian.org/pkg/wxwidgets3.2 > > If we're lucky, a binNMU of libalien-wxwidgets-perl against > libwxgtk3.2-dev,libwxgtk-media3.2-dev 3.2.2 (and later of libwx-perl > against the rebuilt libalien-wxwidgets-perl) might be enough. > > A local rebuild of libalien-wxwidgets-perl runs through, including > autopkgtests. > > (I haven't tried the second step with libwx-perl.) Building the two packages does fix the dependencies indeed. Can these binnmus be scheduled please? So working on d-i doesn't stay stuck on this. nmu libalien-wxwidgets-perl_0.69+dfsg-6 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.2+dfsg-1" nmu libwx-perl_0.9932-8 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.2+dfsg-1" with an extra depend on libalien-wxwidgets-perl (>= 0.69+dfsg-6+b1) Samuel
Bug#1030002: installation-guide: replace http.us.debian.org with deb.debian.org
Control: tags -1 + pending Hello, Cyril Brulebois, le lun. 30 janv. 2023 04:09:57 +0100, a ecrit: > Spotted while working on the update for non-free-firmware: the > installation guide references http.us.debian.org everywhere. Yes, actually it's an entity that translators turn into a closer mirror. That said there was a piece of the install-methods chapter that was using a hardcoded http.us.debian.org, I pushed a fix. Samuel
Bug#1028400: Debian-installer 11.6 not saving static network configuration after DHCP + IPv6 autoconf
Control: tags -1 - unreproducible Control: reassign -1 netcfg Control: retitle -1 Debian-installer 11.6 not saving static network configuration after DHCP + IPv6 autoconf (Please always keep the bug mail in Cc so information is recorded for everybody) Fabio Maione, le mer. 11 janv. 2023 05:30:36 +0100, a ecrit: > As you can see at the end of the video and in the next screenshot, it seems > only IPV6 has been configured with autoconfiguration, the manual > configuration of IPV4 is missing. Ah, there is IPv6 in the story. I can indeed reproduce it with qemu with e.g. -net nic -net user,ipv6-net=2a0c:e300:5:199::/64 (even if the host doesn't have IPv6 connection). Reassigning to netcfg since that's the package that produces the file. Samuel
Bug#1028400: Debian-installer 11.6 not saving static network configuration after DHCP
Control: tags -1 + unreproducible Hello, Fabio Maione, le mar. 10 janv. 2023 15:27:22 +0100, a ecrit: > Hello, during "Graphics install" you will reach the network configurations > dialogs. After DHCP assignment, at the "hostname" dialog you can go back and > choose to configure network manually. > > If you set a static address, the configuration will not be saved in the > '/etc/network/interfaces' file on the target system. I tried it (letting DHCP succeed but then got back and configure statically) and I did get the static configuration in /etc/network/interfaces. So it seems we can't reproduce the issue, perhaps there are more details that make it fail in your case, that you need to determine. Samuel
Bug#1017435: debian-installer: georgian text mode fails to render all characters
Roland Clobus, le sam. 07 janv. 2023 11:31:29 +0100, a ecrit: > On 06/01/2023 16:20, Samuel Thibault wrote: > > Roland Clobus, le ven. 06 janv. 2023 13:38:34 +0100, a ecrit: > > > With the attached script you can generate a list of all characters that > > > are > > > used in the translations. That can be used to determine the minimal set of > > > required characters. > > > > We already do that in the debian installer, but that is not enough to be > > reasonably sure that this covers all questions that might happen during > > installation, since questions could be asked by any udeb. That's why we > > rather request for a an explicit file from actual translators. > > I agree. But the work for the translators can be reduced by automatically > parsing the work they have already done (i.e. the translations). Ah ok I misread what you meant. Yes that can be a good base, which can then be proofread by translators. > In order not to miss any translated text, I've updated the script to parse > all .udeb files that are present on the installation medium and extract the > template from them. This ensures that all questions that might happen during > installation will be could. > Or... are additional udebs downloaded on demand? It seems from the list.gz files that udebs are on the first iso, and from the debian-cd exclude files that the only udebs which are not there are the ones which are already included in the d-i initrd. I doesn't seem that your current script looks at the udebs included in the initrd? Samuel
Bug#1028062: debian-installer: Audio-based Installation - Question for keyboard layout and choice of hot keys
Hello, Thanks for the feedback. Peter Schwede, le ven. 06 janv. 2023 13:18:56 +, a ecrit: > 1) The hotkeys aren't read aloud most of the time. The engine appears to > silent ?, < and >. Yes, that's known, it's #690343. The key bindings are documented in the accessibility section of the manual. https://d-i.debian.org/manual/fr.amd64/ch05s02.html#idm1310 > I suggest to replace them by j, f (and d for example). We need these to be possibly usable for answering textual questions. > 2) Having to use a Germany keyboard, I had to web search for the english > keyboard layout to know what key would repeat the current question. I suggest > to move the question about the keyboard layout up a little. And conversely people have largely told us that we really need to have language/country questions very first, before anything else. I don't think we can change that. Samuel
Bug#1017435: debian-installer: georgian text mode fails to render all characters
Roland Clobus, le ven. 06 janv. 2023 13:38:34 +0100, a ecrit: > On 01/01/2023 20:49, Holger Wansing wrote: > > Samuel Thibault wrote (Sun, 1 Jan 2023 20:14:36 > > +0100): > > > Hello, > > > > > > Holger Wansing, le mar. 16 août 2022 22:59:34 +0200, a ecrit: > > > > Philip Hands wrote (Tue, 16 Aug 2022 11:22:30 +0200): > > > > > openQA just noticed that the rendering of certain characters just > > > > > changed, > > > > > highlighting the fact that the rendering was already broken. > ... > > > The solution is simply to add the required characters in > > > debian-installer/build/needed-characters/ka.utf: > > > So, we need a Georgian translator, providing us a file with all non-ascii > > characters needed for the Georgian language. > > > > Can anyone help us, please? > > With the attached script you can generate a list of all characters that are > used in the translations. That can be used to determine the minimal set of > required characters. We already do that in the debian installer, but that is not enough to be reasonably sure that this covers all questions that might happen during installation, since questions could be asked by any udeb. That's why we rather request for a an explicit file from actual translators. Samuel
Bug#1017435: debian-installer: georgian text mode fails to render all characters
Hello, Holger Wansing, le mar. 16 août 2022 22:59:34 +0200, a ecrit: > Philip Hands wrote (Tue, 16 Aug 2022 11:22:30 +0200): > > openQA just noticed that the rendering of certain characters just changed, > > highlighting the fact that the rendering was already broken. > > To be more precise here: > - this only affects the text installer; rendering in graphical installer > seems fine; > - Georgian started to be available for the text installer in debian 10, and > some > research showed, that this issue is there from that beginning (debian 10). > > Since noone noticed this for years, maybe we can go with a workaround to > disable Georgian for the text installer (if noone finds the real solution > for this). The solution is simply to add the required characters in debian-installer/build/needed-characters/ka.utf: https://d-i.debian.org/doc/i18n-guide/ch03s06.html I'm surprised that this was missed. Was https://d-i.debian.org/doc/i18n-guide/ch03.html not followed? Samuel
Re: bterm-unifont_1.7_amd64.changes ACCEPTED into unstable
Samuel Thibault, le dim. 01 janv. 2023 16:30:50 +0100, a ecrit:
> Samuel Thibault, le dim. 01 janv. 2023 15:57:58 +0100, a ecrit:
> > Samuel Thibault, le dim. 01 janv. 2023 15:46:31 +0100, a ecrit:
> > > Template: mirror/suite
> > > Type: select
> > > Choices-C: ${CHOICES-C}
> > > Choices: ${CHOICES}
> > > Description: Debian version to install:
> > > Debian comes in several flavors. Stable is well-tested and rarely
> > > changes.
> > > Unstable is untested and frequently changing. Testing is a middle ground,
> > > that receives many of the new versions from unstable if they are not too
> > > buggy.
> > > .
> > > Only flavors available on the selected mirror are listed.
> > > Description-ar.UTF-8: إصدارة دبيان التي ستثبّت:
> > > يتوفّر دبيان بعدة أنواع. المستقر مختبر
> > > جيّداً و قلّما يتغيّر. الغير مستقر غير iconv: illegal input sequence at
> > > position 349178
> >
> > Mmm, actually the debian/po/ar.po file itself doesn't seem bogus, but
> > the templates file in the .deb control is.
>
> It's upgrading perl from bullseye to sid that breaks it. I've had issues
> with utf-8 encoding in console-setup indeed, that probably affects
> po-debconf too.
Yes, that's it, I have uploaded a fixed choose-mirror.
Samuel
Re: bterm-unifont_1.7_amd64.changes ACCEPTED into unstable
Samuel Thibault, le dim. 01 janv. 2023 15:57:58 +0100, a ecrit:
> Samuel Thibault, le dim. 01 janv. 2023 15:46:31 +0100, a ecrit:
> > Template: mirror/suite
> > Type: select
> > Choices-C: ${CHOICES-C}
> > Choices: ${CHOICES}
> > Description: Debian version to install:
> > Debian comes in several flavors. Stable is well-tested and rarely changes.
> > Unstable is untested and frequently changing. Testing is a middle ground,
> > that receives many of the new versions from unstable if they are not too
> > buggy.
> > .
> > Only flavors available on the selected mirror are listed.
> > Description-ar.UTF-8: إصدارة دبيان التي ستثبّت:
> > يتوفّر دبيان بعدة أنواع. المستقر مختبر
> > جيّداً و قلّما يتغيّر. الغير مستقر غير iconv: illegal input sequence at
> > position 349178
>
> Mmm, actually the debian/po/ar.po file itself doesn't seem bogus, but
> the templates file in the .deb control is.
It's upgrading perl from bullseye to sid that breaks it. I've had issues
with utf-8 encoding in console-setup indeed, that probably affects
po-debconf too.
Samuel
Re: bterm-unifont_1.7_amd64.changes ACCEPTED into unstable
Samuel Thibault, le dim. 01 janv. 2023 15:46:31 +0100, a ecrit:
> Template: mirror/suite
> Type: select
> Choices-C: ${CHOICES-C}
> Choices: ${CHOICES}
> Description: Debian version to install:
> Debian comes in several flavors. Stable is well-tested and rarely changes.
> Unstable is untested and frequently changing. Testing is a middle ground,
> that receives many of the new versions from unstable if they are not too
> buggy.
> .
> Only flavors available on the selected mirror are listed.
> Description-ar.UTF-8: إصدارة دبيان التي ستثبّت:
> يتوفّر دبيان بعدة أنواع. المستقر مختبر
> جيّداً و قلّما يتغيّر. الغير مستقر غير iconv: illegal input sequence at
> position 349178
Mmm, actually the debian/po/ar.po file itself doesn't seem bogus, but
the templates file in the .deb control is.
Samuel
Re: bterm-unifont_1.7_amd64.changes ACCEPTED into unstable
Hello,
Cyril Brulebois, le dim. 01 janv. 2023 08:48:39 +0100, a ecrit:
> I didn't check, but this looks like a possible culprit for the new d-i
> daily build failures on armel and armhf?
> | hex2bdf \
> | -v "`dpkg-query -W -f '${Version}' unifont`" \
> | -c "`dpkg-query -W -f '${Homepage}' unifont`" \
> | < /usr/share/unifont/unifont.hex \
> | > tmp/kirkwood_netboot/unifont.bdf.full
> | LOCPATH=./tmp/kirkwood_netboot/tree/usr/lib/locale LC_ALL=C.UTF-8
> reduce-font tmp/kirkwood_netboot/unifont.bdf.full <
> ./tmp/kirkwood_netboot/all.utf > tmp/kirkwood_netboot/unifont.bdf.tmp
> | setlocale: C.UTF-8
> | FYI: MB_CUR_MAX/MB_LEN_MAX: 6/16
> | error -1 at position 349178 (bytes: 16 Ù
> | جرّب Ùˆ Ù)
> | Used chars: 2252 (349178 processed)
It could look so indeed, but hex2bdf, unifont.hex, and reduce-font
don't come from it. Looking at all.utf, it seems it's the choose-mirror
package which has a typo:
$ iconv -f utf-8 < all.utf
[...]
Template: mirror/suite
Type: select
Choices-C: ${CHOICES-C}
Choices: ${CHOICES}
Description: Debian version to install:
Debian comes in several flavors. Stable is well-tested and rarely changes.
Unstable is untested and frequently changing. Testing is a middle ground,
that receives many of the new versions from unstable if they are not too
buggy.
.
Only flavors available on the selected mirror are listed.
Description-ar.UTF-8: إصدارة دبيان التي ستثبّت:
يتوفّر دبيان بعدة أنواع. المستقر مختبر
جيّداً و قلّما يتغيّر. الغير مستقر غير iconv: illegal input sequence at
position 349178
(that it happens only on a couple of archs is probably just a different
build time thing).
Samuel
Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)
control: block 1027446 by 1027450 control: merge 1027448 1027450 Hello, Παύλος Γκέσος, le sam. 31 déc. 2022 20:38:23 +0200, a ecrit: > unifont issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027450 I should have be explicit about it: the few "control:" lines at the top of my mail had already created a report there. Now merging the two to avoid a duplicate. Samuel
Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)
Παύλος Γκέσος, le sam. 31 déc. 2022 18:49:04 +0200, a ecrit: > > These are coming from unifont, so that's where we should be fixing it. > > I tried `dpkg -S filename` and it gives me console-setup-linux Yes, but the psf file in the console-setup-linux package is generated from the unifont package. (actually, not yet, but that's the long-term plan). Samuel
Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)
control: clone -1 -2 control: block -1 by -2 control: reassign -2 unifont control: retitle -2 unifont: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution) Hello, Pavlos Gkesos, le sam. 31 déc. 2022 18:06:20 +0200, a ecrit: > Greek characters μ ξ ζ γ appears UGLY. > I fix them and I provide the new Greek-Fixed16.psf.gz These are coming from unifont, so that's where we should be fixing it. Samuel
Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty
Παύλος Γκέσος, le jeu. 29 déc. 2022 23:37:21 +0200, a ecrit: > > Ah, you mean that currently, shift-w produces Sigma, but that's not > > actually useful, so we can just make it a dead key for ̈́? > > Exactly! > This is what Microsoft Windows does. > Probably the Windows kernel has the same limitation too :-) That's very probable, yes. Thanks for your very precise reports :) Samuel
Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty
Παύλος Γκέσος, le jeu. 29 déc. 2022 23:08:23 +0200, a ecrit: > > There is a workaround then. > > The Microsoft Windows workaround: > > > > Press key combination Shift-w (dead key for ΅) > > Press key y or i to get characters ΰ or ΐ. > > To certify what I said about Shift-w: > http://kbdlayout.info/kbdhe Ah, you mean that currently, shift-w produces Sigma, but that's not actually useful, so we can just make it a dead key for ̈́? Samuel
Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty
Hello, Παύλος Γκέσος, le jeu. 29 déc. 2022 23:02:55 +0200, a ecrit: > > Yes, unfortunately that's something that the Linux kernel does not > > support currently. It only supports one dead key press at a time. > > I never imagined that for dead keys there is code in the kernel. The whole Linux console is supported by the Linux kernel, there is no userland code involved except for loading fonts & keyboard layouts into the kernel. > There is a workaround then. > The Microsoft Windows workaround: > > Press key combination Shift-w (dead key for ΅) > Press key y or i to get characters ΰ or ΐ. > > These characters are very useful in the Greek language. > Also the implementation with the Shift-w key combination does not > break anything as: > key s gives char σ > key combination Shift-s gives char Σ > key w gives char ς > key combination Shift-w gives char Σ again I don't understand: in what you described, shift-w is used both for dead key for ΅ and for producing Σ ? Or did you mean shift-; above? Samuel
Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty
Hello, Παύλος Γκέσος, le mar. 27 déc. 2022 11:08:02 +0200, a ecrit: > The following functionality is not fixed: > > WHAT MUST HAPPEN: > Type KEY ; (in Greek is the CHAR "'") - This is a > "dead" key and nothing happens > Type KEY COMBINATION Shift-; (in Greek is the CHAR """) - This is a > "dead" key and nothing happens > Type KEY y (in Greek is the CHAR "υ"). The CHAR "ΰ" > must appear in tty (you have it with Alt+0944 key combination) Yes, unfortunately that's something that the Linux kernel does not support currently. It only supports one dead key press at a time. Samuel
Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty
Hello, Pavlos Gkesos, le dim. 25 déc. 2022 19:36:15 +0200, a ecrit: > I remember this annoying issue, in all Debian based distros, at least for the > last 7 years. Apparently it hasn't been reported for that much time, so... ;) > Type KEY a (in Greek is the CHAR "α"). Two CHARs "'α" appear in tty - WRONG! > (This is not 'α but ά) Oh, indeed, diacritics were completely broken with a newer perl version, and broken in utf-8 mode. I have fixed it in version 1.213. Samuel
Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2
Control: severity -1 important Hello, Michael Biebl, le lun. 17 oct. 2022 13:53:44 +0200, a ecrit: > Source: console-setup > Version: 1.210 > Tags: ftbfs 1.210 does actually build, it's +binnmu1 that doesn't, because + in the build path gets confused with file assembly on the command line: > umask 022; /<>/Fonts/bdf2psf --log > /<>/Fonts/Arabic-Fixed15.log > /<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf > /<>/Fonts/standard.equivalents \ I have now uploaded 1.211, which will thus fulfill your NMU need, and be able to propagate. Leaving this bug as important open since +something uploads are an important thing to support. Samuel
Bug#1020709: unifont doesn't ship unifont_jp.hex any more
Package: unifont Version: 1:15.0.01-1 Severity: important Tags: d-i Control: affects -1 + bterm-unifont Control: notfound 1:14.0.04-1 Hello, As of version 1:15.0.01-1, the unifont package is not shipping /usr/share/unifont/unifont_jp.hex any more, while it was shipping it in version 1:14.0.04-1. Could you restore it? This is making the current git tree of the bterm-unifont package fail to build: https://salsa.debian.org/installer-team/bterm-unifont/-/jobs/3293385 Samuel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unifont depends on: ii fonts-unifont 1:15.0.01-1 ii psf-unifont1:15.0.01-1 Versions of packages unifont recommends: ii xfonts-unifont 1:15.0.01-1 Versions of packages unifont suggests: ii unifont-bin 1:15.0.01-1 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Re: Add colemak keyboard layout
Hello, Holger Wansing, le sam. 24 sept. 2022 20:57:09 +0200, a ecrit: > Hi Robert, > > Am 24. September 2022 19:26:25 MESZ schrieb Robert Alm Nilsson > : > >Hi, I use the colemak keyboard layout but I'm not able to find a > >"colemak" option in the installer where you select keyboard layout. > >Currently every time I install Debian (which happens pretty often > >because I love this operating system) I have to use another keyboard > >layout during the installation and then set XKBVARIANT="colemak" in > >/etc/default/keyboard after the installation. It would be awesome > >to be able to use colemak from the start. I hope we can add that as > >an option. > > I fear, that the installer cannot support every existing cornercase, > as the Colemak layout is also a cornercase. As a complement: please read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698322 for an existing discussion about it, indeed. Samuel
Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers
Cyril Brulebois, le sam. 17 sept. 2022 02:21:27 +0200, a ecrit: > Samuel Thibault (2022-09-17): > > Cyril Brulebois, le sam. 17 sept. 2022 01:41:52 +0200, a ecrit: > > > > > > https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834 > > > > > > To get back on track with the release, I'm tempted to just revert that > > > commit right away, > > > > I have reverted it already :) > > > > Discussion is going on in the corresponding MR, > > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/24 > > At this point, I'm not really interested in diving in each and every > build-dep to figure out what makes sense and what doesn't. A partial > revert that doesn't document what it reverts and what it doesn't… All build-deps are reverted. The only pieces that I haven't reverted are the no-op for normal builds: + -o APT::Architecture=$deb_host_arch \\ -ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH) +ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH) Samuel
Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers
Hello, Cyril Brulebois, le sam. 17 sept. 2022 01:41:52 +0200, a ecrit: > > https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834 > > To get back on track with the release, I'm tempted to just revert that > commit right away, I have reverted it already :) Discussion is going on in the corresponding MR, https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/24 Samuel
Bug#1019009: console-setup-linux: missing compose sequences
Hello,
Jakub Wilk, le sam. 03 sept. 2022 09:45:50 +0200, a ecrit:
> Some compose sequences are not available on the console.
> For example, these two work in X:
>
> ' a = á
> s o = §
>
> But on the console, only the former works, even though "§" is supported
> by my font.
>From ckbcomp:
if ($charmap) {
my $file1 = "/etc/console-setup/compose.${charmap}.inc";
my $file2 = "$installdir/etc/console-setup/compose.${charmap}.inc";
if (-f $file1) {
system("cat $file1");
} elsif (-f $file2) {
system("cat $file2");
}
}
It looks as if the compose files are only included when a non-utf-8
charmap is used?
Perhaps additionally the per-locale compose file should be included?
(and by default, en_US.UTF-8)
Samuel
Re: creating log entries in the installer
Hello, Marc Haber, le lun. 22 août 2022 21:17:09 +0200, a ecrit: > Is logger(1) available in the installer? That looks so, see attached attempt. Samuel
Bug#1007929: netcfg: FTBFS on s390x
Control: tags -1 + pending
> Samuel Thibault wrote (Sun, 20 Mar 2022 01:01:07
> +0100):
> > Cyril Brulebois, le sam. 19 mars 2022 16:32:06 +0100, a ecrit:
> > > > Running suite(s): inet_mton
> > > > 95%: Checks: 24, Failures: 1, Errors: 0
> > > > test/test_netcfg_gateway_reachable.c:94:F:netcfg_gateway_reachable:test_netcfg_gateway_reachable_v6_fe80:0:
> > > > Gateway erroneously unreachable
> > > > make[1]: *** [test/tests.mk:19: test] Error 1
> > > > make[1]: Leaving directory '/<>'
> > > > dh_auto_test: error: make -j1 test returned exit code 2
> > > > make: *** [debian/rules:6: build-arch] Error 25
> > >
> > > Paging Samuel & Igor, hunch says this might be related:
> > >
> > > commit 3549f77c39c06e7dfcfd59fce01ff2d4a0622058
> > > Merge: 90e52aed 6bff2dee
> > > Author: Samuel Thibault
> > > Date: Sun Sep 5 14:59:46 2021 +
> > >
> > > Merge branch 'ipv6-link-local-gateway' into 'master'
> > >
> > > Add support for fe80::/10 addresses as IPv6 gateway, closes
> > > #901255
> > >
> > > See merge request installer-team/netcfg!3
> >
> > I committed
> >
> > -if ((ntohs(gw_addr.in6.s6_addr32[0]) & 0xffc0) == (0xfe80 &
> > 0xffc0)) {
> > +if ((ntohl(gw_addr.in6.s6_addr32[0]) & 0xffc0) == (0xfe80 &
> > 0xffc0)) {
> >
> > which is required for the test to work at all indeed. I guess that'll
> > just fix the issue.
>
> I intended to upload netcfg, but build still fails, apparently with the same
> error:
Oh, now I see it: it was indeed intended to be a ntohs since it's a
16bit value which it was compared to. It's the field name that was
bogus, now fixed.
Samuel
Bug#1012041: Patch: debian/control
Samuel Thibault, le mar. 31 mai 2022 08:41:24 +0200, a ecrit:
> Osamu Aoki, le mar. 31 mai 2022 14:39:03 +0900, a ecrit:
> > -Depends: ${misc:Depends}, liblocale-gettext-perl
> > +Depends: ${misc:Depends}, liblocale-gettext-perl, xkb-data (=
> > ${source:Version})
>
> source:Version is the version of the current source package, i.e.
> console-setup, not of the xkb-data package.
>
> Something like espeakup's ESPEAK_NG_VERSION definition then
> espeak-ng:Version definition needs to be used instead.
And the patch needs to be actually tested.
Samuel
Bug#1012041: Patch: debian/control
Control: tags -1 - patch
Osamu Aoki, le mar. 31 mai 2022 14:39:03 +0900, a ecrit:
> -Depends: ${misc:Depends}, liblocale-gettext-perl
> +Depends: ${misc:Depends}, liblocale-gettext-perl, xkb-data (=
> ${source:Version})
source:Version is the version of the current source package, i.e.
console-setup, not of the xkb-data package.
Something like espeakup's ESPEAK_NG_VERSION definition then
espeak-ng:Version definition needs to be used instead.
Samuel
Re: Skipping disk erase on Debian text-based installation (fwd)
Holger Wansing, le lun. 02 mai 2022 13:52:36 +0200, a ecrit: > Nick is right, if you perform an install with speech output, there is no > interactive possibility to cancel the full disk wipe action in the text > frontend used for speech! > In the newt frontend or graphical installer there is the Cancel button, > but not in the text frontend, sadly. That was fixed in cdebconf 0.261, one can just press control-C. Samuel
Re: Daily installer image FTBFS
Hello, Roland Clobus, le sam. 23 avril 2022 12:10:24 +0200, a ecrit: > The Depends line in control changed from: > Depends:·libc6-udeb·(>=·2.29),·libx11-6-udeb·(>=·2:1.6.0),·libxkbfile1-udeb > to > Depends:·libc6-udeb·(>=·2.33),·libx11-6-udeb·(>=·2:1.6.0),·libxkbfile1-udeb·(>=·1:1.1.0),·libxrandr2·(>=·2:1.5) > > Now the build complains about libxrandr2. > Should it have used 'libxrandr2-udeb' instead? Yes, it's on its way. Samuel
Re: Bug#1002508: readline: Please provide a udeb
Hello,
NEW was processed quickly :)
I have uploaded it to unstable.
Samuel
Samuel Thibault, le dim. 03 avril 2022 16:58:59 +0200, a ecrit:
> I have uploaded the attached changes to DELAYED/10 for experimental so
> its NEW processing doesn't interfere with maintenance.
>
> Samuel
>
> Samuel Thibault, le ven. 11 févr. 2022 02:01:45 +0100, a ecrit:
> > Hello,
> >
> > Is there any news on this? Perhaps I can just NMU?
> >
> > Samuel
> >
> > Samuel Thibault, le sam. 08 janv. 2022 18:21:28 +0100, a ecrit:
> > > Hello,
> > >
> > > I see that a newer upload of readline was done but without the proposed
> > > patch. Is there any problem with it? (attached here again)
> > >
> > > Having readline available would really make the installer a *lot* easier
> > > to handle for blind users.
> > >
> > > Samuel
> > >
> > > Samuel Thibault, le jeu. 23 déc. 2021 15:31:17 +0100, a ecrit:
> > > > So as to provide better support for the text installer for speakup-based
> > > > accessibility, we need libreadline in d-i. Here is a patch to add the
> > > > udeb build, could you apply it?
> > > >
> > > > Thanks,
> > > > Samuel
> >
> > > --- debian/control.original 2021-12-23 14:14:29.494489058 +0100
> > > +++ debian/control2021-12-23 15:03:01.596025090 +0100
> > > @@ -23,6 +23,21 @@
> > > The GNU history library provides a consistent user interface for
> > > recalling lines of previously typed input.
> > >
> > > +Package: libreadline8-udeb
> > > +Architecture: any
> > > +Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
> > > +Pre-Depends: ${misc:Pre-Depends}
> > > +Package-Type: udeb
> > > +Build-Profiles:
> > > +Section: debian-installer
> > > +Description: GNU readline and history libraries, run-time libraries (d-i)
> > > + The GNU readline library aids in the consistency of user interface
> > > + across discrete programs that need to provide a command line
> > > + interface.
> > > + .
> > > + The GNU history library provides a consistent user interface for
> > > + recalling lines of previously typed input.
> > > +
> > > Package: lib64readline8
> > > Architecture: i386 powerpc s390 sparc
> > > Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
> > > @@ -47,6 +62,21 @@
> > > The GNU readline library aids in the consistency of user interface
> > > across discrete programs that need to provide a command line
> > > interface.
> > > + .
> > > + The GNU history library provides a consistent user interface for
> > > + recalling lines of previously typed input.
> > > +
> > > +Package: readline-common-udeb
> > > +Architecture: all
> > > +Multi-Arch: foreign
> > > +Depends: ${misc:Depends}
> > > +Package-Type: udeb
> > > +Build-Profiles:
> > > +Section: debian-installer
> > > +Description: GNU readline and history libraries, common files (d-i)
> > > + The GNU readline library aids in the consistency of user interface
> > > + across discrete programs that need to provide a command line
> > > + interface.
> > > .
> > > The GNU history library provides a consistent user interface for
> > > recalling lines of previously typed input.
> > > --- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
> > > +++ debian/rules 2021-12-23 15:08:20.460279596 +0100
> > > @@ -17,6 +17,10 @@
> > > CROSS=gcc
> > > endif
> > >
> > > +ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
> > > + buildudeb = yes
> > > +endif
> > > +
> > > ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
> > >build64 = yes
> > >CC64 = $(CROSS) -m64
> > > @@ -69,9 +73,11 @@
> > > SHELL= bash
> > >
> > > p_rl = libreadline$(soversion)
> > > +p_rlu= libreadline$(soversion)-udeb
> > > p_rl32 = lib32readline$(soversion)
> > > p_rl64 = lib64readline$(soversion)
> > > p_comm = readline-common
> > > +p_commu = readline-common-udeb
> > > p_rld= libreadline-dev
> > > p_rld32 = lib32readline-dev
> > > p_rld64 = lib64readline-dev
> > > @@ -79,12 +85,15 @@
> > > p_rlfe = rlfe
> > >
> > > d= debian/tmp
> > > +du = debian/
Re: Having a d-i boot timeout for enabling speech?
Pascal Hambourg, le lun. 28 févr. 2022 08:40:12 +0100, a ecrit: > Le 13/02/2022 à 02:28, Samuel Thibault a écrit : > > the MacOS X installation image automatically starts > > a speech-enabled installer when the boot menu is left untouched for > > 10 seconds, so that blind people have really nothing more to do than > > plugging the installation USB key and turning the computer on to get a > > speaking installer > > > > It happens that syslinux supports this > > What about GRUB used for EFI boot ? I could not find a similar feature. Indeed :/ I have added a ticket on https://savannah.gnu.org/bugs/index.php?62254 Samuel
Re: Having a d-i boot timeout for enabling speech?
Hello, Philip Hands, le lun. 28 févr. 2022 09:31:04 +0100, a ecrit: > One could have a very prominent visual notice at the start of the speech > install pointing out to people that if they want a normal install all > they need to do is hit Ctrl-Alt-DEL to restart the boot, and then make > any sort of movement at the menu to interrupt the timeout speech > install. Actually syslinux allows to tune the timeout message, so I have done so. Thanks for the discussion, it's now pushed! Samuel
Re: Bug#1002508: readline: Please provide a udeb
Hello,
I have uploaded the attached changes to DELAYED/10 for experimental so
its NEW processing doesn't interfere with maintenance.
Samuel
Samuel Thibault, le ven. 11 févr. 2022 02:01:45 +0100, a ecrit:
> Hello,
>
> Is there any news on this? Perhaps I can just NMU?
>
> Samuel
>
> Samuel Thibault, le sam. 08 janv. 2022 18:21:28 +0100, a ecrit:
> > Hello,
> >
> > I see that a newer upload of readline was done but without the proposed
> > patch. Is there any problem with it? (attached here again)
> >
> > Having readline available would really make the installer a *lot* easier
> > to handle for blind users.
> >
> > Samuel
> >
> > Samuel Thibault, le jeu. 23 déc. 2021 15:31:17 +0100, a ecrit:
> > > So as to provide better support for the text installer for speakup-based
> > > accessibility, we need libreadline in d-i. Here is a patch to add the
> > > udeb build, could you apply it?
> > >
> > > Thanks,
> > > Samuel
>
> > --- debian/control.original 2021-12-23 14:14:29.494489058 +0100
> > +++ debian/control 2021-12-23 15:03:01.596025090 +0100
> > @@ -23,6 +23,21 @@
> > The GNU history library provides a consistent user interface for
> > recalling lines of previously typed input.
> >
> > +Package: libreadline8-udeb
> > +Architecture: any
> > +Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
> > +Pre-Depends: ${misc:Pre-Depends}
> > +Package-Type: udeb
> > +Build-Profiles:
> > +Section: debian-installer
> > +Description: GNU readline and history libraries, run-time libraries (d-i)
> > + The GNU readline library aids in the consistency of user interface
> > + across discrete programs that need to provide a command line
> > + interface.
> > + .
> > + The GNU history library provides a consistent user interface for
> > + recalling lines of previously typed input.
> > +
> > Package: lib64readline8
> > Architecture: i386 powerpc s390 sparc
> > Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
> > @@ -47,6 +62,21 @@
> > The GNU readline library aids in the consistency of user interface
> > across discrete programs that need to provide a command line
> > interface.
> > + .
> > + The GNU history library provides a consistent user interface for
> > + recalling lines of previously typed input.
> > +
> > +Package: readline-common-udeb
> > +Architecture: all
> > +Multi-Arch: foreign
> > +Depends: ${misc:Depends}
> > +Package-Type: udeb
> > +Build-Profiles:
> > +Section: debian-installer
> > +Description: GNU readline and history libraries, common files (d-i)
> > + The GNU readline library aids in the consistency of user interface
> > + across discrete programs that need to provide a command line
> > + interface.
> > .
> > The GNU history library provides a consistent user interface for
> > recalling lines of previously typed input.
> > --- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
> > +++ debian/rules2021-12-23 15:08:20.460279596 +0100
> > @@ -17,6 +17,10 @@
> > CROSS=gcc
> > endif
> >
> > +ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
> > + buildudeb = yes
> > +endif
> > +
> > ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
> >build64 = yes
> >CC64 = $(CROSS) -m64
> > @@ -69,9 +73,11 @@
> > SHELL = bash
> >
> > p_rl = libreadline$(soversion)
> > +p_rlu = libreadline$(soversion)-udeb
> > p_rl32 = lib32readline$(soversion)
> > p_rl64 = lib64readline$(soversion)
> > p_comm = readline-common
> > +p_commu= readline-common-udeb
> > p_rld = libreadline-dev
> > p_rld32= lib32readline-dev
> > p_rld64= lib64readline-dev
> > @@ -79,12 +85,15 @@
> > p_rlfe = rlfe
> >
> > d = debian/tmp
> > +du = debian/tmp-udeb
> > d32= debian/tmp32
> > d64= debian/tmp64
> > d_rl = debian/$(p_rl)
> > +d_rlu = debian/$(p_rlu)
> > d_rl32 = debian/$(p_rl32)
> > d_rl64 = debian/$(p_rl64)
> > d_comm = debian/$(p_comm)
> > +d_commu= debian/$(p_commu)
> > d_rld = debian/$(p_rld)
> > d_rld32= debian/$(p_rld32)
> > d_rld64= debian/$(p_rld64)
> > @@ -93,6 +102,7 @@
> >
> > srcdir = $(CURDIR)
> > builddir = $(CURDIR)/build
> > +builddiru = $(CURDIR)/buildudeb
> > builddir32 = $(CURDIR)/build32
Bug#1007929: netcfg: FTBFS on s390x
Control: tags -1 + pending
Hello,
Cyril Brulebois, le sam. 19 mars 2022 16:32:06 +0100, a ecrit:
> > Running suite(s): inet_mton
> > 95%: Checks: 24, Failures: 1, Errors: 0
> > test/test_netcfg_gateway_reachable.c:94:F:netcfg_gateway_reachable:test_netcfg_gateway_reachable_v6_fe80:0:
> > Gateway erroneously unreachable
> > make[1]: *** [test/tests.mk:19: test] Error 1
> > make[1]: Leaving directory '/<>'
> > dh_auto_test: error: make -j1 test returned exit code 2
> > make: *** [debian/rules:6: build-arch] Error 25
>
> Paging Samuel & Igor, hunch says this might be related:
>
> commit 3549f77c39c06e7dfcfd59fce01ff2d4a0622058
> Merge: 90e52aed 6bff2dee
> Author: Samuel Thibault
> Date: Sun Sep 5 14:59:46 2021 +
>
> Merge branch 'ipv6-link-local-gateway' into 'master'
>
> Add support for fe80::/10 addresses as IPv6 gateway, closes #901255
>
> See merge request installer-team/netcfg!3
I committed
-if ((ntohs(gw_addr.in6.s6_addr32[0]) & 0xffc0) == (0xfe80 & 0xffc0)) {
+if ((ntohl(gw_addr.in6.s6_addr32[0]) & 0xffc0) == (0xfe80 & 0xffc0)) {
which is required for the test to work at all indeed. I guess that'll
just fix the issue.
Samuel
Re: Bug#1006192: bullseye-pu: package espeak-ng/1.50+dfsg-7+deb11u1
Adam D. Barratt, le lun. 14 mars 2022 20:20:26 +, a ecrit: > On Mon, 2022-02-21 at 00:07 +0100, Samuel Thibault wrote: > > We tried to remove that sleep and it didn't seem to have any nasty > > side effect. Upstream did commit the change and users are really > > happy with the change that completely fixes the delay. > > Does this have any impact on the udeb? The same fix will be used there. d-i doesn't usually spit out large amounts of text so the problem was not really showing up there, the effect won't really be noticed. Samuel
Re: Bug#1006187: bullseye-pu: package espeakup/0.80-20+deb11u1
Adam D. Barratt, le lun. 14 mars 2022 20:19:02 +, a ecrit: > Control: tags -1 + confirmed d-i > > On Sun, 2022-02-20 at 21:35 +0100, Samuel Thibault wrote: > > Users have reported that when they are building large packages in > > parallel, or generally loading the system a bit, the espeakup screen > > reader becomes very laggy. This is because espeakup gets scheduled > > only along other the parallel processes. Worse, if the system goes > > OOM, espeakup might get killed by the OOM killer. > > > > This is not a regression with respect to previous releases. > > > > In the case of the brltty screen reader, we fixed this by making > > brltty niced to -10 and its OOM score set to -900. > > Does this have any impact on the udeb? No because in d-i espeakup is started by hand, the systemd service file is not installed in the .udeb. d-i doesn't usually start large amounts of process in parallel so it's not a problem there. Samuel
Bug#1006590: os-prober: Fail to install in BSD port: depends on mount not installable
Control: tags -1 + pending Hello, Lorenzo Puliti, le dim. 27 févr. 2022 19:30:57 -0600, a ecrit: > Could you please add in the control file freebsd-utils as an alternative > to mount ? I have commited it to my git tree, will push when alsa comes back. Samuel
Re: Possible to force installing from the mirror instead of the installation media?
Glen Huang, le lun. 21 févr. 2022 18:19:30 +0800, a ecrit: > @Geert > > It is "netinst" that you are looking for. > > I am using netinst. Appreciate the detailed steps listed, but with all > due respect, my question was about how to make the installer install > the base system from the mirror and not the installation media. The > listed steps don't seem to help with that. You can use netboot, which does not have any .deb file. Samuel
Bug#992699: debian-installer: Firmwares required for some sound cards
Control: reassign -1 debian-cd Hello, Cyril Brulebois, le dim. 22 août 2021 16:02:20 +0200, a ecrit: > Samuel Thibault (2021-08-22): > > As mentioned in the Bullseye errata, there seems to be a number of > > sound cards that require loading a firmware to be able to emit sound > > (e.g. Intel SOF). Unfortunately currently the installer loads firmware > > after loading the ISO image, while speech synthesis is needed at the > > very first interaction with the user, which is usually before that. We'd > > thus want (for the firmware-enabled image) to include firmware in the > > initrd somehow. > > For context, that's sof I was fighting with: > > https://tracker.debian.org/news/1245087/accepted-hw-detect-1147-source-into-unstable/ > > > We discussed a bit on IRC, possibly we could just, at debian-cd step, > > catenate the cpio archives, or unpack/assemble/repack, or ship several > > initrds. > > And once booted on my sof-enabled laptop, it starts speaking, so I > suppose that's a successful PoC; next step is to confirm whether > tweaking debian-cd to do the cat dance looks good to Steve as well. I had a try at adding support to debian-cd, I can up with this: https://salsa.debian.org/images-team/debian-cd/-/merge_requests/23 It actually follows the debian-edu way which uses cpio -oA to append content. That makes it simpler for anybody who would be trying to gunzip the initrd.gz Cyril, could you try on the actual hardware the resulting image: https://people.debian.org/~sthibault/tmp/debian-sid-amd64-NETINST-1.iso debian-cd people, could you have a look? It would be also very worth applying to the bullseye images. Samuel
Having a d-i boot timeout for enabling speech?
Hello,
Users on the debian-accessibility mailing list reported that they found
it very useful that the MacOS X installation image automatically starts
a speech-enabled installer when the boot menu is left untouched for
10 seconds, so that blind people have really nothing more to do than
plugging the installation USB key and turning the computer on to get a
speaking installer (and notably in the case when the computer does not
have a hardware speaker for beeping at the boot menu).
It happens that syslinux supports this, the attached patch implements
it. What do debian-boot people think about the idea?
Samuel
diff --git a/build/boot/x86/spk.cfg b/build/boot/x86/spk.cfg
index 7b5ee92af..13d51c8c6 100644
--- a/build/boot/x86/spk.cfg
+++ b/build/boot/x86/spk.cfg
@@ -2,3 +2,5 @@ label installspk
menu label Install with ^speech synthesis
kernel ${KERNEL}
append desktop=%desktop% ${VIDEO_MODE} initrd=${INITRD}
speakup.synth=soft --- quiet ${CONSOLE}
+timeout 100
+ontimeout ${KERNEL} desktop=%desktop% ${VIDEO_MODE} initrd=${INITRD}
speakup.synth=soft --- quiet ${CONSOLE}
diff --git a/build/boot/x86/spkgtk.cfg b/build/boot/x86/spkgtk.cfg
index d5bec168e..6391d4310 100644
--- a/build/boot/x86/spkgtk.cfg
+++ b/build/boot/x86/spkgtk.cfg
@@ -2,3 +2,5 @@ label installspk
menu label Install with ^speech synthesis
kernel ${KERNEL}
append desktop=%desktop% ${VIDEO_MODE} initrd=${INITRD_GTK}
speakup.synth=soft --- quiet ${CONSOLE}
+timeout 100
+ontimeout ${KERNEL} desktop=%desktop% ${VIDEO_MODE} initrd=${INITRD_GTK}
speakup.synth=soft --- quiet ${CONSOLE}
diff --git a/build/boot/x86/syslinux.cfg b/build/boot/x86/syslinux.cfg
index 7b2a1ce0d..2063f31d0 100644
--- a/build/boot/x86/syslinux.cfg
+++ b/build/boot/x86/syslinux.cfg
@@ -1,7 +1,7 @@
# D-I config version 2.0
# search path for the c32 support libraries (libcom32, libutil etc.)
path ${SYSDIR}
-include ${SYSDIR}menu.cfg
-default ${SYSDIR}vesamenu.c32
prompt 0
timeout 0
+include ${SYSDIR}menu.cfg
+default ${SYSDIR}vesamenu.c32
Re: Bug#1002508: readline: Please provide a udeb
Hello,
Is there any news on this? Perhaps I can just NMU?
Samuel
Samuel Thibault, le sam. 08 janv. 2022 18:21:28 +0100, a ecrit:
> Hello,
>
> I see that a newer upload of readline was done but without the proposed
> patch. Is there any problem with it? (attached here again)
>
> Having readline available would really make the installer a *lot* easier
> to handle for blind users.
>
> Samuel
>
> Samuel Thibault, le jeu. 23 déc. 2021 15:31:17 +0100, a ecrit:
> > So as to provide better support for the text installer for speakup-based
> > accessibility, we need libreadline in d-i. Here is a patch to add the
> > udeb build, could you apply it?
> >
> > Thanks,
> > Samuel
> --- debian/control.original 2021-12-23 14:14:29.494489058 +0100
> +++ debian/control2021-12-23 15:03:01.596025090 +0100
> @@ -23,6 +23,21 @@
> The GNU history library provides a consistent user interface for
> recalling lines of previously typed input.
>
> +Package: libreadline8-udeb
> +Architecture: any
> +Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
> +Pre-Depends: ${misc:Pre-Depends}
> +Package-Type: udeb
> +Build-Profiles:
> +Section: debian-installer
> +Description: GNU readline and history libraries, run-time libraries (d-i)
> + The GNU readline library aids in the consistency of user interface
> + across discrete programs that need to provide a command line
> + interface.
> + .
> + The GNU history library provides a consistent user interface for
> + recalling lines of previously typed input.
> +
> Package: lib64readline8
> Architecture: i386 powerpc s390 sparc
> Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
> @@ -47,6 +62,21 @@
> The GNU readline library aids in the consistency of user interface
> across discrete programs that need to provide a command line
> interface.
> + .
> + The GNU history library provides a consistent user interface for
> + recalling lines of previously typed input.
> +
> +Package: readline-common-udeb
> +Architecture: all
> +Multi-Arch: foreign
> +Depends: ${misc:Depends}
> +Package-Type: udeb
> +Build-Profiles:
> +Section: debian-installer
> +Description: GNU readline and history libraries, common files (d-i)
> + The GNU readline library aids in the consistency of user interface
> + across discrete programs that need to provide a command line
> + interface.
> .
> The GNU history library provides a consistent user interface for
> recalling lines of previously typed input.
> --- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
> +++ debian/rules 2021-12-23 15:08:20.460279596 +0100
> @@ -17,6 +17,10 @@
> CROSS=gcc
> endif
>
> +ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
> + buildudeb = yes
> +endif
> +
> ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
>build64 = yes
>CC64 = $(CROSS) -m64
> @@ -69,9 +73,11 @@
> SHELL= bash
>
> p_rl = libreadline$(soversion)
> +p_rlu= libreadline$(soversion)-udeb
> p_rl32 = lib32readline$(soversion)
> p_rl64 = lib64readline$(soversion)
> p_comm = readline-common
> +p_commu = readline-common-udeb
> p_rld= libreadline-dev
> p_rld32 = lib32readline-dev
> p_rld64 = lib64readline-dev
> @@ -79,12 +85,15 @@
> p_rlfe = rlfe
>
> d= debian/tmp
> +du = debian/tmp-udeb
> d32 = debian/tmp32
> d64 = debian/tmp64
> d_rl = debian/$(p_rl)
> +d_rlu= debian/$(p_rlu)
> d_rl32 = debian/$(p_rl32)
> d_rl64 = debian/$(p_rl64)
> d_comm = debian/$(p_comm)
> +d_commu = debian/$(p_commu)
> d_rld= debian/$(p_rld)
> d_rld32 = debian/$(p_rld32)
> d_rld64 = debian/$(p_rld64)
> @@ -93,6 +102,7 @@
>
> srcdir = $(CURDIR)
> builddir = $(CURDIR)/build
> +builddiru= $(CURDIR)/buildudeb
> builddir32 = $(CURDIR)/build32
> builddir64 = $(CURDIR)/build64
>
> @@ -111,6 +121,16 @@
> --host=$(DEB_HOST_GNU_TYPE) \
> --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
>
> +ifneq ($(buildudeb),)
> + rm -rf $(builddiru)
> + mkdir $(builddiru)
> + cd $(builddiru) && \
> + CFLAGS="$(CFLAGS) -Os" CPPFLAGS="$(CPPFLAGS)" $(srcdir)/configure \
> + --prefix=/usr\
> + --host=$(DEB_HOST_GNU_TYPE) \
> + --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> +endif
> +
> ifneq ($(build32),)
> rm -rf $(builddir32)
> mkdir $(builddir32)
> @@ -141,6 +161,14 @@
> SHOBJ_LDFLAGS='$(LDFLAGS) -shared' \
> SHLIB_LIB
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Holger Wansing, le mer. 09 févr. 2022 20:38:56 +0100, a ecrit: > >Now we have to wait for it to reach testing before submitting the > >changes for stable. > > If I remember correctly, there's a source-only upload needed for > tasksel to migrate to testing after the binary upload. Indeed. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Samuel Thibault, le dim. 06 févr. 2022 15:49:35 +0100, a ecrit: > Holger Wansing, le dim. 30 janv. 2022 14:44:18 +0100, a ecrit: > > Samuel Thibault wrote (Sun, 30 Jan 2022 14:26:52 > > +0100): > > > Holger Wansing, le dim. 30 janv. 2022 13:42:10 +0100, a ecrit: > > > > So, if I understand that correctly: > > > > - I do an upload to unstable now, which is then 3.69 > > > > > > Yes. > > > > I have prepared this upload in git now. > > During this, however, I noticed that I cannot do this upload myself, > > because it adds new packages to the archive (only task-* pseudo-packages, > > but new packages anyway), and so that requires an binary upload, which I > > am lacking permissions for. > > > > Therefore, could someone upload tasksel 3.69 for me, please? > > I have uploaded it. It's in! Now we have to wait for it to reach testing before submitting the changes for stable. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Hello, Holger Wansing, le dim. 30 janv. 2022 14:44:18 +0100, a ecrit: > Samuel Thibault wrote (Sun, 30 Jan 2022 14:26:52 > +0100): > > Holger Wansing, le dim. 30 janv. 2022 13:42:10 +0100, a ecrit: > > > So, if I understand that correctly: > > > - I do an upload to unstable now, which is then 3.69 > > > > Yes. > > I have prepared this upload in git now. > During this, however, I noticed that I cannot do this upload myself, > because it adds new packages to the archive (only task-* pseudo-packages, > but new packages anyway), and so that requires an binary upload, which I > am lacking permissions for. > > Therefore, could someone upload tasksel 3.69 for me, please? I have uploaded it. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Holger Wansing, le dim. 30 janv. 2022 14:44:18 +0100, a ecrit: > > I guess best would be 3.69~deb11u1, to say that it's essentially 3.69, > > but before 3.69 from bookworm. > > Hmm, my intention was to only bring one of the latest changings into stable > (the "install CUPS on desktop systems" part), not everything. Ok, then it's indeed a 3.68+deb11u1. But the change still has to have already migrated to testing. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Holger Wansing, le dim. 30 janv. 2022 13:42:10 +0100, a ecrit: > Samuel Thibault wrote (Sun, 30 Jan 2022 13:23:25 > +0100): > > In general 3.69 -> 3.68+deb11u1 update looks wrong, it has to be > > increasing :) Mmm, sorry, even if that's what caught my eye, this isn't an absolute rule. > Hmm, increasing is of course right. > However, I guessed this goes per distribution, so: > current version in stable is 3.68, that's why I chose 3.68deb11u1. > Looking at the version history in stable, that would be indeed an increase. > ? Yes, and that's usually what happens: we upload to stable some patched versions of what is already in stable. > So, if I understand that correctly: > - I do an upload to unstable now, which is then 3.69 Yes. > - Then I can upload to stable, which then gets 3.69deb11u1 > Would that be correct? It would have to be less that 3.69 actually, so that on upgrading to bookworm the package gets "upgraded" to 3.69. I guess best would be 3.69~deb11u1, to say that it's essentially 3.69, but before 3.69 from bookworm. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Hello, Holger Wansing, le dim. 30 janv. 2022 13:19:26 +0100, a ecrit: > Holger Wansing wrote (Sun, 30 Jan 2022 12:38:37 +0100): > > > > - Are there any restrictions for such procedere, like: only DDs with > > > > full > > > > upload rights can do that? > > > > Or could I do that for tasksel for example? Remember, I'm only DM, > > > > with > > > > upload rights for some selected packages (d-i related). > > > > > > IIRC DM can upload proposed-updates for their packages too. > > > > Ok, I will give it a try for tasksel then ;-) > > I have prepared tasksel in git for such upload (created a bullseye branch > + adapted the changelog entry with the needed version/upload-target). > > Could you take a look, if all is fine? debian-release wants proposals for stable to be already in testing, so notably the CUPS change has to get tested there first. In general 3.69 -> 3.68+deb11u1 update looks wrong, it has to be increasing :) Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Holger Wansing, le dim. 30 janv. 2022 11:59:18 +0100, a ecrit: > What's needs to happen now? > > I cannot do that for installation-guide anyway, but just for learning: > - Upload > - Uploading to which distribution is controlled by the entry in the > first line of debian/changelog, right? > What needs to be used there? "bullseye" - "stable" - ... - ? IIRC it's a normal stable-proposed-update, so that'd be bullseye. > - Anything else needed? I guess the scripts for the website will automatically get the version from bullseye, but TBH I don't remember :) > - Are there any restrictions for such procedere, like: only DDs with full > upload rights can do that? > Or could I do that for tasksel for example? Remember, I'm only DM, with > upload rights for some selected packages (d-i related). IIRC DM can upload proposed-updates for their packages too. Samuel
Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Holger Wansing, le dim. 30 janv. 2022 11:13:03 +0100, a ecrit: > Maybe we could backport these changings to bullseye manual too? > There is no "bookworm-only" material until now, and we have no bullseye > branch for the manual currently, probably it's a good time for that now? We can do that indeed. Samuel
Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation
D.J.J. Ring, Jr., le mar. 18 janv. 2022 03:28:07 -0500, a ecrit: > No, because the installer still might be selecting the wrong sound card, it's > usually the second choice, so even without sound I press enter to at least > choose something. Ah right. You can check what you ended up selecting with cat /var/run/espeakup.card Samuel
Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation
D.J.J. Ring, Jr., le lun. 17 janv. 2022 22:01:59 -0500, a ecrit: > Using firmware-10.11.0-amd64 installer, I gave this command: > > amixer -c 0 set IEC958,0 off > > I didn't get a response because my sound cards were renumbered. Ah, yes, sure. > So I changed the command to: > amixer -c 1 set IEC958,0 off > > This is the response I received. > > Simple mixer control 'IEC958',0 > Capabilities: pswitch pswitch-joined > Playback channels: Mono > Mono: Playback [off] And that didn't make espeakup start speaking? Samuel
Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation
Hello, Thanks for the information. D.J.J. Ring, Jr., le dim. 16 janv. 2022 22:12:29 -0500, a ecrit: > I already noticed something, in Buster, my digital card isn't listed > with the cat /proc/asound/cards command. Yes, that's because in the bullseye case you have used the mini.iso. As I wrote, please rather use the netinst bullseye iso image. The mini.iso image was only to check whether the presence of the i915 driver would help. > ## Output of amixer -c 0 scontents and amixer -c 1 scontents for the Bullseys > mini_amixer1contents > > > ## Output of amixer -c 0 scontents amixer -c 1 scontents and amixer -c 1 > 10.11.0_amixer1contents One thing I notice is this: Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] It's off in the Buster case and on in the Bullseye case. I guess you are not using the IEC958 output. Could you try running this inside the bullseye installer: amixer -c 0 sset IEC958,0 off samuel
Bug#1002976: Debian 11
D.J.J. Ring, Jr., le dim. 16 janv. 2022 21:44:55 -0500, a ecrit: > The mini iso just gave me an error that firmware was missing for my wifi - I > found the instructions on how to load firmware and put it in a FAT partition > on > USB stick in a directory named /firmware. No more error. That was not the question. Please *exactly* answer the question I am asking: *When* was this error precisely? Before or after the installer language question? That's the information I need, if you don't provide it we'll be unused what works and what doesn't work, and won't be able to fix the bug. Samuel
Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation
D.J.J. Ring, Jr., le dim. 16 janv. 2022 19:13:18 -0500, a ecrit: > Here's the message, i didn't include the bug address. Thanks, that helps a lot to record all information in the bug. So the syslog says that the binding with i915 went fine. But you said you didn't have sound, so that's not the problem. The next thing I can think of is dumping the output of these commands on a USB stick: cat /proc/asound/cards amixer -c 0 scontents amixer -c 1 scontents and doing so both when booting from the buster ISO image (so we can see how it looks like when things work), and when booting from the bullseye ISO image (so we can see how it looks like when things don't work). Samuel
