Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi, Dmitry Shachnev wrote (Fri, 22 Mar 2024 16:04:14 +0300): > On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote: > > [...] > > Anyway, the symlink points to some path inside the package build path, here: > > /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css > > > > and that path does not exist. > > Same in the debian-policy binary package. > > This is expected. The path in the build tree is relative in a way that when > a package is built and installed, it becomes working. Ok, I see. So, we will need to get sphinx-rtd-theme-common installed on all debian.org website mirrors, and it will just work (?) ... > The symlink is generated relative per Policy 10.5. And I think that even if > dh_sphinxdoc generated it as absolute, dh_link would later change it to > relative. > > If you are trying to rely on something that is in the build directory, you > have to turn relative symlinks into absolute ones on your own. Or just don't > call dh_sphinxdoc, then you will get normal files. ... or we switch away from dh_sphinxdoc. But there was already a hint, why this is a bad idea. Will need to be evaluated... Thanks for your time, guys! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi, Andrey Rakhmatullin wrote (Fri, 22 Mar 2024 15:50:26 +0500): > On Fri, Mar 22, 2024 at 11:29:11AM +0100, Holger Wansing wrote: > > > I cannot reproduce this. I downloaded debian-policy source package and > > > built > > > it in an up-to-date sid chroot. And the built package has this: > > > > > > $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css > > > lrwxrwxrwx root/root 0 2024-02-24 15:39 > > > ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> > > > ../../../../../sphinx_rtd_theme/static/css/theme.css > > > > But above output shows a filesize of 0B. > > Shouldn't that be something different? > Not for symlinks. Ok. > > Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any > > useful content, when you open it? > It's a symlink, it can't have content. > It's target does have content, as shown in the quote below: > > > > So, it is a symlink, not an empty file. When resolving the relative path, > > > I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file > > > exists in sphinx-rtd-theme-common and is non-empty. > > > if you open that theme.css file in the debian/debian-policy build path, > > does it have any content? > :-/ > > > Maybe it was bad wording, when I wrote > > "replaces files provided by read-the-doc theme by empty symlinks" in the > > subject of this bug. > > Probably "symlinks pointing to a not-existing file" is more correct? > To which non-existent files? Are they non-existent only when you don't > have sphinx-rtd-theme-common installed? Sure. > > I don't know where's the problem in detail, I only see that in the > > debian-policy binary package that file is empty, and therefore the html > > layout is broken. > It's not empty, it's a symlink that points to a non-existent (on your > system) file. > > > BTW: the same counts for all the symlinks under _static/fonts/: > > > > holgerw@t520:~/debian-policy$ ls -la > > policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/ > > total 64 > > drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 . > > drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 .. > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.eot -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.svg -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf > > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 fontawesome-webfont.woff -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff > > lrwxrwxrwx 1 holgerw holgerw 70 Mar 22 11:17 fontawesome-webfont.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2 > > lrwxrwxrwx 1 holgerw holgerw 64 Mar 22 11:17 Lato-BoldItalic.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf > > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 Lato-BoldItalic.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2 > > lrwxrwxrwx 1 holgerw holgerw 58 Mar 22 11:17 Lato-Bold.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf > > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Bold.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 > > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Italic.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf > > lrwxrwxrwx 1 holgerw holgerw 62 Mar 22 11:17 Lato-Italic.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2 > > lrwxrwxrwx 1 holgerw holgerw 61 Mar 22 11:17 Lato-Regular.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf > > lrwxrwxrwx 1 holgerw holgerw 63 Mar 22 11:17 Lato-Regular.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2 > > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2 > > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2 > > > > All those symlinks are pointing to a not-existing target here. > Only becau
Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi Dmitry,
Dmitry Shachnev wrote (Fri, 22 Mar 2024 00:35:57 +0300):
> I cannot reproduce this. I downloaded debian-policy source package and built
> it in an up-to-date sid chroot. And the built package has this:
>
> $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
> lrwxrwxrwx root/root 0 2024-02-24 15:39
> ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
> ../../../../../sphinx_rtd_theme/static/css/theme.css
But above output shows a filesize of 0B.
Shouldn't that be something different?
Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any
useful content, when you open it?
> So, it is a symlink, not an empty file. When resolving the relative path,
> I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
> exists in sphinx-rtd-theme-common and is non-empty.
As above:
if you open that theme.css file in the debian/debian-policy build path,
does it have any content?
If I open it here, nano shows "New file" in the status bar at the bottom,
so the file does not exist.
Maybe it was bad wording, when I wrote
"replaces files provided by read-the-doc theme by empty symlinks" in the
subject of this bug.
Probably "symlinks pointing to a not-existing file" is more correct?
> The only issue I see is that sphinx-rtd-theme-common is in Recommends of
> debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
> was put there.
>
> Am I doing something wrong?
I don't know where's the problem in detail, I only see that in the
debian-policy binary package that file is empty, and therefore the html
layout is broken.
BTW: the same counts for all the symlinks under _static/fonts/:
holgerw@t520:~/debian-policy$ ls -la
policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/
total 64
drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 .
drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 ..
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.eot ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.svg ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 fontawesome-webfont.woff ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
lrwxrwxrwx 1 holgerw holgerw 70 Mar 22 11:17 fontawesome-webfont.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2
lrwxrwxrwx 1 holgerw holgerw 64 Mar 22 11:17 Lato-BoldItalic.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf
lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 Lato-BoldItalic.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2
lrwxrwxrwx 1 holgerw holgerw 58 Mar 22 11:17 Lato-Bold.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Bold.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Italic.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf
lrwxrwxrwx 1 holgerw holgerw 62 Mar 22 11:17 Lato-Italic.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2
lrwxrwxrwx 1 holgerw holgerw 61 Mar 22 11:17 Lato-Regular.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
lrwxrwxrwx 1 holgerw holgerw 63 Mar 22 11:17 Lato-Regular.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2
lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 RobotoSlab-Bold.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 RobotoSlab-Regular.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2
All those symlinks are pointing to a not-existing target here.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Package: sphinx-common Severity: serious Hi, dh_sphinxdoc does not work well with read-the-doc theme, apparently. Debian policy document has switched to sphinx_rtd_theme recently (see https://salsa.debian.org/dbnpolicy/policy/-/commit/686622814018b5a121252b189d99c1968f332b78 ) However, the built document has a completely broken html layout, because many files under _static/ are empty (0B size), most noteably _static/css/theme.css. If I replace dh $@ --with sphinxdoc by dh $@ (so do not use dh_sphinxdoc), I get a valid html file with the theme in use. More details on that topic can be found in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064593 To get an idea of how it looks like, see https://www.debian.org/doc/debian-policy/ (however, there is also an issue with rtd theme on debian.org, that's why _static/css/ is completely missing there. That's an known issue, but we need a valid document in the debian-policy binary package first, to get the website problem fixed.) So long Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Hi, Colin Watson wrote (Thu, 8 Feb 2024 14:06:05 +): > On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote: > > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > > > Dumping the encoded keymaps for pc105... > > > WARNING: Can not find "caps_switch" in "group". > > > WARNING: Can not find "caps_toggle" in "group". > > > gzip -9n >/Keyboard/pc105.ekbd > > > >/<>/Keyboard/pc105.ekbd.gz > > > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such > > > file > > > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] > > > Error 2 > > > make[1]: Leaving directory '/<>' > > > make: *** [debian/rules:204: udeb-install] Error 2 > > > > > >Version 1.223 builds fine in unstable instead. Perhaps this is related > > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? > > > > What makes you think, that this has happened? > > > > There is a merge request that includes the removal of said package, > > but it has not yet been merged. > > It's not in git, but you appear to have built 1.224 from an unclean > source tree that had that patch applied. > > My inclination is to upload 1.225 without that patch for now, as we need > to rebuild for the new xkb-data to sort out uninstallability in > unstable, and then get the kFreeBSD-removal patch sorted out after that. Uhm, that was not my plan :-( Sorry for that. > Objections? None, of course. Will work that out. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > Dumping the encoded keymaps for pc105... > WARNING: Can not find "caps_switch" in "group". > WARNING: Can not find "caps_toggle" in "group". > gzip -9n >/Keyboard/pc105.ekbd > >/<>/Keyboard/pc105.ekbd.gz > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:204: udeb-install] Error 2 > >Version 1.223 builds fine in unstable instead. Perhaps this is related >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? What makes you think, that this has happened? There is a merge request that includes the removal of said package, but it has not yet been merged. Holger -- Sent from /e/ OS on Fairphone3
Bug#1026858: Dependency on debconf dropped prematurely
Control: tags -1 + pending Cyril Brulebois wrote (Thu, 22 Dec 2022 23:06:05 +0100): > Faidon Liambotis (2022-12-22): > > Going forward there are a few options: > > * Revert the change and depend on debconf again. This is the safest > > option, as this has been the status quo since 2007. > > That would look good to me. Fixed in git. -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#987441: Krita
Hi Lothar, Lothar Oelkers wrote (Fri, 18 Jun 2021 09:56:10 +0200): > Moin, > bin begeistert von bullseye. > Einzig Krita startet nicht nach korrekter Installation. > Nach apt remove qt5dxcd-plugin funktionieren alle Anwendungen. > Niemand vermisst das Paket. Please don't post such issues to this bug! This bug is only for problems regarding the debian-installer for Bullseye, not more. We don't want it to be flooded with diverse Bullseye issues. If you want to report an installation issue, please do so as documented here: https://d-i.debian.org/doc/installation-guide/de.amd64/apas04.html or post to debian-b...@lists.debian.org Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Hi, Chris Hofstaedtler wrote (Sun, 25 Apr 2021 14:13:05 +0200): > While the -exact- same bug does not appear on the > 20210424-7/amd64/iso-cd/debian-testing-amd64-netinst.iso image, I > think the bug is still there, just better hidden. > I managed to make debconf hang by: > - select Marathi > - on the next screen, click the Back button > - in the now appearing list, select something else (I think two > above from what was selected) > - click the Continue button > - hangs Yes, that way it is still reproducible with recent dailies or self-built images. Based on this, I have patched my build tree according https://people.debian.org/~holgerw/d-i/proposal-to-switch-g-i-to-fonts-noto/20200402/ to use noto fonts for all languages except CJK, and with the resulting netboot gtk mini.iso I am unable to make debconf hang, whatever I do! (including the above path) This might be a pointer, that this problem is indeed a font issue... Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Hi, Cyril Brulebois wrote (Sun, 25 Apr 2021 11:53:22 +0200): > Given the question below, I suppose you could revert this change > manually and restart the installer (after all, it's about a symlink and > a line in a config file). Sure. I did that already. But this does not gain any value, because building an image myself now without doing any changings leads to a working d-i (on i386, if arch matters) !!! I don't need to do anything to get a working d-i, just build myself. But why does the RC1 fail then? Holger > > However, I don't get it, why recent dailies are not affected, while > > RC1 (and alpha3) is ??? > > > > (That might be the reason, why this issue slipped through our > > attention until now...) > > > > Are there differences during build for the "release builds" (alpha, > > rc) compared to the dailies? > > You can check debian/rules for USE_UDEBS_FROM: > - releases fetch their udebs from testing; > - dailies fetch their udebs from unstable (to shorten the feedback >loop, and to inform our decision to let some packages migrate or not >when a freeze — udebs or otherwise — is in effect) > > You can switch to/from UNRELEASED in the first line of the changelog to > get the desired results. Or you can set the variable yourself if you run > something like this: > > make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=unstable > > > Cheers, > -- > Cyril Brulebois (k...@debian.org)<https://debamax.com/> > D-I release manager -- Release team member -- Freelance Consultant -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Hi, Chris Hofstaedtler wrote (Sat, 24 Apr 2021 23:45:13 +0200): > Hello, > > * Holger Wansing [210424 21:42]: > > While trying to debug another problem yesterday, I found that the RC1 > > graphical > > installer fails to go forward, when selecting one of these languages: > > - Kannada > > - Marathi > > - Persian > > - Sinhala > > I spent a few hours today on this issue, but did not get very far. > Not totally unexpected if you know nothing about the installer. > > I have, however, a perf top output to share. I believe this more or less means > the font rendering (pango, fontconfig) is stuck somehow? That might support my wild guess, that "Drop fontconfig tweaks" changings could be related. https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f However, I don't get it, why recent dailies are not affected, while RC1 (and alpha3) is ??? (That might be the reason, why this issue slipped through our attention until now...) Are there differences during build for the "release builds" (alpha, rc) compared to the dailies? CC'ing Steve for debian-cd side... Holger > Good luck, > Chris > > Samples: 82K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): > 4370334125 lost: 0/0 drop: 0/0 > Overhead Shared ObjectSymbol >5.29% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x13010 > d [.] pango_default_break >1.44% /lib/libharfbuzz.so.0.20704.00x769b0 > ! [.] 0x000769b0 >1.17% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x8487e > B [.] g_utf8_get_char >1.05% /lib/libharfbuzz.so.0.20704.00x57448 > ! [.] 0x00057448 >1.04% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x1fff2 > d [.] 0x0001fff2 >1.02% /lib/libharfbuzz.so.0.20704.00x8eff5 > ! [.] 0x0008eff5 >0.88% /lib/libharfbuzz.so.0.20704.00x611d0 > ! [.] 0x000611d0 >0.83% /lib/libharfbuzz.so.0.20704.00x5741e > ! [.] 0x0005741e >0.81% /lib/x86_64-linux-gnu/libc-2.31.so 0x88bbd > D [.] _int_malloc >0.80% /lib/libharfbuzz.so.0.20704.00x5a9f7 > ! [.] 0x0005a9f7 >0.79% /lib/libharfbuzz.so.0.20704.00x573d9 > ! [.] 0x000573d9 >0.71% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x3edd8 > B [.] g_hash_table_lookup >0.70% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0xf5a0 > d [.] g_utf8_get_char@plt >0.68% /lib/libharfbuzz.so.0.20704.00x573ee > ! [.] 0x000573ee >0.60% /lib/libharfbuzz.so.0.20704.00x5a830 > ! [.] 0x0005a830 >0.57% /lib/libharfbuzz.so.0.20704.00x71730 > ! [.] 0x00071730 >0.57% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x70590 > B [.] g_slice_free1 >0.56% /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.330x1e7883 > d [.] gtk_text_layout_get_line_display >0.55% /lib/libharfbuzz.so.0.20704.00x6a190 > ! [.] 0x0006a190 >0.52% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x34977 > d [.] pango_shape_with_flags >0.51% /lib/libharfbuzz.so.0.20704.00xc210 > ! [.] 0xc210 >0.51% /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8 0x18fff > B [.] g_object_unref >0.46% /lib/libharfbuzz.so.0.20704.00x578b2 > ! [.] 0x000578b2 >0.44% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x6ff70 > B [.] g_slice_alloc >0.43% /lib/x86_64-linux-gnu/libc-2.31
Bug#987441: debian-installer: D-I must get ready for Bullseye
Hi, Cyril Brulebois wrote (Fri, 23 Apr 2021 22:57:40 +0200): > Let's keep track of things that need to be looked at before D-I is > considered ready for the initial Bullseye release (11.0). > > Carried over from D-I Bullseye RC 1 errata: > - amdgpu firmware > - broken rescue mode Maybe add #987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages here? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Package: debian-installer Version: bullseye-rc1 Severity: grave While trying to debug another problem yesterday, I found that the RC1 graphical installer fails to go forward, when selecting one of these languages: - Kannada - Marathi - Persian - Sinhala (tested with rc1-netinst and -netboot image, on an amd64 qemu machine with 1G RAM) Installer hangs, with only displaying a headline and nothing more, eating up all CPU time. Interestingly, yesterday's daily does not have this problem, while RC1 has!!! And sadly it has not been discovered, that alpha3 is also affected, while alpha2 is fine! Yet another problem which started to appear with alpha3, just like "Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell" !!! The commit https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f "Drop fontconfig tweaks introduced in version 20170828 (See: #873462)" comes to my mind, also included in alpha3 ... ??? The text installer seems to be not affected (well, only Persian from the langs above is available in text installer, and Persian works there). We already have "Bug#983897: installation-reports: Installation in Uyghur hangs" where the installer hangs at some later steps - noticed for Uyghur and Kannada so far... Uyghur is however not affected by this language chooser fail bug. As already mentioned by Samuel, this may be another resurgence - in a tightened form - of "#929877: installation-reports: Buster installer hangs at hard disk step with arabic language" from 2019, where the real reason has not been found... -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#982035: Please consider reverting (i.e. re-adding dependency)
Control: tags 982043 + pending Helge Kreutzmann wrote (Thu, 25 Feb 2021 18:35:47 +0100): > Hello Paul, > hello Holger, > manpages-it comes back, just from a new source package > (manpages-l10n). The reason this was delayed is that I cannot get this > through NEW myself, as I'm only a Debian Maintainer, so I needed a > sponsor (Toddy is currently unavailable). This has been resolved, so > now manpages-it is on it's way through Testing. I received positive > signals from the release team that it will be accepted. > > Currently manpages-l10n (and with it manpages-it) still hast to wait 5 > more days, before it can enter testing. (So it is already in unstable) manpages-it is in testing now. I have re-added manpages-it to task-italian in tasksel (in git). Tagging #982043 as pending. This also draws a final line at #982035 now. > Please note, that manpages-l10n ships the following languages > currently, so you might check tasksel if it follows suit: > manpages-de > manpages-es > manpages-fr > manpages-it > manpages-mk > manpages-nl > manpages-pl > manpages-bt-BR > manpages-ro Missing in tasksel are currently: manpages-es manpages-mk manpages-nl manpages-bt-BR manpages-ro Are these in a good condition for stable? Should they be added to the respective language tasks? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box
Hi, Nobuhiro Iwamatsu wrote (Mon, 1 Mar 2021 06:00:51 +0900): > 2021年2月28日(日) 13:12 YOSHINO Yoshihito : > > > > Adding some Japanese input method to the ibus framework should work > > around the problem > > for Japanese users. Specifically, adding Recommends: ibus-mozc (or > > ibus-anthy on > > architectures where mozc is not available) to this package should work > > around the problem. > > The attached patch should apply the work-around. > > This patch seems to work for this issue. > I have confirmed that ibus-mozc is installed in the GNOME environment by > installing the tasksel/task-japanese-gnome-desktop packages with this patch > applied. May I ask how that interacts with the uim framework? We currently have Recommends: [...] uim, uim-mozc | uim-anthy, in task-japanese-desktop, so if you now add ibus-mozc | ibus-anthy to task-japanese-gnome-desktop, we will have both, uim-mozc and ibus-mozc installed on a Gnome system. Is that ok? Or does that cause any harm/conflict/what ever? Or did I got something wrong? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#982825: netcfg: FTBFS with current bullseye version
Package: netcfg Severity: critical Version: 1.169 While trying to upload a new version of netcfg, I found that current testing version of netcfg fails to build from source, in a stable sbuild environment as well as in an unstable one. The sbuild output (from a stable environment) is attached. I assume this is not a problem in netcfg itself, however I feel somewhat helpless in finding the real course. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 sbuild (Debian sbuild) 0.78.1 (09 February 2019) on t520 +==+ | netcfg 1.169 (amd64) Sun, 14 Feb 2021 22:53:03 + | +==+ Package: netcfg Version: 1.169 Source Version: 1.169 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: full I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-b9f0d463-46de-4f19-92ab-2dfa5cf97d07' with '<>' I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS/resolver-s1BpYp' with '<>' +--+ | Update chroot| +--+ Get:1 http://deb.debian.org/debian unstable InRelease [153 kB] Get:2 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB] Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB] Get:4 http://deb.debian.org/debian unstable/main Sources T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [19.6 kB] Get:4 http://deb.debian.org/debian unstable/main Sources T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [19.6 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [34.7 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [34.7 kB] Fetched 335 kB in 5s (69.7 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: libgcrypt20 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 563 kB of archives. After this operation, 1024 B of additional disk space will be used. Get:1 http://deb.debian.org/debian unstable/main amd64 libgcrypt20 amd64 1.8.7-3 [563 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 563 kB in 0s (2381 kB/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 15717 files and directories currently installed.) Preparing to unpack .../libgcrypt20_1.8.7-3_amd64.deb ... Unpacking libgcrypt20:amd64 (1.8.7-3) over (1.8.7-2) ... Setting up libgcrypt20:amd64 (1.8.7-3) ... Processing triggers for libc-bin (2.31-9) ... +--+ | Fetch source files | +--+ Local sources - /home/holgerw/test/netcfg-1.169/netcfg_1.169.dsc exists in /home/holgerw/test/netcfg-1.169; copying to chroot I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS/netcfg-1.169' with '<>' I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), libiw-dev (>= 27+28pre9), check, libsubunit-dev, build-essential, fakeroot Filtered Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), libiw-dev (>= 27+28pre9), check, libsubunit-dev, build-essential, fakeroot dpkg-deb: building package &#
Bug#982035: tasksel depends on man-pages-it which has been removed
Hi, Holger Wansing wrote: > I will file a new bug as a reminder, to re-add manpages-it to the > task-italian task again, when that package arrives in unstable. That's #982043 -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#982035: tasksel depends on man-pages-it which has been removed
Control: tags -1 + pending Paul Gevers wrote: > man-pages-it has been removed from unstable. Don't ask me how that is > possible as your package still depends on it, but it happened. Please > drop the dependency. The RM bug #979034 suggests the data now lives > elsewhere, albeit I don't know where. The data (italian translations) have been moved from manpages-it package to the manpages-l10n source-package (and translations updated). If manpages-l10n will be uploaded the next time from current git, manpages-it gets re-added to unstable again. Might not be in time for bullseye though... Because of that, I have removed manpages-it from tasksel depends for now. I will file a new bug as a reminder, to re-add manpages-it to the task-italian task again, when that package arrives in unstable. Tagging this bug as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hi, Andreas Henriksson wrote: > Hello Holger, > > On Tue, Oct 06, 2020 at 11:25:06PM +0000, Holger Wansing wrote: > > Hi, > > > > Am Dienstag, 6. Oktober 2020 schrieb Andreas Henriksson: > > > Could you please test rebuilding kbd with --enable-libkeymap to > > > --disable-libkeymap in debian/rules? > > > > sbuild fails when I try it like that. > > A build log is attached. > > Debugging this is somewhat out of my skills, sorry. > > I've uploaded a new version that implements the above suggestion > and would very much appreciate if you could test and give feedback > on where we ended up when you have chance to do so. I built a debian-installer image locally here and tested switching several keymaps there, and it looks as it works correctly now! Thanks Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hi, Am Dienstag, 6. Oktober 2020 schrieb Andreas Henriksson: > Could you please test rebuilding kbd with --enable-libkeymap to > --disable-libkeymap in debian/rules? sbuild fails when I try it like that. A build log is attached. Debugging this is somewhat out of my skills, sorry. Holger -- Sent from my Jolla phone http://www.jolla.com/ kbd_2.3.0-2_i386-2020-10-06T23.02.57Z.build Description: Binary data
Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Control: reopen -1 Switching keyboard in the text installer still fails! So reopening this bug. While debugging this, I executed /bin/setupcon in terminal (this is done by the installer in "Configure the keyboard" step). With --verbose option, I then get on /dev/tty1 executing printf. on /dev/tty2 executing printf. on /dev/tty3 executing printf. on /dev/tty4 executing printf. on /dev/tty5 executing printf. on /dev/tty6 executing printf. on /dev/tty1 executing kbd_mode -u. on /dev/tty2 executing kbd_mode -u. on /dev/tty3 executing kbd_mode -u. on /dev/tty4 executing kbd_mode -u. on /dev/tty5 executing kbd_mode -u. on /dev/tty6 executing kbd_mode -u. executing loadkeys /tmp/tmpbd.MBbsf loadkeys: error while loading shared libraries: libkeymap.so.1: cannot open shared object file. No such file or directory Thus keymap is not set. Please fix loadkeys in udeb. @installer-team: This error is only displayed, when using --verbose option, which is normally not set when running setupcon inside the installer. Without --verbose it just says "setupcon: gzip is not accessible. Will not save cached keyboard map." which seems an uncritical message. So, maybe we should set --verbose option by default, to un-hide such errors? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969965: Switching keyboard layouts broken in text installer (Was: Installation of Debian 11 mostly successfully)
Hi, Am Samstag, 19. September 2020 schrieb Holger Wansing: > I boiled that down to the latest version of kbd, which breaks console-setup > run > with mutiple error messages like this: > > > /bin/setupcon: > line 105: > kbd_mode: not found > > The images from https://d-i.debian.org/daily-images/amd64/20200820-00:20/ > work fine, and one day later it fails. > The new version of kbd was uploaded on 20200821. Comparing the 2.0.4 and 2.2.0 udebs, I see that /bin/kbd_mode was a binary executable in 2.0.4, and is only a wrapper script in 2.2.0, but the binary is missing in the udeb. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#969965: Switching keyboard layouts broken in text installer (Was: Installation of Debian 11 mostly successfully)
Hi, Am Samstag, 19. September 2020 schrieb Holger Wansing: > I boiled that down to the latest version of kbd, which breaks console-setup > run > with mutiple error messages like this: > > > /bin/setupcon: > line 105: > kbd_mode: not found > > The images from https://d-i.debian.org/daily-images/amd64/20200820-00:20/ > work fine, and one day later it fails. > The new version of kbd was uploaded on 20200821. Comparing the 2.0.4 and 2.2.0 udebs, I see that /bin/kbd_mode was a binary executable in 2.0.4, and is only a wrapper script in 2.2.0, but the binary is missing in the udeb. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#963755: Fix that worked for me
Hi, Ambroise Grau wrote: > Regarding Grub that noticed the Windows partition at installation, but did > not write > it on the boot table, a simple `update-grub` from the recovery mode fixed it, > and I > did not have to configure the menu.lst file as suggested in the FaQ > (https://wiki.debian.org/DebianInstaller/FAQ#Q:_What_do_I_do_if_I_can_no_longer_boot_Windows_after_installing_Debian.3F > > <https://wiki.debian.org/DebianInstaller/FAQ#Q:_What_do_I_do_if_I_can_no_longer_boot_Windows_after_installing_Debian.3F> > ). > > This therefore raises two questions from my part: > 1/ Is Grub not updated after writing the new boot loader to the MBR? Please provide the installer logs from /var/log/installer to allow for a detailed analysis. Thanks Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#964616: maint-guide: FTBFS: build-dependency not installable: libopencc2-data
Control: tags -1 + pending Lucas Nussbaum wrote: > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not > > installable > > E: Unable to correct problems, you have held broken packages. > > apt-get failed. Fixed in git. Tagging this bug as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#964674: debian-reference: FTBFS: build-dependency not installable: libopencc2-data
Control: tags -1 + pending Lucas Nussbaum wrote: > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not > > installable > > E: Unable to correct problems, you have held broken packages. > > apt-get failed. Fixed in git. Tagging this bug as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#939813: tasksel: selected packages marked for removal on apt full-upgrade
Control: tags -1 + moreinfo Hi, Jeremy Turnbull wrote (9 Sep 2019): > Package: tasksel > Version: 3.53 > Severity: critical > Justification: breaks unrelated software First of all, I wonder why this did not came to notice for such a long time. I thought RC bugs would trigger an automatic package removal from unstable, if not marked fixed for a longer time? > Dear Maintainer, > > The real packages that are installed from the metapackages that tasksel uses > will be marked for automatic removal after the next full system upgrade > because > neither the metapackages nor the real packages are marked as being manually > installed to apt, and the metapackages are not listed as dependent packages of > tasksel, which is the only one of these packages that is marked as being > manually installed. > > After upgrading from Debian 9.9 to 10.1, I had over 300 packages marked to be > automatically removed. Looking through the list, some of them were what I > would > consider as "core" packages to my desktop computing environment, packages like > LibreOffice, Firefox, and XFCE. I used 'apt install' to both mark some of > these > packages as being manually installed and to ensure that I was not missing any > new, dependent packages. The problem was, I missed that the network-manager > package was also marked as automatically installed and set to be removed, so > after my next 'apt autoremove' and system reboot, my system had no network > connection and was missing a lot of the packages necessary to create one. > > Luckily, I still had a Debian 9.5 installation thumb drive lying around and > was able to boot that into rescue mode and inject the network-manager package > into my root filesystem. However, actions such as this or knowing to > scrutinize > the list of packages marked for automatic removal are not behaviors that > should > be expected of normal users. The list of packages that automatically will be > removed should not break the system or remove core functionality. > > If possible, probably the easiest fix would be to ensure that packages tasksel > marks for installation are also marked as being manually installed to apt. The used concept of marking packages as manually or automatically installed follows a specific goal: to give the possibility to keep the system up-to-date, but - at the same time - get rid of no longer needed packages (say: remove cruft). >From your report I assume you installed a desktop environment task within the tasksel step of the installer. If you have selected the xfce desktop for example, that would lead to the package 'task-xfce-desktop' being directly installed, which then pulls lots of package in due to dependencies. This 'task-xfce-desktop' package would then be marked as manually installed, while all the dependencies would be marked as automatically installed. This way, all would work well so far, as long as this 'task-xfce-desktop' is installed and remains installed! Then, all the dependencies would remain installed too, since they are needed by the 'task-xfce-desktop' and that is not automatically removed, because it's set to 'manually installed'. Long story short: maybe that task package was removed on your system for whatever reason? In that case, it would be "correct" to remove many dependency packages. Or some other manual interaction has been done, to show such follow-ups? I have verified this via an installation of Stretch with xfce desktop, then upgraded to Buster, and all looks as described above: the 'task-..." package is still set to 'manually installed', most of the dependency packages are set to 'automatically installed' (comparing the list of automatically-installed packages from before and after the upgrade, there are only 7 packages removed from that set, and many more added to this set; that looks fine to me). When I now issue 'apt-get autoremove' it wants to remove 169 packages. With ~1400 packages installed after the dist-upgrade, I would count a cleanup of 169 packages not that unrealistic. And performing this autoremoval did not show any grave defects during a quick look. So, at the end, I fear without further information or installation/upgrade logs we are tempted to count this as unreproducible... Best regards Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#963450: Bug #963450: installation-guide: FTBFS: /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty: File `ctexhook.sty' not found.
Control: tags -1 + pending Lucas Nussbaum wrote (Sun, 21 Jun 2020 20:43:17 UTC): > Source: installation-guide > Version: 20191229+rebuild1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200620 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > Info: creating .pdf file... > xelatex failed > /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty: File > `ctexhook.sty' not found. > /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty:105: Emergency stop. > /usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty:105: leading text: > \AtBeginDocument > Unexpected error occured > Error: xelatex compilation failed > Error: build of pdf failed with error code 1 > Info: creating temporary .html file... > Info: creating .txt file... > Warning: The following formats failed to build: pdf > make[1]: *** [Makefile:8: ja.i386] Error 2 This bug did not show up on debian-boot ... texlive added additional Build-Depends somewhere in last versions for Chinese|Japanese|Korean PDFs (texlive-lang-chinese / texlive-lang-korean). Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961703 Fixed for installation-guide now. Tagging this bug as pending. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#963450: marked as pending in installation-guide
Control: tag -1 pending Hello, Bug #963450 in installation-guide reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/installer-team/installation-guide/-/commit/b418563b17831827fbff903c4489c0509c547911 texlive-lang-chinese: Additional Build-Depends for PDF in CJK languages to fix FTBFS (needed for texlive starting from v.2020; more info can be found in #961703). Closes: #963450 (this message was generated automatically) -- Greetings https://bugs.debian.org/963450
Bug#960056: src:tasksel: fails to migrate to testing for too long
Hi, Paul Gevers wrote: > Source: tasksel > Version: 3.58 > Severity: serious > Control: close -1 3.59 > Tags: sid bullseye > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), kibi, > > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:tasksel in > its current version in unstable has been trying to migrate for 60 days > [2]. Hence, I am filing this bug. This has already been noted on debian-boot some days ago. I fail to see what's the reason for this. We have some pending changings in git. Should I do another upload, to try to get this fixed? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954948: [d-i bullseye alpha2] Sinhala font missing
Jonas, many thanks for the quick fix! Holger Date: Thu, 26 Mar 2020 01:24:08 + From: "Debian Bug Tracking System" To: Holger Wansing Subject: Bug#954948 closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#954948: fixed in fonts-noto 20200323-1) This is an automatic notification regarding your Bug report which was filed against the fonts-noto package: #954948: [d-i bullseye alpha2] Sinhala font missing It has been closed by Debian FTP Masters (reply to Jonas Smedegaard ). -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954948: [d-i bullseye alpha2] Sinhala font missing
Control: reassign -1 fonts-noto Holger Wansing wrote: > Package: debian-installer > Severity: grave > > > While testing the alpha2 netinst image I noticed that the graphical installer > has no fonts for Sinhala anymore, this was ok until alpha1. > > Screenshots attached. > According to ../trunk/installer/build/pkg-lists/gtk-common d-i relies on 'fonts-noto-hinted-udeb' for Sinhala fonts. Looking into that package, the current version for sid/bullseye is lacking NotoSansSinhala-Bold.ttf NotoSansSinhala-Regular.ttf which exist in buster version. Did that font files moved to another udeb? Re-assigning to fonts-noto. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Control: severity -1 normal Control: retitle -1 [d-i bullseye alpha2 i386] Configuring 'grub-installer' failed with error code 134 Control: tags -1 + unreproducible Steve McIntyre wrote: > Hey Holger! > > On Fri, Mar 20, 2020 at 01:35:24PM +0100, Holger Wansing wrote: > >Steve McIntyre wrote: > >> > >> Hmmm. Can you try wiping the partition table in between tests? > > > >I already tried that on wednesday, with no success. > > > >However, today it does the trick! Success! > >Curious, but installation completed fine. > > > >Will see, if I can reproduce it again... > > ACK. I'm struggling to understand this otherwise. Hmm, this is getting annoying: while doing several test installs, I thought I had a path how to reproduce the issue, but then suddenly it looked completely different than before. So, that's something between "some portion of coincidence involved" and "wow, not it looks like a hardware failure". And since I was never able to reproduce the issue on amd64, it seems at least to be a i386-only issue, and thus could be considered as a corner case... Therefore reducing severity to normal and tagging as unreproducible + renaming to include the exact error message: "Configuring 'grub-installer' failed with error code 134" (leaving this bug open for a while, other people with the same problem may find it, and probably shade some light on it.) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Steve McIntyre wrote: > On Thu, Mar 19, 2020 at 12:42:48PM +0100, Holger Wansing wrote: > >Hi, > > > >Steve McIntyre wrote: > >> On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote: > >> >Hi, > >> > > >> >Steve McIntyre wrote: > >> >> One silly question: what media are you using with the Thinkpad? Is it > >> >> the same USB stick (or whatever) every time? Can you verify it's > >> >> written OK? > >> > > >> >I used the same USB stick for alpha1 and alpha2, re-flashing it over and > >> >over again. > >> >And I have checked installation media integrity with alpha2, it reports > >> >no error, "image is valid". > >> > >> Hmmm, OK. Wondering what's causing this then. I'll try another > >> installation test on a physical machine and get back to you. > > > >I noticed a difference between a alpha1 and alpha2 install on the Thinkpad: > >in alpha1 I get the message that the new Debian seems to be the only OS > >on the machine. However, on alpha2 install I did not get that message. > > > >But I see no relevant changing in os-prober between alpha1 and 2 which > >would explain that ... > > > >I wonder if it's a kernel issue somehow? > > Hmmm. Can you try wiping the partition table in between tests? I already tried that on wednesday, with no success. However, today it does the trick! Success! Curious, but installation completed fine. Will see, if I can reproduce it again... Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Steve McIntyre wrote: > On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote: > >Hi, > > > >Steve McIntyre wrote: > >> One silly question: what media are you using with the Thinkpad? Is it > >> the same USB stick (or whatever) every time? Can you verify it's > >> written OK? > > > >I used the same USB stick for alpha1 and alpha2, re-flashing it over and > >over again. > >And I have checked installation media integrity with alpha2, it reports > >no error, "image is valid". > > Hmmm, OK. Wondering what's causing this then. I'll try another > installation test on a physical machine and get back to you. I noticed a difference between a alpha1 and alpha2 install on the Thinkpad: in alpha1 I get the message that the new Debian seems to be the only OS on the machine. However, on alpha2 install I did not get that message. But I see no relevant changing in os-prober between alpha1 and 2 which would explain that ... I wonder if it's a kernel issue somehow? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Steve McIntyre wrote: > One silly question: what media are you using with the Thinkpad? Is it > the same USB stick (or whatever) every time? Can you verify it's > written OK? I used the same USB stick for alpha1 and alpha2, re-flashing it over and over again. And I have checked installation media integrity with alpha2, it reports no error, "image is valid". Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Holger Wansing wrote: > Hi, > > Holger Wansing wrote: > > Hi, > > > > Am Dienstag, 17. März 2020 schrieb Steve McIntyre: > > Yes, I had it with alpha2, then tested with alpha1 (everything > > fine) and then again tested with alpha2 to be able to > > provide logs. > > > > I can do further tests though, with different partitioning > > scheme or filesystem type... > > I tried different approaches (use only one ext4 partition + swap; use only one > ext2 partition + swap; use only one xfs partition + swap; create a complete > new parition table and then use only one ext4 partition + swap) and all fail > with the same error. > > Now I will test again with alpha1 to make sure it is no hardware issue... With alpha1 it succeeds without problems. So, there is something different with alpha2... Note, that this was i386, tested on a real machine (IBM Thinkpad)! Then I tested an alpha2 netinst amd64 image on QEMU, and it works fine! Need to find out where the difference is... Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Holger Wansing wrote: > Hi, > > Am Dienstag, 17. März 2020 schrieb Steve McIntyre: > Yes, I had it with alpha2, then tested with alpha1 (everything > fine) and then again tested with alpha2 to be able to > provide logs. > > I can do further tests though, with different partitioning > scheme or filesystem type... I tried different approaches (use only one ext4 partition + swap; use only one ext2 partition + swap; use only one xfs partition + swap; create a complete new parition table and then use only one ext4 partition + swap) and all fail with the same error. Now I will test again with alpha1 to make sure it is no hardware issue... Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Am Dienstag, 17. März 2020 schrieb Steve McIntyre: > On Tue, Mar 17, 2020 at 12:06:45PM +, Steve McIntyre wrote: > > > >I can see from your log that you're just using ext4 for the new > >system, and you're booting in BIOS mode. Any other disks attached to > >the system? > > > >Testing at the weekend didn't show any problems for me or Andy. I'm > >doing an explicit re-test now so I can check for any of the above > >messages in my log.s > > I don't see any mention of "corrupted size" in my log and thinks > seemed to run just fine. > > Is this problem repeatable for you? I'm wondering if it might be a > hardware problem or something... Yes, I had it with alpha2, then tested with alpha1 (everything fine) and then again tested with alpha2 to be able to provide logs. I can do further tests though, with different partitioning scheme or filesystem type... Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Am Dienstag, 17. März 2020 schrieb Steve McIntyre: > >Mar 16 09:55:43 main-menu[285]: (process:1258): grub-probe: error: unknown > >filesystem. > > I can see from your log that you're just using ext4 for the new > system, and you're booting in BIOS mode. Any other disks attached to > the system? No, just one SSD. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Am Dienstag, 17. März 2020 schrieb John Paul Adrian Glaubitz: > On 3/17/20 11:05 AM, Holger Wansing wrote: > > Logs attached. > > grub-installer did not report any problems: > > Mar 16 09:55:41 grub-installer: info: Installing grub on '/dev/sda' > Mar 16 09:55:41 grub-installer: info: grub-install does not support > --no-floppy > Mar 16 09:55:41 grub-installer: info: Running chroot /target grub-install > --force "/dev/sda" > Mar 16 09:55:41 grub-installer: Installing for i386-pc platform. > Mar 16 09:55:42 grub-installer: Installation finished. No error reported. > Mar 16 09:55:42 grub-installer: info: grub-install ran successfully However: > Mar 16 09:55:43 main-menu[285]: (process:1258): grub-probe: error: unknown > filesystem. [...] > Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size > Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted > Mar 16 09:55:43 main-menu[285]: WARNING **: Configuring 'grub-installer' > failed with error code 134 > Mar 16 09:55:43 main-menu[285]: WARNING **: Menu item 'grub-installer' failed. -- Sent from my Jolla phone http://www.jolla.com/
Bug#954134: [d-i bullseye alpha2] installing grub fails
Hi, Holger Wansing wrote: > > > > I will sent installation logs shortly. > > Logs attached. The relevant part seems to be: Mar 16 09:55:41 grub-installer: info: Installing grub on '/dev/sda' Mar 16 09:55:41 grub-installer: info: grub-install does not support --no-floppy Mar 16 09:55:41 grub-installer: info: Running chroot /target grub-install --force "/dev/sda" Mar 16 09:55:41 grub-installer: Installing for i386-pc platform. Mar 16 09:55:42 grub-installer: Installation finished. No error reported. Mar 16 09:55:42 grub-installer: info: grub-install ran successfully Mar 16 09:55:42 in-target: Reading package lists... Mar 16 09:55:42 in-target: Mar 16 09:55:42 in-target: Building dependency tree... Mar 16 09:55:42 in-target: Mar 16 09:55:42 in-target: Reading state information... Mar 16 09:55:42 in-target: Mar 16 09:55:42 in-target: grub-common is already the newest version (2.04-5). Mar 16 09:55:42 in-target: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted Mar 16 09:55:43 main-menu[285]: (process:1258): File descriptor 3 (pipe:[11552]) leaked on lvdisplay invocation. Mar 16 09:55:43 main-menu[285]: (process:1258): Parent PID 1549: /bin/sh Mar 16 09:55:43 main-menu[285]: (process:1258): File descriptor 4 (/dev/pts/0) leaked on lvdisplay invocation. Mar 16 09:55:43 main-menu[285]: (process:1258): Parent PID 1549: /bin/sh Mar 16 09:55:43 main-menu[285]: (process:1258): File descriptor 5 (/dev/pts/0) leaked on lvdisplay invocation. Mar 16 09:55:43 main-menu[285]: (process:1258): Parent PID 1549: /bin/sh Mar 16 09:55:43 main-menu[285]: (process:1258): File descriptor 6 (/dev/pts/0) leaked on lvdisplay invocation. Mar 16 09:55:43 main-menu[285]: (process:1258): Parent PID 1549: /bin/sh Mar 16 09:55:43 main-menu[285]: (process:1258): Mar 16 09:55:43 main-menu[285]: (process:1258): Volume group "sda" not found Mar 16 09:55:43 main-menu[285]: (process:1258): Cannot process volume group sda Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): grub-probe: error: unknown filesystem. Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted Mar 16 09:55:43 main-menu[285]: WARNING **: Configuring 'grub-installer' failed with error code 134 Mar 16 09:55:43 main-menu[285]: WARNING **: Menu item 'grub-installer' failed. Mar 16 09:55:44 main-menu[285]: INFO: Modifying debconf priority limit from 'high' to 'medium' Mar 16 09:55:44 debconf: Setting debconf/priority to medium -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#954134: [d-i bullseye alpha2] installing grub fails
Holger Wansing wrote: > > I will sent installation logs shortly. Logs attached. -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 installer.tar.gz Description: application/gzip
Bug#954134: [d-i bullseye alpha2] installing grub fails
Package: debian-installer Severity: grave While testing the alpha2 netinst image on a spare Thinkpad, I found that grub cannot be installed successfully (and rebooting into the new installation fails as well). This was ok in alpha1. This might look like an grub-installer issue, however there were only trivial installation update releases since alpha1, so I suspect it's not in issue in grub-installer. Therefore I file this against debian-installer. I will sent installation logs shortly. Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#952279: installation-guide: FTBFS: mkdir: cannot create directory ‘build.tmp.el.amd64/dblatex/mt7706.tmp’: No such file or directory
Hi, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 > > tcrm1000 > > mkdir: cannot create directory ‘build.tmp.el.i386/dblatex/mt7684.tmp’: No > > such file or directory > > kpathsea: Appending font creation commands to missfont.log. > > > > xdvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF > > output... > > > > No output PDF file written. > > xelatex failed > > Unexpected error occured > > Error: xelatex compilation failed > > Error: build of pdf failed with error code 1 > > Info: creating temporary .html file... > > > > kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 > > tcrm1000 > > mkdir: cannot create directory ‘build.tmp.el.amd64/dblatex/mt7706.tmp’: No > > such file or directory > > kpathsea: Appending font creation commands to missfont.log. > > > > xdvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF > > output... > > > > No output PDF file written. > > xelatex failed > > Unexpected error occured > > Error: xelatex compilation failed > > Error: build of pdf failed with error code 1 > > Info: creating temporary .html file... > > Info: creating .txt file... > > Warning: The following formats failed to build: pdf > > make[1]: *** [Makefile:8: el.i386] Error 2 Together with Norbert Preining, we have boiled this down to some problems in the babel greek driver. This is tracked in 952481. Norbert provided a patch, which introduces a workaround to fix the build for now. I will apply that shortly, since I'm unsure how long it will take to really fix things. However, it still leaves a problem open with broken text in the Greek manual (in appendix GPL), which is caused by another problem (broken xml->TeX conversion outside of TeX, done by dblatex). Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#948801: refcard: FTBFS: pdfjoin: Command not found
Control: tags -1 + pending Mattia Rizzolo wrote: > Source: refcard > Version: 10.5 > Severity: serious > Tags: ftbfs > > Dear maintainer, > > during a rebuild in a standard sid chroot, your package failed to build: [...] > pdfjoin --vanilla --fitpaper true --outfile refcard-en-lt.s.pdf.x.pdf > refcard-en-lt.s.pdf empty.pdf empty.pdf > make[2]: pdfjoin: Command not found > make[2]: *** [Makefile:64: refcard-en-lt.t.pdf] Error 127 > make[2]: *** Waiting for unfinished jobs Fixed in git. Tagging this bug as pending. Thanks Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#749991: Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package
Control: tags 749991 + pending Control: tags 367515 + pending Ben Hutchings wrote: > On Tue, 2019-11-05 at 22:17 +0100, Holger Wansing wrote: > [...] > > I just noticed that the relevant message currently appears with netinst > > image, > > too (because build badly broken). > > > > So, maybe we should not restrict the above proposed changing to the > > "netboot" > > installation method? > > (means: skipping the "check if you are using an up-to-date netboot image" > > part) > > That seems reasonable. Ok. Now committed. Tagging bugs as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#749991: Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package
Hi, Holger Wansing wrote: > That looks reasonable. > I have prepared a proposal for this: > > > snip === > > diff --git a/debian/anna.templates b/debian/anna.templates > index 66677ee..3709584 100644 > --- a/debian/anna.templates > +++ b/debian/anna.templates > @@ -66,14 +66,14 @@ Template: anna/no_kernel_modules > Type: boolean > Default: false > # :sl2: > -_Description: Continue the install without loading kernel modules? > +_Description: No kernel modules found > No kernel modules were found. This probably is due to a mismatch between > the kernel used by this version of the installer and the kernel version > available in the archive. > . > - If you're installing from a mirror, you can work around this problem by > - choosing to install a different version of Debian. The install will probably > - fail to work if you continue without kernel modules. > + You should make sure that your installation image is current (check if you > + are using an up-to-date netboot image), or - if that's the case - try a > + different mirror, preferably deb.debian.org. > > Template: anna/retriever > Type: string I just noticed that the relevant message currently appears with netinst image, too (because build badly broken). So, maybe we should not restrict the above proposed changing to the "netboot" installation method? (means: skipping the "check if you are using an up-to-date netboot image" part) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#749991: debian-installer: Wrong kernel in debian-installer package
Hi,
Ben Hutchings wrote:
> > That looks reasonable.
> > I have prepared a proposal for this:
>
> The new text looks good to me.
>
> [...]
> > > Also, this should be an error message, not a question.
> >
> > For this, I would need some help, since I'm lacking the needed skills there.
> > The relevant part of anna.c seems to be:
> []
> > if (!kernel_packages_present) {
> > di_log(DI_LOG_LEVEL_WARNING, "no packages matching running
> > kernel %s in archive", running_kernel);
> > #ifdef __GNU__
> > /* GNU Mach does not have modules */
> > #else
> > debconf_input(debconf, "critical", "anna/no_kernel_modules");
> > if (debconf_go(debconf) == 30)
> > return 0;
> > debconf_get(debconf, "anna/no_kernel_modules");
> > if (strcmp(debconf->value, "false") == 0)
> > return 0;
>
> I think that for an error message the above 5 lines (after
> debconf_input(...)) can be changed to:
>
> debconf_go(debconf);
> return 0;
A patch is attached.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
diff --git a/anna.c b/anna.c
index e03d34a..3e4552f 100644
--- a/anna.c
+++ b/anna.c
@@ -57,11 +57,8 @@ int packages_ok (di_packages *packages) {
/* GNU Mach does not have modules */
#else
debconf_input(debconf, "critical", "anna/no_kernel_modules");
- if (debconf_go(debconf) == 30)
- return 0;
- debconf_get(debconf, "anna/no_kernel_modules");
- if (strcmp(debconf->value, "false") == 0)
- return 0;
+ debconf_go(debconf);
+ return 0;
#endif
}
diff --git a/debian/anna.templates b/debian/anna.templates
index 66677ee..1c95573 100644
--- a/debian/anna.templates
+++ b/debian/anna.templates
@@ -63,17 +63,16 @@ _Description: Failed to load installer component
Loading ${PACKAGE} failed for unknown reasons. Aborting.
Template: anna/no_kernel_modules
-Type: boolean
-Default: false
+Type: error
# :sl2:
-_Description: Continue the install without loading kernel modules?
+_Description: No kernel modules found
No kernel modules were found. This probably is due to a mismatch between
the kernel used by this version of the installer and the kernel version
available in the archive.
.
- If you're installing from a mirror, you can work around this problem by
- choosing to install a different version of Debian. The install will probably
- fail to work if you continue without kernel modules.
+ You should make sure that your installation image is current (check if you
+ are using an up-to-date netboot image), or - if that's the case - try a
+ different mirror, preferably deb.debian.org.
Template: anna/retriever
Type: string
diff --git a/debian/changelog b/debian/changelog
index 806f59e..b2671e2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+anna (1.73) UNRELEASED; urgency=medium
+
+ * Change template, to give a senseful message to the user, when no kernel
+modules can be found with netboot image. Also, turn that from a question
+into an error message.
+
+ -- Holger Wansing Fri, 01 Nov 2019 22:52:30 +0100
+
anna (1.72) unstable; urgency=medium
* Team upload
Bug#749991: debian-installer: Wrong kernel in debian-installer package
Hi,
Ben Hutchings wrote:
> On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
> > Bugreport against kernel version mismatch, when using outdated or broken
> > netboot images:
> >
> >
> > Since it's unlikely that we completely prevent this issue to happen, maybe
> > we
> > could at least change the error message, saying that the user should try
> > another / a newer installation image?
> > (as already suggested in bug#367515)
> >
> > It would be a good time for such template changing now...
> > Patch attached.
>
> I feel that we ought to give a more definite answer, instead of "you
> can try" and "will probably fail". I don't think that "choosing to
> install a different version of Debian" is likely to be a useful answer
> very often, and continuing without kernel modules is definitely going
> to fail.
>
> If I understood correctly, this message can only appear when using a
> netboot image, and can be caused by either (a) old netboot image or (b)
> broken mirror. If that's right, we should recommend (a) make sure your
> netboot image is current (b) if it is, then try another mirror,
> recommending deb.debian.org.
That looks reasonable.
I have prepared a proposal for this:
snip ===
diff --git a/debian/anna.templates b/debian/anna.templates
index 66677ee..3709584 100644
--- a/debian/anna.templates
+++ b/debian/anna.templates
@@ -66,14 +66,14 @@ Template: anna/no_kernel_modules
Type: boolean
Default: false
# :sl2:
-_Description: Continue the install without loading kernel modules?
+_Description: No kernel modules found
No kernel modules were found. This probably is due to a mismatch between
the kernel used by this version of the installer and the kernel version
available in the archive.
.
- If you're installing from a mirror, you can work around this problem by
- choosing to install a different version of Debian. The install will probably
- fail to work if you continue without kernel modules.
+ You should make sure that your installation image is current (check if you
+ are using an up-to-date netboot image), or - if that's the case - try a
+ different mirror, preferably deb.debian.org.
Template: anna/retriever
Type: string
snap ===
> Also, this should be an error message, not a question.
For this, I would need some help, since I'm lacking the needed skills there.
The relevant part of anna.c seems to be:
snip ===
/* Go through the available packages to see if it contains at least
* one package that is valid for the subarchitecture and corresponds
* to the kernel version we are running */
int packages_ok (di_packages *packages) {
di_slist_node *node;
di_package *package;
bool kernel_packages_present = false;
for (node = packages->list.head; node; node = node->next) {
package = node->data;
if (!di_system_package_check_subarchitecture(package,
subarchitecture))
continue;
if (((di_system_package *)package)->kernel_version) {
if (running_kernel &&
strcmp(running_kernel, ((di_system_package
*)package)->kernel_version) == 0) {
kernel_packages_present = true;
break;
}
}
}
if (!kernel_packages_present) {
di_log(DI_LOG_LEVEL_WARNING, "no packages matching running
kernel %s in archive", running_kernel);
#ifdef __GNU__
/* GNU Mach does not have modules */
#else
debconf_input(debconf, "critical", "anna/no_kernel_modules");
if (debconf_go(debconf) == 30)
return 0;
debconf_get(debconf, "anna/no_kernel_modules");
if (strcmp(debconf->value, "false") == 0)
return 0;
#endif
}
return 1;
}
snap ===
I assume, just turning
= snip
Template: anna/no_kernel_modules
Type: boolean
Default: false
# :sl2:
_Description: Continue the install without loading kernel modules?
= snap
into
= snip
Template: anna/no_kernel_modules
Type: error
# :sl2:
_Description: No kernel modules found
= snap
is not enough here?
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#749991: debian-installer: Wrong kernel in debian-installer package
Bugreport against kernel version mismatch, when using outdated or broken netboot images: Since it's unlikely that we completely prevent this issue to happen, maybe we could at least change the error message, saying that the user should try another / a newer installation image? (as already suggested in bug#367515) It would be a good time for such template changing now... Patch attached. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/debian/anna.templates b/debian/anna.templates index 66677ee..dd9e49f 100644 --- a/debian/anna.templates +++ b/debian/anna.templates @@ -72,8 +72,12 @@ _Description: Continue the install without loading kernel modules? available in the archive. . If you're installing from a mirror, you can work around this problem by - choosing to install a different version of Debian. The install will probably - fail to work if you continue without kernel modules. + choosing to install a different version of Debian. + . + You can also try to use another/a newer installation image. + . + The install will probably fail to work if you continue without kernel + modules. Template: anna/retriever Type: string
Bug#932258: console-setup-freebsd: missing dependency
Hi, Cyril Brulebois wrote: > Héctor Orón Martínez (2019-07-17): > > Package: console-setup-freebsd > > Version: 1.191 > > Severity: grave > > > > > > Dear Maintainer, > > > > console-setup-freebsd has a dependency on vidcontrol, which is not > > part of buster|bullseye|unstable, and causes the package to be > > uninstallable. > > Adding debian-bsd@ to the loop for advise. The same counts for kbdcontrol, also not existing in all suites. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#927165: [pkg-cryptsetup-devel] Bug#927165: debian-installer: improve support for LUKS
Hi, Am Mittwoch, 3. Juli 2019 schrieb Cyril Brulebois: > Don't worry about the delay, I'm very happy to merge this now, and have > an opportunity to backport it in a point release later on. If I got the > process right, having the changes in master should trigger an update of > pot/po files by the l10n robot, and translators will be able to catch up > in a couple of hours. Yes, that assumption is correct, the update of po files will happen automatically this night. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, ButterflyOfFire wrote: > Hi, > I think it is okay for those diacritics. > Regards, I have uploaded that fix now. Leaving this bug open as a reminder for the "real" problem inside of gtk (?) Holger > ‐‐‐ Original Message ‐‐‐ > Le mardi 18 juin 2019 22:26, Holger Wansing a écrit : > > > Hi, > > > > Samuel Thibault sthiba...@debian.org wrote: > > > > > Hello, > > > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > > > > > > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > > > > > > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > > > > > > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > > > > > > > > > > > > "لاحقاً" > > > > > > > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > > > > > > > That avoids the issue here indeed. I however see it used in various > > > > > > > > > > Hmm. > > > > > There has been no changing in the ar.po of partman-auto > > > > > for 3 years now (JFTR), thus the real problem seems to be > > > > > sitting somewhere else ... > > > > > > > > How should we proceed here? > > > > Since we are late in the freeze, and it's most probably not that > > > > easy to find out what happened and what the real issue is: > > > > should we go with the "work-around" proposed by > > > > Butterflyoffire and confirmed to fix the issue by Samuel? > > > > > > Personally, I don't think I'll have the time to debug what is actually > > > happening inside gtk until the release, so even if it's ugly, I guess > > > the browntape fix is the least worst I can come up with. > > > > That looks fair. > > I have committed the proposed fix now. > > > > @butterflyoffire: could you please take a look at > > https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7 > > to double-check if the fix is fine by you? > > Thanks! > > > > Holger > > > > > > - > > > > Holger Wansing hwans...@mailbox.org > > PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 > > -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, Samuel Thibault wrote: > Hello, > > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > > >> "لاحقاً" > > > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > > > That avoids the issue here indeed. I however see it used in various > > > > > > Hmm. > > > There has been no changing in the ar.po of partman-auto > > > for 3 years now (JFTR), thus the real problem seems to be > > > sitting somewhere else ... > > > > How should we proceed here? > > Since we are late in the freeze, and it's most probably not that > > easy to find out what happened and what the real issue is: > > should we go with the "work-around" proposed by > > Butterflyoffire and confirmed to fix the issue by Samuel? > > Personally, I don't think I'll have the time to debug what is actually > happening inside gtk until the release, so even if it's ugly, I guess > the browntape fix is the least worst I can come up with. That looks fair. I have committed the proposed fix now. @butterflyoffire: could you please take a look at https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7 to double-check if the fix is fine by you? Thanks! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > Hi, > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > >> "لاحقاً" > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > That avoids the issue here indeed. I however see it used in various > > Hmm. > There has been no changing in the ar.po of partman-auto > for 3 years now (JFTR), thus the real problem seems to be > sitting somewhere else ... How should we proceed here? Since we are late in the freeze, and it's most probably not that easy to find out what happened and what the real issue is: should we go with the "work-around" proposed by Butterflyoffire and confirmed to fix the issue by Samuel? Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > >> "لاحقاً" > > > > This word means "later" and can be replaced by "لاحقا". > > That avoids the issue here indeed. I however see it used in various Hmm. There has been no changing in the ar.po of partman-auto for 3 years now (JFTR), thus the real problem seems to be sitting somewhere else ... Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
While ButterflyOfFire reported to be unable to reproduce this, I can indeed reproduce this with qemu here. Looking more closely, that bug is there for me with the rc1 installer, however not with the alpha5 one. So, that would come down to this two commits (if it's a matter of arabic translations): https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52 https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093 @ButterflyOfFire: is there something eye-catching problematic with one of these changings? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#913159: task-kannada-desktop: uninstallable on mips and mipsel
Control: notfound -1 3.50 Holger Wansing wrote: > Hi, > > Ivo De Decker wrote: > > Control: found -1 3.39 > > > > Hi > > > > On Wed, Nov 07, 2018 at 07:19:21PM +0100, Ivo De Decker wrote: > > > version: 3.47 > > > > As kibi noted on IRC, this also affects the version in stretch. > > > > Ivo > > > "task-kannada-desktop depends on 'firefox-esr-l10n-kn | firefox-l10n-kn', > which > is not installable on mips and mipsel, because the latest firefox doesn't > build there (yet)." > > I committed that for Buster now. > Does this deserve a stable upload for Stretch? With yesterday's upload of tasksel, this has been fixed for Buster. Tagging accordingly. Should we leave this bug open for Stretch? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#913159: task-kannada-desktop: uninstallable on mips and mipsel
Hi, Ivo De Decker wrote: > Control: found -1 3.39 > > Hi > > On Wed, Nov 07, 2018 at 07:19:21PM +0100, Ivo De Decker wrote: > > version: 3.47 > > As kibi noted on IRC, this also affects the version in stretch. > > Ivo "task-kannada-desktop depends on 'firefox-esr-l10n-kn | firefox-l10n-kn', which is not installable on mips and mipsel, because the latest firefox doesn't build there (yet)." I committed that for Buster now. Does this deserve a stable upload for Stretch? Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#910560: [choose-mirror] fails to build when parallel build is activated
Package: choose-mirror Severity: serious Version: 2.92 Since version 2.92, choose-mirror fails to build with "dpkg-buildpackage -j", the debian/iso_3166.tab file seems to be removed by error: (can also be seen at jenkins: https://jenkins.debian.net/view/d-i_packages/job/d-i_build_choose-mirror/ where I found it initially) holgerw@t520:~/uploading-d-i/d-i/packages/choose-mirror$ dpkg-buildpackage -j dpkg-buildpackage: info: source package choose-mirror dpkg-buildpackage: info: source version 2.94 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Holger Wansing dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build choose-mirror fakeroot debian/rules clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' rm -rf debian/locales debian/sort-tmp /usr/bin/make clean check-masterlist make[2]: Entering directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' rm -f choose-mirror choose-mirror.o *~ mirrors_*.h rm -f debian/templates-countries debian/httplist-countries debian/httpslist-countries debian/ftplist-countries rm -f demo demo.templates rm -rf debian/iso-codes/ debian/pobuild*/ rm -f debian/iso_3166.tab *** WARNING: Mirrors.masterlist was last committed more *** than 2 weeks ago, maybe it needs an update? You can try the following command to run a sync, and use git diff/git commit: make Mirrors.masterlist make[2]: Leaving directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' make[1]: Leaving directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' dh_clean dpkg-source -b choose-mirror dpkg-source: info: using source format '3.0 (native)' dpkg-source: info: building choose-mirror in choose-mirror_2.94.tar.xz dpkg-source: info: building choose-mirror in choose-mirror_2.94.dsc dpkg-source: warning: missing information for output field Standards-Version debian/rules build dh build dh_testdir dh_update_autotools_config dh_auto_configure debian/rules override_dh_auto_build make[1]: Entering directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' # Don't try to sync the mirror masterlist during the build: /usr/bin/make small ONLINE=n make[2]: Entering directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' rm -f choose-mirror choose-mirror.o *~ mirrors_*.h if [ "$ONLINE" != n ]; then \ if wget -nv 'https://salsa.debian.org/mirror-team/masterlist/raw/master/Mirrors.masterlist' -O - > Mirrors.masterlist.new && \ test -s Mirrors.masterlist.new; then \ mv Mirrors.masterlist.new Mirrors.masterlist; \ else \ rm -f Mirrors.masterlist.new; \ fi; \ fi isoquery -c | cut -f 1,4 | sort >debian/iso_3166.tab rm -f debian/templates-countries debian/httplist-countries debian/httpslist-countries debian/ftplist-countries rm -f demo demo.templates rm -rf debian/iso-codes/ debian/pobuild*/ rm -f debian/iso_3166.tab if [ "$USE_HTTP" ]; then ./mirrorlist http Mirrors.masterlist debian/iso_3166.tab; fi if [ "$USE_HTTPS" ]; then ./mirrorlist https Mirrors.masterlist debian/iso_3166.tab; fi if [ "$USE_FTP" ]; then ./mirrorlist ftp Mirrors.masterlist debian/iso_3166.tab; fi ./mirrorlist httplist Mirrors.masterlist debian/iso_3166.tab ./mirrorlist httpslist Mirrors.masterlist debian/iso_3166.tab ./mirrorlist ftplist Mirrors.masterlist debian/iso_3166.tab Unable to read debian/iso_3166.tab at ./mirrorlist line 23. Unable to read debian/iso_3166.tab at ./mirrorlist line 23. Unable to read debian/iso_3166.tab at ./mirrorlist line 23. Makefile:81: recipe for target 'debian/httplist-countries' failed make[2]: *** [debian/httplist-countries] Error 2 make[2]: *** Waiting for unfinished jobs Makefile:99: recipe for target 'mirrors_https.h' failed make[2]: *** [mirrors_https.h] Error 2 Makefile:84: recipe for target 'debian/httpslist-countries' failed make[2]: *** [debian/httpslist-countries] Error 2 Unable to read debian/iso_3166.tab at ./mirrorlist line 23. Makefile:87: recipe for target 'debian/ftplist-countries' failed make[2]: *** [debian/ftplist-countries] Error 2 Unable to read debian/iso_3166.tab at ./mirrorlist line 23. Makefile:96: recipe for target 'mirrors_http.h' failed make[2]: *** [mirrors_http.h] Error 2 make[2]: Leaving directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' debian/rules:15: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/home/holgerw/uploading-d-i/d-i/packages/choose-mirror' debian/rules:3: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#898665: [installation-guide] change "Alioth" and "svn" to "Salsa" and "git"
Control: tags -1 + pending Holger Wansing wrote: > Package: installation-guide > Severity: serious > > > Since the source code repository has moved from Alioth (svn repo) to Salsa > (now git), the manual needs some editing to follow this: > Alioth -> Salsa > svn -> git > and relevant URLs > > It should be possible to easily sync that changes to translations as well. Just committed. Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#898665: [installation-guide] change "Alioth" and "svn" to "Salsa" and "git"
Package: installation-guide Severity: serious Since the source code repository has moved from Alioth (svn repo) to Salsa (now git), the manual needs some editing to follow this: Alioth -> Salsa svn -> git and relevant URLs It should be possible to easily sync that changes to translations as well. So long Holger -- Created with Sylpheed 3.2.0 under the new D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/
Bug#897529: installation-guide is marked for autoremoval from testing
Hi, Debian testing autoremoval watch wrote: > installation-guide 20170614 is marked for autoremoval from testing on > 2018-05-31 > > It is affected by these RC bugs: > 897529: installation-guide: FTBFS This is because of the "ID xxx-yyy already defined" validation errors", which has already been reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880210 and which was already fixed in svn repo (oh, this is now git). Maybe we should do an upload to get this fixed in the archive? However, that would be an upload for Buster (there's "Bump release name to buster" in the changelog). Hmm ... Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#892499: Non-ascii characters broken in d-i (text-based installer)
> It seems there is something generic broken in the installer. > A screenshot of the languagechooser screen is attached, where several broken > characters can be seen (in Arabic, Belarusian, Bulgarian, Chinese, Czech and > Greek, for example). Please also note the broken alignment of the right frame > border. I managed to boil this down to the build of 2018-03-05: https://d-i.debian.org/daily-images/amd64/20180305-00:29/ 20180302ok 20180303ok < no build for 2018-03-04, hmm > 20180305broken 20180306broken Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#867101: refcard: Build-dependency pdfjam no longer available
Control: tags -1 + pending Adrian Bunk wrote: > Source: refcard > Version: 9.0.4 > Severity: serious > Tags: buster sid > > The texlive-extra-utils package ships still ships pdfjam but > no longer provides it in the dependencies. Replaced pdfjam by texlive-extra-utils in the package dependencies. Marking this bug as pending. Thanks Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#859150: installation-guide: leaves many /tmp/tmp* files behind
Control: tags -1 + pending Cyril Brulebois wrote: > Source: installation-guide > Severity: serious > Tags: patch > Justification: Fills up /tmp on dillon.debian.org > > Hi, > > Maybe to ease hands-on debugging, dblatex is called with the -d flag, > which tells it to leave temporary files behind. This ends up filling > up dillon's /tmp (in addition to being rather bad style in the first > place…). > > Two possibilities: > - remove the -d flag entirely (untested); > - or set TMPDIR to a subdirectory of $tempdir, which gets automatically >removed after a build. > > The attached patch implements the second solution, but comments are > welcome. Patch tested and applied. Thanks -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#859150: installation-guide: leaves many /tmp/tmp* files behind
Hi, Am Fr. Mär. 31 00:24:41 2017 GMT+0200 schrieb Samuel Thibault: > Hello Holger, > > Cyril Brulebois, on ven. 31 mars 2017 00:09:34 +0200, wrote: > > Maybe to ease hands-on debugging, dblatex is called with the -d flag, > > which tells it to leave temporary files behind. This ends up filling > > up dillon's /tmp (in addition to being rather bad style in the first > > place…). > > Is -d really useful now that we have seen the whole thing working? > > Alternatively, > > > - or set TMPDIR to a subdirectory of $tempdir, which gets automatically > >removed after a build. > > would be fine to me, I'm just thinking that we perhaps just not need > these files at all now. There is probably a chance, that a new version of dblatex or another tool breaks something some day. So I would vote for the second variant. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#834677: refcard: FTBFS in testing (xelatex compilation failed)
Hi, victory wrote: > On Wed, 31 Aug 2016 01:41:03 -0400 > Jeremy Bicha wrote: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/refcard.html > > > ! I can't find file `IPAPMincho'. > > ! I can't find file `IPAPGothic'. > > apparently new Depends are needed, maybe > fonts-ipafont-gothic, > fonts-ipafont-mincho, Indeed. And that's why: in stable, texlive-lang-cjk had a Depends on those two, while in unstable that Depends-dependencies are no longer there. I was working on stable here, that's probably the reason why I did not catch that. I have build refcard successfully in a sid VM before the upload of 9.0.2. Don't know what went wrong. Now, I am currently unable to build refcard in a sid chroot. It complains about /proc/self/stat being unavailable. I couldn't find something about this in the maint guide https://www.debian.org/doc/manuals/maint-guide/build.en.html ... Need to investigate further. Martin: I fear, there is another upload needed :-( I fixed the build dependencies in git now. Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#834677: refcard: FTBFS in testing (xelatex compilation failed)
Control: tags -1 + pending Santiago Vila wrote: > Package: src:refcard > Version: 9.0.1 > Severity: serious > > Dear maintainer: > > I tried to build this package with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: Fixed in git. Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#833265: refcard: depends on unexistent package
Hi,
victory wrote:
> On Tue, 2 Aug 2016 10:25:13 + (UTC)
> Gianfranco Costamagna wrote:
>
> > As said, "ttf-kochi-gothic" is not available in Debian, so, the package
> > seems to be not buildable from source, at least with Debian repositories.
>
> as long as stable has it, "not available in Debian" is not true;
> anyway you can apply this:
>
> Index: refcard/dblatex.xsl
> ===
> --- refcard/dblatex.xsl (r42)
> +++ refcard/dblatex.xsl (wc)
> @@ -10,7 +10,7 @@
> \setCJKmainfont{IPAPGothic}
> \setCJKsansfont{IPAPMincho}
> \setCJKmonofont{IPAexGothic}
> - \setmainfont{Kochi Gothic}
> + \setmainfont{IPAPGothic}
> \setsansfont{IPAPMincho}
> \setmonofont{IPAexGothic}
>
I assume you have checked the displaying of the IPAPGothic font, right?
So that I can blindly commit the above?
Holger
--
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .
Registered Linux User #311290 - https://linuxcounter.net/
Bug#777439: Jessie DI-rc1 amd64 after installation no network interfaces
Hi, Heiko Ernst wrote: > this is my installer syslog [...] > Feb 10 07:52:49 debootstrap: Creating /etc/network/interfaces. Hmm, at the beginning of the installation, /etc/network/interfaces is created and apparently works (OP did not complain about network problems _during_installation_ ). But at the end of install: > Feb 10 08:14:44 finish-install: info: Running /usr/lib/finish- > install.d/55netcfg-copy-config > Feb 10 08:14:45 netcfg[29439]: INFO: Starting netcfg v.1.127 (built > 20150104-2209) > Feb 10 08:14:45 netcfg[29439]: INFO: Starting netcfg v.1.127 (built > 20150104-2209) > Feb 10 08:14:45 netcfg[29439]: DEBUG: No interface given; clearing > /etc/network/interfaces > Feb 10 08:14:45 netcfg[29439]: DEBUG: Writing informative header > Feb 10 08:14:45 netcfg[29439]: DEBUG: Success! > Feb 10 08:14:45 netcfg[29439]: DEBUG: Writing loopback interface > Feb 10 08:14:45 netcfg[29439]: DEBUG: Success! /etc/network/interfaces is wiped out! This shouldn't have happened in a shell-only install ... Holger -- Created with Sylpheed 3.2.0 under D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777439: Jessie DI-rc1 amd64 after installation no network interfaces
Hi, Heiko Ernst wrote: > On Mon, 09 Feb 2015 04:46:17 + Ben Hutchings wrote: > > OK, then this is not expected. > > This is my etc/network/interfaces file I have wrote hope this is a workaround > for this time but why show me the network manager in kde not the connection? > I > see only a ? over the icon. This is getting confusing: In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777439#35 you wrote, that you have done a shell-only install (no desktop environment). Now you write, that you have kde and network-manager installed. ??? Without the installer logs there is no chance to get this sorted out. PS: when you want to configure your network connections with network-manager, the corresponding network interfaces have to be completely deleted out of the /etc/network/interfaces file. Holger > > --- > > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet dhcp > > # The wlan interface > auto wlan0 > iface wlan0 inet dhcp > wpa-ssid $myssid > wpa-psk xx > wpa-key-mgmt WPA-PSK -- Created with Sylpheed 3.2.0 under D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607193: debian-www: document / provide links for images with non-free firmware
Hi, there is still something left on this bug: on http://www.debian.org/releases/squeeze/debian-installer/ we have a fat warning and links to the images. This should also be pushed on d.o/CD and d.o/CD/netinst. I have prepared a patch for this: The idea is, to add a tag for the already existing warning (on http://www.debian.org/releases/squeeze/debian-installer/), so that we can link to it from other places on the website. Because of being inofficial, there is no need to make the images that much promiment IMHO. Having the info at one place and link to that place from other sites should be enough. Patch is attached. Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Powered by Sylpheed 3.0.2 under Debian GNU/ / _ _ _ _ _ __ __ / /__ / / / \// //_// \ \/ / // /_/ /_/\/ /___/ /_/\_\6.0 / Squeeze. Registered LinuxUser #311290 - http://counter.li.org/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Index: CD/index.wml === RCS file: /cvs/webwml/webwml/english/CD/index.wml,v retrieving revision 1.35 diff -u -r1.35 index.wml --- CD/index.wml 8 Apr 2011 15:11:17 - 1.35 +++ CD/index.wml 15 Jul 2012 11:35:36 - @@ -44,6 +44,11 @@ which you can use to try Debian first and then install the contents of the image. + Inofficial + images with non-free firmware. + Some hardware requires non-free firmware. Find detailed info and images + here. + Official CD releases are signed so that you can Official businesscard images for the stable release — see below + Inofficial netinst images for the stable release + including non-free firmware — find detailed info here + Images for the testing release, both daily builds and known working snapshots, see the Debian-Installer page. Index: releases/squeeze/debian-installer/index.wml === RCS file: /cvs/webwml/webwml/english/releases/squeeze/debian-installer/index.wml,v retrieving revision 1.7 diff -u -r1.7 index.wml --- releases/squeeze/debian-installer/index.wml 14 Dec 2011 19:50:37 - 1.7 +++ releases/squeeze/debian-installer/index.wml 15 Jul 2012 11:35:38 - @@ -82,6 +82,8 @@ +Images with non-free firmware + If any of the hardware in your system requires non-free firmware to be
Bug#594184: debian-installer: activating bootflag on ext2/ext3 partition not possible
Package: debian-installer Severity: grave With a daily build netinst cd from 23. August 2010, it is impossible, to set the bootflag from Off to On. I tested this on two different machines (x86, pc-compatible), on an ext2 and an ext3 partition with msdos partition table (don't know if other partition types or partition table types behave different). Switch the bootflag from On to Off works fine, but the other way does not. Deleting the complete setup by hand and setting up a new, clean partition table gives the same result, it's impossible to create a setup with a bootable partition included. With a squeeze alpha1 businesscard cd, this all works fine. Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Created with Sylpheed 2.5.0 under DEBIAN GNU/LINUX 5.0.0 - L e n n y Registered LinuxUser #311290 - http://counter.li.org/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
