Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, Le 15/04/2024 à 17:12, Bo YU a écrit : Again, I've seen this issue several times with OCaml packages, but I didn't bother to investigate. It looks like another toolchain issue, which should be fixed in a more central package, not in bisect-ppx itself. So just leave the lintian warnings as is. It seems the issue should be fixed on lintian side as your analyst. But unfortunately, this is one lintian error that will lead to ftp-master auto-rejected if uploaded: ``` E: libbisect-ppx-ocaml-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml.debug] E: libbisect-ppx-ocaml-dev-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml-dev.debug] ``` I tried many attempts but failed. One common workaround is shipping one lintian-override via dh_lintian, like[0] and [1]. Although the error was gone, but we will get another error: ``` libbisect-ppx-ocaml-dev-dbgsym: non-debug-file-in-debug-package [usr/share/lintian/overrides/libbisect-ppx-ocaml-dev-dbgsym] ``` Passing `--no-dwz-multifile` to dh_dwz maybe has side effects on the debug package but it seems this is a workaround if we can upload to upstable.And I agree. I've pushed two minor changes. Please review them. Then, I will upload the package. I will open two separate reportbugs to track these issues once the package unloaded to unstable. Thank you for your work. Cheers, -- Stéphane
Bug#1069073: lua-mode: FTBFS: failing tests
Control: tags -1 pending Hi, I have committed a fix to the team repo (together with other tweaks) and prepared a package on mentors. See Bug#1069078[1] for the RFS request. Please help sponsoring. TIA! -- Xiyue Deng [1] https://bugs.debian.org/1069078
Bug#1069078: Acknowledgement (RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs)
Forwarding to the Debian Emacsen Team list. Start of forwarded message From: Xiyue Deng To: sub...@bugs.debian.org Subject: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs Date: Mon, 15 Apr 2024 21:06:11 -0700 Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lua-mode": * Package name : lua-mode Version : 20210802-4 Upstream contact : immerrr * URL : https://github.com/immerrr/lua-mode * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/lua-mode Section : lisp The source builds the following binary packages: elpa-lua-mode - Emacs major-mode for editing Lua programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20210802-4.dsc Changes since the last upload: lua-mode (20210802-4) unstable; urgency=medium . * Team upload * Mark lexical binding patch as Forwarded and Applied-Upstream * Add patch to use eval in lexical scope to fix tests (Closes: #1069073) * Keep source *.el in autopkgtest to make it work * Add Upstream-Contact in d/copyright * Update homepage to github page in d/control (old link no longer works) * Set Rules-Requires-Root to no in d/control * Drop Built-Using from arch:all package in d/control * Trim trailing whitespace in d/changelog * Bump debhelper from old 10 to 13 * Set debhelper-compat version in Build-Depends * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse * Update Standards-Version to 4.7.0; no change needed * Modernize d/watch with substitute strings to be more robust Regards, -- Xiyue Deng End of forwarded message
Bug#1067025: dokuwiki: Please package the new upstream version 2024-02-06a "Kaos"
Hi, any news or ETA on this? do you need help? Regards, Daniel
Bug#1064235: cloud.debian.org: systemd-resolved et al. status (bookworm)
Hi Noah, First of all many thanks for the new images and for the help with this bug report. Regarding removing libnss-resolve, that's good to know. I figured doing bullseye->bookworm was not a good strategy long-term anyways, so I decided to look further for a solution, which I found by removing the resolve entries in /etc/nsswitch.conf. But I'll definitely will try by removing libnss-resolve on next installs. For instance, the other issue I was facing turned out not to be related to s-resolved, but to s-networkd not honoring DHCP search domains (for which I'm currently testing a solution and plan to file a bug reports soon, hopefully with a proposed workaround). Regards, On 2024-04-11 20:33, Noah Meyerhans wrote: On Wed, Apr 03, 2024 at 09:39:40PM -0700, Flavio Veloso Soares wrote: Hi Noah - I guess I'll be doing bullseye->bookworm installs in the meantime, until 12.6 so I can fill bug reports (if any). It should be plenty to start with the bookworm images and simply remove the libnss-resolve package. It's quite a lot simpler. noah -- FVS
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lua-mode": * Package name : lua-mode Version : 20210802-4 Upstream contact : immerrr * URL : https://github.com/immerrr/lua-mode * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/lua-mode Section : lisp The source builds the following binary packages: elpa-lua-mode - Emacs major-mode for editing Lua programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20210802-4.dsc Changes since the last upload: lua-mode (20210802-4) unstable; urgency=medium . * Team upload * Mark lexical binding patch as Forwarded and Applied-Upstream * Add patch to use eval in lexical scope to fix tests (Closes: #1069073) * Keep source *.el in autopkgtest to make it work * Add Upstream-Contact in d/copyright * Update homepage to github page in d/control (old link no longer works) * Set Rules-Requires-Root to no in d/control * Drop Built-Using from arch:all package in d/control * Trim trailing whitespace in d/changelog * Bump debhelper from old 10 to 13 * Set debhelper-compat version in Build-Depends * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse * Update Standards-Version to 4.7.0; no change needed * Modernize d/watch with substitute strings to be more robust Regards, -- Xiyue Deng
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Sebastian Ramacher, le lun. 15 avril 2024 05:41:48 +0200, a ecrit: > On 2024-04-14 14:19:18 +0200, Santiago Vila wrote: > > El 14/4/24 a las 13:25, Sylvestre Ledru escribió: > > > I am sorry but I am not sure to see how it is actionable. > > > > > > Without a test case, i don't think there is much I can do here. > > > > The test case is that nvda2speechd fails to build from source. > > > With rust, cargo, custom build script, there are many things that can go > > > wrong before LLVM. > > > > > > Sebastian, I think it could be move to normal. From LLVM perspective, it > > > isn't serious severity (many programs are built with LLVM 16). > > > > We can release trixie with compilers having bugs, but I don't think it > > would be ok at > > all to release trixie as stable with packages which do not build from > > source, that would > > be against Release Policy. > > > > So, in my opinion, this is still RC, either in the compiler or in the > > package failing > > to build. If solving this in the compiler is too complex, then the bug > > should be reassigned back to src:nvda2speechd. > > Given that nvda2speechd downloads rust and plenty of crates during the > build, it will have to prevent odd interactions with the system provided > LLVM. Let's keep this as RC bug against nvda2speechd. The problem is that bindgen insists on interacting with the system-provided LLVM: https://github.com/rust-lang/rust-bindgen/blob/main/bindgen/lib.rs#L620 It force-loads libclang, and when that's libclang16, we get the bug. For now I "fixed" the bug by dropping the rust/cargo/clang build-deps entirely, and build-dep on libclang 14 rather than 16. I don't know why the issue shows up only when building speech-dispatcher-sys, perhaps that's just because it's the only crate that uses bindgen. Samuel
Bug#1069077:
Control: retitle es8316 driver causes kernel oops / panic on rockpro64 Blacklisting the snd_soc_es8316 module in /etc/modprobe.d seems to restore kernel stability, as far as I have seen from half a dozen reboots.
Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
Otto, et al, On Sun, Apr 7, 2024 at 12:09 AM Otto Kekäläinen wrote: > > Hi Daniel! > > Do you think this change is still needed? > > Do you want to participate in some open source development/testing to > make it work? > > On Sun, 14 Jan 2024 at 16:03, Otto Kekäläinen wrote: > > > > FYI: Discussion about this continued in > > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61 Yes. I believe that the default configuration should not generate errors or warnings when MariaDB is started. Version 1:10.11.6-2 has one of each (see below). And I agree with you that upstream option values should only be changed if there are compelling reasons. Thank you! Dan Urbana, Illinois --- "PRIORITY" : "3", "MESSAGE" : "2024-04-16 1:33:25 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.", "PRIORITY" : "4", "MESSAGE" : "mariadb.service: Referenced but unset environment variable evaluates to an empty string: MYSQLD_OPTS, _WSREP_NEW_CLUSTER", ###
Bug#1069077: rockpro64: multiple kernel oops and frequent boot failures
Package: src:linux Version: 6.7.9-2 Severity: important X-Debbugs-Cc: fores...@sonic.net Dear Maintainer, The current debian unstable kernel causes a variety of failures that are not present in the bookworm kernel, on the RockPro64 single board computer. (This is an arm64 machine built upon the Rockchip rk3399 SoC.) The system is sometimes able to reach a state where sshd login works, allowing me to run reportbug, but not always. Regardless of whether it gets that far, dmesg often contains one or more stack traces, along with messages like these: kernel BUG at mm/slub.c:448! Internal error: Oops - BUG: f2000800 [#1] SMP WARNING: CPU: 2 PID: 0 at kernel/context_tracking.c:128 ct_kernel_exit.isra.0+0xa0/0xa8 Unable to handle kernel paging request at virtual address 4daee1bbcd3980fb I have noticed es8316 driver error messages preceding some of these stack traces, though I'm not sure if that is always the case. Sometimes the stack traces appear only once, during boot, and the system appears to run normally after that. Other times, they appear every few minutes, and various things like network services and the ability to cleanly shut down, or even log in at the serial console, fail. In one case, I noticed a message mentioning a kernel panic in the serial console output when I was trying to shut down. Since the worst examples of failure prevent me from logging in, I am unable to run reportbug to capture information about those cases. Reverting to linux-image-6.1.0-20-arm64 solves the problem. -- Package-specific info: ** Version: Linux version 6.7.9-arm64 (debian-ker...@lists.debian.org) (aarch64-linux-gnu-gcc-13 (Debian 13.2.0-18) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP Debian 6.7.9-2 (2024-03-13) ** Command line: root=/dev/mapper/ console=ttyS2,150n8 net.ifnames=0 ** Tainted: DWC (1664) * kernel died recently, i.e. there was an OOPS or BUG * kernel issued warning * staging driver was loaded ** Kernel log: [ 56.250803] driver_attach+0x2c/0x40 [ 56.250809] bus_add_driver+0x11c/0x238 [ 56.250814] driver_register+0x64/0x138 [ 56.250821] __platform_driver_register+0x30/0x48 [ 56.252550] graph_card_init+0x28/0xff8 [snd_soc_audio_graph_card] [ 56.252565] do_one_initcall+0x60/0x298 [ 56.252574] do_init_module+0x60/0x218 [ 56.252581] load_module+0x22b4/0x23b8 [ 56.252588] __do_sys_init_module+0x230/0x290 [ 56.252593] __arm64_sys_init_module+0x24/0x38 [ 56.252599] invoke_syscall+0x78/0x100 [ 56.252609] el0_svc_common.constprop.0+0xc8/0xf0 [ 56.252617] do_el0_svc+0x24/0x38 [ 56.252624] el0_svc+0x3c/0x108 [ 56.252633] el0t_64_sync_handler+0x120/0x130 [ 56.252639] el0t_64_sync+0x190/0x198 [ 56.256943] Code: 52800024 97fff9b4 a94563f7 17d0 (d421) [ 56.256952] ---[ end trace ]--- [ 56.256957] note: (udev-worker)[554] exited with irqs disabled [ 56.257262] [ cut here ] [ 56.258816] WARNING: CPU: 2 PID: 0 at kernel/context_tracking.c:128 ct_kernel_exit.isra.0+0xa0/0xa8 [ 56.259633] Modules linked in: snd_soc_audio_graph_card(+) snd_soc_simple_card snd_soc_rockchip_i2s evdev snd_soc_spdif_tx snd_soc_simple_card_utils snd_soc_es8316 snd_soc_hdmi_codec v4l2_vp9 rockchip_rga v4l2_h264 videobuf2_dma_contig snd_soc_core v4l2_mem2mem sha512_arm64 videobuf2_dma_sg governor_simpleondemand snd_compress snd_pcm_dmaengine snd_pcm videobuf2_memops panfrost dw_wdt videobuf2_v4l2 snd_timer ofpart gpu_sched snd drbg(+) leds_gpio pwm_fan drm_shmem_helper spi_nor videodev des_generic ansi_cprng dw_hdmi_i2s_audio dw_hdmi_cec rk_crypto ecdh_generic(+) rockchip_saradc gpio_ir_recv rfkill videobuf2_common mc crypto_engine ecc nvmem_rockchip_efuse soundcore libdes mtd rockchip_thermal coresight_cpu_debug industrialio_triggered_buffer sg kfifo_buf coresight_etm4x rockchip_dfi industrialio coresight cpufreq_dt loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod dax sd_mod t10_pi xhci_plat_hcd xhci_hcd crc64_rocksoft_generic crc64_rocksoft crc_t10dif [ 56.259856] crct10dif_generic crc64 realtek ahci libahci libata rk808_regulator dwc3 scsi_mod udc_core scsi_common fusb302 tcpm ulpi typec crct10dif_ce crct10dif_common polyval_ce rockchipdrm polyval_generic dw_hdmi dwmac_rk fan53555 cec ghash_ce stmmac_platform rc_core stmmac gf128mul dw_mipi_dsi analogix_dp sha2_ce pcs_xpcs pwm_regulator sha256_arm64 drm_display_helper phylink ohci_platform sha1_ce dwc3_of_simple of_mdio gpio_rockchip gpio_keys ohci_hcd ehci_platform drm_dma_helper fixed_phy sdhci_of_arasan ehci_hcd sdhci_pltfm drm_kms_helper cqhci dw_mmc_rockchip fwnode_mdio phy_rockchip_inno_usb2 phy_rockchip_emmc phy_rockchip_pcie phy_rockchip_typec usbcore io_domain pl330 pwm_rockchip spi_rockchip drm dw_mmc_pltfm sdhci libphy dw_mmc i2c_rk3x usb_common fixed aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [ 56.274047] CPU: 2 PID: 0 Comm:
Bug#1069076: Please update to enet 1.3.18
Source: enet Version: 1.3.17+ds-2 Severity: normal Hi! ENet upstream just cut a release after I requested it on github. As you know, the last released happened 4 years ago and quite a few features and fixes have been piling up in Github. I depend on the new version to be able to build the latest release of dolphin-emu. Please update the package, thanks! Jordi -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca_ES:ca Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’
Hi Timo, On Sat, 2 Mar 2024 09:21:43 +0100 Timo =?utf-8?Q?R=C3=B6hling?= wrote: > > On Sun, 25 Feb 2024 20:28:53 +0100 Lucas Nussbaum > wrote: > > > /usr/include/thrust/detail/type_traits.h:736:1: error: expected > > > type-specifier before ‘template’ > > This bug is caused by a #ifdef cascade for different > THRUST_DEVICE_SYSTEM values, which sadly no longer works with > THRUST_DEVICE_SYSTEM_OMP. This makes it effectively impossible to > build the HIP backend and the OpenMP backend from the same source. Am I understanding correctly that this was broken in a rocthrust update? Should this be treated as a rocthrust bug? [1] Sincerely, Cory Bloor [1]: https://bugs.debian.org/1064730
Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs
On Tue, 16 Apr 2024, Timo Lindfors wrote: I would very much like to have some sort of workaround to start moving some I noticed that if I use cmd = [ "virt-install", "--connect", "qemu+ssh://ansi...@hypervisor.example.com/system", "--name", "linditest", "--cloud-init", "user-data=cloudinit-user-data.yml,network-config=cloudinit-network-config.yml", "--os-variant", "debiantesting", "--network", "bridge=br0,model=virtio", "--disk", "size=20,backing_store=/srv/images/debian-12-generic-amd64.qcow2", "--graphics", "none", "--autostart" ] subprocess.check_call(cmd) I get the error messages about grep and sed being missing but still somehow the filesystem gets resized: Warning: fsck not present, so skipping root file system [2.993780] EXT4-fs (vda1): mounted filesystem with ordered data mode. Quota mode: none. done. Begin: Running /scripts/local-bottom ... GROWROOT: /sbin/growpart: 824: /sbin/growpart: grep: not found GPT PMBR size mismatch (4194303 != 41943039) will be corrected by write. The backup GPT table is not on the end of the device. /sbin/growpart: 853: /sbin/growpart: sed: not found WARN: unknown label /sbin/growpart: 354: /sbin/growpart: sed: not found FAILED: sed failed on dump output /sbin/growpart: 83: /sbin/growpart: rm: not found done. Begin: Running /scripts/init-bottom ... done. ... [ OK ] Started session-1.scope - Session 1 of User ansible. Debian GNU/Linux 12 linditest ttyS0 linditest login: ansible Password: Linux linditest 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Apr 15 21:28:07 UTC 2024 from 80.242.28.204 on pts/0 ansible@linditest:~$ df -h Filesystem Size Used Avail Use% Mounted on udev462M 0 462M 0% /dev tmpfs97M 624K 96M 1% /run /dev/vda120G 1006M 18G 6% / tmpfs 481M 0 481M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/vda15 124M 12M 113M 10% /boot/efi tmpfs97M 0 97M 0% /run/user/1000 # -Timo
Bug#1069075: elogind: service broken by elogind path change in 255.4.1
Package: runit-services Version: 0.7.1 Severity: important X-Debbugs-Cc: plore...@disroot.org Version 255.4.1 of elogind changes elogind's path from /lib/elogind/elogind to /usr/libexec/elogind; this breaks quite a lot in a desktop setup. the runscript and the bin metafiles need to be updated -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages runit-services depends on: ii runit 2.1.2-58 ii runit-helper 2.16.2 Versions of packages runit-services recommends: ii runit-init 2.1.2-58 Versions of packages runit-services suggests: ii socklog 2.1.0+repack-5 -- no debconf information
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hi, a new upload for mini-httpd/1.30-10 is ready on mentors. This upload clarifies systemd hardening features with a NEWS entry, removes commented PrivateUsers directive and a typo in the changelog. Thanks, Salvo ! I think we're getting close to release. Please take a look at your convenience (#2): https://mentors.debian.net/package/mini-httpd/ Have a great day and thank you for your interest in Debian, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]
On Tue, Mar 26, 2024 at 02:36:06PM +0100, Cyril Brulebois wrote: > Control: tag -1 patch pending > > Lucas Nussbaum (2024-03-13): > > This is most likely caused by a change in dpkg 1.22.6, that enabled > > -Werror=implicit-function-declaration. For more information, see > > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > > > Relevant part (hopefully): > > > ../../common/scheduler/task.c: In function ‘task_perform’: > > > ../../common/scheduler/task.c:137:25: error: implicit declaration of > > > function ‘clamp’ [-Werror=implicit-function-declaration] > > > 137 | task->backoff = clamp(task->backoff * 2, 60, > > > ODS_SE_MAX_BACKOFF); > > > | ^ > > > cc1: some warnings being treated as errors > > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1 > > I thought there would be several things but apparently that's just the > one. A quick look upstream shows there are more PRs and more fixups > needed for even newer compilers, but I'm limiting my patch to the bare > minimum. > > Since that's been open for 10+ days, and since reverse dependencies > could get kicked out of testing, I'm uploading an NMU right now so that > I don't forget, but to DELAYED/2 so there's some room to do things > differently if desired. I'm happy to reschedule/cancel if needed. Thanks for the NMU. I had a look at the new warnings and they all seem to be false positives. I'd rather not introduce unnecessary changes in the packaged version compared to upstream just to silence them. This missing header will do. -- Mathieu Mirmont signature.asc Description: Digital signature
Bug#1055811: O: coreboot -- free firmware
On 2024-04-15 23:02:20, Matthias Geiger wrote: > On 15.04.24 22:59, Antoine Beaupré wrote: >> On 2024-04-15 22:22:04, Matthias Geiger wrote: >>> On 15.04.24 21:01, Antoine Beaupré wrote: On 2023-12-22 00:15:30, Matthias Geiger wrote: > Once the StarBook VI AMD get mainline coreboot support I will adopt this > package. Hi! It would be nice to see this come through! Do you still intend on adopting this package, and if so, when will StarBook get that nice update? :) >>> Hi. >>> >>> yes, I still intend to adopt coreboot once the StarBook (AMD variant) >>> gets coreboot support. TTBOMK this hasn't happened yet. >>> >>> I could update it right now but this is of little use if I have no >>> device to test it on. >> I believe I have such a device this could be tested on, at least to a >> certain extent. It seems like the Framework laptop can use the recent ectool >> binary from coreboot even if the BIOS itself doesn't use coreboot: >> >> https://community.frame.work/t/exploring-the-embedded-controller/12846/156?u=anarcat >> >> So I'm happy to serve as a guinea pig if you need one, otherwise I'm >> considering just looking at doing the upgrade myself (gulp!) but i'm not >> sure i have the cycles in maintaining this long term. >> >> a. > > If you're willing to test the package then I will look into updating > coreboot to the latest release. This might take some time. I hope > StarLabs can get coreboot to work in a reasonable timeframe. > > I'll ping back here once I made some progress. Amazing, thanks! -- The true revolutionary is guided by a great feeling of love. - Ernesto "Che" Guevara
Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs
Hi, I would very much like to have some sort of workaround to start moving some systems from proprietary clouds to libvirt. I don't quite understand how cloud-init works, does the workaround suggested in the first message basically require me to rebuild the image? If that is the case then maybe simply running virt-resize could be a workaround for now? -Timo
Bug#1055811: O: coreboot -- free firmware
On 15.04.24 22:59, Antoine Beaupré wrote: On 2024-04-15 22:22:04, Matthias Geiger wrote: On 15.04.24 21:01, Antoine Beaupré wrote: On 2023-12-22 00:15:30, Matthias Geiger wrote: Once the StarBook VI AMD get mainline coreboot support I will adopt this package. Hi! It would be nice to see this come through! Do you still intend on adopting this package, and if so, when will StarBook get that nice update? :) Hi. yes, I still intend to adopt coreboot once the StarBook (AMD variant) gets coreboot support. TTBOMK this hasn't happened yet. I could update it right now but this is of little use if I have no device to test it on. I believe I have such a device this could be tested on, at least to a certain extent. It seems like the Framework laptop can use the recent ectool binary from coreboot even if the BIOS itself doesn't use coreboot: https://community.frame.work/t/exploring-the-embedded-controller/12846/156?u=anarcat So I'm happy to serve as a guinea pig if you need one, otherwise I'm considering just looking at doing the upgrade myself (gulp!) but i'm not sure i have the cycles in maintaining this long term. a. If you're willing to test the package then I will look into updating coreboot to the latest release. This might take some time. I hope StarLabs can get coreboot to work in a reasonable timeframe. I'll ping back here once I made some progress. -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg
Bug#1055811: O: coreboot -- free firmware
On 2024-04-15 22:22:04, Matthias Geiger wrote: > On 15.04.24 21:01, Antoine Beaupré wrote: >> On 2023-12-22 00:15:30, Matthias Geiger wrote: >>> Once the StarBook VI AMD get mainline coreboot support I will adopt this >>> package. >> Hi! >> >> It would be nice to see this come through! Do you still intend on >> adopting this package, and if so, when will StarBook get that nice >> update? :) > > Hi. > > yes, I still intend to adopt coreboot once the StarBook (AMD variant) > gets coreboot support. TTBOMK this hasn't happened yet. > > I could update it right now but this is of little use if I have no > device to test it on. I believe I have such a device this could be tested on, at least to a certain extent. It seems like the Framework laptop can use the recent ectool binary from coreboot even if the BIOS itself doesn't use coreboot: https://community.frame.work/t/exploring-the-embedded-controller/12846/156?u=anarcat So I'm happy to serve as a guinea pig if you need one, otherwise I'm considering just looking at doing the upgrade myself (gulp!) but i'm not sure i have the cycles in maintaining this long term. a. -- Freedom of speech is a principal pillar of a free government; when this support is taken away, the constitution of a free society is dissolved, and tyranny is erected on its ruins. - Benjamin Franklin, 1737
Bug#1055583: base-files: EFI System Partition should mount on /efi not /boot/efi
On 15/04/2024 at 13:51, Santiago Vila wrote: In this bug report, I'm asked to provide /efi as a mount point for the EFI partition. Given that base-files does not even contain /boot/efi (the supposedly "old" location), I believe this is a decision for you to make, hence the reassign. partman-efi sets /boot/efi as the mount point for the ESP because this is where grub-install expects the ESP to be mounted by default. Changing the ESP mount point first implies to either: - change all relevant package and installer scripts to call grub-install with --efi-directory=/efi - change grub-install --efi-directory default to /efi instead of or in addition to /boot/efi - replace GRUB with a boot loader such as systemd-boot which expects the ESP to be mounted on /efi by default
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: > On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: > > Package: base-files > > Version: 12.4+deb12u1 > > Followup-For: Bug #1039979 > > Control: tags -1 patch > > > > I attach a patch to change absolute symlinks to relative symlinks, > which would fix this bugreport if you choose to do so. > > At least the /var/run directory is also created as a symlink to ../run > by tmpfiles.d: > > /usr/lib/tmpfiles.d/var.conf from the systemd package contains: > L /var/run - - - - ../run Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ? /usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1069073: lua-mode: FTBFS: failing tests
Package: src:lua-mode
Version: 20210802-3
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules build
dh build --with elpa
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
dh_auto_build
make -j2
make[1]: Entering directory '/<>'
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
version is 20210802
make[1]: Leaving directory '/<>'
dh_elpa_test
buttercup -L .
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Warning (buttercup): Found duplicate spec names in suite: ("lua-skip-ws-and-comments-forward respects
limit when escaping multi-line comment 1: limit=8 \"--[[<1> <2> ]] \\n\"")
Running 392 out of 410 specs.
Test electric mode
works with curly braces
[32m works with curly braces[0m (3.66ms)
works with parentheses
[32m works with parentheses[0m (0.97ms)
works with end
[32m works with end[0m (1.13ms)
works with else
[32m works with else[0m (1.13ms)
works with elseif
[32m works with elseif[0m (1.16ms)
Electric pair mode
skips parens when electric-pair-skip-self is t
[32m skips parens when electric-pair-skip-self is t[0m (1.60ms)
Test fill-paragraph
fills single-line comment
[32m fills single-line comment[0m (0.45ms)
fills comment after code
[32m fills comment after code[0m (0.39ms)
fills multiline comment
[33m fills multiline comment[0m[33m PENDING[0m (0.07ms)
does not spill comments into code (issue #25)
[32m does not spill comments into code (issue #25)[0m (0.38ms)
Test fill-paragraph preserves point position
doesn't move point if nothing has changed
[32m doesn't move point if nothing has changed[0m (0.96ms)
doesn't move point in refilled region
[32m doesn't move point in refilled region[0m (2.26ms)
doesn't move point if nothing has changed (multi-line)
[32m doesn't move point if nothing has changed (multi-line)[0m (0.71ms)
Fontification of built-ins
fontifies built-ins
[32m fontifies built-ins[0m (0.27ms)
fontifies built-ins with spaces between members
[32m fontifies built-ins with spaces between members[0m (0.26ms)
doesn't fontify things that look like built-ins
[32m doesn't fontify things that look like built-ins[0m (0.50ms)
fontifies built-in class if method is not built-in
[32m fontifies built-in class if method is not built-in[0m (0.24ms)
fontifies built-ins after concatenation operator
[32m fontifies built-ins after concatenation operator[0m (0.19ms)
Fontification of constants
fontifies constants
[32m fontifies constants[0m (0.20ms)
fontifies constants used as attributes
[32m fontifies constants used as attributes[0m (0.19ms)
Fontification of keywords
fontifies keywords
[32m fontifies keywords[0m (0.27ms)
fontifies keywords used as attributes
[32m fontifies keywords used as attributes[0m (0.24ms)
Fontification of variables
fontifies "local foo, bar, baz = 1, 2, 3"
[32m fontifies "local foo, bar, baz = 1, 2, 3"[0m (0.21ms)
fontifies "local foo, bar, baz"
[32m fontifies "local foo, bar, baz"[0m (0.20ms)
fontifies "local x =" at end of buffer
[32m fontifies "local x =" at end of buffer[0m (0.16ms)
fontifies local "x =" at end of line
[32m fontifies local "x =" at end of line[0m (0.18ms)
does not fontify "for" inside strings
[32m does not fontify "for" inside strings[0m (0.22ms)
fontifies "for x123 ="
[32m fontifies "for x123 ="[0m (0.16ms)
fontifies "for x, y, z"
[32m fontifies "for x, y, z"[0m (0.18ms)
Fontification of function headers
fontifies function (...) headers
[32m fontifies function (...) headers[0m (0.20ms)
fontifies local function (...) headers
[32m fontifies local function (...) headers[0m (0.21ms)
fontifies = function (...) headers
[32m fontifies = function (...) headers[0m (0.19ms)
fontifies local = function (...) headers
[32m fontifies local = function (...) headers[0m (0.20ms)
fontifies parameters in function literals
[32m fontifies parameters in function literals[0m (0.18ms)
fontifies different variations of headers altogether
[32m fontifies different variations of headers altogether[0m (0.41ms)
fontifies headers inside tables
[32m fontifies headers inside tables[0m (0.31ms)
does not fail on issue #59 again
[32m does not fail on issue #59 again[0m (0.30ms)
does not choke on function names with underscores
Bug#1069074: totalopenstation: FTBFS: failing tests
Package: src:totalopenstation Version: 0.5.2-4 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:311: python3.11 setup.py config running config dh_auto_build -O--buildsystem=pybuild I: pybuild base:311: /usr/bin/python3 setup.py build running build running build_py creating /<>/.pybuild/cpython3_3.11/build/totalopenstation copying totalopenstation/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/trimble.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/zeiss_elta_r55.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/nikon_npl_350.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/custom.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_polar.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_topcon_gts.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_trimble_are.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_gsi.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_zeiss_r5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_geojson.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_csv.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_zeiss.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_nikon.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_rw5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_sokkia_sdr33.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_dxf.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/nikon_raw_v200.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/trimble_are.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/topcon_gts.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/sokkia_sdr33.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/conversion.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/zeiss_r5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/polar.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_gsi.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/zeiss_rec_500.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/carlson_rw5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/output copying totalopenstation/output/tops_sql.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/output copying
Bug#1055811: O: coreboot -- free firmware
On 15.04.24 21:01, Antoine Beaupré wrote: On 2023-12-22 00:15:30, Matthias Geiger wrote: Once the StarBook VI AMD get mainline coreboot support I will adopt this package. Hi! It would be nice to see this come through! Do you still intend on adopting this package, and if so, when will StarBook get that nice update? :) a. Hi. yes, I still intend to adopt coreboot once the StarBook (AMD variant) gets coreboot support. TTBOMK this hasn't happened yet. I could update it right now but this is of little use if I have no device to test it on. best, -- Matthias Geiger Debian Maintainer
Bug#1069072: new upstream (0.36)
Package: nwipe Hi, it would be nice if you could upload the current nwipe release to Debian. Regards, Daniel
Bug#1068008: rustc: Please package rust 1.75 or higher
On Fri, Mar 29, 2024 at 11:14:44AM -0400, Wesley Schwengle wrote: > Package: rustc > Version: 1.70.0+dfsg1-9 > Severity: wishlist > X-Debbugs-Cc: wes...@schwengle.net > > Dear Maintainer, > > > I was trying to build a rust package from source when I noticed they use > traits. Async traits are supported as of 1.75. It would be beneficial to > Debian that > we can start developing rust with these traits. > > Currently upstream sits at 1.77.x, it would be nice if we could get at least > to > 1.75 , but 1.77.x would be preferred. > > https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html Firefox will require 1.74 in version 125 (which will be released in a few hours), and at least 1.76 in version 127. Mike
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi, James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > From some testing of these: the search results have a problem that they > hyperlink to a language-less .html URL, meaning that clicking a result link in > the DE-language search results takes the user to a EN-language page. Yes, good catch. However it's even worse: if you view a German page and use the Search function, the search index for English is used. I have tried to deal with this by some adaptions in the cronjob - see the first two additions in my patch: change all links to search.html into search.§lang.html, and rename the language-specific searchindex files into searchindex.$lang.js. However, that does not seem to be enough. > The _other_ hyperlinks in the static content are replaced as part of the > cronjob[1] - but that doesn't work for items in the searchindex.js file. Why is that a problem at all (maybe you know this already): since we use content negotiation at Debian website (so the pages are delivered in the correct language according to user's browser setting), we change the directory structure away from the default how it's build by Sphinx: after Sphinx' make there are separate directories for every language, and they contain everything for that language, including the searchindex.js file. And in that structure it works fine. On Debian website we put everything in one directory, adding the language code into the filename in front of the .html extension. While this works fine for static content, it does not for the search function here. > Fortunately I think there might be a better way to do this. Sphinx itself has > an HTML builder option 'html_file_suffix' and I think we could use that > instead > to define the filenames. That option is respected by the search JavaScript > using a template variable[3] in the documentation_options.js file. > > We should be careful of other side-effects if making that change, but it > would remove a deployment transformation step on the static content, and I > think that's beneficial. I don't understand how that could affect our search function problem, but I could give it a try. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1069071: libadios-bin: adiosxml2h fails to run
Package: libadios-bin Version: 1.13.1-36 Severity: normal Dear Maintainer, adiosxml2h fails to run with the error: $ adiosxml2h Traceback (most recent call last): File "/usr/bin/adiosxml2h", line 13, in import ad_config ModuleNotFoundError: No module named 'ad_config' Also, from the same package "skel" fails to run with the error: $ skel File "/usr/bin/skel", line 61 print parser.description SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? -- Regards Sudip -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libadios-bin depends on: ii libblosc1 1.21.5+ds-1+b1 ii libbz2-1.01.0.8-5.1 ii libc6 2.37-17 ii libhdf5-mpich-103-1t641.10.10+repack-3.3 ii libhdf5-mpich-hl-100t64 1.10.10+repack-3.3 ii libhdf5-openmpi-103-1t64 1.10.10+repack-3.3 ii liblz4-1 1.9.4-2 ii libmpich124.2.0-5.1 ii libnetcdf-mpi-19 1:4.9.0-1+b3 ii libnetcdf19t641:4.9.2-5+b1 ii libopenmpi3t644.1.6-9 ii libsz21.1.3-1 ii python3 3.11.8-1 ii zlib1g1:1.3.dfsg-3.1 Versions of packages libadios-bin recommends: ii libadios-dev 1.13.1-36 libadios-bin suggests no packages.
Bug#1065797: st: FTBFS on arm{el,hf}: res.c:115:12: error: implicit declaration of function ‘_getshort’; did you mean ‘__putshort’? [-Werror=implicit-function-declaration]
Package: st Followup-For: Bug #1065797 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/02-implicit-declarations.patch: Fix an improper macro feature check. (Closes #1065797, LP: #2060973). * debian/patches/1032955_riscv_support.patch: Add support for RISC-V CPU. Thanks to Steven Liu . (LP: #2061639). Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-27-generic (SMP w/10 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru st-1.9/debian/patches/02-implicit-declarations.patch st-1.9/debian/patches/02-implicit-declarations.patch --- st-1.9/debian/patches/02-implicit-declarations.patch1969-12-31 17:00:00.0 -0700 +++ st-1.9/debian/patches/02-implicit-declarations.patch2024-04-15 10:06:57.0 -0600 @@ -0,0 +1,21 @@ +Description: Fix an improper macro feature check + This resolves the implicit declaration error on armhf +Author: Zixing Liu +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065797 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/st/+bug/2060973 +Forwarded: no +Last-Update: 2024-04-15 +--- +Index: st/examples/res.c +=== +--- st.orig/examples/res.c st/examples/res.c +@@ -82,7 +82,7 @@ + #endif + + /* New in Solaris 7 */ +-#if !defined(_getshort) && defined(ns_get16) ++#if !defined(_getshort) && defined(NS_GET16) + #define _getshort(cp) ns_get16(cp) + #endif + diff -Nru st-1.9/debian/patches/1032955_riscv_support.patch st-1.9/debian/patches/1032955_riscv_support.patch --- st-1.9/debian/patches/1032955_riscv_support.patch 1969-12-31 17:00:00.0 -0700 +++ st-1.9/debian/patches/1032955_riscv_support.patch 2024-04-15 10:06:57.0 -0600 @@ -0,0 +1,111 @@ +Description: Add support for RISC-V CPU +Author: Steven Liu +Origin: https://github.com/ossrs/state-threads/commit/c865500b8c1f4821cc77627094c1a30fef403dbb +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032955 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/st/+bug/2061639 +Applied-Upstream: https://github.com/ossrs/state-threads/commit/c865500b8c1f4821cc77627094c1a30fef403dbb +Reviewed-by: Zixing Liu +Last-Update: 2022-07-20 +--- +Index: st-1.9/md.S +=== +--- st-1.9.orig/md.S st-1.9/md.S +@@ -431,5 +431,81 @@ _st_md_cxt_restore: + + // + ++#elif defined(__riscv) ++ ++// ++/* ++ * Internal __jmp_buf layout ++ * riscv-asm: https://github.com/riscv/riscv-asm-manual/blob/master/riscv-asm.md ++ */ ++#define JB_SP 0/* A0, SP, Stack pointer */ ++#define JB_RA 1/* RA, Return address */ ++#define JB_FP 2/* FP/S0 Frame pointer */ ++#define JB_S1 3/* S1 Saved register*/ ++#define JB_S2 4/* S2-S11, Saved register */ ++#define JB_S3 5/* S2-S11, Saved register */ ++#define JB_S4 6/* S2-S11, Saved register */ ++#define JB_S5 7/* S2-S11, Saved register */ ++#define JB_S6 8/* S2-S11, Saved register */ ++#define JB_S7 9/* S2-S11, Saved register */ ++#define JB_S8 10/* S2-S11, Saved register */ ++#define JB_S9 11 /* S2-S11, Saved register */ ++#define JB_S10 12 /* S2-S11, Saved register */ ++#define JB_S11 13 /* S2-S11, Saved register */ ++ ++ ++ .file "md.S" ++ .text ++ ++ /* _st_md_cxt_save(__jmp_buf env) */ /* The env is $a0, https://en.wikipedia.org/wiki/RISC-V#Register_sets */ ++ .globl _st_md_cxt_save ++ .type _st_md_cxt_save, %function ++ .align 2 ++_st_md_cxt_save: ++ sdsp, JB_SP * 8(a0) ++ sdra, JB_RA * 8(a0) ++ sds0, JB_FP * 8(a0) ++ sds1, JB_S1 * 8(a0) ++ sds2, JB_S2 * 8(a0) ++ sds3, JB_S3 * 8(a0) ++ sds4, JB_S4 * 8(a0) ++ sds5, JB_S5 * 8(a0) ++ sds6, JB_S6 * 8(a0) ++ sds7, JB_S7 * 8(a0) ++ sds8, JB_S8 * 8(a0) ++ sds9, JB_S9 * 8(a0) ++ sds10, JB_S10 * 8(a0) ++ sds11, JB_S11 * 8(a0) ++ lia0, 0 ++ jrra ++ .size _st_md_cxt_save, .-_st_md_cxt_save ++ ++
Bug#1067618: FTBFS: error: implicit declaration of function 'yyerror'; did you mean 'yyerrok'? [-Werror=implicit-function-declaration]
Package: whitedune Followup-For: Bug #1067618 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/implicit-declarations.patch: Add missing includes and function prototypes. (LP: #2061038). Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-27-generic (SMP w/10 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru whitedune-0.30.10/debian/patches/implicit-declarations.patch whitedune-0.30.10/debian/patches/implicit-declarations.patch --- whitedune-0.30.10/debian/patches/implicit-declarations.patch 1969-12-31 17:00:00.0 -0700 +++ whitedune-0.30.10/debian/patches/implicit-declarations.patch 2024-04-15 11:23:06.0 -0600 @@ -0,0 +1,60 @@ +Description: Add missing includes and function prototypes + This fixes FTBFS on armhf +Author: Zixing Liu +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067618 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/whitedune/+bug/2061038 +Forwarded: no +Last-Update: 2024-04-15 +--- +Index: whitedune/src/SDLjoystick/SDL_joystick_c.h +=== +--- whitedune.orig/src/SDLjoystick/SDL_joystick_c.h whitedune/src/SDLjoystick/SDL_joystick_c.h +@@ -2,3 +2,11 @@ + * This Makefile is free software; the Free Software Foundation + * gives unlimited permission to copy, distribute and modify it. + */ ++extern int SDL_PrivateJoystickButton(SDL_Joystick *joystick, ++ Uint8 button, Uint8 state); ++extern int SDL_PrivateJoystickAxis(SDL_Joystick *joystick, ++ Uint8 axis, Sint16 value); ++extern int SDL_PrivateJoystickBall(SDL_Joystick *joystick, ++ Uint8 ball, Sint16 xrel, Sint16 yrel); ++extern int SDL_PrivateJoystickHat(SDL_Joystick *joystick, ++ Uint8 hat, Uint8 value); +Index: whitedune/src/swt/rc/rclex.l +=== +--- whitedune.orig/src/swt/rc/rclex.l whitedune/src/swt/rc/rclex.l +@@ -28,6 +28,7 @@ + #include + + #include ++#include + #include "y.tab.h" + #include "rc.h" + +Index: whitedune/src/swt/rc/rcparse.y +=== +--- whitedune.orig/src/swt/rc/rcparse.y whitedune/src/swt/rc/rcparse.y +@@ -38,6 +38,7 @@ static RCNode *append(RCNode *node1, RCN + static RCBitmap *newBitmap(int id, const char *filename); + static void addAccelerator(int key, int modifiers, int command); + static int getVirtkey(const char *str); ++int yyerror(const char *s); + + RCBitmap **bitmaps = NULL; + RCNode **nodes = NULL; +Index: whitedune/src/pngLoad.c +=== +--- whitedune.orig/src/pngLoad.c whitedune/src/pngLoad.c +@@ -20,6 +20,7 @@ + + #include + #include ++#include + + #include "config.h" + diff -Nru whitedune-0.30.10/debian/patches/series whitedune-0.30.10/debian/patches/series --- whitedune-0.30.10/debian/patches/series 2019-02-12 14:32:01.0 -0700 +++ whitedune-0.30.10/debian/patches/series 2024-04-15 11:20:26.0 -0600 @@ -1,3 +1,4 @@ libxp-configure.patch png1.5.patch avoid-grep-binary.patch +implicit-declarations.patch
Bug#1066247: uhub: FTBFS: adcclient.c:178:33: error: implicit declaration of function ‘ADC_client_connect_internal’; did you mean ‘ADC_client_connect’? [-Werror=implicit-function-declaration]
Package: uhub
Followup-For: Bug #1066247
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* debian/patches/implicit-declarations.patch: Add missing function
prototypes. (LP: #2061039).
* debian/patches/riscv64-fix-ftbfs.patch: Add RISC-V architecture to
CPU list. Thanks to Eric Long . (LP: #2061039).
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-27-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru uhub-0.4.1/debian/patches/implicit-declarations.patch
uhub-0.4.1/debian/patches/implicit-declarations.patch
--- uhub-0.4.1/debian/patches/implicit-declarations.patch 1969-12-31
17:00:00.0 -0700
+++ uhub-0.4.1/debian/patches/implicit-declarations.patch 2024-04-15
12:08:31.0 -0600
@@ -0,0 +1,20 @@
+Description: Add missing function prototypes
+ This fixes FTBFS on armhf
+Author: Zixing Liu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066247
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/uhub/+bug/2061039
+Forwarded: no
+Last-Update: 2024-04-15
+---
+Index: uhub/src/tools/adcclient.c
+===
+--- uhub.orig/src/tools/adcclient.c
uhub/src/tools/adcclient.c
+@@ -88,6 +88,7 @@ static void ADC_client_on_login(struct A
+ static int ADC_client_parse_address(struct ADC_client* client, const char*
arg);
+ static int ADC_client_on_recv_line(struct ADC_client* client, const char*
line, size_t length);
+ static int ADC_client_send_queue(struct ADC_client* client);
++int ADC_client_connect_internal(struct ADC_client* client);
+
+ static void ADC_client_debug(struct ADC_client* client, const char* format,
...)
+ {
diff -Nru uhub-0.4.1/debian/patches/riscv64-fix-ftbfs.patch
uhub-0.4.1/debian/patches/riscv64-fix-ftbfs.patch
--- uhub-0.4.1/debian/patches/riscv64-fix-ftbfs.patch 1969-12-31
17:00:00.0 -0700
+++ uhub-0.4.1/debian/patches/riscv64-fix-ftbfs.patch 2024-04-15
12:09:00.0 -0600
@@ -0,0 +1,22 @@
+Description: Add RISC-V architecture to CPU list
+Author: Eric Long
+Origin:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1020965;filename=riscv64-fix-ftbfs.patch;msg=5
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020965
+Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/uhub/+bug/2061039
+Forwarded: no
+Reviewed-by: Zixing Liu
+Last-Update: 2022-09-30
+---
+--- a/src/system.h
b/src/system.h
+@@ -242,6 +242,10 @@
+ #define CPUINFO "s390"
+ #endif
+
++#if defined(__riscv)
++#define CPUINFO "RISC-V"
++#endif
++
+ /* Misc */
+ #ifdef MSG_NOSIGNAL
+ #define UHUB_SEND_SIGNAL MSG_NOSIGNAL
diff -Nru uhub-0.4.1/debian/patches/series uhub-0.4.1/debian/patches/series
--- uhub-0.4.1/debian/patches/series2022-09-12 03:10:42.0 -0600
+++ uhub-0.4.1/debian/patches/series2024-04-15 12:09:00.0 -0600
@@ -1,3 +1,5 @@
fix-build-on-hurd-i386
openssl1.1.patch
arm64-fix-ftbfs.patch
+implicit-declarations.patch
+riscv64-fix-ftbfs.patch
Bug#1066484: tcpxtract: FTBFS: confy.c:494:16: error: implicit declaration of function ‘yylex’ [-Werror=implicit-function-declaration]
Package: tcpxtract
Followup-For: Bug #1066484
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* debian/patches/70_fix-implicit-declarations.patch: Add missing
includes and function prototypes. Closes #1066484, LP: #2061589.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-27-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tcpxtract-1.0.1/debian/patches/70_fix-implicit-declarations.patch
tcpxtract-1.0.1/debian/patches/70_fix-implicit-declarations.patch
--- tcpxtract-1.0.1/debian/patches/70_fix-implicit-declarations.patch
1969-12-31 17:00:00.0 -0700
+++ tcpxtract-1.0.1/debian/patches/70_fix-implicit-declarations.patch
2024-04-15 10:41:14.0 -0600
@@ -0,0 +1,57 @@
+Description: Add missing includes and function prototypes
+ This fixes the FTBFS on armhf
+Author: Zixing Liu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066484
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2061589
+Forwarded: no
+Last-Update: 2024-04-15
+---
+Index: tcpxtract/conf.h
+===
+--- tcpxtract.orig/conf.h
tcpxtract/conf.h
+@@ -24,5 +24,8 @@
+ #define CONF_H
+
+ extern void config_type(char *, char *, char *, char *);
++int yyparse (void);
++int yyerror(char *s);
++int yylex (void);
+
+ #endif /* CONF_H */
+Index: tcpxtract/confl.l
+===
+--- tcpxtract.orig/confl.l
tcpxtract/confl.l
+@@ -20,6 +20,7 @@
+Tcpxtract, a sniffer that extracts files based on headers
+by Nick Harbour
+ */
++#include
+ #include "confy.h"
+ %}
+
+Index: tcpxtract/confy.y
+===
+--- tcpxtract.orig/confy.y
tcpxtract/confy.y
+@@ -23,6 +23,7 @@
+
+ #include
+ #include "conf.h"
++#include "confy.h"
+ %}
+
+ %union {
+Index: tcpxtract/tcpxtract.c
+===
+--- tcpxtract.orig/tcpxtract.c
tcpxtract/tcpxtract.c
+@@ -44,6 +44,7 @@
+
+ #include "sessionlist.h"
+ #include "util.h"
++#include "conf.h"
+ #include "confy.h"
+ #include "search.h"
+
diff -Nru tcpxtract-1.0.1/debian/patches/series
tcpxtract-1.0.1/debian/patches/series
--- tcpxtract-1.0.1/debian/patches/series 2023-02-06 05:27:00.0
-0700
+++ tcpxtract-1.0.1/debian/patches/series 2024-04-15 10:38:13.0
-0600
@@ -4,3 +4,4 @@
40_fix-png-header-bytes.patch
50_fix-spelling-binary.patch
60_libfl.patch
+70_fix-implicit-declarations.patch
Bug#1065944: squeak-plugins-scratch: FTBFS on arm{el,hf}: WeDoLinux.c:175:9: error: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Werror=implicit-function-declaration]
Package: squeak-plugins-scratch Followup-For: Bug #1065944 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/add-missing-include.patch: Add a missing header to fix build on armhf. (Closes #1065944, LP: #2061587). * debian/control: Add quilt to B-D as this is previously missing. Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-27-generic (SMP w/10 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru squeak-plugins-scratch-1.4.0.2~svn.r83/debian/control squeak-plugins-scratch-1.4.0.2~svn.r83/debian/control --- squeak-plugins-scratch-1.4.0.2~svn.r83/debian/control 2024-03-08 00:00:18.0 -0700 +++ squeak-plugins-scratch-1.4.0.2~svn.r83/debian/control 2024-04-15 10:23:53.0 -0600 @@ -1,8 +1,8 @@ Source: squeak-plugins-scratch Section: devel Priority: optional Maintainer: Miriam Ruiz -Build-Depends: debhelper, dh-buildinfo, +Build-Depends: debhelper, dh-buildinfo, quilt, libcairo2-dev (>= 1.8.6), libpango1.0-dev (>= 1.24.1), libglib2.0-dev (>= 2.20.1), libv4l-dev (>= 0.5.8) Standards-Version: 4.2.1.4 diff -Nru squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/add-missing-include.patch squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/add-missing-include.patch --- squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/add-missing-include.patch 1969-12-31 17:00:00.0 -0700 +++ squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/add-missing-include.patch 2024-04-15 10:23:10.0 -0600 @@ -0,0 +1,19 @@ +Description: Add a missing header to fix build on armhf +Author: Zixing Liu +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065944 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/squeak-plugins-scratch/+bug/2061587 +Forwarded: no +Last-Update: 2024-04-15 +--- +Index: squeak-plugins-scratch/wedo/WeDoLinux.c +=== +--- squeak-plugins-scratch.orig/wedo/WeDoLinux.c squeak-plugins-scratch/wedo/WeDoLinux.c +@@ -37,6 +37,7 @@ + #include + #include + #include ++#include + #include + + diff -Nru squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/series squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/series --- squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/series 1969-12-31 17:00:00.0 -0700 +++ squeak-plugins-scratch-1.4.0.2~svn.r83/debian/patches/series 2024-04-15 10:17:28.0 -0600 @@ -0,0 +1 @@ +add-missing-include.patch
Bug#1069070: fcitx5-chinese-addons: Appdata metainfo XML not in main pkg, breaking Appstream software install
Source: fcitx5-chinese-addons Version: 5.0.4-1 Severity: normal Control: forwarded -1 https://github.com/fcitx/fcitx5-chinese-addons/issues/165 In order to make sure that fcitx5-chinese-addons are correctly installed using Appstream-based GUI software such as KDE Discover or GNOME Software, the Appdata metainfo XML file shall not be placed in a separate package. It should be installed in the main (meta)package. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1069069: reportbug: mma does not work on Python-3
Package: mma Version: 21.09-1 Severity: normal Dear Maintainer, Most of the scripts in the package does not work with Python3. $ mma-mnx File "/usr/bin/mma-mnx", line 262 x=0L ^ SyntaxError: invalid decimal literal $ pg2mma File "/usr/bin/pg2mma", line 9 print "pg2mma, (c) Bob van der Poel" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? $ mma-rm2std File "/usr/bin/mma-rm2std", line 31 print m ^^^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? $ synthsplit File "/usr/bin/synthsplit", line 13 print "synthsplit, (c) Bob van der Poel" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? -- Regards Sudip -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mma depends on: ii python3 3.11.8-1 ii python3-tk 3.12.3-1 Versions of packages mma recommends: ii timidity 2.14.0-8.2 mma suggests no packages.
Bug#1069068: pantalaimon: FTBFS some tests fail with asyncio CancelledError
Source: pantalaimon
Version: 0.10.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
pantalaimon FTBFS in sid (but could be built successfully in bookworm):
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:311: cd /build/pantalaimon-0.10.5/.pybuild/cpython3_3.11/build;
python3.11 -m pytest tests
= test session starts ==
platform linux -- Python 3.11.9, pytest-8.1.1, pluggy-1.4.0
rootdir: /build/pantalaimon-0.10.5
plugins: Faker-24.4.0
collected 17 items
tests/pan_client_test.py .Fss. [ 29%]
tests/proxy_test.py .E.E.E.E.E [ 58%]
tests/store_test.py E...s.. [100%]
ERRORS
___ ERROR at teardown of TestClass.test_daemon_start[pyloop] ___
self =
response_class = , method = 'GET'
path =
'/_matrix/client/r0/sync?access_token=abc123_state=true=%7B%22room%22%3A%7B%22state%22%3A%7B%22lazy_load_members%22%3Atrue%7D%7D%7D'
data = None, response_data = None, content_type = None, trace_context = None
data_provider = None, timeout = 0, content_length = None, save_to = None
async def _send(
self,
response_class: Type,
method: str,
path: str,
data: Union[None, str, AsyncDataT] = None,
response_data: Optional[Tuple[Any, ...]] = None,
content_type: Optional[str] = None,
trace_context: Optional[Any] = None,
data_provider: Optional[DataProvider] = None,
timeout: Optional[float] = None,
content_length: Optional[int] = None,
save_to: Optional[os.PathLike] = None,
):
headers = (
{"Content-Type": content_type}
if content_type
else {"Content-Type": "application/json"}
)
if content_length is not None:
headers["Content-Length"] = str(content_length)
if self.config.custom_headers is not None:
headers.update(self.config.custom_headers)
got_429 = 0
max_429 = self.config.max_limit_exceeded
got_timeouts = 0
max_timeouts = self.config.max_timeouts
while True:
if data_provider:
# mypy expects an "Awaitable[Any]" but data_provider is a
# method generated during runtime that may or may not be
# Awaitable. The actual type is a union of the types that we
# can receive from reading files.
data = await data_provider(got_429, got_timeouts) # type:
ignore
try:
> transport_resp = await self.send(
method,
path,
data,
headers,
trace_context,
timeout,
)
/usr/lib/python3/dist-packages/nio/client/async_client.py:777:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/nio/client/async_client.py:291: in wrapper
return await func(self, *args, **kwargs)
/usr/lib/python3/dist-packages/nio/client/async_client.py:855: in send
return await self.client_session.request(
/usr/lib/python3.11/unittest/mock.py:2251: in _execute_mock_call
result = await effect(*args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
orig_self =
method = 'GET'
url =
URL('https://example.org/_matrix/client/r0/sync?access_token=abc123=%257B%2522room%2522%253A%257B%2522state%2522%253A%257B%2522lazy_load_members%2522%253Atrue%257D%257D%257D_state=true')
args = ()
kwargs = {'data': None, 'headers': {'Content-Type': 'application/json'}, 'ssl':
False, 'timeout': 0, ...}
url_origin =
'https://example.org/_matrix/client/r0/sync?access_token=abc123_state=true=%7B%22room%22%3A%7B%22state%22%3A%7B%22lazy_load_members%22%3Atrue%7D%7D%7D'
url_str =
'https://example.org/_matrix/client/r0/sync?access_token=abc123=%257B%2522room%2522%253A%257B%2522state%2522%253A%257B%2522lazy_load_members%2522%253Atrue%257D%257D%257D_state=true'
prefix = 'http://127.0.0.1'
key = ('GET',
URL('https://example.org/_matrix/client/r0/sync?access_token=abc123=%257B%2522room%2522%253A%257B%2522state%2522%253A%257B%2522lazy_load_members%2522%253Atrue%257D%257D%257D_state=true'))
request_call = RequestCall(args=(), kwargs={'data': None, 'ssl': False,
'headers': {'Content-Type': 'application/json'}, 'trace_request_ctx': None,
'timeout': 0, 'allow_redirects': True})
response = None
async def _request_mock(self, orig_self: ClientSession,
method: str, url: 'Union[URL, str]',
*args: Tuple,
**kwargs: Any) -> 'ClientResponse':
"""Return mocked response object or raise connection error."""
if
Bug#1055811: O: coreboot -- free firmware
On 2023-12-22 00:15:30, Matthias Geiger wrote: > Once the StarBook VI AMD get mainline coreboot support I will adopt this > package. Hi! It would be nice to see this come through! Do you still intend on adopting this package, and if so, when will StarBook get that nice update? :) a. -- Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." - Edward Snowden
Bug#1069067: xxdiff-scripts: xx-svn-review fails to run
Package: xxdiff-scripts Version: 1:5.1+git20220924+dfsg-1 Severity: normal Dear Maintainer, xx-svn-review fails to run with the error: $ xx-svn-review --help Traceback (most recent call last): File "/usr/bin/xx-svn-review", line 7, in from StringIO import StringIO ModuleNotFoundError: No module named 'StringIO' -- Regards Sudip -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xxdiff-scripts depends on: ii python3 3.11.8-1 ii xxdiff 1:5.1+git20220924+dfsg-1+b1 Versions of packages xxdiff-scripts recommends: ii gnupg 2.2.40-1.1 ii patch 2.7.6-7 xxdiff-scripts suggests no packages.
Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?
Source: gcc-14 Version: 14-20240121-1 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: debian-cr...@lists.debian.org Hello Matthias, the -for-host stuff doesn't quite work for architecture cross bootstrap yet and I'm looking into why. What initially seemed like a trivial question turned out be a bit subtle. Which gcc builds should emit -for-host packages? This may sound like an obvious question initially, but looking beneath makes it a little less obvious. It is relatively obvious that native builds and cross builds (build!=host=target) should both emit -for-host packages. The question becomes more interesting when you look into cross toolchain builds. >From an end-user pov using a cross toolchain, there is no need for -for-host packages. They can use a built cross toolchain entirely without these packages as -for-host packages effectively are metapackages. If we look at e.g. src:gcc-14-cross, it builds e.g. gcc-14-aarch64-linux-gnu, so in principle it could be emitting gcc-14-for-host:arm64, but since host!=target, we can never include this binary package in a .changes files nor upload it to the archive. We can see that cross toolchain builds via src:gcc-14-cross must not include -for-host packages. Likewise, cross-toolchain-base cannot include them. The point where we really need -for-host packages is when we need to satisfy Debian package dependencies in a cross build setting. In this setting, we also need libstdc++-14-dev and others. This is not something you get from a cross toolchain build (unless you patch in the with_deps_on_target_arch_pkgs patch that you removed and is now available in cross-gcc-dev). So when you need libstdc++-14-dev, you end up building DEB_STAGE=rtlibs (or using natively built packages for your target architecture) and when you do not need libstdc++-14-dev, you almost certainly also won't need -for-host packages. Quite clearly, doing both a cross toolchain build and a DEB_STAGE=rtlibs build should result in -for-host packages and ideally should produce them only once. Currently, the cross toolchain build produces them and the DEB_STAGE=rtlibs build does not produce them. Given my reasoning in the previous paragraph, it would also be plausible to emit them from DEB_STAGE=rtlibs only. Another aspect is the content of -for-host packages. They install their doc directory as a symbolic link to $(p_xbase). In a cross toolchain build (without with_deps_on_target_arch_pkgs), p_xbase ends up being target-dependent. Hence, the symlink target in these -for-host packages differs. While native builds and cross builds link to gcc-14-base, cross toolchains link to gcc-14$(cross_bin_arch)-base and dpkg very much does not like Multi-Arch: same packages to install conflicting symbolic links. As a result, the -for-host packages we emit from cross toolchain builds cannot be installed concurrently with any other -for-host package significantly defeating their purpose. I looked into fixing this problem and the obvious thing to try is changing the symlink targets in cross toolchain builds to also point to gcc-14-base. As a consequence, they also depend on gcc-14-base, but a cross toolchain build does not currently produce a gcc-14-base package for the target architecture. If we were producing it, both the cross toolchain build and the DEB_STAGE=rtlibs build were producing them and a user would have to choose which one of them to use. It also means introducing another variant of naming base packages besides p_base, p_lbase and p_xbase which already are non-trivial to understand. If we were moving the -for-host packages from the cross toolchain build to the DEB_STAGE=rtlibs build, they would automatically reference the right base package, because the runtime libraries also link their documentation to it. On the flip side, the resulting -for-host packages would not have satisfiable dependencies unless combining with a cross toolchain build (or a native compiler for the target architecture), so the DEB_STAGE=rtlibs would no longer be self-contained in a sense. This move would not affect gcc-14-cross nor cross-toolchain-base, because neither of them include -for-host packages (as we saw earlier). In writing this, I am providing arguments that rather strongly suggest that we should move them from the cross toolchain build to the DEB_STAGE=rtlibs build, but is this really the right conclusion or am I missing something? In any case, I looked into prototyping this suggested move as a patch to the gcc packaging. I am attaching a proof-of-concept of this, but I'm not particularly fond of it as it noticeably increases the packaging complexity. I am adding a lot of "addons" and pull a bit of code from various debian/rules.d/binary-*.mk to a new debian/rules.d/binary-forhost.mk such that prefixes that were only used in a particular file are now spread to multiple. For instance, all ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier and are now
Bug#1069066: LIMITS_H_TEST is frequently wrong on Debian
Source: gcc-14
Tags: patch upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cr...@lists.debian.org
Hi Matthias,
I've been fighting LIMITS_H_TEST for a long time. The basic problem with
it is that it uses different search paths from the actual compiler and
thus ends up occasionally detecting absence of limits.h when limits.h
really does exist. There have been various attempts to rectify this and
most of them are documented in the forwarded gcc ticket. Ultimately
though, I think the best course of action is deferring the check from a
build-time check to a run-time check thus using the actual compiler's
search path removing any possibility for misdetection. This can be done
using has_include_next in principle, but until recently,
has_include_next was broken on gcc in ways that would make this solution
inapplicable. These problems with has_include_next have recently been
resolved in gcc-14 and the Debian package includes a working version. As
a result I suggest that we also move forward with my proposed
LIMITS_H_TEST replacement in Debian. Upstream gcc fails to move forward
here and the problem affects Debian in particular due to our use of
multiarch and our changing of the compiler search path. Would you agree
to carry this as a Debian patch until gcc manages to fix it one way or
another? I've been using this last iteration of the patch for quite a
while now and didn't have any misdetections since.
Helmut
--- a/src/gcc/limitx.h
+++ b/src/gcc/limitx.h
@@ -29,7 +29,7 @@
#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */
#define _GCC_LIMITS_H_
-#ifndef _LIBC_LIMITS_H_
+#if !defined(_LIBC_LIMITS_H_) && __has_include_next()
/* Use "..." so that we find syslimits.h only in this same directory. */
#include "syslimits.h"
#endif
--- a/src/gcc/limity.h
+++ b/src/gcc/limity.h
@@ -3,7 +3,7 @@
#else /* not _GCC_LIMITS_H_ */
-#ifdef _GCC_NEXT_LIMITS_H
+#if defined(_GCC_NEXT_LIMITS_H) && __has_include_next()
#include_next /* recurse down to the real one */
#endif
--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -3139,11 +3139,7 @@
sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
include_dir=include$${multi_dir}; \
- if $(LIMITS_H_TEST) ; then \
- cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
- else \
- cat $(T_GLIMITS_H) > tmp-xlimits.h; \
- fi; \
+ cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
$(mkinstalldirs) $${include_dir}; \
chmod a+rx $${include_dir} || true; \
$(SHELL) $(srcdir)/../move-if-change \
Bug#1069063: distro-info: Please support distro-info --alias=trixie -r
Package: distro-info Version: 1.7 Severity: minor Dear Maintainer, distro-info --alias=trixie -r is misleading it return trixie instead of 13... Maybe a feature but should be documented I workarround by doing in my script in two steps: distro-info --$(distro-info --alias=trixie) -r Bastien signature.asc Description: This is a digitally signed message part.
Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move
Package: util-linux-extra Version: 2.40-6 Severity: serious User: helm...@debian.org Usertags: dep17p1 Control: affects -1 + util-linux Hi Chris, I think I mentioned this on IRC already and you intended to revert, but nothing happened, so lets turn this into a bug for tracking purposes at least. util-linux-extra gained the utils ctrlaltdel, fsck.cramfs, fsck.minix, mkfs.bfs, mkfs.cramfs, and mkfs.minix. In util-linux-extra, these now reside below /usr/sbin while they used to reside in /sbin in util-linux in bookworm and earlier. Hence upgrading from bookworm to sid can cause these files to be lost. I think we have three ways to address this: 1. Revert the move and retry after trixie. I think you favoured this? 2. Upgrade Breaks to Conflicts and issue a temporary protective diversion from u-l-e.preinst to u-l-e.postinst. In theory, apt can first unpack u-l, then unpack u-l-e and then configure both, so there is a safe solution. However, there is a risk that apt could decide to temporarily remove u-l and that would be really bad. 3. Keep Breaks and issue temporary diversions to be removed in forky's u-l-e.postinst. Please let me know your choice and I can do a patch. Helmut
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
reassign 1039979 debian-policy thanks Dear Policy editors: In this bug I'm asked to make /var/run and /var/lock symlinks to be relative. Maybe it's the right thing to do, but last time I tried to do that, this is what happened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345 [ Summary: I had to revert the change because it was against policy ]. So, I'm reassigning this bug to debian-policy. Please drop me a note whenever there is a consensus that relative symlinks are ok for /var/run and /var/lock (even if there is not a new policy release reflecting it yet). Thanks.
Bug#1069048: All NICs tried with same retries and timeouts?
What is the behaviour if computer has 5 NICs and all of them are linked to a DHCP-served network? Will all of them get network configuration or only first succeeded one? -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should remove and omit any @, dot and mailto combinations against automated addresses collectors.
Bug#1069046: fgallery: Missing map.png image in the distributed package
I see that the fgallery project has moved to gitlab. There the geolocation merge request is still opened: https://gitlab.com/wavexx/fgallery/-/merge_requests/95 It references the missing map.png file available from https://gitlab.com/tillea/fgallery/-/commit/2eaf626c02c805aad32c86307f512ddf2f5ab833 Kim Minh.
Bug#947478: Fwd: freeimage and CVE-2019-12214
Information about this CVE and bug. -- Forwarded message - From: Cyrille Bollu Date: Sun, 14 Apr 2024 at 12:24 Subject: Re: freeimage and CVE-2019-12214 To: Ola Lundqvist Cc: Hi, I've performed a more thoroughful investigation and have informed NIST that the offending line is actually to be found in openjpeg between version 2.0.0 up to (excluding) 2.1.0. Debian Buster isn't affected as it uses version 2.3.0-2+deb10u2. Hereunder copy of the email I've sent ot NIST. Best regards, Cyrille >Message-ID: <981f8fc77d9e0fee8399a19e6e4c9c64ceeea9a7.ca...@bollu.be> >Subject: CVE-2019-12214: missing vulnerable configuration >From: Cyrille Bollu >To: cpe_diction...@nist.gov >Date: Sun, 14 Apr 2024 12:01:43 +0200 >Content-Type: text/plain; charset="UTF-8" >Content-Transfer-Encoding: quoted-printable >User-Agent: Evolution 3.46.4-2 >MIME-Version: 1.0 >X-Evolution-Identity: 953def08ae37ee7006cd76b472f065ecb205f7e1 >X-Evolution-Fcc: >folder://d19e895bfc6f11c136a14747fb40c471b2a393e7/Sent >X-Evolution-Transport: 80f305883d50f910e4b81fcb40b6c46360542068 >X-Evolution-Source: > >Dear NIST, > >As part of an investigation performed on-behalf of Debian-LTS team, >I've found out that CVE-2019-12214 is actualy located in code from the >openjpeg project (https://github.com/uclouvain/openjpeg) which >freeimage copied in its source tree. > >The offending line, "memcpy(l_cp->ppm_data_current, p_header_data, >l_N_ppm);", has been introduced in version 2.0.0 (see >https://github.com/uclouvain/openjpeg/archive/refs/tags/version.2.0.tar.gz ) >and removed in version 2.1.1 (see >https://github.com/uclouvain/openjpeg/archive/refs/tags/v2.1.1.tar.gz) . > >So, all intermediatory versions (version 2.0.0 included) might be >vulnerables (I haven't investigated more than just the presence of >absence of this line though). > >I think it's worth updating CVE-2019-12214 with this information. > >Best regards, > >Cyrille Bollu Le samedi 13 avril 2024 à 09:56 +0200, Cyrille a écrit : > I don’t know anything about your procedures, but I don’t see why we > wouldn’t… > > I would also contact NIST (or whoever is in charge of the CVE > database; I can’t remember by heart who it is) to let them know this, > so they update the CVE’s vulnerable configurations. I’ll try to do > that next week, but I will probably first have to find out which > exact versions of openjpeg2 have been affected (which will probably > be quite difficult for me) > > Nice week-end > > Cyrille > > > Le 13 avr. 2024 à 00:22, Ola Lundqvist a écrit : > > > > Hi Cyrille > > > > > On Fri, 12 Apr 2024 at 16:32, Cyrille Bollu > > > wrote: > > > > > > Hi Ola, > > > > > > Thank you for your help. > > > > > > So, IIUC: > > > > > > 1. CVE-2019-12214 shouldn't be assigned to freeimage in Debian > > > Buster; > > > 2. CVE-2019-12214 might be assigned to source package openjpeg2 > > > or > > > openjpeg (the later doesn't seem to be available in Buster > > > though) > > > > Yes, potentially so. At least if I understand the email from > > Santiago correctly. > > > > freeimage build depends on libopenjp2-7-dev which is built from > > openjpeg2 so in buster it is openjpeg2 where it should belong. > > > > But I do not know whether we typically re-assign things like this > > or > > not so I do not want to give advice for this. Better if someone > > else > > who knows the practice answers this. > > > > // Ola > > > > -- > > --- Inguza Technology AB --- MSc in Information Technology > > > o...@inguza.como...@debian.org| > > > http://inguza.com/Mobile: +46 (0)70-332 1551 | > > --- > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)
found 1069059 239-1 found 1069059 287-1 tags 1069059 + bullseye bookworm thanks El 15/4/24 a las 19:28, Salvatore Bonaccorso escribió: The update for cockpit in DSA 5655-1 had problems with the test-sshbridge test, causing FTBFS: For completeness: this was already happening in bullseye and bookworm before the DSA. (Reminder for myself: report all the bugs I found last week while rebuilding bullseye and bookworm). Thanks.
Bug#1069062: golang-github-disintegration-imaging: CVE-2023-36308
Package: golang-github-disintegration-imaging X-Debbugs-CC: t...@security.debian.org Severity: normal Tags: security Hi, The following vulnerability was published for golang-github-disintegration-imaging. CVE-2023-36308[0]: | disintegration Imaging 1.6.2 allows attackers to cause a panic | (because of an integer index out of range during a Grayscale call) | via a crafted TIFF file to the scan function of scanner.go. NOTE: it | is unclear whether there are common use cases in which this panic | could have any security consequence If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-36308 https://www.cve.org/CVERecord?id=CVE-2023-36308 Please adjust the affected versions in the BTS as needed. Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1069061: gosa: cannot create new ACL except ACL type "Current Object"
Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-11
Severity: normal
X-Debbugs-Cc: sasajim...@jp.fujitsu.com
Dear Maintainer,
When I create a new ACL on any objects, GOsa will show following ACL types:
* Complete subtree
* Complete subtree (permanent)
* Current object
* One level
* Reset ACLs
* Use ACLs defined in role
.
By default, "Current object" is set.
However, if I choose another ACL type (e.g. Complete subtree),
GOsa resets my choice to the default.
This bug caused following code:
--- /usr/share/gosa/include/class_acl.inc.debian 2024-04-16 02:27:39.747593228
+0900
+++ /usr/share/gosa/include/class_acl.inc.orig 2024-04-16 02:45:22.783564170
+0900
@@ -494,7 +494,7 @@
if($this->acl_is_writeable("")){
foreach (array("aclType","aclFilter", "aclObject", "target") as
$key){
if (isset($_POST[$key])){
-$this->key= get_post($key);
+$this->$key= get_post($key);
}
}
}
There is not this bug in original Github code.
-- System Information:
Debian Release: 12.4
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldoldstable-updates'), (500,
'oldoldstable'), (500, 'oldstable'), (110, 'oldoldstable'), (90, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.10.0-1127.13.1.el7.x86_64 (SMP w/2 CPU threads)
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gosa depends on:
ii apache2 [httpd]2.4.57-2
ii fonts-liberation 1:1.07.4-11
ii gettext0.21-12
ii imagemagick8:6.9.11.60+dfsg-1.6
ii imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.6
ii libcrypt-smbhash-perl 0.12-4.1
ii libjs-scriptaculous1.9.0-3
ii nullmailer [mail-transport-agent] 1:2.2-4
ii php2:8.2+93
ii php-cgi2:8.2+93
ii php-curl 2:8.2+93
ii php-gd 2:8.2+93
ii php-imap 2:8.2+93
ii php-ldap 2:8.2+93
ii php-mbstring 2:8.2+93
ii php-mysql 2:8.2+93
ii php-xml2:8.2+93
ii php7.4-cli [php-cli] 7.4.33-1+deb11u4
ii php7.4-curl [php-curl] 7.4.33-1+deb11u4
ii php7.4-gd [php-gd] 7.4.33-1+deb11u4
ii php7.4-ldap [php-ldap] 7.4.33-1+deb11u4
ii php7.4-mbstring [php-mbstring] 7.4.33-1+deb11u4
ii php7.4-xml [php-xml] 7.4.33-1+deb11u4
ii php8.2 [php] 8.2.7-1~deb12u1
ii php8.2-cgi [php-cgi] 8.2.7-1~deb12u1
ii php8.2-cli [php-cli] 8.2.7-1~deb12u1
ii php8.2-curl [php-curl] 8.2.7-1~deb12u1
ii php8.2-gd [php-gd] 8.2.7-1~deb12u1
ii php8.2-imap [php-imap] 8.2.7-1~deb12u1
ii php8.2-ldap [php-ldap] 8.2.7-1~deb12u1
ii php8.2-mbstring [php-mbstring] 8.2.7-1~deb12u1
ii php8.2-xml [php-xml] 8.2.7-1~deb12u1
ii smarty-gettext 1.7.0-1
ii smarty44.3.0-1+deb12u1
gosa recommends no packages.
Versions of packages gosa suggests:
pn cyrus21-imapd
ii gosa-schema2.8~git20230203.10abe45+dfsg-1+deb12u2
pn php-apc
pn php-fpdf
pn php-suhosin
pn postfix-ldap
ii slapd 2.5.13+dfsg-5
-- Configuration Files:
/etc/gosa/gosa-apache.conf changed [not included]
-- no debconf information
Bug#1044151: Re: Bug#1044151: gnome-shell-extension-autohidetopbar: Fails to build source after successful build
Contol: tags -1 -pending The fix broke stuff, so I reverted the previous attempt. -- tobi On Sun, 13 Aug 2023 17:49:56 + Tobias Frost wrote: > Control: tags -1 pending > > Thanks Lucas for the report. > > I've fixed it already on salsa and with the next upload this will be solved > >
Bug#1069060: elpa-go-mode: Emacs warnings when using go-mode
Package: elpa-go-mode
Version: 3:1.6.0-1
Severity: normal
Dear Maintainer,
I installed elpa-go-mode and added the following lines to ~/.emacs:
(autoload 'go-mode "go-mode" nil t)
(add-to-list 'auto-mode-alist '("\\.go\\'" . go-mode))
The first time I open a .go file I get warnings:
Warning (comp): go-mode.el:2158:13: Warning: Empty let* body Disable
showing Disable logging
Warning (comp): go-mode.el:743:37: Warning: the function
‘go--boring-comment-p’ is not known to be defined. Disable showing Disable
logging
Warning (comp): go-mode.el:743:18: Warning: the function ‘go--empty-line-p’
is not known to be defined. Disable showing Disable logging
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-20-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages elpa-go-mode depends on:
ii dh-elpa-helper 2.0.16
ii emacsen-common 3.0.5
Versions of packages elpa-go-mode recommends:
ii golang-golang-x-tools 1:0.5.0+ds-1
elpa-go-mode suggests no packages.
-- no debconf information
Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)
Source: cockpit
Version: 287.1-0+deb12u1
Severity: serious
Justification: missing binary builds, FTBFS
X-Debbugs-Cc: t...@security.debian.org, a...@debian.org, car...@debian.org
Hi
The update for cockpit in DSA 5655-1 had problems with the
test-sshbridge test, causing FTBFS:
>From the tail of the test failure:
# cockpit-protocol-DEBUG: test-ssh: output queue empty
(cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
(src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed:
(ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)
(cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
(src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed:
(ssh_options_parse_config (data->session, NULL) == 0)
# cockpit-protocol-DEBUG: test-ssh: reading input 1
# cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
# cockpit-protocol-DEBUG: test-ssh: want more data
**
cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
assertion failed (json_object_get_string_member (init, "command") == "init"):
("authorize" == "init")
Bail out!
cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
assertion failed (json_object_get_string_member (init, "command") == "init"):
("authorize" == "init")
cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't connect:
Hostname required 'some_host' '22'
cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken pipe
cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message:
Inappropriate ioctl for device
FAIL test-sshbridge (exit status: 134)
Regards,
Salvatore
Bug#1066876: RFS: hyprland/0.36.0+ds-1 [ITP] -- Dynamic tiling Wayland compositor
Updated to newer upstream version 0.38.1
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
Control: tags -1 - moreinfo > This FTBFS: "! LaTeX Error: File `lmodern.sty' not found." > Also I think the additional notes in the changelog entry belong in > README.Debian or README.source. Done and done. Alan M Varghese (NyxTrail)
Bug#1069058: RFS: libhyprcursor/0.1.7-1 [ITP] -- hyprland cursor format, library and utilities (headers)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libhyprcursor": * Package name : libhyprcursor Version : 0.1.7-1 Upstream contact : https://github.com/hyprwm/hyprcursor/issues * URL : https://github.com/hyprwm/hyprcursor * License : BSD-3-Clause * Vcs : https://salsa.debian.org/NyxTrail/hyprcursor Section : x11 The source builds the following binary packages: hyprcursor-util - Utility to manipulate hyprcusor and xcursor themes libhyprcursor0 - hyprland cursor format, library and utilities libhyprcursor-dev - hyprland cursor format, library and utilities (headers) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhyprcursor/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhyprcursor/libhyprcursor_0.1.7-1.dsc Changes for the initial release: libhyprcursor (0.1.7-1) UNRELEASED; urgency=low . * Initial release. Closes: #1067116 Regards, -- Alan M Varghese
Bug#1069057: ITP: golang-github-edwvee-exiffix -- EXIF orientation correct replacement for golang's image.Decode
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org, nil...@debian.org * Package name: golang-github-edwvee-exiffix Version : 0.0~git20240229.0dbb146 Upstream Contact: https://github.com/edwvee/exiffix/issues * URL : https://github.com/edwvee/exiffix * License : Expat Programming Lang: Go Description : EXIF orientation correct replacement for golang's image.Decode (library) Exiffix is a one function golang library made to be a replacement for image.Decode to handle orientation stored in EXIF data. . exiffix.Decode has mostly the same signature as image.Decode. The difference is that it requires io.ReadSeeker instead of io.Seeker. New dependency of kitty 0.34.0. Will be maintained within Golang team & will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Bug#1069056: RFS: python-chameleon/4.5.4-1 -- XML-based template compiler - doc
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-chameleon": * Package name : python-chameleon Version : 4.5.4-1 Upstream contact : Malthe Borch * URL : https://github.com/malthe/chameleon * License : BSD-3-clause~repoze, Zope-2.1, Python * Vcs : https://salsa.debian.org/debian/python-chameleon Section : python The source builds the following binary packages: python3-chameleon - XML-based template compiler python-chameleon-doc - XML-based template compiler - doc To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-chameleon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-chameleon/python-chameleon_4.5.4-1.dsc Changes since the last upload: python-chameleon (4.5.4-1) unstable; urgency=medium . * New upstream version 4.5.4 * d/control: Bump Standards-Version to 4.7.0 * d/rules: Modify PYBUILD_TEST_ARGS to enable previously disabled tests Regards, -- Akash Doppalapudi OpenPGP_0xBCBCAE31ECE05007.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#575781: Please resolve IPv6 gateway too
Control: tags -1 - patch [Philipp Kern 2013-05-04] > Scrap that. We want to implement gethostbyname4, which is what nss-myhostname > does. This returns gaih_addrtuple instead of hostents, which are able to > bear scope IDs. OK. Assume a different patch is needed and remove the patch tag. -- Happy hacking Petter Reinholdtsen
Bug#1068797: modsecurity-crs: IncludeOptional in file owasp-crs.load is incompatible with nginx
Hi Salil, Thanks for reporting. Unfortunately this is a known bug of libmodsecurity3 + Nginx: this installation does not support the `IncludeOptional` directive. The workaround is that you change it manually. Note, that CRS team suggest (since CRS 4) to use the `Include` form in all cases - see documentation: https://coreruleset.org/docs/deployment/extended_install/#includes-for-nginx Regards, a. On Thu, Apr 11, 2024 at 11:27 AM Salil Sayed wrote: > Package: modsecurity-crs > Version: 3.3.4-1 > Severity: important > Tags: newcomer > X-Debbugs-Cc: salilsa...@gmail.com > > Dear Maintainer, > > I configured modsecurity for nginx using the available packages in the > bookworm > repository; namely, libmodsecurity3 and libnginx-mod-http-modsecurity. It > worked like charm except with this package modsecuirty-crs. The two > IncludeOptional directives in the file owasp-crs.load had to be changed to > Include since nginx does not support IncludeOptional. This simply worked > but by > editing a file that the user is not supposed to edit and is likely to be > overwritten on update. > > I believe there may be a way to make the whole modsecurity implementation > to > work out of the box for nginx as well by simply changing these two > IncludeOptional directives to Include. Both of them include files that are > already provided by the package hence IncludeOptional is redundant. > > Thanks, > Salil > > > > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > modsecurity-crs depends on no packages. > > modsecurity-crs recommends no packages. > > Versions of packages modsecurity-crs suggests: > pn geoip-database-contrib > pn libapache2-mod-security2 > pn lua > pn python > pn ruby >
Bug#1069055: chr: Hardcode build-depends on library pkg libqt5concurrent5, blocks time_64 transition
Source: chr Version: 0.1.77-1 Severity: serious X-Debbugs-CC: c...@istoph.de Dear Debian chr package maintainer, Your package builds-depends on library package libqt5concurrent5, which does not exist in Debian Sid after Debian 64-bit time_t transition since the library package was renamed. In all occurrences, you shall not build-depends on the library package directly. Please replace such build-dependency with the actual development package behind it. If no development package is needed in this case, such build-dependency shall be removed. If you have any questions or do not know how to find the corresponding development package, please feel free to let me know. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1069054: shim: install ca for secure boot
Source: shim Severity: minor Dear Maintainer, Could you install the ca used for secure boot somewhere in the tree ? It will help to check by autopkgtest the ca chain Bastien signature.asc Description: This is a digitally signed message part.
Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland
Control: tags -1 - moreinfo
Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not << 0.2
as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends} (which
will be emoty anyway).
Done and done.
Alan M Varghese (NyxTrail)
Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA
|Control: |tags -1 - moreinfo > The package FTBFS: /bin/bash: line 1: /usr/bin/python3: No such file or directory Fixed by adding python3 build-dep > Also, debian/watch is empty but present Added comments about why it is not filled in: # Upstream has not published a new version in ~10+ years and # there is no active development. # There is no meaningful way to configure uscan at the moment. > __AUTO_PERMISSIVE__ and __UNKNOWN__ in debian/copyright. These were for m4/* and INSTALL files. Removed them. Additionally, I also changed the version to 0+20221013 instead of 0~20221013. Thanks, Alan M Varghese (NyxTrail)
Bug#1069053: toilet man page: @PACKAGE_VERSION@
Package: toilet Version: 0.3-1.4 There's unexpanded @PACKAGE_VERSION@ in the man page: $ man toilet | tail -n1 libcaca @PACKAGE_VERSION@ 2006‐11‐10 toilet(1) -- System Information: Architecture: i386 -- Jakub Wilk
Bug#1069052: FTBFS with SQLAlchemy 2.x
Source: gertty Version: 1.6.0-1 Severity: important Tags: patch Hi, As per subject, there's a patch upstream here to fix this bug: https://review.opendev.org/c/ttygroup/gertty/+/880123 Cheers, Thomas Goirand (zigo)
Bug#1067831: libaio: the t64 package slipped through and is in testing
Re: Raphael Hertzog > There are (proprietary) software out there that link against it and we > happen to ship some in Kali's non-free (oracle-instantclient-*). > > https://pkg.kali.org/pkg/oracle-instantclient-basic > https://pkg.kali.org/pkg/oracle-instantclient-devel > > It would be nice if we could continue to keep compabitility with binaries > compiled against upstream's SONAME. Fwiw I've now stumbled over this for the same reason - the Oracle-interfacing packages on apt.postgresql.org are now uninstallable on Ubuntu 24.04 noble which has already picked up this rename. I tried to paper over the problem by making them depend on "libaio1 | libaio1t64" but since the .so file was also renamed, this doesn't work. The installation instructions for Oracle on Linux have been "install libaio1 and then run this giant installer" for the past few decades, so this rename is going to confuse quite a few people if not reverted. Christoph
Bug#1068425: pflogsumm: Postfix logs days in month < 10 with leading zeroes, pflogsumm expects space padding
Hi,
I was using (in postfix main.cf)
maillog_file = /var/log/maillog
Logs look like:
Apr 15 17:09:23 mail postfix/master[125626]: daemon started -- version
3.7.10, configuration /etc/postfix
If postfix logging is unchanged from debian conf (no maillog_file=), I
get timestamps like:
2024-04-15T17:08:12.982938+02:00
and the logs appear both in the journal and in /var/log/mail.log
pflogsumm args:
pflogsumm -d yesterday \
-u 20 -h 20 \
--problems_first \
--smtpd_stats \
--ignore_case \
--bounce_detail=0 \
--deferral_detail=0 \
--reject_detail=0 \
--smtpd_warning_detail=0 \
--no_no_msg_size \
--iso_date_time \
--verp_mung=2 \
/var/log/maillog
/magnus
On 2024-04-12 15:03, Sven Hoexter wrote:
On Fri, Apr 05, 2024 at 01:01:52AM +0200, Magnus Stenman wrote:
Hi,
sorry for the delay, I just started to briefly look into the issue.
Pflogsumm reports zero mails on day 1-9 of every month
Stock debian postfix version
Patch:
--- /usr/sbin/pflogsumm.orig2024-04-05 00:45:38.214914066 +0200
+++ /usr/sbin/pflogsumm 2024-04-05 00:45:44.710952673 +0200
@@ -1518,7 +1518,7 @@
}
my ($t_mday, $t_mon, $t_year) = (localtime($time))[3,4,5];
-return sprintf("%s %2d", $monthNames[$t_mon], $t_mday),
sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
+return sprintf("%s %02d", $monthNames[$t_mon], $t_mday),
sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
}
It's been a while I looked into pflogsumm and for me it still works,
but I do not rely for a long time on the traditional BSD syslog format.
Also Debian doesn't do that by default for some time, so I'm wondering
what exactly your logs look like. If possible please provide a sample.
Also how did you invoke pflogsumm, any flags in use?
According to RFC3164 section 4.1.2 there isn't zero padding but space
padding in the traditional timestamp. Likely there is a bug
somewhere, maybe even in one of the other patches I carry in the
package, but I believe the format returned here, without zero
padding on the day of the month is correct.
Sven
Bug#1065327: ITA: python-levenshtein
On Fri, 15 Mar 2024 14:21:17 + Julian Gilbey wrote: > On Fri, Mar 15, 2024 at 10:03:44AM -0400, Louis-Philippe Véronneau wrote: > Quick update, having taken a peek at the package: the version > currently in unstable is quite old - it is a version that did not > require rapidfuzz. So I will leave it as-is until rapidfuzz makes it > into testing (which may be some time), and then it can be updated. I see rapidfuzz has cleared NEW. In the interest of making some progress towards the autoremovals that are queued up behind levenshtein's removal from testing, I've updated levenshtein in git as a Team Upload and uploaded the package to experimental. It now needs to clear NEW itself (since it has grown a -doc package now that it has more extensive documentation via sphinx). Once levenshtein has cleared NEW and landed in experimental, we'll be able to see how rdeps go with the new version too, prior to pushing such a big update to unstable. Prior to landing in unstable, it should get some humans listed in Uploaders too. I wasn't sure who really wanted their name in there and since no-one had done so in git yet, I didn't make assumptions about who that would be. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, Thanks for your review and loop in me with #1017530. On Mon, Apr 15, 2024 at 2:03 PM Stéphane Glondu wrote: > > Dear Bo, > > Le 14/04/2024 à 16:30, Bo YU a écrit : ... > > ``` > > In fact, the original solution is that I refer to this[1]. But I am > > not sure if this is a toolchain issue or not, so I have reported this > > to upstream[2] also. The workaround for this issue I could think of: > > 1. Keep those lintian messages here and open a reportbug to track the > > issue until upstream fix the issue; > > 2. Use the solution like [1] as my previous post and open a reportbug > > to track the issue until upstream fix the issue; > > 3. Wait to upstream to fix this issue; > > 4. Persuading the maintainers of debhelper to strip static library > > with broader name scheme.But I think this is not a good wishlist.:) > > Personally I prefer to option 2 still. > > Thank you for looking into this, I wasn't expecting that! > > By a "toolchain issue", I meant an issue in debhelper or lintian (or > maybe in dh-ocaml or ocaml itself). This is definitely not an upstream > issue (of bisect-ppx), as all OCaml packages face it. > > One possible fix would be to change dh_strip, for example by telling it > to strip $FOO.a if $FOO.cmxa exists, if this is correct (I'm not sure: I > don't know why lib*.a are stripped in the first place). That would be > your option 4. Or fix lintian to not issue the warning for $FOO.a if > $FOO.cmxa exists. Right now, I don't know which option is correct. > > But this should not hinder bisect-ppx packaging, so I would go to option > 1 first, then investigate which of my two options is the correct one. Okay, I can do some experimental/feedback on these both tools here also. > > > For dh_dwz issue. It seems that the issue will be fixed by passing > > `--no-dwz-multifile` arg. In my understanding, there is two ELF > > binaries on the debug package, so the no-mutlifile arg can assure > > dropping `../.dwz/../.debug`. > > Again, I've seen this issue several times with OCaml packages, but I > didn't bother to investigate. It looks like another toolchain issue, > which should be fixed in a more central package, not in bisect-ppx > itself. So just leave the lintian warnings as is. It seems the issue should be fixed on lintian side as your analyst. But unfortunately, this is one lintian error that will lead to ftp-master auto-rejected if uploaded: ``` E: libbisect-ppx-ocaml-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml.debug] E: libbisect-ppx-ocaml-dev-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml-dev.debug] ``` I tried many attempts but failed. One common workaround is shipping one lintian-override via dh_lintian, like[0] and [1]. Although the error was gone, but we will get another error: ``` libbisect-ppx-ocaml-dev-dbgsym: non-debug-file-in-debug-package [usr/share/lintian/overrides/libbisect-ppx-ocaml-dev-dbgsym] ``` Passing `--no-dwz-multifile` to dh_dwz maybe has side effects on the debug package but it seems this is a workaround if we can upload to upstable.And I will open two separate reportbugs to track these issues once the package unloaded to unstable. Thanks again. BR, Bo [0]: https://www.mail-archive.com/pkg-kde-talk@alioth-lists.debian.net/msg00457.html [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820310#22 > > > Cheers, > > -- > Stéphane >
Bug#762336: Please enable hardened build flags
Since the original report and patch, the package have been orphaned, and the rules file changed in a way that make the tested patch no longer apply. I suspect something like the following untested patch might work. diff --git a/debian/rules b/debian/rules index 16aad6f..f55fc4c 100755 --- a/debian/rules +++ b/debian/rules @@ -6,6 +6,9 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk + configureoptions = --bindir=/usr/sbin/ --sysconfdir=/etc/bandwidthd/ --localstatedir=/var/lib/ p_bwdstatic = bandwidthd @@ -26,7 +29,7 @@ configure-bwdstatic-stamp: cp -f /usr/share/misc/config.sub config.sub dh_autoreconf chmod +x configure - INSTALL='install --strip-program=true' dh_auto_configure -- $(configureoptions) --disable-pgsql + $(shell dpkg-buildflags --export=cmdline) INSTALL='install --strip-program=true' dh_auto_configure -- $(configureoptions) --disable-pgsql touch $@ configure-bwdpgsql: configure-bwdpgsql-stamp I do not dare to apply it without testing. -- Happy hacking Petter Reinholdtsen
Bug#1069051: r-cran-spatstat.model: autopkgtest regression in testing
Source: r-cran-spatstat.model Version: 3.2-8-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Hi Maintainer Sometime around 2023-12-01, r-cran-spatstat.model's autopkgtest regressed in testing [1]. I've copied what I hope is the relevant part of the log below. Regards Graham [1] https://ci.debian.net/packages/r/r-cran-spatstat.model/testing/amd64/ 104s Error in check.nvector(weights, nX, vname = "weights") : 104s Some values of weights are NA or NaN 104s Calls: local ... diagnose.ppm.engine -> density.ppp -> pointweights -> check.nvector 104s In addition: Warning messages: 104s 1: Values of the covariate ‘cv’ were NA or undefined at 96% (1774 out of 1845) of the quadrature points. Occurred while executing: ppm.ppp(Q = Y, trend = ~cv + I(cv^2), data = list(list(c(1, 1.91953576453823, 104s 2: Some infinite, NA or NaN increments were removed 104s 3: Numerical underflow detected: sigma is probably too small 104s Execution halted
Bug#1069050: RFS: streamlink/6.7.3-1 -- CLI for extracting video streams from various websites to a video player
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "streamlink" for a new upstream version 6.7.3. * Package name: streamlink Version : 6.7.3-1 Upstream Author : Streamlink Team * URL : https://streamlink.github.io/ * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1 * Vcs : https://salsa.debian.org/amurzeau/streamlink/ Section : python It builds those binary packages: python3-streamlink - Python module for extracting video streams from various websites python3-streamlink-doc - CLI for extracting video streams from various websites (documentation) streamlink - CLI for extracting video streams from various websites to a video player To access further information about this package, please visit the following URL: https://mentors.debian.net/package/streamlink/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.3-1.dsc Changes since the last upload to unstable: streamlink (6.7.3-1) unstable; urgency=medium * tests: also run build_backend tests * d/source/options: ignore .devcontainer and .vscode * New upstream version 6.7.3 -- Alexis Murzeau Mon, 15 Apr 2024 15:49:45 +0200 Regards, -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F |
Bug#1069049: unison-2.53: Update to 2.53.4
Package: unison-2.53 Severity: normal Dear Maintainer, Please update to 2.53.4. https://github.com/bcpierce00/unison/releases The old homepage has been archived, so please change the homepage to GitHub. Best, Amr -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unison-2.53 depends on: ii libc6 2.37-15 Versions of packages unison-2.53 recommends: ii openssh-client [ssh-client] 1:9.6p1-4 unison-2.53 suggests no packages.
Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs
Hello, Santiago Vila, le lun. 15 avril 2024 13:08:30 +0200, a ecrit: > Can we also drop PATH from /etc/profile in non-Linux systems like hurd-i386? > (I'm Cc:ing Samuel for that). I tried to comment out the PATH definition from /etc/profile on the exodar porterbox, and it seems to be going fine? Samuel
Bug#1057204: RM: r-bioc-rhdf5filters [s390x] -- ROM; Build-Depends missing on s390x
Hi Andreas It looks like the issue with r-bioc-rhdf5filters was fxied in 1.14.1+dfsg-2. Is removal still required? Regards Graham
Bug#1069048: live-boot fails to DHCP on all NICs with link up
Package: live-boot
Version: 1:20230131
Severity: important
Tags: patch
Hi,
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. On each run, as soon as there
is one interface with link up, the script will exit, leaving no time
for other NICs to be up in any eventual subsequent run.
This only works if:
- one is lucky
- if only the interfaces with DHCP have an actual ethernet link.
For cases where there is more than one interface with the link up,
but only one is connected to a DHCPd server, it is possible that it
will fail (depending which card will have the link first).
The attached patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
We've tested this patch in production, with such a case where it
was failing (ie: our 25Gbits/s cards were detected first, but were not
connected to a DHCP server, while the 1Gbits/s cards that were supposed
to be holding the network boot were never tried by live-boot). And
this patch fixed things for us.
Please merge this patch if you feel like it's correct. I also would
like to have it fixed in Stable if possible (once I have the approval
from the team).
Cheers,
Thomas Goirand (zigo)
P.S: If one would like to test it, the easiest way is to build a
Debian live the normal way, then unpack the ramdisk with cpio with
something like this:
zstdcat | | cpio -idmv
Then recompress like this:
find . | cpio --create --format='newc' | zstd >
If running an older version of Debian, replacing zstdcat by zcat and
zstd by "gzip -9" also works.
>From 899aa9e8625570137fc57c4ed675bcb090119ace Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 15 Apr 2024 15:40:46 +0200
Subject: [PATCH] Do DHCP on multiple interfaces
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. If there is more than one
interface, but only one is found during a run, then it currently
gives-up searching for other interfaces and exits.
This works if one is lucky, or if only the interfaces with DHCP
have an actual ethernet link. For cases where there is more than
one interface with the link up, but only one is connected to a
DHCPd server, it is possible that it will fail (depending which
card will have the link first).
This patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
---
components/9990-select-eth-device.sh | 68
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/components/9990-select-eth-device.sh
b/components/9990-select-eth-device.sh
index b660a3d..719a234 100755
--- a/components/9990-select-eth-device.sh
+++ b/components/9990-select-eth-device.sh
@@ -93,46 +93,56 @@ Select_eth_device ()
fi
found_eth_dev=""
- while true
+ echo -n "Looking for a connected Ethernet interface."
+
+ for interface in $l_interfaces
do
- echo -n "Looking for a connected Ethernet interface ..."
+ # ATTR{carrier} is not set if this is not done
+ echo -n " $interface ?"
+ ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
+ sleep 1
+ done
+
+ echo ''
+ for step in 1 2 3 4 5
+ do
for interface in $l_interfaces
do
- # ATTR{carrier} is not set if this is not done
- echo -n " $interface ?"
- ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
- sleep 1
- done
-
- echo ''
+ # Skip the interface if it's already found.
+ IN_IT=no
+ for DEV in $found_eth_dev ; do
+ if [ "${DEV}" = "$interface" ] ; then
+ IN_IT=yes
+ fi
+ done
- for step in 1 2 3 4 5
- do
- for interface in $l_interfaces
- do
+ if [ "${IN_IT}" = "no" ] ; then
ip link set $interface up
carrier=$(cat /sys/class/net/$interface/carrier
\
2>/dev/null)
# link detected
-
- case "${carrier}" in
- 1)
- echo "Connected
Bug#1061519: shim: CVE-2023-40546 CVE-2023-40547 CVE-2023-40548 CVE-2023-40549 CVE-2023-40550 CVE-2023-40551
On Mon, Apr 15, 2024 at 11:33:14AM +, Bastien Roucariès wrote: >Source: shim >Followup-For: Bug #1061519 >Control: tags -1 + patch > >Dear Maintainer, > >Please find a MR here >https://salsa.debian.org/efi-team/shim/-/merge_requests/13 ACK. Thanks for trying to help, but the merge isn't the hard bit here. Tthe new upstream is a little problematic and I'm debugging some boot failures in my local CI already. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#1069047: librust-bindgen-dev: Thread 'main' panicked at 'called Result::unwrap() on an Err value
Package: librust-bindgen-dev
Version: 0.66.1-4
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: noisyc...@tutanota.com
Dear Maintainer,
While building the linux kernel with additional patches to enable support for
Apple Silicon, I came across a Rust panic due to the way bindgen v0.66
generates bindings. The error message I got was
> Thread 'main' panicked at 'called Result::unwrap() on an Err value:
> FromBytesWithNulError { kind: InteriorNul(x) }
(where x is an integer I did not take note of). After a bit of digging I found
out this is a known regression introduced in v0.66 and fixed in v0.68, having
to do with how bindgen deals with strings that have null bytes inside them.
More detail can be found at
https://github.com/rust-lang/rust-bindgen/issues/2566 (issue) and
https://github.com/rust-lang/rust-bindgen/pull/2567 (resolution). Would it be
possible to upload a version of bindgen v0.66 with the patch backported from
v0.68, or, as an alternative, to upgrade to the latter? I checked that the
original patch applies cleanly to v0.66 as present in the Debian archive, e.g.
by streamlining it and modifying the path of the patched file like in
attachment.
Thank you,
NoisyCoil
*** /home/noisycoil/bindgen.patch
--- a/codegen/mod.rs
+++ b/codegen/mod.rs
@@ -714,18 +714,18 @@ impl CodeGenerator for Var {
let len = proc_macro2::Literal::usize_unsuffixed(
cstr_bytes.len(),
);
-let cstr = CStr::from_bytes_with_nul(_bytes).unwrap();
// TODO: Here we ignore the type we just made up, probably
// we should refactor how the variable type and ty ID work.
let array_ty = quote! { [u8; #len] };
let cstr_ty = quote! { ::#prefix::ffi::CStr };
-let bytes = proc_macro2::Literal::byte_string(
-cstr.to_bytes_with_nul(),
-);
+let bytes = proc_macro2::Literal::byte_string(_bytes);
-if rust_features.const_cstr && options.generate_cstr {
+if options.generate_cstr &&
+rust_features.const_cstr &&
+CStr::from_bytes_with_nul(_bytes).is_ok()
+{
result.push(quote! {
#(#attrs)*
#[allow(unsafe_code)]
Bug#1069046: fgallery: Missing map.png image in the distributed package
Package: fgallery Version: 1.9.1+ds-1 Severity: normal X-Debbugs-Cc: kaplan+bugs.debian@kim-minh.com Dear Maintainer, I use fgallery with option -g (Respect GPS coordinates of images). I took some pictures with my smartphone with GPS coordinates embeded in the EXIF data. Then I created my photo gallery with the -g option. The gallery is generated and usable, but the picture of the button to access the OpenStreetMap site with the location where the picture was taken is broken. And the webserver logs show 404 errors trying to access a file called "map.png". I expect to have a somewhat nice picture for this button. Just dropping an picture named "map.png" in the gallery directory solves the issue. Thus I believe that when the Debian Add-geolocation-option.patch was applied, it forgot to add that file. Thank you for your work, Kim Minh. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages fgallery depends on: ii exiftran 2.10-4+b1 ii imagemagick 8:6.9.11.60+dfsg-1.6+deb12u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.6+deb12u1 ii libimage-exiftool-perl 12.57+dfsg-1 ii libjs-mootools 1.4.5~debian1-3 ii libjson-perl 4.1-1 ii p7zip-full 16.02+dfsg-8 ii zip 3.0-13 Versions of packages fgallery recommends: ii facedetect 0.1-3+b4 ii liblcms2-utils 2.14-2 Versions of packages fgallery suggests: ii jpegoptim 1.4.7-1 ii pngcrush 1.8.13-0.1 -- no debconf information
Bug#1069045: Support for propose-updates package archives
Package: live-build Version: 1:20230502 Severity: wishlist live-build currently supports: backports, security and updates package archives with config options: --backports --security --updates It would be useful to also have a `--propose-updates` config option to support adding the proposed-updates archive. https://wiki.debian.org/StableProposedUpdates
Bug#1068412: apache2: Missing Upgrade to Security Issues in bookworm
Package: apache2 Version: 2.4.57-2 Followup-For: Bug #1068412 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Security Updates in unstable are not propagated to stable * What exactly did you do (or not do) that was effective (or ineffective)?A Waited for the update to arrive in bookworm * What was the outcome of this action? Well it's not there after almost two weeks * What outcome did you expect instead? ... *** End of the template - remove these template lines *** Apparently there are build issues in sid (maybe due to t64 migration). However that is not a problem in bookworm and after. Please consider to work around the issues and have a fix for "normal users". Ubuntu has provided the update to 2.4.59 last week already. Thank you! Bets regards Peter PS: below is only one of my systems. arm64, amd64 and armhf all miss this update! -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-18-arm64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apache2 depends on: pn apache2-bin pn apache2-data pn apache2-utils ii init-system-helpers1.65.2 ii lsb-base 11.6 ii media-types10.0.0 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages apache2 recommends: ii ssl-cert 1.1.2 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser
Bug#973620: bash: overflow on integer variables greater than 9223372036854775807
On 4/15/24 7:59 AM, Gioele Barabucci wrote: Control: found -1 5.2.21-2 Control: tags -1 upstream X-Debbugs-CC: bug-b...@gnu.org On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote: Dear Maintainer, recently while I was running some tests, I ran into this strange overflow: $ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$i -> $n"; n+=1; done 0 -> 9223372036854775800 1 -> 9223372036854775801 2 -> 9223372036854775802 3 -> 9223372036854775803 4 -> 9223372036854775804 5 -> 9223372036854775805 6 -> 9223372036854775806 7 -> 9223372036854775807 8 -> -9223372036854775808 9 -> -9223372036854775807 10 -> -9223372036854775806 11 -> -9223372036854775805 12 -> -9223372036854775804 13 -> -9223372036854775803 14 -> -9223372036854775802 The integer handled by bash is obviously very large, but I believe that in the event of an overflow it would be better to reset the variable and issue an error flow warning, rather than remain silent. Hi. Thanks for the report. As documented, bash integer arithmetic doesn't check for overflow (it never has). Adding such checks is a low-priority item. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069037: less: new upstream version
Package: less Version: 590-2 Severity: wishlist Hey. Less 590 is quite outdated (from somewhere mid 2021)... would be nice to have the current version. There's been quite some changes meanwhile including improvements to follow mode. Cheers, Chris.
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
* Holger Levsen [2024-04-15 12:13]:
> I've got two remaining questions about libscout (and diffoscope)
>
> On Thu, Apr 11, 2024 at 01:48:18AM +0200, Fay Stegerman wrote:
> > unzip does seem to extract all the files, though it errors out. Not sure
> > what
> > diffoscope should do here. This is definitely a broken ZIP file. That bug
> > should probably be reported against libscout or whatever tooling it used to
> > create that JAR.
>
> you filed https://github.com/python/cpython/issues/117779
> (thanks again!), am I correct to assume that thus there's no need
> to file a seperate bug against libscout?
It's generating a broken ZIP file with duplicate entries. It really shouldn't
be doing that, regardless of whether we can extract the files nonetheless.
That's still a bug that should be reported and fixed.
> and 2nd,
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/libscout.html
> now as expected displays:
>
> './usr/share/java/libscout.jar' has 35 duplicate entries
> './usr/share/java/libscout.jar' has 35 duplicate entries
>
> (which is nice, though maybe could only been shown once?)
Ah. It correctly shows that twice as there could be differences between the two
files being compared wrt whether they have duplicate entries (and if so how
many).
And if you run 'diffoscope foo.zip bar.zip' it'll show those two different file
names. But in this case we have nested archives and the path (and in this case
also the number of duplicate entries) is identical for both, so maybe we can
tweak the output to show which top-level file it belongs to?
> but
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/arm64/diffoscope-results/libscout.html
> shows this:
>
> Command `'zipdetails --redact --scan --utc {}'` failed with exit code 255.
> Standard output:
[...]
> though this later is done using diffoscope from unstable while the
> rest of the userland is bullseye, so this might be expected as well?
Ah. Looks like zipdetails(1) on bullseye doesn't support the --redact, --scan,
and --utc options yet.
- Fay
Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases
Hi Peter, On Mon, Apr 15, 2024 at 02:28:18PM +0200, Petter Reinholdtsen wrote: > Dear package maintainer of git-buildpackage, > > Do you have an idea when you will find time to look at this patch? Sorry, I assumed that it was meant to show the intended result not as an actual patch proposal (as it doesn't use any of the methods provided by gbp but shells out via popen). (It *is* helpful to demo the desired outcome, thanks Gioele). So is the intended flow to - import the new upstream version - fake merge that into the packaging branch (using the "replace" mode to avoid any conflicts (e.g. if the upstream source contain a debian/ dir) - apply the new debian/ on or debian diff on top? If so a patch that reuses the corresponding bits from import-orig (plus adjusting the test to verify it) would be very welcome. Cheers, -- Guido > [Gioele Barabucci 2024-08-19] > > The attached new patch, although still "quick and dirty", improves the > > handing of possible modification+deletion conflicts that may arise while > > merging the the upstream branch into the Debian branch. > > -- > Happy hacking > Petter Reinholdtsen >
Bug#1069036: mp3diags: Update to 1.5.03
Package: mp3diags Version: 1.5.01-2+b1 Severity: normal Dear Maintainer, If you deem appropriate, please update mp3diags to 1.5.03. https://github.com/mciobanu/mp3diags Best, Amr -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mp3diags depends on: ii libboost-program-options1.83.0 1.83.0-2+b2 ii libboost-serialization1.83.01.83.0-2+b2 ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libqt5core5a5.15.10+dfsg-7 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5svg5 5.15.10-2+b1 ii libqt5widgets5 5.15.10+dfsg-7 ii libqt5xml5 5.15.10+dfsg-7 ii libstdc++6 14-20240201-3 mp3diags recommends no packages. mp3diags suggests no packages. -- no debconf information
Bug#1069035: ITP: objconv -- object file converter
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: objconv Version : 2.54+ds Upstream Authors: Agner Fog URL : object file converter * License : GPL-3.0-or-later Description : object file converter This utility can be used for converting object files between COFF/PE, OMF, ELF and Mach-O formats for all 32-bit and 64-bit x86 platforms. Can modify symbol names in object files. Can build, modify and convert function libraries across platforms. Can dump object files and executable files. Also includes a very good disassembler supporting the SSE4, AVX, AVX2, AVX512, FMA3, FMA4, XOP and Knights Corner instruction set.
Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs
Hey. I mostly forgot the details of this issue ^^ On Mon, 2024-04-15 at 13:08 +0200, Santiago Vila wrote: > I'd like to be sure that things will not break horribly > for somebody. What I can say at least (which is of course not a definite answer) is, that I personally run my systems since quite some years now without touching PATH in any of .profile, .bashrc, /etc/profile, /etc/bash.bashrc. Some people want to add e.g. ~/bin to their PATH, but I think the default profile didn't do that out of the box, or did it? I personally found that (adding ~/bin/ anyway) rather unclean, as it will get inherited by all programs started by my session, but what most of the time I actually want is some additional commands or overrides for just my interactive sessions. So instead of ever adding ~/bin to the PATH, I do set up any executable in there as an alias (which won't get exported to other shells). Cheers, Chris.
Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases
Dear package maintainer of git-buildpackage, Do you have an idea when you will find time to look at this patch? [Gioele Barabucci 2024-08-19] > The attached new patch, although still "quick and dirty", improves the > handing of possible modification+deletion conflicts that may arise while > merging the the upstream branch into the Debian branch. -- Happy hacking Petter Reinholdtsen
Bug#833319: base-files: Please package debian-swirl icon
reassign 833319 adwaita-icon-theme thanks I don't think this is appropriate for base-files. Reassigning back. Please find another package (not base-files) for that. Thanks.
Bug#1069034: openfst FTCBFS: multiple reasons
Source: openfst Version: 1.7.9-5 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs openfst fails to cross build from source for two reasons. One is that it has an unskippable AC_RUN_IFELSE check. Reading configure.ac reveals that this is a safety check that is also being done in the test suite. We have no chance of running this test in a cross build so the only option is to skip it in cross builds. The other is that debian/rules passes sse flags whenever building on x86, but it should only pass the flags when building for x86. I'm attaching a patch to fix both for your convenience. Helmut diff --minimal -Nru openfst-1.7.9/debian/changelog openfst-1.7.9/debian/changelog --- openfst-1.7.9/debian/changelog 2022-08-16 16:58:50.0 +0200 +++ openfst-1.7.9/debian/changelog 2024-04-15 13:06:02.0 +0200 @@ -1,3 +1,12 @@ +openfst (1.7.9-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ cross.patch: Allow skipping equality reflexivity test. ++ debian/rules: Fix build vs host confusion. + + -- Helmut Grohne Mon, 15 Apr 2024 13:06:02 +0200 + openfst (1.7.9-5) unstable; urgency=low * debian/rules: Set --max-parallel=2 in override_dh_auto_test to avoid diff --minimal -Nru openfst-1.7.9/debian/patches/cross.patch openfst-1.7.9/debian/patches/cross.patch --- openfst-1.7.9/debian/patches/cross.patch1970-01-01 01:00:00.0 +0100 +++ openfst-1.7.9/debian/patches/cross.patch2024-04-15 13:06:01.0 +0200 @@ -0,0 +1,12 @@ +--- openfst-1.7.9.orig/configure.ac openfst-1.7.9/configure.ac +@@ -180,7 +180,8 @@ + [AC_MSG_FAILURE(m4_normalize([ +Test float equality failed! +Compile with -msse -mfpmath=sse if using g++. +- ]))]) ++ ]))], ++ [echo "Skipping float equality test for cross compilation"]) + + AC_CHECK_LIB([dl], dlopen, [DL_LIBS=-ldl]) + AC_SUBST([DL_LIBS]) diff --minimal -Nru openfst-1.7.9/debian/patches/series openfst-1.7.9/debian/patches/series --- openfst-1.7.9/debian/patches/series 2022-08-16 16:58:50.0 +0200 +++ openfst-1.7.9/debian/patches/series 2024-04-15 13:05:31.0 +0200 @@ -1,3 +1,4 @@ openfst-atomic.diff openfst-cxx17.diff #openfst-sse.diff # Only applied on non-x86 archs +cross.patch diff --minimal -Nru openfst-1.7.9/debian/rules openfst-1.7.9/debian/rules --- openfst-1.7.9/debian/rules 2022-08-16 16:58:50.0 +0200 +++ openfst-1.7.9/debian/rules 2024-04-15 13:06:02.0 +0200 @@ -13,9 +13,9 @@ dh $@ override_dh_autoreconf: -ifeq ($(DEB_BUILD_ARCH),i386) +ifeq ($(DEB_HOST_ARCH),i386) patch -p1 < debian/patches/openfst-sse.diff -else ifeq ($(DEB_BUILD_ARCH),amd64) +else ifeq ($(DEB_HOST_ARCH),amd64) patch -p1 < debian/patches/openfst-sse.diff endif dh_autoreconf
Bug#973620: bash: overflow on integer variables greater than 9223372036854775807
Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org
On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote:
Dear Maintainer,
recently while I was running some tests, I ran into this strange overflow:
$ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$i -> $n";
n+=1; done
0 -> 9223372036854775800
1 -> 9223372036854775801
2 -> 9223372036854775802
3 -> 9223372036854775803
4 -> 9223372036854775804
5 -> 9223372036854775805
6 -> 9223372036854775806
7 -> 9223372036854775807
8 -> -9223372036854775808
9 -> -9223372036854775807
10 -> -9223372036854775806
11 -> -9223372036854775805
12 -> -9223372036854775804
13 -> -9223372036854775803
14 -> -9223372036854775802
The integer handled by bash is obviously very large, but I believe
that in the event of an overflow it would be better to reset the
variable and issue an error flow warning, rather than remain silent.
Bash 5.2.21 is affected by this issue:
$ declare -i n=$((2**63 - 2))
$ for i in {1..4}; do echo "$i -> $n"; n+=1; done
1 -> 9223372036854775806
2 -> 9223372036854775807
3 -> -9223372036854775808
4 -> -9223372036854775807
$ declare -i n=36893488147419103234; echo $?
0
$ echo $n
2
Would it be possible to detect this overflow (or non-representable
numbers, like in the second case) and warn about it?
Regards,
--
Gioele Barabucci
Bug#1055583: base-files: EFI System Partition should mount on /efi not /boot/efi
reassign 1055583 debian-installer thanks Dear debian-installer people: In this bug report, I'm asked to provide /efi as a mount point for the EFI partition. Given that base-files does not even contain /boot/efi (the supposedly "old" location), I believe this is a decision for you to make, hence the reassign. [ I would be open to include /efi in base-files, but only if you consider necessary ]. Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
btw: /var/local is still :staff owned ... while /usr/local is no longer. Is that on purpose? Historical reasons. There was also a time in which, by default, /usr/local was also root:staff and writeable by staff. The /var/local thing is already reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039973 Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
It would be nice if it could be considered to add/create: /etc/local /usr/local/libexec Thanks for the report. I'll add /usr/local/libexec as the outcome for this bug report. According to what I read, it should exist because /usr/libexec also exists. /etc/local is even kinda indirectly standardised by FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html "/usr/local/etc may be a symbolic link to /etc/local." I don't think that's a mandate to provide /etc/local, because /etc/local is missing in the chapter about /etc. I see it just as a way to allow /usr/local/etc to exist as a directory or as a symlink, at your choice. Since we do not provide /etc/local, it should be ok for /usr/local/etc to remain as a directory. Thanks.
Bug#1069033: pipewire: Update to 1.0.5
Source: pipewire Version: 1.0.5-1 Severity: wishlist Please update pipewire to 1.0.5. Could you also mark the new release as fixing LP: #2061381 ? https://launchpad.net/bugs/2061381 The new pipewire release improves how well the gnome-snapshot webcam app works for me. (Still buggy, but it's an improvement!) Let me know if you need help with this update. Thank you, Jeremy Bícha
Bug#1061519: shim: CVE-2023-40546 CVE-2023-40547 CVE-2023-40548 CVE-2023-40549 CVE-2023-40550 CVE-2023-40551
Source: shim Followup-For: Bug #1061519 Control: tags -1 + patch Dear Maintainer, Please find a MR here https://salsa.debian.org/efi-team/shim/-/merge_requests/13 Bastien signature.asc Description: This is a digitally signed message part.
Bug#961679: base-files: please include window title in /etc/issue
El 27/5/20 a las 22:43, Adam Borowski escribió: Package: base-files Version: 11 Severity: wishlist Tags: patch Hi! It would be good if /etc/issue set the window title appropriately. While it might sound wrong (as /etc/issue is used only for local terminals), serial consoles do count as local. Thus, the output may hit either a real console which since Linux 3.16 ignores these sequences, or a terminal emulator. Hello. I don't see this very useful because normally when you have a serial console you have only one of it (so there is usually no need to differentiate between them). Simple question: I don't have a serial console myself. Is this a change for which the effects can be seen when using virtual machines in the cloud? (Let's say, Hetzner, GCP, Linode, Digital Ocean, etc). Thanks.
Bug#931197: base-files: Include minor version in /etc/os-release
severity 931197 normal thanks I consider this to be a normal bug, and will try to discuss with Release Managers to see if we can change it for trixie. Thanks.
