Bug#1081794: E: /usr/bin/ssh-askpass[39]: too many open files (3 -> 212): Success
Hi Timo, >$ ssh-keygen -t ed25519 -f /tmp/test >$ ssh-add /tmp/test < /dev/null >E: /usr/bin/ssh-askpass[39]: too many open files (3 -> 212): Success >$ echo $? >1 > >key is not added to the agent this is quite puzzling. First guess: is $DISPLAY set and points to a usable X11 server? Second guess: /usr/bin/pinentry points to a real one, not to pinentry-kwallet, right? (Otherwise, there can be recursion.) Third… please put “set -xv” in the top of the script and retry, for debugging. Out of ideas, otherwise. Thanks, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1081501: musescore3: Buttons too big
On Thu, 12 Sep 2024, Paul Menzel wrote: > Using Debian sid/unstable with *gnome-shell* 47~rc-3 from the suite > *experimental*, and scaling the screen content to 200 %, the buttons > are too big in MuseScore as seen in the attachment. Hmm. Asides from this potentially being a GNOME issue, there’s a few things you can do on the mscore side. First, start it with the -D option and the actual dpi. If it then looks the same, you’ll know that GNOME sets the dpi correctly, otherwise you’ll have a knob to try. Second, there’s the -x option for GUI scaling, you could try something like -x 0.5 and see what happens. Third, if you go to E̲dit → P̲references… then in the General tab, option group Theme, there’s icon width/height, to be set in pixels. It might be that GNOME scales “just” those, nothing else; if so, halve the values there to match GNOME’s settings. Fourth, you could see whether there’s anything to configure in the system-wide (per-user, probably) Qt5 settings. I admit I have no idea about those. Unfortunately, autodetection of these things only seems to work in basic cases, and desktop environments have always been inventing their own knobs which then only work well in their own applications, so I’m afraid there isn’t anything we can do on the code side, except if you find that this is something fixed in mu͒3.7 Evolution (to soon be packaged as musescore-snapshot, but I’m not there yet), in which case we could backport the fix. I’d ask you to please try out the above things and report back, but, unless someone finds a commit to backport, I’ll handle this as user support request* and not as bugreport. *) Upstream notably doesn’t support 2.x/3.x any more, but the forums on musescore.org and third-party boards like https://www.notensatzforum.net/f2-MuseScore-Forum.html and https://www.musiker-board.de/forum/musescore.934/ still have active enough communities around this, and there’s likely someone there who also uses GNOME (I don’t personally use a desktop environment, just a window manager) and possibly has experience with it. Good luck, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Bug#1081331: /usr/share/man/man1/cvs.1.gz: some commands missing from headings?
Hi наб,
>Quoth cvs(1):
the manpage is autogenerated from *parts* of the
texinfo source, using arcane and weird scripts.
> suck, update, server & pserver, CVS commands
> suck‒Download RCS ,v file raw
> suck module/pa/th
> [...]
>
> update, , suck, CVS commands
> update‒Bring work tree in sync with repository
> update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r
> tag[:date] | -D date] [-W spec] files...
> [...]
Ouch!
I suppose the scripts don’t deal well with some of the
texinfo-level bugfixes I had to do.
New:
release, server & pserver, rdiff, CVS commands
release—Indicate that a directory is no longer in use
• release [-d] directories...
Old:
release
Indicate that a directory is no longer in use
• release [-d] directories...
So it’s “only” the subsection heading cleanup that needs
some love.
The corresponding texinfo part looks:
@node release, server & pserver, rdiff, CVS commands
@appendixsec release---Indicate that a directory is no longer in use
doc/mkman.pl (which also probably needs to have all those
"See node \\(aq$content\\(aq in the CVS manual" replaced with
"See node \\(aq$content\\(aq in cvs(GNU)" for the HTML-level
links to work… hmm…) does:
# Chapter headers.
$last_header = $1 if s/^\@node\s+(.*)$/.SH "$1"/;
if (/^\@appendix\w*\s+(.*)$/)
{
[…]
I believe replacing the two (.*) with (.*?)(,.*)? or so
ought to do (most of) the trick… though… the old code had…
@node release
@appendixsec release---Indicate that a directory is no longer in use
… hmm, ah okay, the --- is converted to \(em and the Perl
code matches with ^$last_header so that’s not correct… so
it probably suffices to change the first (.*) RE for this
to work again.
However.
It’s widely known that the generation process for the manpage
is problematic, and that the result is missing some basic-ish
information. I’d rather write a small -mdoc replacement but
haven’t gotten around to actually doing so, and the Cederqvist
is basically always needed to get the full docs. You *will*
find more things like that, should you wish to dig deeper in
the manpage.
Small fixes like this one are easy enough, but I don’t have
the capacity to fix it all…
I suggest to just read the texinfo page (or its rendered
versions as per /usr/share/doc-base/cvs-doc* registrations)
and blame RMS or something. (Though the actual content of
it is an actual book, not the “usual” GNU texinfo-format
fare ☻ and there’s a PDF.)
Of course you can also just throw CVS questions into my
general direction, like you already did on Fedi.
Good luck,
//mirabilos
--
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty
17:14⎜ Thanks big help you are :-)mira|nwt: ty again
18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o
18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks
18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-)
18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that
21:57⎜ yeah, I really appreciate help
18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly
20:50⎜ i see. mirabilos, thnks for your support
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs»
Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help.
21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you
21:34⎜ mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time
23:39⎜ this worked, thank you very much 16:26⎜ ok
thx, i'll try that 20:00⎜«stableable:#cvs» Thank you.20:50⎜«s833:#cvs»
mirabilos: thanks a lot.19:34⎜ Thanks for confirming :)
20:08⎜ ...works like a charm.. thanks mirabilos
Bug#1081156: hunspell-en-gb: no /var/lib/dictionaries-common/hunspell/ file
Package: hunspell-en-gb Version: 1:7.1.0~rc3-3 Severity: normal X-Debbugs-Cc: t...@x61p.mirbsd.org Not sure whether this is an actual problem, but /var/lib/dictionaries-common/hunspell/ contains what I think are registration files for both hunspell-en-us and myspell-de-de-1901 but hunspell-en-gb is curiously missing one, in sid as well. -- System Information: Debian Release: 11.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-32-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages hunspell-en-gb depends on: ii dictionaries-common 1.28.4 hunspell-en-gb recommends no packages. Versions of packages hunspell-en-gb suggests: pn hunspell ii libreoffice-writer 1:7.0.4-4+deb11u10 -- no debconf information
Bug#1079399: linux: things written to tty vanish after a day or two
Package: src:linux
Version: 5.10.223-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
In /etc/rc.local I write a text file to /dev/tty11.
I have getty on 1-6 as usual and syslog on 12.
After booting the system, I can confirm this works.
A day or two later (I have not timed this exactly),
I can still Ctrl-Alt-F12 to read syslog, but trying
Ctrl-Alt-F11 does nothing, i.e. it does not even
switch from the syslog tty to the one with the text.
-- Package-specific info:
** Version:
Linux version 5.10.0-32-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.223-1 (2024-08-10)
** Command line:
BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-32-amd64
root=/dev/mapper/vg--cSD-lv--root ro net.ifnames=0 vga=792 TZ=:Europe/Berlin
** Tainted: OE (12288)
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: LENOVO
product_name: 7674D67
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7674D67
board_version: Not Available
** Loaded modules:
fuse
tun
ctr
ccm
cpufreq_ondemand
binfmt_misc
cpufreq_powersave
tp_smapi(OE)
thinkpad_ec(OE)
snd_hda_codec_analog
snd_hda_codec_generic
i915
snd_hda_intel
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
iwl4965
snd_compress
iwlegacy
soundwire_cadence
coretemp
snd_hda_codec
mac80211
snd_hda_core
kvm_intel
snd_hwdep
soundwire_bus
thinkpad_acpi
drm_kms_helper
kvm
cfg80211
snd_pcm
pcmcia
cec
ppdev
nvram
snd_timer
drm
ledtrig_audio
snd
iTCO_wdt
evdev
irqbypass
intel_pmc_bxt
yenta_socket
soundcore
i2c_algo_bit
pcmcia_rsrc
libarc4
rfkill
iTCO_vendor_support
watchdog
serio_raw
pcmcia_core
pcspkr
parport_pc
sg
parport
ac
acpi_cpufreq
button
ecb
aes_generic
libaes
crypto_simd
cryptd
glue_helper
xts
dm_crypt
dm_mod
ext4
crc16
mbcache
jbd2
crc32c_generic
mmc_block
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
sr_mod
cdrom
sdhci_pci
cqhci
ata_generic
ahci
uhci_hcd
ehci_pci
libahci
ata_piix
e1000e
sdhci
libata
ehci_hcd
ptp
i2c_i801
scsi_mod
psmouse
usbcore
i2c_smbus
mmc_core
lpc_ich
usb_common
pps_core
battery
video
** PCI devices:
not available
** USB devices:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 17ef:1000 Lenovo ThinkPad X6 UltraBase
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0483:2016 STMicroelectronics Fingerprint Reader
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
-- System Information:
Debian Release: 11.10
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-32-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages linux-image-5.10.0-32-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.140
ii kmod28-1
ii linux-base 4.6
Versions of packages linux-image-5.10.0-32-amd64 recommends:
pn apparmor
ii firmware-linux-free 20200122-1
Versions of packages linux-image-5.10.0-32-amd64 suggests:
pn debian-kernel-handbook
ii grub-pc 2.06-3~deb11u6
pn linux-doc-5.10
Versions of packages linux-image-5.10.0-32-amd64 is related to:
pn firmware-amd-graphics
pn firmware-atheros
pn firmware-bnx2
pn firmware-bnx2x
pn firmware-brcm80211
pn firmware-cavium
pn firmware-intel-sound
pn firmware-intelwimax
pn firmware-ipw2x00
pn firmware-ivtv
ii firmware-iwlwifi 20210315-3
pn firmware-libertas
pn firmware-linux-nonfree
pn firmware-misc-nonfree
pn firmware-myricom
pn firmware-netxen
pn firmware-qlogic
pn firmware-realtek
pn firmware-samsung
pn firmware-siano
pn firmware-ti-connectivity
pn xen-hypervisor
-- no debconf information
Bug#1079393: lintian: mismatched-override cannot be overridden
Package: lintian Version: 2.118.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I have trouble creating an override file that works for all architectures. On some architectures, lintian (correctly) issues: mksh: statically-linked-binary [bin/lksh] I can override this. But on other architectures, lintian (wrongly) issues… mksh: shared-library-lacks-prerequisites [bin/lksh] … instead (for static-PIE executables). I can override this as well. But when I put in both overrides, I get one of… mksh: mismatched-override statically-linked-binary [bin/lksh] mksh: mismatched-override shared-library-lacks-prerequisites [bin/lksh] … obviously. I tried putting… mksh: mismatched-override statically-linked-binary [bin/lksh] * mksh: mismatched-override shared-library-lacks-prerequisites [bin/lksh] * … but they did not take. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.43-2 ii bzip2 1.0.8-5.1 ii diffstat1.66-1 ii dpkg1.22.11 ii dpkg-dev1.22.11 ii file1:5.45-3 ii gettext 0.22.5-2 ii gpg 2.2.43-8 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.16.0-1 ii libapt-pkg-perl 0.1.40+b5 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b3 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b3 ii libclone-perl 0.46-1+b2 ii libconfig-tiny-perl 2.30-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.38-1 ii libdata-dpath-perl 0.59-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-3 ii libdevel-size-perl 0.84-1 pn libdigest-sha-perl ii libdpkg-perl1.22.11 ii libemail-address-xs-perl1.05-1+b3 ii libencode-perl 3.21-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.025-1 ii libipc-run3-perl0.049-1 ii libjson-maybexs-perl1.004008-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.146-1 ii libperlio-gzip-perl 0.20-1+b3 ii libperlio-utf8-strict-perl 0.010-1+b2 ii libproc-processtable-perl 0.636-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1+b2 ii libsereal-encoder-perl 5.004+ds-1+b2 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-2 ii libterm-readkey-perl2.38-2+b3 ii libtext-levenshteinxs-perl 0.03-5+b3 ii libtext-markdown-discount-perl 0.16-1+b2 ii libtext-xslate-perl 3.5.9-2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2+b2 ii liburi-perl 5.28-1 ii libwww-mechanize-perl 2.18-1 ii libwww-perl 6.77-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-4 ii libyaml-libyaml-perl0.89+ds-1+b1 ii lzip [lzip-decompressor]1.24.1-2 ii lzop1.04-2 ii man-db 2.12.1-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.38.2-5 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.6.2-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#1079165: ansiweather: illegible time format
Package: ansiweather Version: 1.11-1.1 Severity: normal Tags: l10n X-Debbugs-Cc: t...@mirbsd.de ansiweather insists on using the weird AM/PM format used by a vast minority of people instead of 24-hour clock format for e.g. sunrise/sundown, even if I set the metric option or the locale. -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages ansiweather depends on: ii bc1.07.1-2+b2 ii curl 7.88.1-10+deb12u5~bpo11+0wtf1 ii jq1.6-2.1 ansiweather recommends no packages. ansiweather suggests no packages. -- no debconf information
Bug#856877: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit:
>I was not aware of any mips* buildds still on 4.9 (Debian 9 kernel). The
>only mips family architecture listed on buildd.debian.org is mips64el, for
I think 4.9 is some mipsel buildds. Shortly after the discussion,
which I’m attaching as I don’t know where it’s otherwise archived,
mipsel was removed from sid with no fanfare or announcement, so I
think those now only build for the old releases’ security support,
but the porters/buildd admins would know. Also unsure whether any
derivative distro still has mipsel with sid packages (but it then
is their problem to obtain newer kernels).
>If there are unofficial mips* buildds outside the buildd.debian.org
>infrastructure, then I would hope that either they can be upgraded to a
>Debian 10 or later kernel, or they can run a Debian 12 or older user-space
>(in particular, not keeping up with the latest sbuild).
Or that.
>However, if I'm
>reading kernel git history correctly, the patch proposed on #1079124
>should in principle work with any 4.7+ kernel (not tested). This would
>not have been broad enough compatibility in 2017, but seems OK now.
Yes, certainly.
Thanks,
//mirabilos
--
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival--- Begin Message ---
Hi,
On 2023-08-04 21:40, Thorsten Glaser wrote:
> Hi,
>
> some of the buildds still use Linux 4.19 but klibc has started to
> require Linux 5.1-specific features with the latest sid upload.
> This has implications on mksh (for the mksh-static and lksh binaries
> and for passing the testsuite) as well.
>
> Could we please get the buildds to run with the stable or at least
> the oldstable kernel?
Unfortunately newer kernels do not work on those buildds:
https://lists.debian.org/debian-mips/2023/07/msg00052.html
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
--- End Message ---
--- Begin Message ---
On Fri, 2023-08-04 at 23:58 +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-08-04 21:40, Thorsten Glaser wrote:
> > Hi,
> >
> > some of the buildds still use Linux 4.19 but klibc has started to
> > require Linux 5.1-specific features with the latest sid upload.
> > This has implications on mksh (for the mksh-static and lksh binaries
> > and for passing the testsuite) as well.
> >
> > Could we please get the buildds to run with the stable or at least
> > the oldstable kernel?
>
> Unfortunately newer kernels do not work on those buildds:
>
> https://lists.debian.org/debian-mips/2023/07/msg00052.html
I have to wonder why this did not disqualify mips{,64}el as release
architectures for bookworm.
The error messages are coming from of_irq_parse_pci(), which wasn't
called at all in the buster kernel because we didn't enable CONFIG_OF
or CONFIG_OF_IRQ. That changed with:
commit 8a788b0708ba1593f1fd4f3c585b7d5466a29f16
Author: YunQiang Su
Date: Sat May 23 23:17:42 2020 +0800
Enable CONFIG_OF and CONFIG_SERIAL_OF_PLATFORM for Loongson-3
Loongson64, aka loongson-3 switch to devicetree, and the console
cannot accept input anymore due to SERIAL_OF_PLATFORM is
not enabled.
While SERIAL_OF_PLATFORM depends on OF, we need to enable it
at the same time.
These options can only work with 5.7+.
Do you have an FDT for these systems, and is the boot loader passing
it? I'm guessing not, because we currently don't build or package any
FDTs in the kernel. In 6.1 these sources are available:
arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
Hopefully one of those marked with an asterisk would be suitable.
Relatedly, I see that eller is also running a 4.19 kernel. What's the
story there?
Ben.
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
On Sat, 2023-08-05 at 02:09 +0200, Ben Hutchings wrote:
[...]
> Do you have an FDT for these systems, and is the boot loader passing
> it? I'm guessing not, because we currently don't build or package any
> FDTs in the kernel.
[...]
That has actually been fixed post-bookworm, but should probably be
backported to bookworm:
https://salsa.debian.org/kernel-team/linux/-/commit/7b4954db782
Bug#1006451: drop mimimi-maven-plugin as its only user was removed
reassign 1006451 ftp.debian.org retitle 1006451 RM: minify-maven-plugin -- RoM; only remaining user gone severity 1006451 normal thanks guacamole-client was RoQA'd in #926276 so this can be garbage-collected
Bug#856877: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit: >was rather recent at that time, but hopefully we no longer have any >machines that are running Debian 8 kernels... The varios MIPS buildds run 4.19 and some even 4.9 kernels (AFAIHH due to hardware/patch constraints), which has led to problems (e.g. I had to disable klibc builds of mksh on them because klibc now uses Linux 5.1 features). AIUI this is being worked on, but not yet resolved. >(As far as I can see, the fstab configuration in dsa-puppet is intended to >add some lines to schroot's defaults, rather than forcing specific handling >for /dev/pts, but it forces specific handling for /dev/pts as a side-effect >because it's overwriting the whole file.) Ah, ouch. Those config tools where doing that is easier than doing the actual manipulation… Thanks again for digging into this, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Hi Simon, thanks for testing. >I'm using Thorsten's regression report in #983423 as my representative >sample of a package that regressed with schroot 1.6.13-4, because mksh >builds much more quickly than gcc-14 (You can add mksh-firstbuilt to DEB_BUILD_OPTIONS so it doesn’t build and test binaries for dietlibc/klibc/musl.) >, but I suspect that the same would >apply equally to Adrian's regression report in #856877: the important >factor is probably just "any package that wants to run script(1) >or expect(1)". I think so. >I was not able to reproduce the mksh build failure, so there must be >some relevant difference in setup (other than CPU architecture, which Oh, okay. Adrian? bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit:
>> as well as open("/dev/tty", O_RDWR, 0)
>
>Asserting that /dev/tty is the correct device node and has appropriate
>permissions should cover that.
Totally not, unfortunately: it only works when it actually has a ctty.
>> and later F_DUPFD and F_SETFD, FD_CLOEXEC fcntl
>
>Those are basic syscalls that act on any valid fd (not just terminals)
>so if they somehow fail then we already have much, much worse problems.
Yeah, these are granted.
>> Perhaps isolating that as a small C or Perl program to use
>> for those tests?
>
>It looks like even perl-base (which is Essential) should have
>POSIX::isatty, so that's probably the most convenient.
That and the builtin open to open /dev/tty ought to do,
but I’m not a Perl monk, so feel free to ;-)
Thanks,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit:
>On Mon, 19 Aug 2024 at 16:27:24 +0000, Thorsten Glaser wrote:
>> mksh actually does things inside script(1) that use the tty
>
>For the purposes of having a test-case for schroot that doesn't require
>mksh, perhaps a good approximation to this would be asserting that
>tty(1) from coreutils exits successfully and prints the path to a char
>device that exists and is rw?
Unsure. It also requires and accesses /dev/tty, it doesn’t just
do isatty on stdio.
>For a manual smoke-test for this change, having a known-good version
>of mksh build and pass its test suite seems like a better indicator
>that the terminal is indeed working, but I think that's too large and
>involved to make a reasonable autopkgtest for schroot to guard against
>this maybe regressing.
Right.
Looking at the code, it seems we need isatty(0) && isatty(2)
to succeed as well as open("/dev/tty", O_RDWR, 0) to succeed
(and later F_DUPFD and F_SETFD, FD_CLOEXEC fcntl).
Perhaps isolating that as a small C or Perl program to use
for those tests?
>on a pty or tty, or produce some other output if not?
Produce some other output (error messages) if not.
$ echo true | sudo chroot /tmp/a /sh -i; echo
W: /sh: can't find controlling tty: Permission denied
W: /sh: won't have full job control
# #
The two warning lines are absent if the tty is present.
They look different in older versions, though.
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#911312: firefox-esr: automatical download of libgmpopenh264.so with default settings
Package: firefox-esr Version: 115.14.0esr-1~deb11u1 Followup-For: Bug #911312 X-Debbugs-Cc: t...@mirbsd.de Control: severity -1 serious The binary plugin is still automatically downloaded (and likely used). This is likely a violation of “main” rules. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-32-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libasound2 1.2.4-1.1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u11 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.28-0+deb11u1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u2 ii libglib2.0-0 2.66.8-1+deb11u4 ii libgtk-3-0 3.24.24-4+deb11u4 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.2-1+deb11u2 ii libx11-xcb1 2:1.7.2-1+deb11u2 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.7-0+deb11u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix pn libcanberra0 ii libgssapi-krb5-2 1.18.3-6+deb11u5 pn pulseaudio -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/firefox-esr/browser/omni.ja (from firefox-esr package) debsums: changed file /usr/lib/firefox-esr/omni.ja (from firefox-esr package)
Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit: >On Sun, 18 Aug 2024 at 23:44:57 +0000, Thorsten Glaser wrote: >> On three buildds, mksh FTBFS already because the whole >> /dev/ptmx and /dev/pts stuff is malfunctioning again > >Which buildds? Are you referring to -ports builds >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0 >each of which reported >"script: failed to create pseudo-terminal: Permission denied"? Yes, indeed. >-powerpc, -sparc teams: how are those buildds >(debian-project-be-1.buildd.org, blaauw.buildd.org, sompek.debian.net) >set up? >* host system suite: testing? unstable? other? >* kernel: seems to be 6.9.12 in each case, presumably from testing/unstable >* schroot: 1.6.13-4 or some sort of backport? >* is there any container/chroot/other confinement between the host system > and sbuild+schroot? >* any special schroot or kernel configuration? → cbmuser et al. >Thorsten, I see that >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=59c-39&stamp=1724031130&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sh4&ver=59c-39&stamp=1724031300&raw=0 >seem to be running script(1) successfully, but failing with an error >that looks different (possibly related to using qemu-user on an amd64 >system). Can I assume that those are out-of-scope here? Right, these are from the failure to set argv[0] again, which is somehow on-again off-again with these hosts, despite qemu having been fixed ages ago. >> have you actually tested that this works? > >I initially provided the patch that was recently applied to schroot back >in 2017, and unfortunately I don't completely remember what I did 7 years Fair. >ago, but I think my usual reproducer for "do pseudo-terminals work?" was >to run something like "script -c 'cat /etc/os-release' /dev/null" inside >a schroot. Is that a good mockup of what mksh needs to do, or is there Half of it: mksh actually does things inside script(1) that use the tty. I cannot test this in that environment currently, but something like… case $(script -c 'echo true | env -i /bin/mksh-static -i' 2>&1) in *[!\ \#\$]*) echo fail ;; esac … or, if you can guarantee running as nōn-root (root ignores PS1 if it does not contain an octothorpe), case $(script -c 'echo true | env -i PS1=X /bin/mksh-static -i' 2>&1) in *[!X]*) echo fail ;; esac could work (i.e. test whether the returned text is just the prompt). The -i after the shell is important. You could also check for the warning message, but their format is not guaranteed to be fixed. Or just inspect this interactively. >I have not been continually testing that patch for 7 years, and I didn't >make the decision to integrate it now, so I can't speak to what testing >was done before the upload that integrated it. tbh I was more addressing the uploader with this, but I was rather tired yesternight when I found this and just wanted to throw the ball to “someone”. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#983423: schroot (1.6.13-4) unstable; urgency=medium
Hi, have you actually tested that this works? On three buildds, mksh FTBFS already because the whole /dev/ptmx and /dev/pts stuff is malfunctioning again, after like 15 years of it working after having had to fight for packages being allowed to depend on it to obtain a pty/tty for tests during build with script(1). Not sure it’s related, jrtc27 pointed out it’s a recent change that might be, and cbmuser would be the one to recreate the chroots there. I have about negative band‐ width to debug this myself right now, so… please.
Bug#1079020: lintian: bin-sbin-mismatch vs. shells
Package: lintian Version: 2.118.0 lintian reports now, after dh_movetousr: X: mksh: bin-sbin-mismatch bin/mksh -> usr/bin/mksh [usr/share/doc/mksh/examples/uhr] I can only assume that this is due to the #!/bin/mksh shebang in that file. If so, please carry a list of interpreters in lintian whose canonical path is in /bin/ (or /sbin/) instead of the /usr/-moved locations, so that people won’t mistakenly change the canonical #!/bin/mksh shebang to the unportable, broken #!/usr/bin/mksh[sic!].
Bug#1078772: pmake: “bmake: no system rules (sys.mk).”
Santiago Vila dixit: > El 15/8/24 a las 22:49, Thorsten Glaser escribió: >> a package that Build-Depends on pmake and uses it >> in its debian/rules build targets in a clean bullseye chroot > > Did you really mean bmake (not pmake) here? No, pmake. > If yes: Can you provide an example of package in the > described set? https://debr.mirbsd.org/repos/wtf/dists/bullseye/wtf/Pkgs/host/ > I ask because I rebuilt the whole of bullseye one month ago, > and among the few packages still pending to be reported, > none of them uses bmake. Yeah, this is not uploaded to Debian proper. I use pmake quite a lot, though. bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 17:14⎜ Thanks big help you are :-)mira|nwt: ty again 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks
Bug#1078772: pmake: “bmake: no system rules (sys.mk).” under qemu-user
retitle 1078772 pmake: “bmake: no system rules (sys.mk).” under qemu-user severity 1078772 important thanks Dixi quod… >Hm, but I just tested with pmake_1.111-3.2_armel.deb from >the archive, and it also failed. > >Is it possible that it doesn’t work right under qemu-user? Apparently, this is it, so it doesn’t break for everyone. My Pi 1 running armel is apparently building this fine, if sloowly. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1078772: pmake: “bmake: no system rules (sys.mk).”
Dixi quod… >stracing shows that, despite the -m option being passed by >the pmake wrapper, it still accesses /usr/share/mk/. Hm, but I just tested with pmake_1.111-3.2_armel.deb from the archive, and it also failed. Is it possible that it doesn’t work right under qemu-user? (Which would also be possibly devastating…) Or under cowbuilder (same)? bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1078772: pmake: “bmake: no system rules (sys.mk).”
Package: bmake Version: 20200710-14+deb11u1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: t...@mirbsd.de Building a package that Build-Depends on pmake and uses it in its debian/rules build targets in a clean bullseye chroot completely fails with: bmake: no system rules (sys.mk). stracing shows that, despite the -m option being passed by the pmake wrapper, it still accesses /usr/share/mk/. I’ve not yet tested whether bookworm+ are also affected. -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages bmake depends on: ii libc6 2.31-13+deb11u10 bmake recommends no packages. bmake suggests no packages. -- no debconf information
Bug#1073608: Request for clarification on RC-ness of DEP17 bugs
Paul Gevers dixit: > The Release Team considers packages that ship files in /usr-merged aliased > locations RC buggy. > > We have put our trust in Helmut to come up with the right solutions during the > preparation for trixie Hmpf. He’s doing the dirty work for Md and bluca now. >, so I'm asking you to either convince him of a better approach Tried that, didn’t work. >, or apply the patches he proposes. So, then. Give me a patch that: • does not rely on the version of the packages (considering there are packages in external repos with higher version numbers that do not move) → even when later upgrading to such one (e.g. in case someone has trixie but also the external repo’s bookworm in sources.list, where the latter ships mksh with a higher version but without the move) ⚠ • ensures /bin/lksh is never nōn-existent on upgrades and downgrades Then I’ll grudgingly apply it. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne dixit: >> Maybe the protective diversions also protect against this problem as well >> as the problem of moved files? I unfortunately failed to spot where the >> protective diversions were added in dh_movetouser (if that even is the >> right place to be looking), so I'm fairly sure I'm missing something. > >dh_movetousr has nothing to do with protective diversions. It does not >add nor remove diversions nor does it change any. All it changes is >locations of files in the data.tar of a .deb. All of the protective >diversions that we ever installed for DEP17 are managed in maintainer >scripts and dh_movetousr does not touch maintainer scripts at all. Huh? So the lots of diversions to /sbin/something.moved-to-usr I’ve been seeing come from maintainer scripts? But at what point does dpkg remove /bin/mksh vs. rename /usr/bin/mksh.dpkg-new to /usr/bin/mksh? I thought the diversions were needed so the latter doesn’t then get renamed? Agh, this is all so complex and fragile. Are you really surprised that maintainers are very much against this? >In the first bug, Andrew stated that selecting the shell via debconf >wasn't supported. Still salty about this, as it worked in lenny and before, and the Canonical agents who made dash the default shell unilaterally broke this, refused cross-shell communication, ignored suggested patches and sat out the rc bugs for 2 releases until we just gave up. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
(Another data point is that there’s versions of mksh with version numbers larger than what’s in sid around in my own repo, for those wanting to follow CVS snapshots more closely, backported to all versions up to sarge, so bookworm users can very well have mksh packages with a version number that is greater than what will be in trixie so anything that relies on version numbers for transitioning will also not work.)
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne dixit: >that the way people tend to use mksh is by adding a local diversion for Unfortunately not. The way we have to do it since squeeze, when dash unilaterally broke cross-package coordination, is: dpkg-reconfigure dash ⇒ remove its owning of /bin/sh (so it reverts to bash) ln -sf lksh /bin/sh This cleanly persists across upgrades, bash was never problematic wrt this. >I don't think the CTTE has actually issued a ruling on DEP17 or >/usr-move short of repealing the moratorium in order to enable moving >forward. That, and that UsrMove via symlinks /bin etc. is to be instated. There is absolutely no reason to force files to move, given they are now aliased already *anyway*. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Russ Allbery dixit: >Thorsten Glaser writes: > >> You got your merged /usr already, and to force packages to move their >> files WILL break users’ systems. In particular, mksh as /bin/sh is a >> supported configuration. > >Could you explain how this would break a user's system? From your second >sentence I'm guessing that you're anticipating some problem related to >diversions, but I can't put the pieces together without some more details. If I have a link from /bin/sh to a binary from the mksh package, then on normal upgrades dpkg updates it atomically. Diverting the binary in /bin/ away will leave the symlink from /bin/sh (which is managed by the local admin because the dash package ignored two(!) rc bugs regarding its changed /bin/sh management behaviour, when they broke it, for more than two releases so the bug got eventually closed so mksh couldn’t offer package-controlled /bin/sh management that was coordinated with bash post-lenny) dangling. Despite all this, running with mksh (the /bin/lksh binary) as /bin/sh is a supported configuration (Policy 10.4), and I’ve read of many users who are doing this. This means that, hypothetically, should someone upload mksh with the suggested move, which would divert the /bin/ files away in preinst, users would need to be told to manually change their /bin/sh back to bash for a bit, upgrade then, and then switch it back, or have their system break on upgrade. This is fragile, and the “benefits” are nowhere even near worth it: /usr-merge per top-level symlinks per CTTE was forced on all systems, so we got that now, and it is absolutely unnecessary for packages that are not part of the pseudo-Essential set to move their files because their implicit Pre-Depends on the Essential set will ensure that the /bin symlink is already in place so this is a total nōn-issue. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#1073608: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne dixit: >I expect this policy change to come into effect before trixie is >released and the current mksh and pax will be violating said policy. I’m veto’ing this. >> 1. the /bin symlink >> >> The implicit Pre-Depends on the Essential set being unpacked, >> where base-files contains the /bin symlink, is sufficient to >> avoid /bin ending up as a directory. No action needs to be >> taken in the packages that are not part of the (Pseudo‑)Essential >> set. > >This relies on undefined behaviour in dpkg. Guillem is working on >improving metadata tracking and accurately tracking metadata will make >this break. It is not enough to rely on the implicit essential >dependency. Then the tracking could be aware of this and DTRT. >> Au contraire, moving the files WILL break users’ systems, as >> having /bin/sh be a symlink to lksh is a supported configuration, >> and I am a̲b̲s̲o̲̲l̲u̲t̲e̲l̲̲y̲ ̲N̲O̲T̲ taking a possible convoluted thing to >> work around this. mksh is continuously backported (not in bpo) >> as well, I’m totally not going to break things. > >I recommend using dh_movetousr or dh-sequence-movetousr in order to And that works how? By diverting the files away temporarily, leaving users with a dangling /bin/sh symlink during the pak‐ kage upgrade which almost certainly will lead to a failing upgrade which will leave the user with a hosed system. >I kindly request that you reopen these bugs for tracking purpose. I As an issue reporter, there comes a time when you are of the opinion that what you opened is a bug, but the maintainer dis‐ agrees. This is such a case. This is not a bug in mksh, and even if it were, the fix would lead to broken users’ systems and therefore isn’t worth it. Alternative ways to fix this, #2 in dpkg and #1 is currently a nōn-issue (and if dpkg’s new metadata tracking is being written, it can be written to account for this, as I have the right of having been here first). bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Bug#1073608: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Helmut Grohne dixit: >I would like to take the opportunity make you aware of a Debian policy >change #1074014 about merged-/usr. I mentioned your approach in mksh and >pax and the consensus among discussion participants was that policy >should not allow for such interpretation. We have six seconds on the >following diff now: > >- To support merged-/usr systems, packages must not install files in both >- /path and /usr/path. For example, a package must not install both >- /bin/example and /usr/bin/example. >+ Since base-files implements mandatory merged-/usr by installing the >+ aliasing symbolic links, other packages must not install files into >+ aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is >+ not prepared to deal with such aliasing and in prohibiting the >+ installation into aliased locations, we avoid triggering undefined >+ behaviour. Conversely, packages may assume that /bin, /lib and /sbin are >+ symlinks at all times and that their files below /usr/bin, /usr/lib and >+ /usr/sbin are also accessible via their aliased locations. This is dangerous, and I’d like to officially veto this policy change. You got your merged /usr already, and to force packages to move their files WILL break users’ systems. In particular, mksh as /bin/sh is a supported configuration. bye, //mirabilos -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) Comment: ☃ ЦΤℱ—８ ☕☂☄ iQIcBAEBCQAGBQJmspuTAAoJEHa1NLLpkAfg4cUP/1yEiYQSl+TQBe0WdF4JR0CQ YLx2v/vAO4WWmUOgvZ4eFhsxQOucaTnWSBA+wq+NsUi7xVP7soOCEVG1CqgEo92W rIBpqxYUegFGTZUdbSf/Eut5fPCug8JoEuTGUVSVFnij6AoQ8GZtkJldGbOfe3oO 4J7ArKTJ3+8k7VvYYgohxebp7RPpC+KRKk0oNe2iec3csW71eQriiDINV2kRC9ZK S9cV16Uda8pw6P/u0ioyjYnRiKYBXCJg+HPFuioI4zefsRVfqoLFN0O7WmE99zKJ sb8JBnvVoA3eUcSPBBfqHIFbhdUO6F8KxXtUyqxZNgKigbHCAzAyUu9qH95pwltZ 7vMVeCM15kfhdWRT5vRYgSYHwryawi2gc22W1gpuAba68FgNnz1O0qaNTY/Lcfdi zKRDAUDFRWUmpDuPEHFyNZgiRpv6kAEad378FRUv4ESOqEbGKLeJmLIRjdsgPrBl 7L3Yp/eKOC/5O2XPQcBI48cMc9zrREFgDKZXOcer2nUX+xR39/8qRNV5u0DPUUk5 /xseGZhYVah1q8Y2j6sUP1lEm3w62tGq1+fBEFdLKVo6WZtHnpO5ZWIIXMPHs9Sb j9//r8gdeb7W10qwxZKoTnMPSeQyt8Rn7fzwpPRnA54hXMtjzBcB9dulxrQLyg6l IAOF5fwerKsRufeCPy8h =PRWD -END PGP SIGNATURE-
Bug#919265: RFH: xloadimage -- Graphics file viewer under X11
submitter 919265 ! retitle 919265 RFH: xloadimage -- Graphics file viewer under X11 thanks I’m taking over xloadimage and fixing the RC and some of the other bugs, but I originally wanted to reduce, not increase, my involvement in post-bullseye Debian, and I don’t know X11 programming well, so I would like to request help by people who do. I do use xloadimage basically daily, though.
Bug#1077944: musescore3: musescore4 packaging
retitle 1077944 FAQ: musescore4 packaging tags 1077944 = wontfix thanks Hi Tuxicoman, >I wonder if Musescore 4 will be packaged in Debian or if there are any concerns >preventing it ? yes, there are concerns. They’ve arrived too late for bookworm, but the https://packages.debian.org/sid/musescore3 current description of the package documents them: Mu͒seScore Studio 4 relies on proprietary, binary-only downloadable content for most functionality, so no Debian package is currently planned for the releases by the new (Muse Group) owners. As Mu͒seScore Studio 2 and 3 packager, I won’t stand in the way of others wanting to package 4, however I believe it will be a disservice to users because they w̲i̲l̲l̲ be wanting those proprietary plugins, as the “core” functionality (e.g. playback) otherwise is w̲o̲r̲s̲e̲ than in 3, plus I have vague concerns, sometimes more, sometimes less, regarding the new owners, their development process, amount of community involve‐ ment, etc. and being involved in various musicians’ fora, I see quite an amount of users unhappy with 4.x I’ll personally keep musescore2, musescore3 and musescore-snapshot (which will soon be a package of Mu͒seScore Evolution 3.7, a true community effort) working, and the different versions are coïnstallable anyway (because you need 2.x to work on a 2.x score, etc., to avoid having to invest h̲o̲u̲r̲s̲ to relayout for the new version). Any 4.x packager would do well to ensure to keep the proprietary content, telemetry, and other phone-home content (such as the start centre loading a webpage controlled by upstream that contains Yandex, Google, etc. trackers) patched out (a neverending battle). As I see this becoming a FAQ, I’ll keep this “bugreport” open. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1077676: pcscd: unprivileged users not authorised to access OpenPGP smart cards
On Thu, 1 Aug 2024, Mark Hindley wrote: >On Thu, Aug 01, 2024 at 09:02:07AM +0200, Gian Piero Carrubba wrote: >> The problem is registering an xdm-initiated session with elogind. >> /etc/pam.d/xdm includes /etc/pam.d/common-session that calls >> libpam-elogind, so in this sense xdm uses elogind. That’s… very convoluted and doubly indirected, and xdm does not itself provide /etc/pam.d/common-session, so I’d categorically refute this statement (not that that’s grounds to not try and fix this, but I want to make this point clear first. >> So, if the $x-display-manager is standardized by the Debian Policy >> (i.e., all the display managers define the facility) > >I think most do, but it is no longer policy. This ought to suffice. >> tested), the solution should be for elogind to include >> >> # X-Start-Before: $x-display-manager Yes. >I am not averse to this, but I am not sure it addresses all cases. In >particular non-graphical login to a console. The getty(8)s are only started after the run commands have all finished, so console login is anyway only possible after that. I always found it weird that Debian started the graphical login managers “too early” and had problems with that in the lenny/hardy time myself, so I tended to wait for a few minutes or did a quick Ctrl-Alt-F1 to see if rc was finished then Ctrl-Alt-F7, on the work desktops. I remember this was introduced in a time when the operating systems raced for quick boot times (a time that spawned much bad design and decisions); Microsoft cheated, too, by making the user able to login before half their background services were started just to be able to prove their assumed superiority (that the system was laggy and barely usable the first minutes after login was carefully not mentioned), and I guess that the “modern” GNU/Linux desktop crowd just followed suit. Given how the latter are now using systemd anyway, I think it prudent to make sure that any graphical login manager is ran as late as possible in the boot sequence, if not last, always. People using sysvinit and consorts tend to have reliability as of a higher worth than perceived speed so are unlikely to com‐ plain, anyway. (I know I revert sysvinit to sequential boot on a̲n̲y̲ ̲a̲n̲d̲ ̲a̲l̲l̲ systems.) bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1077201: mod_autoindex: IndexOptions FoldersFirst does not work
Package: apache2-bin Version: 2.4.61-1~deb11u1 Severity: normal Adding “IndexOptions FoldersFirst” to a .htaccess does have the (desired) effect to disable fancy indexing, but the sorting the directories first does not work (it does in Apache httpd 1.3.x). -- Package-specific info: -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-31-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages apache2-bin depends on: ii libapr1 1.7.0-6+deb11u2 ii libaprutil1 1.6.1-5+deb11u1 ii libaprutil1-dbd-sqlite3 1.6.1-5+deb11u1 ii libaprutil1-ldap 1.6.1-5+deb11u1 ii libbrotli1 1.0.9-2+b2 ii libc62.31-13+deb11u10 ii libcrypt11:4.4.18-4 ii libcurl4 7.88.1-10+deb12u5~bpo11+0wtf1 ii libjansson4 2.13.1-1.1 ii libldap-2.4-22.4.57+dfsg-3+deb11u1 ii liblua5.3-0 5.3.3-1.1+deb11u1 ii libnghttp2-141.43.0-1+deb11u1 ii libpcre3 2:8.39-13 ii libssl1.11.1.1w-0+deb11u1 ii libxml2 2.9.10+dfsg-6.7+deb11u4 ii perl 5.32.1-4+deb11u3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 apache2-bin recommends no packages. Versions of packages apache2-bin suggests: ii apache2-doc 2.4.61-1~deb11u1 pn apache2-suexec-pristine | apache2-suexec-custo ii lynx [www-browser] 2.9.0rel.1-0.2 ii w3m [www-browser] 0.5.3+git20210102-6+deb11u1 Versions of packages apache2 depends on: ii apache2-data 2.4.61-1~deb11u1 ii apache2-utils2.4.61-1~deb11u1 ii dpkg 1.20.13 ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii mime-support 3.66 ii perl 5.32.1-4+deb11u3 ii procps 2:3.3.17-5 Versions of packages apache2 recommends: ii ssl-cert 1.1.0+nmu1 Versions of packages apache2 suggests: ii apache2-doc 2.4.61-1~deb11u1 pn apache2-suexec-pristine | apache2-suexec-custo ii lynx [www-browser] 2.9.0rel.1-0.2 ii w3m [www-browser] 0.5.3+git20210102-6+deb11u1 Versions of packages apache2-bin is related to: ii apache2 2.4.61-1~deb11u1 ii apache2-bin 2.4.61-1~deb11u1 -- no debconf information
Bug#1076149: debootstrap: distro-info shall be at *most* Recommends
Package: debootstrap Version: 1.0.136 Severity: normal X-Debbugs-Cc: t...@mirbsd.de It is a useless dependency, only used when no script is given after all (thankfully; the Depends gave me a shock thinking newer debootstrap versions can no longer just be used on any Linux). -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii distro-info 1.7 ii wget 1.24.5-1 Versions of packages debootstrap recommends: pn arch-test ii debian-archive-keyring 2023.4 ii gnupg 2.2.43-7 ii mount 2.40.2-1 Versions of packages debootstrap suggests: ii binutils2.42.50.20240710-1 pn squid-deb-proxy-client pn ubuntu-archive-keyring ii xz-utils5.6.2-2 ii zstd1.5.6+dfsg-1 -- no debconf information
Bug#1010627: molly-guard: check cryptsetup passwords on shutdown
Package: molly-guard Version: 0.7.2 Followup-For: Bug #1010627 X-Debbugs-Cc: t...@mirbsd.de You could scan the crypttab on nōn-systemd services for devices with “initramfs” in the last field, and/or offer an /etc/defaults/ file where one could list their crypt devices to check (the raw names, i.e. something like /dev/sda2, LABEL=foo or UUID=foo) and then iterate over them with: cryptsetup --test-passphrase luksOpen $device -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-30-amd64 (SMP w/1 CPU thread) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages molly-guard depends on: ii procps 2:3.3.17-5 molly-guard recommends no packages. molly-guard suggests no packages. -- no debconf information
Bug#1076100: /usr/share/initramfs-tools/hooks/cryptroot: replaces stable LABEL=… lines in crypttab with unstable UUID=… entries
Package: cryptsetup-initramfs Version: 2:2.3.7-1+deb11u1 Severity: normal X-Debbugs-Cc: t...@mirbsd.de The /cryptroot/crypttab file in the initramfs contains lines like: cPV UUID=---- none discard,luks,initramfs This is bad because these are less stable than the LABEL=… lines I put into crypttab(5): the UUID changes then you do a restore from backup, whereas the LABEL can be easily made to stay the same. It should not do so for LABEL= lines. (I can understand wishing to do so for others, but even GRUB has a GRUB_DISABLE_LINUX_UUID=true option because they realise UUIDs can be troubling.) -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-5.10.0-30-amd64 root=/dev/mapper/vg---lv--root ro rootdelay=5 net.ifnames=0 ip=6,0,eth0,.mirbsd.org,2a02:::::1/64,fe80::1 nomodeset TZ=:UTC -- /etc/crypttab # cPV LABEL=cPV nonediscard,luks,initramfs cswp1 /dev/vg-/lv-swp1/dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap cswp2 /dev/vg-/lv-swp2/dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap -- /etc/fstab /dev/vg-/lv-root / ext4 defaults,auto_da_alloc,relatime,lazytime 0 2 LABEL=-boot /boot ext4 defaults,auto_da_alloc,noatime,lazytime,nodev,noexec 0 1 swap /tmp tmpfs defaults,noatime,lazytime,nosuid,nodev0 0 /dev/vg-/lv-mbsd /var/anoncvs ext4 defaults,auto_da_alloc,noatime,lazytime,nodev 0 3 /dev/mapper/cswp1 swap swap sw,discard=once 0 0 /dev/mapper/cswp2 swap swap sw,discard=once 0 0 swap /var/log/apache2 tmpfs size=37748736,async,noatime,lazytime,auto,nodev,noexec,nosuid,rw,nouser,uid=0,gid=4,mode=2750 0 0 -- lsmod Module Size Used by nft_reject_inet16384 7 nf_reject_ipv4 16384 1 nft_reject_inet nf_reject_ipv6 20480 1 nft_reject_inet nft_reject 16384 1 nft_reject_inet nf_tables 274432 56 nft_reject_inet,nft_reject libcrc32c 16384 1 nf_tables nfnetlink 20480 1 nf_tables joydev 28672 0 drm_kms_helper278528 0 evdev 28672 2 cec61440 1 drm_kms_helper sg 36864 0 serio_raw 20480 0 pcspkr 16384 0 drm 634880 1 drm_kms_helper virtio_balloon 24576 0 qemu_fw_cfg20480 0 button 24576 0 dm_crypt 57344 3 dm_mod163840 19 dm_crypt ext4 942080 3 crc16 16384 1 ext4 mbcache16384 1 ext4 jbd2 151552 1 ext4 crc32c_generic 16384 0 hid_generic16384 0 usbhid 65536 0 hid 151552 2 usbhid,hid_generic crc32_pclmul 16384 0 crc32c_intel 24576 7 sd_mod 61440 3 t10_pi 16384 1 sd_mod crc_t10dif 20480 1 t10_pi crct10dif_generic 16384 0 crct10dif_pclmul 16384 1 crct10dif_common 16384 3 crct10dif_generic,crc_t10dif,crct10dif_pclmul virtio_scsi24576 2 virtio_net 61440 0 net_failover 24576 1 virtio_net failover 16384 1 net_failover ghash_clmulni_intel16384 0 ata_generic16384 0 uhci_hcd 57344 0 ata_piix 36864 0 libata299008 2 ata_piix,ata_generic ehci_hcd 98304 0 aesni_intel 372736 6 scsi_mod 270336 4 virtio_scsi,sd_mod,libata,sg libaes 16384 1 aesni_intel crypto_simd16384 1 aesni_intel cryptd 24576 5 crypto_simd,ghash_clmulni_intel glue_helper16384 1 aesni_intel psmouse 184320 0 virtio_pci 28672 0 virtio_ring36864 4 virtio_balloon,virtio_scsi,virtio_pci,virtio_net virtio 16384 4 virtio_balloon,virtio_scsi,virtio_pci,virtio_net i2c_piix4 28672 0 usbcore 331776 3 usbhid,ehci_hcd,uhci_hcd usb_common 16384 3 usbcore,ehci_hcd,uhci_hcd floppy 90112 0 -- System Information: Debian Release: 11.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-30-amd64 (SMP w/1 CPU thread) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages cryptsetup-initramfs depends on: ii busybox 1:1.30.1-6+b3 ii cryp
Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Helge Deller dixit: >* Thorsten Glaser : >> >> Maybe other 5/6-argument syscalls also need review… > >Yes, and basically I tink it's stupid to try to distinguish syscalls >with 1-4 arguments from those which use 5 or 6 arguments. >With every added syscall someone needs to check again. Agreed. >That way we don't need to distinguish and it will always work. >The downside is some small overhead for every syscall, but I >think this is neglectable. I think this is a good solution. Squeezing every last instruction out is something for active projects with large manpower or something. >Maybe you can apply it? Uploaded, thanks. >(btw, upstream dietlibc is dead?) dead-ish, but in general, unresponsive to requests to apply the patches we have in Debian; I tried to reach out multiple times over the years since 2011 and never got a response. Our entire ARM support totally differs from upstream’s by now even… 🙀 however it works, so I’ve not switched to the latter. I think, by now, it’s mostly on life support but works good enough to justify not throwing it away. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Helge Deller dixit: > The attached patch fixes the dietlibc testsuite crash on hppa > in the socketfns testcase. Thanks, applied. > So, instead of adding and ifdef for hppa/syscall6_weak, simply > drop the weak function and call the normal __unified_syscall6. Looking at the nm output of libc.a, it seems to use the 6 version for sendto but not recvfrom. Huh. Maybe other 5/6-argument syscalls also need review… > I think it was simply luck why the testcase succeeded on physical machines. OK, I reverted the marking as expect-fail and uploaded your patch. Thanks, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1075820: libklibc-dev: unusable on hppa with recent Linux: conflicting types for 'sigset_t'
Helge Deller dixit: > Maybe sigset_t needs to be removed from > klibc/include/arch/parisc/klibc/archsignal.h ? That (with a versioned Depends on the newer kernel headers) or with a #if LINUX_VERSION_CODE < KERNEL_VERSION(6, 9, 0) (which will end up causing similar hassle should the change be backported to stable kernels). But, yes, such changes to the headers generally require changes to klibc, as it subsumes those headers explicitly. This bugreport was intended to signal to the developers to please do so ☻ bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1075820: libklibc-dev: unusable on hppa with recent Linux: conflicting types for 'sigset_t'
Package: libklibc-dev Version: 2.0.13-4 Severity: important X-Debbugs-Cc: t...@mirbsd.de, Helge Deller ] In file included from /usr/lib/klibc/include/signal.h:14, ] from /usr/lib/klibc/include/sys/select.h:11, ] from /usr/lib/klibc/include/unistd.h:13, ] from conftest.c:9: ] /usr/lib/klibc/include/arch/parisc/klibc/archsignal.h:17:3: error: conflicting types for 'sigset_t'; have 'struct ' ]17 | } sigset_t; ] | ^~~~ ] In file included from /usr/lib/klibc/include/arch/parisc/klibc/archsignal.h:11: ] /usr/lib/klibc/include/asm/signal.h:72:3: note: previous declaration of 'sigset_t' with type 'sigset_t' ]72 | } sigset_t; ] | ^~~~ This is with linux-libc-dev_6.9.7-1
Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Helge Deller dixit: > Beside the kernel & glibc patches some qemu-user patches will probably > be necessary as well. I think so, given how it basically interposes for both. > I think disabling such tests is probably best right now. OK. I’ll try debootstrapping an hppa chroot in qemu and see if I can reproduce it locally. You’re not on IRC (OFTC), are you? bye, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Helge Deller dixit: > I just did a give-back, and this time the build succeeded (on the > "c8000" buildd server). The last build failed on the "pasta" buildd > server, which is a qemu-user based build machine, while "c8000" is > a physical server which runs the *very latest* stable native > Linux kernel (v6.9.7). Aaah, that could of course be a thing. > Of course I will try to reproduce it on "pasta" again just to If this can be reproduced under qemu-user but not on native hardware I can mark that test as expected to fail under qemu-user. There’s a few of them already. Perhaps qemu-user does not yet support the new constants from those patches? bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Helge Deller dixit: > Ok, so we have to wait until at least the oldstable kernels are "new" enough. Given hppa is a ports architecture and this had some time to percolate, I applied the patches now. However, I get a (possibly unrelated) build failure on hppa now (dietlibc in experimental): debian/unittests/socketfns.c segfaults. I thought I could have a look on a porterbox, but unfortunately, the one that says porterbox is also used as a buildd and so has no CPU percentage to spare for interactive use, and the one that says porterbox/buildd doesn’t accept my SSH key, so perhaps you could have at this on some of your machine(s)? Thanks in advance, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#1069365: dietlibc: FTBFS on arm64: E: Build killed with signal TERM after 150 minutes of inactivity
tags 1069365 + confirmed pending
thanks
Lucas Nussbaum dixit:
>> E: Build killed with signal TERM after 150 minutes of inactivity
Indeed, it busy-spins in diet(1):
include/sys/cdefs.h:#define __likely(foo) __expect((foo),1)
29 size_t strlen(const char *s)
30 {
42 register size_t i;
43 for (i=0; __likely(*s); ++s) ++i;
44 return i;
So, something miscompiles this.
While I don’t speak arm64 assembly, my best guess is…
Dump of assembler code for function strlen:
0x00401800 <+0>: bti c
0x00401804 <+4>: adrpx1, 0x41
0x00401808 <+8>: mov x3, x0
0x0040180c <+12>:mov x2, x0
0x00401810 <+16>:ldr w1, [x1, #776]
0x00401814 <+20>:cbz w1, 0x401830
0x00401818 <+24>:b 0x401800
… that GCC optimises the for loop into a call to strlen,
for which I have multiple ideas.
Thanks,
//mirabilos
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no idea and rebasing just fscked │ Segmentation
should have cloned into a clean repo │ fault (core dumped)
if I rebase that now, it's really ugh │ wuahh
Bug#1074595: dygraphs: Move from jsdoc-toolkit to node-jsdoc2
Bastian Germann dixit: > Please move from to-be-removed jsdoc-toolkit to node-jsdoc2. Aah! (Translation: can the nodejs world even do *anything* stable?) Given I’m also now upstream but have practically no idea about jsdoc-whatever, a patch would be welcome, even if just as a starting point (otherwise I pretty much have no idea about this). bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D
Bug#1074346: Trixie and later on i386 will no longer support UEFI Secure Boot
Steve McIntyre dixit: >we no longer have a signed >shim. Signed GRUB and fwupd-efi packages will also be removed soon. Might want to note this on amd64 as well, for those 64-bit systems with 32-bit EFI. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
Hi Guillem, >These directories are included because the package should be >self-contained and ship all required parent directories, otherwise >dpkg would fail to unpack as you mentioned (even though there's right. >generally the Essential set in play), and so that the directory >"ref-counting" (as a shared resource) works and the last package >shipping it that gets removed/purged (regardless of the order) can >properly remove all owned entries. Also for «dpkg -S»'s sake. If I omit just the top-level directories (bin, etc, usr), these things all still work (see my previous message), and I specifically tested dpkg -S both on unmerged bookworm (a buildd chroot, hence unmerged) and merged sid (chroot). >> Hmh, lintian warns, and dpkg needs the directories present if >> not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs. > >It looks like you went in this direction for the packages in Debian. No, I have not uploaded anything yet. I only attached as experiment… https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1073608;filename=mksh_59c-38_amd64.deb;msg=39 … to this bugreport, for inspection by Helmut and others to see whether this approach will suffice as I refuse to introduce trouble for users by moving the files around. Could you please have a look at it, compared with 59c-37 in sid, to see whether this would work for you? My tests indicate so. Directory refcounting is not a problem as a package that does not ship say /bin in its data.tar can create a symlink in /bin/ as part of the maintainer scripts. The top-level directories are Essential. >But I'd ask you to please stop doing that, as I consider this to also >be breaking dpkg assumptions. And as part of the filesystem metadata Huh, then we’re at an impasse… although, again, the implicit “base-files has to be extracted first” with base-files containing the /bin symlink will suffice for any normal operation, and as to Helmut saying that “dpkg-deb -x” will cause problems, I’ll have to defer this to you as dpkg maintainer to fix. >In the future my plan is to add a special dpkg filesystem metadata type […] That’d be good, except… >parent). So the data.tar would contain /usr/bin/, the package … no, data.tar should still be able to contain /bin/. The CTTE decision for the installed OS to be usrmerged has no bearing on individual packages’ layout after all, and the .deb files could conceivably also be used on nōn-usrmerged systems, so this entire “fun” needs to be done outside of packages (other than base-files and the Essential set, of course). bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
Dixi quod… >Or, better yet, absence of that entry in the ustar (possibly >combined with a Pre-Depends). It’s ridiculous that every pak‐ >kage ships all those directory entries anyway. That avoids Hmh, lintian warns, and dpkg needs the directories present if not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs. I’ll experiment later when less headaches. 🐈⬛, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#1073608: Bug#1073622: Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
Dixi quod… >If your only concern is the “undeclared symlink conflict”, >I’d be willing to entertain considering adding a Pre-Depends >and/or changing the top-level “bin” in the data.tar.xz member Or, better yet, absence of that entry in the ustar (possibly combined with a Pre-Depends). It’s ridiculous that every pak‐ kage ships all those directory entries anyway. That avoids trouble when extracting without the ‘h’ option of tar as well as trouble from moving files around. Meow, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1073608: Bug#1073622: Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
Helmut Grohne dixit: >There is a significant difference here. mksh has an undeclared directory >vs symlink conflict with base-files about /bin. This is known to cause >problems. But there’s handling in installers to deal with that, and by keeping the files in mksh in the same location, there won’t be any of the problems with possibly missing files, symlinks, etc. (This is worse for mksh because it’s often used as /bin/sh as well.) > In principle, what happens with the location is dependent on >the unpack order though all practical installations will unpack >base-files before mksh. See. >For another dpkg-deb -x mksh.deb / will break a /usr-merged system. That is not my problem but that of those who decided to use a filesystem layout that dpkg doesn’t support. >a different one than the one I requested, but the status quo is not >something we can continue using as is. Why? You systemd iconoclasts got your filesystem layout, so no need to break even more stuff by hurriedly moving stuff around that doesn’t need to be moved. I very much disagree with this. If your only concern is the “undeclared symlink conflict”, I’d be willing to entertain considering adding a Pre-Depends and/or changing the top-level “bin” in the data.tar.xz member of the .deb ar archive to a symbolic link when building for trixie and newer only. AIUI, this shouldn’t make a difference when the system is already poetteringised, which, by requirement for fully upgraded bookworm systems, it is. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
close 1073608 close 1073622 thanks Helmut Grohne dixit: >This package is part of the /usr-move (DEP17) transition, because it >contains files in aliased locations and should have those files moved to No. The files in both packages are in their canonical location. And if you use a usrmerged system, it does not make any practical difference anyway. For mksh, this is even worse as I regularily backport to before bookworm so newer version numbers must be able to stay in their current canonical (i.e. /bin/) location. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1073508: libxml2: just another API+ABI break; please bump soname
On Mon, 17 Jun 2024, Aron Xu wrote: >Control: tags -1 - pending Oops, right. >It looks that this libxml2 update is causing more troubles than >expected, I would like to ask for your opinion whether it's better to >revert to an older version for the moment? Might be useful while you ask upstream what they’re doing there with regards to both API and ABI, and/or someone diffs the API and ABI surface of the old and new version and figures out whether there are any other such surprises. Security fixes might need backporting though. Maybe they haven’t realised themselves and decide they need to bump to libxml3 upstream at some point. bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1073508: another libxml2 ABI break, might need RM attention (Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’)
On Sun, 16 Jun 2024, Thorsten Glaser wrote: >Better prevent this from landing in trixie until the package >gets its soname bumped. In fact, unless someone has the tuits to diff every single API and ABI surface of the package between trixie (ideally bookworm) and sid versions, it would be best if any package built against libxml2 >2.12 be binNMU’d in trixie, and once 2.12 is renamed to libxml3 or something, they are to be rebuilt in sid anyway. Who knows what other API and ABI breaks are hiding herein… bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
clone 1073313 -1 reassign -1 libxml2 found -1 2.12.7+dfsg-3 retitle -1 libxml2: just another API+ABI break; please bump soname severity -1 serious tags -1 sid thanks On Sun, 16 Jun 2024, Thorsten Glaser wrote: >This is not the first time in *very* recent history that libxml2 >has an ABI break (e.g. LibreOffice ran into that), and… I wonder […] >Looking at the other context in that commit, the “flags” member >definitely does *not* replace the “checked” member in a compatible >way. Rather, the functionality that used to be behind “checked” >is gone in its entirety. Better prevent this from landing in trixie until the package gets its soname bumped. bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
On Sun, 16 Jun 2024, Yavor Doganov wrote:
>IMVHO removing a public struct member constitutes an API break.
Definitely. I just took a peek at this.
>It is also an ABI break, because if a program or a library accesses
>such member and is compiled against an old libxml2 version that is
>supposed to be ABI-compatible (like 2.9.14+dfsg-1.3 in trixie), it
>will crash at runtime with the new library version.
I thought “could be, could be not” from:
@@ -56,10 +58,8 @@ struct _xmlEntity {
struct _xmlEntity *nexte; /* unused */
const xmlChar *URI; /* the full URI as computed */
intowner; /* does the entity own the childrens */
-int checked; /* was the entity content
checked */
- /* this is also used to count entities
-* references done from that entity
-* and if it contains '<' */
+intflags; /* various flags */
+unsigned long expandedSize; /* expanded size */
};
/*
… but then I looked at the git history and saw:
commit f34f184f8e957e6f9a6eda9859ce85e883c77e5f
Author: Nick Wellnhofer
Date: Mon Dec 19 15:24:53 2022 +0100
entities: Add "flags" member to struct xmlEntity
This will hold various flags and eventually replace the "checked"
member.
[…]
--- a/include/libxml/entities.h
+++ b/include/libxml/entities.h
@@ -60,6 +60,7 @@ struct _xmlEntity {
/* this is also used to count entities
* references done from that entity
* and if it contains '<' */
+intflags; /* various flags */
};
/*
This is not the first time in *very* recent history that libxml2
has an ABI break (e.g. LibreOffice ran into that), and… I wonder
what kind of shitshow upstream runs when they commit things like
that‽
commit ce76ebfd1312459951d555ad9d87fb9a89eede55
Author: Nick Wellnhofer
Date: Mon Dec 19 20:56:23 2022 +0100
entities: Stop counting entities
This was only used in the old version of xmlParserEntityCheck.
[…]
--- a/include/libxml/entities.h
+++ b/include/libxml/entities.h
@@ -56,10 +56,6 @@ struct _xmlEntity {
struct _xmlEntity *nexte; /* unused */
const xmlChar *URI; /* the full URI as computed */
intowner; /* does the entity own the childrens */
-int checked; /* was the entity content
checked */
- /* this is also used to count entities
-* references done from that entity
-* and if it contains '<' */
intflags; /* various flags */
unsigned long expandedSize; /* expanded size */
};
Looking at the other context in that commit, the “flags” member
definitely does *not* replace the “checked” member in a compatible
way. Rather, the functionality that used to be behind “checked”
is gone in its entirety.
bye,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1073062: e2fsprogs: orphan_file option not even documented
Theodore Ts'o dixit: >That being said, a quick Google search would have turned up this >explanation of the orphan_file feature, from the kernel documentation: > > > https://www.kernel.org/doc/html/latest/filesystems/ext4/globals.html#orphan-file Yes, that’s what I found later as well, when I was still wondering what it was good for. The use case I was thinking of when looking in manpages was to figure out the exact syntax for tune2fs from a rescue system of some kind while offline. >The TL;DR is[…] Right, it does make sense. >So first of all, I very much doubt that the Debian Release Managers >would consider a documentation addition to be critical enough to >warrant a backport to Debian Stable, since that seems to be reserved >for critical bug fixes, especially those that are security related. I Right… but perhaps if you have to update it anyway, or so… >Secondly, while I do backport from Debian Testing (trixie) to Debian >Backports (bookworm-backports), there is certainly no policy which >mandates that a package be backported. Of course not, but given you already backported from testing(bookworm) to bullseye, Backports policy indicates that the backport should be kept in sync with later updates to then-testing or at least be brought up to the version now in bookworm-as-stable. >I suppose if I had time I could try to wrangle an upload to >bullseye-backports-sloppy, although I've generally not bothered to do >backports to Debian oldstable. That gets old really soon, yes, but the existing backport in bullseye-backports (not -sloppy) should be updated at least. This would give the world a slightly better-than-average chance at obtaining a tune2fs and e2fsck capable of working with that. (For example, I can install most bullseye packages on the live ISO I use as it was cut from testing not too long before the release… I actually have been considering trying to re-roll it based on the bullseye release, with all security and other fixes applied and a few more packages included.) I do know that adding changes unrelated to backporting is also frowned upon, but the second-to-last entry in /u/s/d/e/c.D.gz will at least contain the two magic words needed, and that may be enough. Thanks, //mirabilos -- 08:05⎜ mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ yeah. /bin/rm. ;) 08:09⎜ hexdump -C 08:31⎜ ft, mrud: *g*
Bug#1073062: e2fsprogs: orphan_file option not even documented
Package: e2fsprogs Version: 1.47.1~rc2-1 Severity: normal Tags: bookworm trixie sid X-Debbugs-Cc: t...@mirbsd.de Looking at the whole metadata_csum_seed and orphan_file thing, I wanted to see in the manpages where they are described, also so I can find them for copy/pasting later for disabling where needed. metadata_csum_seed was easily found, but I could not find orphan_file in ext4(5) nor tune2fs(8) nor (in raising levels of panic) mkfs.ext4(8), and not even in mke2fs.conf(5). In a slightly less unideal world, this would be documented there, also in bookworm, and the fix also included should you wish to follow Debian Backports policy and update the bullseye-backports version to the bookworm one. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages e2fsprogs depends on: ii libblkid1 2.40-8 ii libc6 2.37-19 ii libcom-err21.47.1~rc2-1 ii libext2fs2t64 1.47.1~rc2-1 ii libss2 1.47.1~rc2-1 ii libuuid1 2.40-8 ii logsave1.47.1~rc2-1 Versions of packages e2fsprogs recommends: pn e2fsprogs-l10n Versions of packages e2fsprogs suggests: pn e2fsck-static pn fuse2fs pn gpart ii parted 3.6-4 -- no debconf information
Bug#1072804: mod_autoindex: should default to XHTML and send the charset in the document
Package: apache2
Version: 2.4.59-1~deb11u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
The W3C validator is not quite happy with the default directory indicēs.
Applying the following change to its config…
- IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=*
DescriptionWidth=* Charset=UTF-8
+ IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=*
DescriptionWidth=* Charset=UTF-8 XHTML
… makes it a little happier, only one warning left (no HTML
meta element to declare the charset, which would involve
patching the C source to emit…
("\n",
whateverCharsetVar);
… as well (the whateverCharsetVar is the content of the 「Charset=UTF-8」
config from IndexOptions).
-- Package-specific info:
-- System Information:
Debian Release: 11.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-30-amd64 (SMP w/1 CPU thread)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages apache2 depends on:
ii apache2-bin 2.4.59-1~deb11u1
ii apache2-data 2.4.59-1~deb11u1
ii apache2-utils2.4.59-1~deb11u1
ii dpkg 1.20.13
ii init-system-helpers 1.60
ii lsb-base 11.1.0
ii mime-support 3.66
ii perl 5.32.1-4+deb11u3
ii procps 2:3.3.17-5
Versions of packages apache2 recommends:
ii ssl-cert 1.1.0+nmu1
Versions of packages apache2 suggests:
pn apache2-doc
pn apache2-suexec-pristine | apache2-suexec-custom
ii lynx [www-browser] 2.9.0rel.1-0.2
Versions of packages apache2-bin depends on:
ii libapr1 1.7.0-6+deb11u2
ii libaprutil1 1.6.1-5+deb11u1
ii libaprutil1-dbd-pgsql1.6.1-5+deb11u1
ii libaprutil1-dbd-sqlite3 1.6.1-5+deb11u1
ii libaprutil1-ldap 1.6.1-5+deb11u1
ii libbrotli1 1.0.9-2+b2
ii libc62.31-13+deb11u10
ii libcrypt11:4.4.18-4
ii libcurl4 7.88.1-10+deb12u5~bpo11+0wtf1
ii libjansson4 2.13.1-1.1
ii libldap-2.4-22.4.57+dfsg-3+deb11u1
ii liblua5.3-0 5.3.3-1.1+deb11u1
ii libnghttp2-141.43.0-1+deb11u1
ii libpcre3 2:8.39-13
ii libssl1.11.1.1w-0+deb11u1
ii libxml2 2.9.10+dfsg-6.7+deb11u4
ii perl 5.32.1-4+deb11u3
ii zlib1g 1:1.2.11.dfsg-2+deb11u2
Versions of packages apache2-bin suggests:
pn apache2-doc
pn apache2-suexec-pristine | apache2-suexec-custom
ii lynx [www-browser] 2.9.0rel.1-0.2
Versions of packages apache2 is related to:
ii apache2 2.4.59-1~deb11u1
ii apache2-bin 2.4.59-1~deb11u1
-- Configuration Files:
/etc/apache2/conf-available/charset.conf changed [not included]
/etc/apache2/conf-available/security.conf changed [not included]
/etc/apache2/mods-available/autoindex.conf changed [not included]
/etc/apache2/mods-available/mpm_prefork.conf changed [not included]
/etc/apache2/sites-available/000-default.conf changed [not included]
/etc/apache2/sites-available/default-ssl.conf changed [not included]
/etc/logrotate.d/apache2 changed [not included]
-- no debconf information
Bug#1072768: debian-installer: menu item to select to install oldstable gone
Package: debian-installer Severity: normal X-Debbugs-Cc: t...@mirbsd.de https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso I was booting in expert mode and expecting between the mirror select and the installing of the base system there to be an option to select which release to install (oldstable, stable, testing, unstable), as I have been using occasionally for years. This menu did not show up. -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-29-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init)
Bug#1072165: ftpmasters: please decide on sunrpc in dietlibc
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: christ...@iwakd.de, t...@mirbsd.de, bastian.germ...@gmx.de Control: blocks -1 1067946 1069365 Dear ftpmasters, in #1067946 it was reported that some consider the sunrpc code as included in dietlibc nōn-free. Given that the actual wording is… > […] Users > * may copy or modify Sun RPC without charge, but are not authorized > * to license or distribute it to anyone else except as part of a product or > * program developed by the user. … and that we receive dietlibc as “a product or program developed by” Fefe (upstream author) under GPL, I think differently, and this *has* passed review in the past. Ultimately, *our* options are closing this as not a problem, removing dietlibc (not very favourable), and excising the code in question hoping not to break any downstream users. The reporter has also sent this to upstream, which is the correct place where to apply the fix suggested (replace with a different implementation), but there hasn’t yet been any response or decision either way. Now I don’t just want to close it or play bug pingpong, so I’d prefer there to be an official decision either way, so that we can decide what to do. (And then, I can invest some time to look at the other RC reported and try to reproduce it on a porterbox etc. but I prefer to do this when there’s not a sword of possible removal hanging over us.) Thanks in advance!
Bug#1067946: dietlibc: Includes non-free Sun RPC
Bastian Germann dixit: >> Do you have a link? > > No. It is not a public address. Ah, yes, that is unfortunate. I used to be subscribed and have no idea why I’m not, but I re-subscribed (though have not yet seen any traffic in the last couple of days). >> What did upstream say? > > No upstream response up to now. OK. I just asked in #d-ftp whether we can get an official statement on whether “we received this as part of dietlibc (a product or program developed by user” (i.e. Fefe) under GPL will suffice (which I personally consider true). If they say yes, I’ll fix that the block is missing from d/copyright and have a look at #1069365 (unless Christian prefers to). If they say no, we’ll have to inform reverse dependencies of this, ask upstream again with some more urgency, and prepare for removal of this meanwhile (I don’t think we can just swap out such much code in the packaging)… or possibly excise the sunrpc code and hope this doesn’t break any users. Until then… no idea. Wait and drink tea, or something? bye, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#1070860: musescore3: CVE-2023-44428
Moritz Mühlenhoff dixit: >Am Fri, May 10, 2024 at 06:39:20PM + schrieb Thorsten Glaser: >> This is a bit like the limited security support for binutils, >> I suppose. Could/should we document that in the same places? > >Sure thing, this sounds similar to what was done for Lilypond, Ah, okay. >best to simply ship a similar README.Debian.security within I was thinking a README.Debian with: -snip- Note on possible security issues from untrusted input: Upstream has never considered it on scope that the software cannot “crash” on incorrect input, unfortunately. There is also no security or other support for this version branch from upstream. Please consider this and don’t expose the software to untrusted, possibly incorrect, input files to avoid triggering DoS or possible security problems in its parsers without suitable confining measures. This is even more true for import filters than for the native formats’ parsers (and includes the MusicXML import). Mu͒seScore Studio was designed to operate as an unconnected desktop program and not as a remotely accessible service, so please take care. -snap- I’ll accept suggestions to improve, of course; I think I’ll add the magic word “sandboxing” to the last paragraph? bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#1070860: musescore3: CVE-2023-44428
Dixi quod… >Huh. MuseScore (Studio) is a desktop application. I’ll add a README.Debian note about that fact and that upstream has never considered crashes on invalid input a bug and that it hasn’t been designed as a remotely accessible service, but as a desktop application, and that users should confine suitably. The Capella import is a vast minority feature and incomplete anyway, so I douby many users use it directly. It’ll also document that these versions receive no support (security or otherwise) from upstream any more (they’ve gone open-core, proprietary-extension, version 4, which I don’t intend to package), though there’s a 3.x community effort whose initiator I know, which I’ve been intending to package as musescore-snapshot (it’s “tip of the git branch” without releases to avoid looking official due to the use of the well-known name) and with whom I’ll cooperate. This is a bit like the limited security support for binutils, I suppose. Could/should we document that in the same places? >I will have to investigate whether they mean indeed this >or the musescore.com site or mobile äpps or something. Given the lack of further information, I’ve contacted the ZDI to get some; otherwise I can run it with valgrind a bit, but without a reproducer testcase it’s not very likely to find it. I’ll keep the bugreport informed. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1070860: musescore3: CVE-2023-44428
Moritz Mühlenhoff dixit: >| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code >| Execution Vulnerability. This vulnerability allows remote attackers Huh. MuseScore (Studio) is a desktop application. I will have to investigate whether they mean indeed this or the musescore.com site or mobile äpps or something. But if there’s a fix for a parsing issue, I’ll backport it (also to musescore2 if applicable). Thanks for noticing, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dmitry Shachnev dixit:
>Will you be able to forward your patch upstream when you finalize it?
Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
respond well if they want me to test things with vanilla upstream
(instead of the packaging), or if they have requests I as a C (but
not C++) developer don’t understand.
(The other half of fixing things is even more challenging. I got a
confirmation that Mu͒seScore Evolution upstream cannot upgrade their
Qt versions so they’ll need a different fix subclassing and overriding
the library functions for some cases. If anyone sufficiently proficient
in C++ is interested in helping with that, once we got the fix for Qt
itself going, ping me. Alternatively, helping to figure out how to patch
and rebuild the exact versions they use for Win/Mac or upgrade their
versions without losing Win7 and qtwebengine, IIUC — AIUI their Mac OSX
builds are still at Qt 5.9 for that reason…)
>> +static inline int roundForBbox(qreal v)
>> +{
>> +return (v < 0) ? floor(v) : ceil(v);
>> +}
>
>I see you are passing negated values to this function, e.g. roundForBbox(-x).
Not only them. And roundForBbox is basically just the canonical
“round away from zero / towards ±infinity for integer results”.
The negation in the callers is to convert *some* Qt coordinates
to PS/PDF coordinates, but only for the Y axis, as the X axis is
the same for them.
>I see why you moved properties to the top, but is moving postscriptName
>needed? Maybe leave it where it was to minimize the diff?
It’s not. I moved the whole block to make it easier to read,
but good point.
>You are passing scalep pointer here only to multiply it by this value?
Yes.
>It looks like fontEngine is a public member of QFontSubset, so you can
>do it in the calling code.
Yes, except it’s the callee that determines the scaling factor,
not the caller. By passing it back like this, nothing would have
to change in the caller should the callee ever decide to not scale.
Sune Stolborg Vuorela dixit:
>I can't find any references to something that look like a "OS/2" table
>in the pdf spec.
That’s because we’re talking about OTF/TTF-format tables here.
The problem exists at two different layers.
One is that, when embedding and subsetting a font, Qt generates
a PDF font descriptor whose bounding box is wrong.
The other is that, when embedding and subsetting a font, Qt
converts it to quadratic-spline TTF and scales it to 2048 ppem,
then embedding the resulting TTF in the data object corresponding
to the above-mentioned font descriptor (the data object itself,
when extracted, is a fully functional .ttf font file). The OTF/TTF
file format has description tables, and Qt does not correctly adjust
all values in all tables it includes when scaling the font itself.
>Just to help me double check, how is is the OS/2 table described in the
>font in the pdf ?
The references I’ve been using are:
PDF:
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.0.pdf
TTF: https://learn.microsoft.com/en-us/typography/opentype/spec/
The OS/2 table specifically is documented at:
https://learn.microsoft.com/en-us/typography/opentype/spec/os2
bye,
//mirabilos
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod…
>Dmitry Shachnev dixit:
>>Now that you dug so deeply, maybe you can try to replace qRound in those
>>three lines that you mentioned with TO_TTF, and check if it fixes the bug
>
>That *and* figure out somehow how to fix the PDF /FontBBox, at
>least… (though I binary-patched the hhea ascender in the PDF and
>it made Atril happy, so it “should”, despite the still-wrong OS/2
>table values some of which are notably used in clipping by some
>softwares…)
Yes, that worked. I’m attaching the final patch in entirety again
for your convenience.
>I’m trying this (attached). That does both (by letting toTruetype()
>adjust the already-existing scaling factor in the caller) and
>applies suitable rounding (normal for normal values, away from zero
>for the bounding box so it’s guaranteed to encompass all possible
>values). I’ll build it now so I don’t know if it even compiles yet…
It still does not address the OS/2 table, but it does manage to
fix both the PDF-side and font-side hhea table metrics, which is
enough for Atril at least. (Not sure whether it’s enough for my
gf’s printer, I’ll have to test. Or extend the patch to fix the
OS/2 table as well, which I probably should anyway; I have to find
the time for that sometime within the next few days.)
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.miscDescription: scale /FontBBox and hhea table when scaling fonts
for embedding (the OS/2 table needs handling XXX TODO)
Author: mirabilos
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406
--- a/src/gui/painting/qpdf.cpp
+++ b/src/gui/painting/qpdf.cpp
@@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR
"endobj\n");
}
+static inline int roundForBbox(qreal v)
+{
+return (v < 0) ? floor(v) : ceil(v);
+}
+
void QPdfEnginePrivate::embedFont(QFontSubset *font)
{
+QFontEngine::Properties properties = font->fontEngine->properties();
+QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
+qreal scale = 1000/properties.emSquare.toReal();
+
//qDebug() << "embedFont" << font->object_id;
int fontObject = font->object_id;
-QByteArray fontData = font->toTruetype();
+QByteArray fontData = font->toTruetype(&scale);
#ifdef FONT_DUMP
static int i = 0;
QString fileName("font%1.ttf");
@@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS
int toUnicode = requestObject();
int cidset = requestObject();
-QFontEngine::Properties properties = font->fontEngine->properties();
-QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
-
{
-qreal scale = 1000/properties.emSquare.toReal();
addXrefEntry(fontDescriptor);
QByteArray descriptor;
QPdf::ByteStream s(&descriptor);
@@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS
s << '+' << postscriptName << "\n"
"/Flags " << 4 << "\n"
"/FontBBox ["
- << properties.boundingBox.x()*scale
- << -(properties.boundingBox.y() +
properties.boundingBox.height())*scale
- << (properties.boundingBox.x() +
properties.boundingBox.width())*scale
- << -properties.boundingBox.y()*scale << "]\n"
+ << roundForBbox(properties.boundingBox.x()*scale)
+ << roundForBbox(-(properties.boundingBox.y() +
properties.boundingBox.height())*scale)
+ << roundForBbox((properties.boundingBox.x() +
properties.boundingBox.width())*scale)
+ << roundForBbox(-properties.boundingBox.y()*scale) << "]\n"
"/ItalicAngle " << properties.italicAngle.toReal() << "\n"
-"/Ascent " << properties.ascent.toReal()*scale << "\n"
-"/Descent " << -properties.descent.toReal()*scale << "\n"
-"/CapHeight " << properties.capHeight.toReal()*scale << "\n"
-"/StemV " << properties.lineWidth.toReal()*scale << "\n"
+"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n"
+"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n"
+"/CapHeight " << qRound(properties.capHeight.toReal()*scale) <<
"\n"
+"/StemV " << qRound(properties.lineWidth.toReal()*scale) << "\n"
"/FontFile2 " << fontstream << "0 R\n"
"/CIDSet " << cidset << "0 R\n"
">>\nendobj\n";
--- a/src/gui/text/qfontsubset.cpp
+++ b/src/gui/text/qfontsubset.cpp
@@ -1162,13 +1162,14 @@ static QByteArray bindFont(const QVector
if really required.
*/
-QByteArray QFontSubset::toTruetype() const
+QByteArray QFontSubset::toTruetype(qreal *scalep) const
{
qttf_font_tables font;
memset(&font, 0, sizeof(qttf_font_tables));
qreal ppem = fontEngine->fontDef.pixelSize;
#define TO_TTF(x) qRound(x * 2048. / ppem
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod… >values). I’ll build it now so I don’t know if it even compiles yet… font.hhea.ascender = TO_TTF(properties.ascent.toReal()); font.hhea.descender = TO_TTF(-properties.descent.toReal()); font.hhea.lineGap = TO_TTF(properties.leading.toReal());
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod…
>>Now that you dug so deeply, maybe you can try to replace qRound in those
>>three lines that you mentioned with TO_TTF, and check if it fixes the bug
>
>That *and* figure out somehow how to fix the PDF /FontBBox, at
I’m trying this (attached). That does both (by letting toTruetype()
adjust the already-existing scaling factor in the caller) and
applies suitable rounding (normal for normal values, away from zero
for the bounding box so it’s guaranteed to encompass all possible
values). I’ll build it now so I don’t know if it even compiles yet…
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/changelog
qtbase-opensource-src-5.15.2+dfsg/debian/changelog
--- qtbase-opensource-src-5.15.2+dfsg/debian/changelog 2021-07-02
17:58:04.0 +0200
+++ qtbase-opensource-src-5.15.2+dfsg/debian/changelog 2024-05-05
23:58:03.0 +0200
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.15.2+dfsg-9.0.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/bug1070406.diff
+
+ -- Thorsten Glaser Sun, 05 May 2024 23:58:03 +0200
+
qtbase-opensource-src (5.15.2+dfsg-9) unstable; urgency=medium
* Revert adding fix-misplacement-of-placeholder-text-in-QLineEdit.diff.
diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
--- qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
1970-01-01 01:00:00.0 +0100
+++ qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
2024-05-05 23:57:53.0 +0200
@@ -0,0 +1,107 @@
+Description: scale /FontBBox and hhea table when scaling fonts
+ for embedding (the OS/2 table needs handling XXX TODO)
+Author: mirabilos
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406
+
+--- a/src/gui/painting/qpdf.cpp
b/src/gui/painting/qpdf.cpp
+@@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR
+ "endobj\n");
+ }
+
++static inline int roundForBbox(qreal v)
++{
++return (v < 0) ? floor(v) : ceil(v);
++}
++
+ void QPdfEnginePrivate::embedFont(QFontSubset *font)
+ {
++QFontEngine::Properties properties = font->fontEngine->properties();
++QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
++qreal scale = 1000/properties.emSquare.toReal();
++
+ //qDebug() << "embedFont" << font->object_id;
+ int fontObject = font->object_id;
+-QByteArray fontData = font->toTruetype();
++QByteArray fontData = font->toTruetype(&scale);
+ #ifdef FONT_DUMP
+ static int i = 0;
+ QString fileName("font%1.ttf");
+@@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS
+ int toUnicode = requestObject();
+ int cidset = requestObject();
+
+-QFontEngine::Properties properties = font->fontEngine->properties();
+-QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
+-
+ {
+-qreal scale = 1000/properties.emSquare.toReal();
+ addXrefEntry(fontDescriptor);
+ QByteArray descriptor;
+ QPdf::ByteStream s(&descriptor);
+@@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS
+ s << '+' << postscriptName << "\n"
+ "/Flags " << 4 << "\n"
+ "/FontBBox ["
+- << properties.boundingBox.x()*scale
+- << -(properties.boundingBox.y() +
properties.boundingBox.height())*scale
+- << (properties.boundingBox.x() +
properties.boundingBox.width())*scale
+- << -properties.boundingBox.y()*scale << "]\n"
++ << roundForBbox(properties.boundingBox.x()*scale)
++ << roundForBbox(-(properties.boundingBox.y() +
properties.boundingBox.height())*scale)
++ << roundForBbox((properties.boundingBox.x() +
properties.boundingBox.width())*scale)
++ << roundForBbox(-properties.boundingBox.y()*scale) << "]\n"
+ "/ItalicAngle " << properties.italicAngle.toReal() << "\n"
+-"/Ascent " << properties.ascent.toReal()*scale << "\n"
+-"/Descent " << -properties.descent.toReal()*scale << "\n"
+-"/CapHeight " << properties.capHeight.toReal()*scale << "\n"
+-"/StemV " << properties.lineWidth.toReal()*scale << "\n"
++"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n"
++"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n"
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Hi Dmitry, (you use Googlemail, which is problematic, I picked your reply from the BTS; perhaps send to 1070406-submitter@b.d.o instead which should arrive) >I checked Qt 4 history [1] and there this code dates back to “Long live Qt!” >commit from 2009. So it’s unlikely that we can find the original developer Thanks for checking. >and ask why it is like that and whether we actually need the OS/2 table. Yeah. Some renderers might benefit from it in some cases probably. It contains about 17 or so values that need to be scaled, and it has multiple versions… I could probably write something… >(and does not break anything else)? Chances are extremely slim that fixing the metrics will break anything ;-) >Now that you dug so deeply, maybe you can try to replace qRound in those >three lines that you mentioned with TO_TTF, and check if it fixes the bug That *and* figure out somehow how to fix the PDF /FontBBox, at least… (though I binary-patched the hhea ascender in the PDF and it made Atril happy, so it “should”, despite the still-wrong OS/2 table values some of which are notably used in clipping by some softwares…) I think I can try that, though my weekend’s about up by now. I’d try it with one of the versions (most likely bullseye’s) if that is okay for you. For the Mu͒seScore side, things get trickier though as they likely won’t be able to obtain fixed Qt builds for all platforms. I wonder whether it would be possible to subclass and just override the faulty code (or do post-fixups somehow) and patch it to just do that (if the bug is still present in the used Qt version)… I’m not even a C++ programmer… *sigh* bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod…
>correct… but it only changes the metrics in the head table, not
>in the OS/2 or hhea tables (as can be seen when loading the font
>from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
>is constructed from the values from the original font.
And Atril uses the values from the hhea table (found by hexediting).
#define TO_TTF(x) qRound(x * 2048. / ppem)
This is used in things like…
font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth());
… but not in…
font.hhea.ascender = qRound(properties.ascent);
font.hhea.descender = -qRound(properties.descent);
font.hhea.lineGap = qRound(properties.leading);
… and of course not when the OS/2 table is copied:
if (!noEmbed) {
QTtfTable os2;
os2.tag = MAKE_TAG('O', 'S', '/', '2');
os2.data = fontEngine->getSfntTable(os2.tag);
if (!os2.data.isEmpty())
tables.append(os2);
}
(all examples from stretch’s Qt, as the oldest I had at hand)
bye,
//mirabilos
--
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod… >$ atril moo.pdf Further debugging reveals the cause: When Qt5 embeds a font, it scales it to 2048 ppem, no matter if it was 1000 ppem (PS/CFF) or 1024 ppem (TTF) before. I think this is because [QTBUG-586] it cannot embed CFF fonts, so it always converts to TTF (apparently even if it was TTF already). The conversion is done not incompetently, the new metrics are correct… but it only changes the metrics in the head table, not in the OS/2 or hhea tables (as can be seen when loading the font from the PDF in FontForge). Furthermore, the /FontBBox in the PDF is constructed from the values from the original font. I can confirm that if I prescale the font to 2048 ppem, ceteris paribus, the bug no longer appears. QPdfEnginePrivate::embedFont calls font->toTruetype() but later uses font->fontEngine->properties() for metrics. QFontSubset::toTruetype does the conversion to 2048 ppem and others, saying it does not need to add an OS/2 table, only to later copy the one from the original font if present without adjusting its values. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Package: qtbase5-dev
Version: 5.15.10+dfsg-7.2+b1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Control: found -1 5.15.2+dfsg-9
Control: found -1 5.7.1+dfsg-3+deb9u4
Control: affects -1 musescore
Control: affects -1 musescore3
I’ve received reports that PDFs generated by Mu͒seScore when
viewed in Atril (but not in Okular or mupdf!) have the top
of the treble clef cut off. I found that the same happens
for glyphs of the font I use for URLs and copyright notices
(attached), but only from Mu͒seScore, not from LibreOffice.
I first reported this to Atril both because I couldn’t find
anything wrong with the font metrics (or after fixing what
could have been, I tried multiple variants) upstream at
https://github.com/mate-desktop/atril/issues/610 where a
helpful soul found that there’s some clip path in the PDFs
which Atril honours that clips off the rendering but that
under that the glyphs are fully present.
Then I dug into the Mu͒seScore Studio source code, but could
not find anything suspicious, so I extracted an MWE from its
source code (under GPLv2 though I doubt the example below is
actually nōntrivial enough to be copyrightable) to generate
a PDF and, voilà, the top of the text is cut off in Atril but
not in mupdf.
I’m attaching the MWE (qex.pro + qex.cc) and the font file
(SIL OFL, currently the .otf is the source) so you can
reproduce this. It reproduces for me on stretch, bullseye and
sid, probably universally. (Make sure $DISPLAY is set. Put the
.otf into ~/.local/share/fonts/ to test.)
$ QT_SELECT=5 qmake qex.pro && make && ./qex
$ mupdf moo.pdf
$ atril moo.pdf
Please forward this bug upstream as suitable. Thanks in advance!
(I don’t have the means to test with upstream’s versions.)
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500,
'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages qtbase5-dev depends on:
ii libegl-dev 1.7.0-1+b1
ii libgl-dev 1.7.0-1+b1
ii libglu1-mesa-dev [libglu-dev] 9.0.2-1.1+b1
ii libqt5concurrent5t64 5.15.10+dfsg-7.2+b1
ii libqt5core5t64 5.15.10+dfsg-7.2+b1
ii libqt5dbus5t64 5.15.10+dfsg-7.2+b1
ii libqt5gui5t64 5.15.10+dfsg-7.2+b1
ii libqt5network5t64 5.15.10+dfsg-7.2+b1
ii libqt5printsupport5t64 5.15.10+dfsg-7.2+b1
ii libqt5sql5t64 5.15.10+dfsg-7.2+b1
ii libqt5test5t64 5.15.10+dfsg-7.2+b1
ii libqt5widgets5t64 5.15.10+dfsg-7.2+b1
ii libqt5xml5t64 5.15.10+dfsg-7.2+b1
ii libvulkan-dev 1.3.280.0-1
ii libxext-dev2:1.3.4-1+b1
ii qt5-qmake 5.15.10+dfsg-7.2+b1
ii qtbase5-dev-tools 5.15.10+dfsg-7.2+b1
ii qtchooser 66-2
Versions of packages qtbase5-dev recommends:
pn libqt5opengl5-dev
Versions of packages qtbase5-dev suggests:
pn default-libmysqlclient-dev
pn firebird-dev
pn libpq-dev
pn libsqlite3-dev
pn unixodbc-dev
-- no debconf information
#include
#include
#include
#include
#include
#include
#include
#define ensure(what) if (!(what)) errx(1, "%s", #what)
int main(int argc, char *argv[]) {
QGuiApplication MyApp(argc, argv);
QPdfWriter printerDev("moo.pdf");
QPainter p;
ensure(p.begin(&printerDev));
p.setRenderHint(QPainter::Antialiasing, true);
p.setRenderHint(QPainter::TextAntialiasing, true);
QPointF ofs(100, 1000);
QFont font("Inconsolatazi4varl_qu", 72);
p.setFont(font);
p.drawText(ofs, "foi Test 0'l");
p.end();
errx(0, "done");
}
CONFIG += debug
SOURCES += qex.cc
TARGET = qex
Inconsolatazi4varl_qu-Regular.otf
Description: application/vnd.ms-opentype
Bug#1067946: dietlibc: Includes non-free Sun RPC
Hi Bastian, >I have already informed upstream about it. did you do that on a mailing list? Do you have a link? What did upstream say? Still unconvinced, //mirabilos -- If Harry Potter gets a splitting headache in his scar when he’s near Tom Riddle (aka Voldemort), does Tom get pain in the arse when Harry is near him? -- me, wondering why it’s not Jerry Potter………
Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Jay Berkenbilt dixit: >How's that? That explains it very well and not ambiguous to nōn-native speakers (I hope). Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#789401: Proposed patch to solve the issue.
Hi Georgios, why not just ensure the parent directory of the chroot is not traversable for just any normal user? That would allow preserving /tmp/buildd as build place as well as retaining stuff under /run which packages create and which is, in practice, often needed for chroots where initscripts are not run. In addition, I often do use the access to the /tmp in the chroot for debugging and bootstrapping, so maybe create a new system group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750 that directory, and good is? (Untested.) Then, I could add my user to that group and continue doing so. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1069697: lintian: debian-changelog-line-too-short CVEs
Richard Lewis dixit: >would it make a difference if the somewhat ambiguous line "CVEs" was >changed to "Fixes the following CVEs:" ? It’s very much not ambiguous, as the entire entry is a list of fixes, that’d be reducing the signal:noise ratio (besides this part of the changelog is copy-pasted from the upstream release announcement). I find that lintian is overly opinionated here. I could agree, were this just a single line (given the tag’s stated purpose), but not for multi-line or lists. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >So Thorsten, in case you or someone else is aware of any [intermediate] >results from these task forces ([9[) it would be nice to hear about >them or better even in form of some "official" statement from Debian. JFTR I’m not involved in those myself. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1069697: lintian: debian-changelog-line-too-short CVEs
Package: lintian Version: 2.117.0 P: openjdk-8-doc: debian-changelog-line-too-short CVEs [usr/share/doc/openjdk-8-doc/changelog.Debian.gz:4] The changelog in question is: * New upstream release * CVEs - CVE-2024-21011 - CVE-2024-21085 - CVE-2024-21068 - CVE-2024-21094 * Security fixes […] I find this a little opinionated anyway, but here not quite appropriate as the changelog “line” spans more than a physical line. Maybe, if you won’t consider the space until the next /^ \* / a “line”, then at least exclude itemisations from that tag? Thanks.
Bug#1069678: openjdk-8: CVE-2024-21011 CVE-2024-21068 CVE-2024-21085 CVE-2024-21094
tags 1069678 + pending thanks I’m working on it. Upload should come RSN. AIUI the security team can feel free to ignore openjdk-8 as it’s in sid for bootstrapping and preparing ELTS upgrades and downstreams purposes, and not “as is” security-supported in Debian, so if it helps lowering the workload…
Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches
Hi Nilesh, >Right. AFAICS, lintian spews that warning because the header in that patch in >incomplete. It also needs a "From" and "Subject" (which can be same as commit this is not entirely correct. The full patch header is: Description: fix typeset -p confusion between empty and unset Origin: commit:10065BC69BE555D6721 Description is the standard name for Subject (the same way Author is the standard DEP 3 name for From), and it’s present, and when Origin indicates an upstream commit (as shown here), Author does not need to be present, per DEP 3. bye, //mirabilos -- If Harry Potter gets a splitting headache in his scar when he’s near Tom Riddle (aka Voldemort), does Tom get pain in the arse when Harry is near him? -- me, wondering why it’s not Jerry Potter………
Bug#1068873: openjdk-21: more m68k patches
Dixi quod…
>>I’ll recompile with re-enabled alignment on the missing base
>
>Seems to be only one.
>
>--- src/hotspot/share/memory/allocation.hpp~ 2024-04-12 23:52:54.0
>+
>+++ src/hotspot/share/memory/allocation.hpp2024-04-12 23:52:56.0
>+
>@@ -276,7 +276,7 @@ class CHeapObj {
> void operator delete [] (void* p) {
> CHeapObjBase::operator delete[](p);
> }
>-};
>+} __attribute__ ((aligned (4)));
>
> // Base class for objects allocated on the stack only.
> // Calling new or delete will result in fatal error.
>
>>classes like we have in 17. But if someone has ideas ’til then…
>
Yes, with this, the build gets much further, so I’d be glad if you
could include this in the next -21 upload (and -20 if you do any
more of these, but probably not, and not necessary on my account).
Thanks,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Jay Berkenbilt dixit: >As it happens, I am upstream. Oh, nice ☻ in that case, thanks for qpdf. >--- >It is not generally practical to remove objects from QDF files without >messing up object numbering, but if you remove all indirect references >to an object (without removing the object itself), this will leave the >object unreferenced. Then you can run qpdf on the file (after running >:command:`fix-qdf`), and qpdf will omit the now-orphaned object. >--- That fixes the ambiguity but leaves the reader¹ wondering, on two reading passes, what other references than indirect there are. The reader who has not digested the PDF spec in and out, at least. If you s/ indirect//, would it still be correct? That would be less possibly-ambiguous, I think. bye, //mirabilos ① or at least me right now -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Bernhard Übelacker dixit:
> On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser
> wrote:
>> Sometimes, it does not crash with a smashed stack but instead:
>>
>> Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
>> BDB0002 __fop_file_setup: Retry limit (100) exceeded
>> saslpasswd2: generic failure
>
> This looks to be a result of the pre-existing /etc/__db.sasldb2.
> If this file gets removed the stack smashing occurs again.
Right, I got there as well but not any further.
> By some experimenting I could convince gdb to load the debug symbols.
Massive detective work, thanks!
> And the stack seems to point into function __os_unique_id from libdb-5.3.so.
>
> Unfortunately I am not sure where the canary gets overwritten.
I had an immediate hunch as I saw this:
> 38 __os_gettime(env, &v, 1);
And:
> (gdb) ptype /o v
> type = struct {
> /* 0 | 8 */time_t tv_sec;
> /* 8 | 4 */long tv_nsec;
>
> /* total size (bytes): 12 */
> }
This is, in the source:
typedef struct {
time_t tv_sec; /* seconds */
#ifdef HAVE_MIXED_SIZE_ADDRESSING
int32_t tv_nsec;
#else
longtv_nsec;/* nanoseconds */
#endif
} db_timespec;
Compare the newer system header:
struct timespec
{
#ifdef __USE_TIME_BITS64
__time64_t tv_sec;/* Seconds. */
#else
__time_t tv_sec; /* Seconds. */
#endif
#if __WORDSIZE == 64 \
|| (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
|| (__TIMESIZE == 32 && !defined __USE_TIME_BITS64)
__syscall_slong_t tv_nsec;/* Nanoseconds. */
#else
# if __BYTE_ORDER == __BIG_ENDIAN
int: 32; /* Padding. */
long int tv_nsec; /* Nanoseconds. */
# else
long int tv_nsec; /* Nanoseconds. */
int: 32; /* Padding. */
# endif
#endif
};
This is actually longer and (IMHO) really stupid. But Linux has:
struct __kernel_timespec {
__kernel_time64_t tv_sec; /* seconds */
long long tv_nsec;/* nanoseconds */
};
So this is actually expected. *checks POSIX* which says:
| The header shall declare the timespec structure, which shall
| include at least the following members:
|
| time_t tv_sec Whole seconds.
| long tv_nsec Nanoseconds [0, 999 999 999].
So both the kernel definition (tv_nsec must be long, not long long,
which is incompatible on ILP32 big endian platforms) and the one by
db5.3 (struct timespec may include extra members and be in any order)
actually violate POSIX… *sigh*
And yes, it does cast to struct timespec and passes it
to clock_gettime().
But it does give us a possible fix, which I’ll be testing.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1068873: openjdk-21: more m68k patches
Dixi quod…
>I’ll recompile with re-enabled alignment on the missing base
Seems to be only one.
--- src/hotspot/share/memory/allocation.hpp~2024-04-12 23:52:54.0
+
+++ src/hotspot/share/memory/allocation.hpp 2024-04-12 23:52:56.0
+
@@ -276,7 +276,7 @@ class CHeapObj {
void operator delete [] (void* p) {
CHeapObjBase::operator delete[](p);
}
-};
+} __attribute__ ((aligned (4)));
// Base class for objects allocated on the stack only.
// Calling new or delete will result in fatal error.
>classes like we have in 17. But if someone has ideas ’til then…
gn8,
//mirabilos
--
This space for rent.
Bug#1068873: openjdk-21: more m68k patches
Dixi quod…
>>(This is what I found trying to build openjdk-20, but it’ll be
>>needed in 21 as well. Even getting to this point took 13½ days
>>already…)
>
>And turns out that this isn’t the cause.
>
>In 17, we’ve got src/hotspot/share/memory/allocation.hpp to
>align all CHeapObj, StackObj, MetaspaceObj, etc. classes; this
>is gone in 21. So this needs to be brought back instead.
Hmmhmm. Since I’m having to build/debug 20 first…
… in 20, StackObj has its alignment bumped manually,
but CHeapObj doesn’t. MetaspaceObj does, ResourceObj
and ArenaObj don’t, AnyObj does.
So I’m guessing we will want to fix up the allocators instead?
(Though raising the alignment for cases where people allocate
them on the stack may still be useful…)
ArenaObj… is not allocated‽
resource_allocate_bytes uses Thread::current()->resource_area()->allocate_bytes
which uses Amalloc which seems to align well.
AllocateHeap uses os::malloc which uses ::malloc (C function?)
in NMT and normal cases. Huh. MallocHeader is 16 bytes, also okay.
The glibc texinfo docs say…
| The address of a block returned by ‘malloc’ or ‘realloc’ in GNU systems
| is always a multiple of eight (or sixteen on 64-bit systems). If you
… so that should *also* be okay?! Unless that’s not true, anyway…
#define SIZE_SZ (sizeof (INTERNAL_SIZE_T))
#define MALLOC_ALIGNMENT (2 * SIZE_SZ < __alignof__ (long double) \
? __alignof__ (long double) : 2 * SIZE_SZ)
… it should.
So where does the unaligned _futex_barrier member in the
class LinuxWaitBarrier : public CHeapObj come from?
AFAICS, the caller is:
WaitBarrier* SafepointSynchronize::_wait_barrier;
_wait_barrier = new WaitBarrier(vmthread);
With:
typedef LinuxWaitBarrier WaitBarrierDefault;
template
class WaitBarrierType : public CHeapObj {
WaitBarrierImpl _impl;
…
}
typedef WaitBarrierType WaitBarrier;
So the “new WaitBarrier” should call CHeapObj::operator new(size_t size)
TTBOMK (IANAC++Programmer) which calls CHeapObjBase::operator new(size,
mtInternal)
= AllocateHeap(size, mtInternal)…
Hmmm. But, oops, I see something more:
src/hotspot/share/services/mallocTracker.hpp: static const size_t
overhead_per_malloc = sizeof(MallocHeader) + sizeof(uint16_t);
That would dealign things… but MallocTracker::record_malloc
only adds sizeof(MallocHeader) and has an assert (unsure if
NDEBUG though) that checks alignment…
I am lost. I can *see* an under-aligned futex barrier in strace.
19270 futex(0xcf80078a, FUTEX_WAKE_PRIVATE, 2147483647) = -1 EINVAL (Invalid
argument)
I cannot see how, though.
FWIW, /tmp/buildd/openjdk-20-20.0.2+9/build/jdk/bin/java \
-XX:NativeMemoryTracking=summary -version also crashes, same
with an explicit -XX:NativeMemoryTracking=off :/
I’ll recompile with re-enabled alignment on the missing base
classes like we have in 17. But if someone has ideas ’til then…
Mraw,
//mirabilos
--
exceptions: a truly awful implementation of quite a nice idea.
just about the worst way you could do something like that, afaic.
it's like anti-design. that too… may I quote you on that?
sure, tho i doubt anyone will listen ;)
Bug#1068873: openjdk-21: more m68k patches
Dixi quod… >(This is what I found trying to build openjdk-20, but it’ll be >needed in 21 as well. Even getting to this point took 13½ days >already…) And turns out that this isn’t the cause. In 17, we’ve got src/hotspot/share/memory/allocation.hpp to align all CHeapObj, StackObj, MetaspaceObj, etc. classes; this is gone in 21. So this needs to be brought back instead.
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Hi Vladimir, if you have any suggestions as to what to do best with openjdk-8, feel free to say. In Debian, it’s only relevant in unstable, ELTS stretch and jessie, but for Ubuntu it’s used in more. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068873: openjdk-21: more m68k patches
Source: openjdk-21
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
Please add the following patch e.g. to debian/patches/m68k-support.diff
for more making implicit alignment assumptions (here by the futex
syscall) explicit:
--- src/hotspot/os/linux/waitBarrier_linux.hpp~ 2024-04-12 18:24:38.584686322
+0200
+++ src/hotspot/os/linux/waitBarrier_linux.hpp 2024-04-12 18:24:46.768716977
+0200
@@ -29,7 +29,7 @@
#include "utilities/globalDefinitions.hpp"
class LinuxWaitBarrier : public CHeapObj {
- volatile int _futex_barrier;
+ volatile int _futex_barrier __attribute__((__aligned__(4)));
NONCOPYABLE(LinuxWaitBarrier);
Thanks!
(This is what I found trying to build openjdk-20, but it’ll be
needed in 21 as well. Even getting to this point took 13½ days
already…)
Bug#1068615: pbuilder will overwrite LANG/LC_ALL if they are set via config file
Sergio Durigan Junior dixit:
>-export LANG=C
>-export LC_ALL=C
>+export LANG="${LANG:-C}"
>+export LC_ALL="${LC_ALL:-C}"
Ouch, no.
IMHO, they ought to really be unset for sane build environments,
and if the thing to be built needs locales, it can set its own.
Passing environment variables, even “just” the locale, from the
outside into the build environment is a dark path.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Jay Berkenbilt dixit: >Can you tell me where in the docs it says what you're describing? >Here's a direct quote from the current qpdf documentation: > >It is not generally practical to remove objects from QDF files without >messing up object numbering, but if you remove all references to an >object, you can run qpdf on the file (after running fix-qdf), and qpdf >will omit the now-orphaned object. Yes, I meant that. At least two people assumed that “remove all references” includes the object itself, but now that you point it out, it likely doesn’t, but we are no native speakers, so I don’t know which of the two interpretations is more likely to them or if even both are possible. Maybe, if you have good connections to upstream, suggest to them to add “(but not the object itself)” to behind “all references to an object”, but the bug can then be closed. Thanks for looking into it, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Jonathan Wiltshire dixit: >Please go ahead. Thanks. Do you need a blurb for the point release notes or something? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Rich Felker dixit: >Is there anything weird about how these objects were declared that >might have caused ld not to resolve them statically like it should? It >seems odd that these data symbols, but not any other ones, would be >left as symbolic relocations. I don’t think so? In I already posted the short version; the actual source is (mirrored): The initcoms array is here: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/main.c#L77 Tdr is defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L3055 The u_ops array is declared a few lines above that and defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/funcs.c#L160 initvsn is defined at… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L713 … with the EXTERN and E_INIT macros from… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L657 where main.c defines EXTERN, so the string is embedded into the file using it. Is there perhaps a misunderstanding with the gcc/binutils/glibc developers as to what static-pie is meant to be? bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >I may not really know what I am talking about, so take this with a grain >of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that >switch causes ld to not emit symbolic relocations. I seem to remember >reading long ago in Rich's initial -static-pie proposal that that was >one of the switches added to the linker command line. When searching for which architectures support static PIE in the first place (sadly, there doesn’t seem a consistent list), I found one saying it’s no longer necessart after some point, so I didn’t check it. >In any case, the emission of non-relative relocations is the issue here, >and it is coming from the linker. They are present in the glibc static-pie binary as well, though. And tbh they look to me like “just plug the absolute address of the symbol here, please”, which is perfectly fine for things like an array of strings when the actual string has already its own symbol. (Disclaimer: I know… barely anything about Unix relocation types, a bit more about those on DOS and even TOS.) bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed. Gotcha! They are all R_390_RELATIVE except for: 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 00045ff8 00110016 R_390_64 00042c58 u_ops + 0 00047020 00110016 R_390_64 00042c58 u_ops + 80 00047088 00110016 R_390_64 00042c58 u_ops + 80 000470a8 00110016 R_390_64 00042c58 u_ops + b8 00047220 00110016 R_390_64 00042c58 u_ops + 80 00046900 00260016 R_390_64 00015af8 c_command + 0 00046940 00070016 R_390_64 00017238 c_exec + 0 00046ab0 00200016 R_390_64 00016a80 c_trap + 0 00047090 00250016 R_390_64 000430ac initvsn + 0 00047278 00550016 R_390_64 00047438 null_string + 2 That’s our missing strings. >Is it possible you are linking in the wrong start file? gcc -v should >output the command line it feeds to the linker. Should be correct: /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o /usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o HTH & HAND, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1067752: anacrontab(5) incorrectly says the only @period is @monthly (@yearly also supported)
Hi, I don’t think a /etc/cron.yearly/ should be created as directory, given that the default /etc/crontab never executes anything in it even if anacron may do. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Now I (or someone) is going to have to reduce that to a testcase, so
No success with that, unfortunately.
>But this does seem to be a toolchain bug: adding -static-pie to the
>glibc dynamic-pie link command and…
>
>(gdb) print initcoms
>$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c
>"HOME", 0xda7d8 "PATH",
Wait, what?
(gdb) b main
Breakpoint 1 at 0xd820: file ../../main.c, line 785.
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/full/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa4d8) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7eda494 "typeset", 0x3fff7ee4548 "-r",
0x3fff7ee4ae0 "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian",
0x0, 0x3fff7eda494 "typeset",
[…]
While in musl:
(gdb) print initcoms
$1 = {0x414a4 "typeset", 0x0, 0x0, 0x0, 0x414a4 "typeset", 0x0, 0x40478 "HOME",
0x41d42 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/static-musl/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa498) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
So the existing ones did get relocated, but the nullptrs stayed thusly.
Apparently, it *is* supported on glibc on s390x, mjt (qemu maintainer)
also said so in 2023.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs
Sebastian Andrzej Siewior dixit: >the older "previous" kernel has it. And that won’t be fixed even with a trigger. Used to be -uk all would, but (#1065698) that doesn’t work any more. Given how widespread the info already is and that it affects sid and a subset of trixie users, maybe go with just a NEWS.Debian entry for that? (I’d be more interested of what other backdoors there might be like joeyh indicated.) bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Hmm, actually… I could… test whether that one fixes static-pie
>on zelenka. Or at least the same approach. I’ll get back with
>report from that.
Having looked at the spec file, the only extra things the stock
specs do that the overriding specs don’t is:
*link:
[…] %{!static|static-pie:--eh-frame-hdr} […] %{static-pie:-static -pie
--no-dynamic-linker -z text} […]
instead of:
[…] %{static-pie:-static -pie --no-dynamic-linker} […]
The -Wl,-z,text makes TEXTRELs an error. Granted.
The -Wl,--eh-frame-hdr is added for anything that’s not a normal
static executable, however adding that to a musl build doesn’t
fix the problem either.
A bit of gdb-ing shows the problem, though: the source code has…
#define Ttypeset "typeset"
#define Tdr "-r"
//… (a variant of this is used for string sharing on ancient Unix)
static const char *initcoms[] = {
Ttypeset, Tdr, initvsn, NULL,
Ttypeset, Tdx, "HOME", TPATH, TSHELL, NULL,
[…]
};
It then iterates over these commands with:
for (wp = initcoms; *wp != NULL; wp++) {
c_builtin(wp);
while (*wp != NULL)
wp++;
}
This is where the extra output happens:
(gdb) print initcoms
$3 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
Notice the nullptrs there where string pointers are expected.
It shows the same output when just loading the executable, i.e. this
isn’t a runtime issue.
Linking the exact same .o files with the exact same command minus
-static-pie gives:
(gdb) print initcoms
$1 = {0x103cb34 "typeset", 0x103e368 "-r",
0x103e73c "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 0x0,
0x103cb34 "typeset",
But this does seem to be a toolchain bug: adding -static-pie to the
glibc dynamic-pie link command and…
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
Now I (or someone) is going to have to reduce that to a testcase, so
we can detect static-pie viability before it’s committed to being used…
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Sometimes, it does not crash with a smashed stack but instead: Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ... BDB0002 __fop_file_setup: Retry limit (100) exceeded saslpasswd2: generic failure dpkg: error processing package sasl2-bin (--configure): installed sasl2-bin package post-installation script subprocess returned error exit status 1 (I tried rebuilding it, but that didn’t fix it either.)
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
Rich Felker dixit: >I seem to recall the musl-gcc wrapper does not handle static-pie >right. Hmm. Inhowfar? And it does seem to work fine on the other architectures. >A real cross toolchain should. I fear that that’s out of question for Debian. I’ve got a github action test setup for mksh though, which also uses jirutka/setup-alpine to set up chroots of Alpine Linux for various architectures and uses them to build natively under qemu-user. I could use that to check static-pie? IIUC, these use “a real cross toolchain”, if natively; qemu-user adds an extra potential failure dimension though… >If there's an easy fix for the wrapper I'd be happy to merge it. Together with the MIPS fix? Hmm, actually… I could… test whether that one fixes static-pie on zelenka. Or at least the same approach. I’ll get back with report from that. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
Szabolcs Nagy dixit: >the next culprit is gcc (each target can have their own gcc-13_13.2.0-23 >static pie specs) or the way you invoked gcc (not visible As I wrote earlier, though with more flags. Dropping all the -D… and -W… and -I… and other irrelevant ones: musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing -fstack-protector-strong -fwrapv -c … musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing -fstack-protector-strong -fwrapv -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie -fno-lto -o mksh *.o Same for both. You can see the full log by activating the [64]Installed and [71]Installed links respectively on https://buildd.debian.org/status/package.php?p=mksh and skipping to 'compilation of mksh in static-musl' to get to the beginning of the configure phase for that. >are you sure static pie works on these targets? No ;-) That’s why I reported this issue. I had just enabled it for the musl builds, as the security people like that more than normal static. Thanks for looking, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
