Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf
Package: dhcpcd-base Version: 1:10.0.5-2 Severity: normal Hello and thanks for maintaining this package in Debian! I am giving it a try (inside a virtual machine), as a drop-in replacement for isc-dhcp-client (with the ifupdown package). It seems to work pretty well, just like isc-dhcp-client, but I noticed an issue in a network where the DHCP server sends two domains as "search domains" (let's call them MYDOMAIN and OTHERDOMAIN). When I use dhcpcd-base as a DHCP client, I get the following resolv.conf file: $ cat /etc/resolv.conf # Generated by dhcpcd from enp0s3.dhcp # /etc/resolv.conf.head can replace this line domain MYDOMAIN nameserver 192.168.0.1 # /etc/resolv.conf.tail can replace this line This lacks the two search domains I was expecting. To be honest, the isc-dhcp-client Debian package behaves similarly (somehow failing to write OTHERDOMAIN as second search domain). But Rocky Linux clients (on the same network, with the ISC DHCP client and ifup/ifdown mechanism) correctly set the resolv.conf with the two search domains: $ cat /etc/resolv.conf ; generated by /usr/sbin/dhclient-script search MYDOMAIN. OTHERDOMAIN. nameserver 192.168.0.1 Even Windows clients (on the same network) correctly obtain the two search domains... Why cannot I have the two search domains on Debian? What's wrong? What did I fail to understand? Shouldn't this work out of the box? Please let me know, thanks for your time. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; 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 dhcpcd-base depends on: ii adduser 3.137 ii libc6 2.37-12 ii libssl3 3.0.11-1 ii libudev1 254.5-1 dhcpcd-base recommends no packages. Versions of packages dhcpcd-base suggests: pn resolvconf | openresolv | systemd-resolved -- no debconf information
Bug#1056566: firmware-iwlwifi: firmware doesn't load for intel Alder Lake-S PCH CNVi WiFi [8086:7af0]
Package: firmware-iwlwifi Version: 20230210-5 Severity: important Dear Maintainer, I am a bit new to debian and I am not that much of a technical person. So pardon me if I am reporting this to wrong place. * What led up to the situation? My wifi on motherboard is "Intel Corporation Alder Lake-S PCH CNVi WiFi [8086:7af0]" according to lspci. Wifi was working on new debian bookworm 12 stable install but after some updates to the system, my wifi stopped showing up. dmesg is showing "iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, REV=0x430 thermal thermal_zone1: failed to read out thermal zone (-61)" * What exactly did you do (or not do) that was effective (or ineffective)? I tried the debian kde live iso to check if this is a hardware issue and wifi is detected and working in the live environment. I tried to load newer firmware files from linux git snapshot but that did not work. I also tried older kerner to match the live iso but that too did not work. * What was the outcome of this action? Wifi is still not working * What outcome did you expect instead? Wifi to wrok like it worked after new install Please let me know if you need any more details or outputs of any commands etc. Thank you -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1056308: transition: wireshark
Control: tags -1 confirmed On 2023-11-20 11:37:49 +0100, Bálint Réczey wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I'd like to update wireshark in unstable. The only reverse dependency to be > rebuilt is libvirt [1]. Please go ahead. Cheers > > Libvirt fails to rebuild for me locally on an Ubuntu system in an unstable > schroot environment with and without wireshark with the same test error: > > ... > --- stderr > --- > TEST: virnetsockettest > Cannot identify IPv4/6 availability > ... > Summary of Failures: > > 124/173 libvirt:bin / virnetsockettestFAIL > 0.05s exit status 1 > > Ok: 171 > Expected Fail: 0 > Fail: 1 > Unexpected Pass:0 > Skipped:1 > Timeout:0 > ... > > I believe libvirt will build fine with the updated wireshark package on the > buildds. > > Thank you, > Balint > > [1] https://release.debian.org/transitions/html/auto-wireshark.html -- Sebastian Ramacher
Bug#1056568: qbittorrent: Incorrect versioned dependency on libtorrent-rasterbar-dev in debian/control
Source: qbittorrent Version: 4.6.1-1 Severity: minor X-Debbugs-Cc: bzanett...@gmail.com Dear Maintainer, according to upstream the correct libtorrent-rasterbar-dev version required to build the current qbittorrent should be either >=1.2.19 (for the 1.2.x series) or >=2.0.9 (for the 2.0.x series) while the version listed in debian/control is still 2.0.4. This is not an issue in unstable/testing which already has 2.0.9, but it prevents the build of a possible no-changes backport package for stable-backports, provided that libtorrent-rasterbar is backported too. It would be nice to see this simple fix in the next version, thanks. Regards Bruno Zanetti
Bug#1056567: ITP: r-cran-patrick -- GNU R parameterized unit testing
Package: wnpp Severity: wishlist Subject: ITP: r-cran-patrick -- GNU R parameterized unit testing Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-patrick Version : 0.2.0 Upstream Author : Michael Quinn * URL : https://cran.r-project.org/package=patrick * License : Apache-2.0 Programming Lang: GNU R Description : GNU R parameterized unit testing This is an extension of the 'testthat' package that lets you add parameters to your unit tests. Parameterized unit tests are often easier to read and more reliable, since they follow the DNRY (do not repeat yourself) rule. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-patrick
Bug#1055857: transition: opm-common
Control: tags -1 moreinfo On 2023-11-12 21:42:20 +0100, Markus Blatt wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-scie...@lists.debian.org > > Dear Debian release team, > > A new upstream release of OPM is available. To ease migration to testing I am > requesting a mini-transition. Uploading to unstable would probably work even > without a transition, but I would like to play it safe. > > This should only affect the OPM source packages opm-common, opm-grid, opm- > models, opm-simulators and opm-upscaling. > > I have already uploaded new versions to experimental that seemed to have built > without any issues, see [1]. > (please explain about the transition: impacted packages, reason, ... > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > Ben file: > > title = "libopm-common-2023"; > is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- > common-2023.10"; > is_good = .depends ~ "libopm-common-2023.10"; > is_bad = .depends ~ "libopm-common-2023.04"; libopm-common has a Provides: libopm-common-X, but the shared library included in libopm-common also has a SONAME of libopm-common.X. Why is the packaging not following the common practice of matching the package name with the SONAME? Cheers -- Sebastian Ramacher
Bug#1034159: Kernel support for more ChromeOS devices
Hi, I'd hope "during a mini-DebCamp at ARM" is the perfect time to poke you about kernel support for more ARM platforms? On 2023-10-15 16:30 +03:00, Alper Nebi Yasak wrote: > I'll also look into configs needed for ARM Chromebooks in more detail, > but that'll take more time because more things were already-enabled on > the x86 side compared to the ARM side. I've got things mostly working on some MediaTek Chromebooks and filed some merge requests for linux and initramfs-tools, more details at [3]. Please take a look. I have also written up a "dts2config" script inspired by another script Diederik used to analyze RK3588 platforms' dts files for related config options. The script and short / long results for all dts files are available at [3] attached to a comment. I hope they will be useful in enabling support for more hardware. With that, I generated some short lists of config options per SoC, based on device-tree "compatible" strings in ChromeOS boards' dts' for that SoC. Attaching those as a tarball here. It would be nice if you enabled those that aren't enabled yet, but I don't expect that will happen before I can get those tested on actual hardware... [3] [arm64] Enable configs for MediaTek MT8173 and MT8183 Chromebooks https://salsa.debian.org/kernel-team/linux/-/merge_requests/906 P.S.: I'd also appreciate you looking at my x86 ChromeOS configs MR: https://salsa.debian.org/kernel-team/linux/-/merge_requests/768 cros-configs-per-soc.tar.xz Description: application/xz
Bug#1056549: grantlee5: Is there intention to port the lib to Qt6 ?
On Wednesday, November 22, 2023 3:49:57 PM CET Filippo Rusconi wrote: > There appears to be an effort upstream to port Grantlee to Qt6. Is there any > intention downstream to actually create binary packages for Qt6 ? Grantlee has been ported to Qt6 and renamed to KTextTemplate https:// invent.kde.org/frameworks/ktexttemplate and will be released in february together with the rest of KDE's frameworks based on Qt6 (and plasma and ...) /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#1056569: libbrotli-dev: libbrotlidec.a corrupted due to c-p error in 0001-build-static-libraries-by-default.patch
Package: libbrotli-dev
Version: 1.1.0-1
Severity: normal
Dear Maintainer,
libbrotlidec.a is unusable in brotli 1.1.0-1 since it is identical to
libbrotlicommon.a
This happened because patch 0001-build-static-libraries-by-default.patch seems
to contain
a copy paste error:
+add_library(brotlicommon-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlidec-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlienc-static STATIC ${BROTLI_ENC_SOURCES})
I rebuild the package with the line of brotlidec-static changed to
BROTLI_DEC_SOURCES
and the library is usable again.
I caught the problem because I tried to link libfreetype statically
which required libbrotlidec.a
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 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 libbrotli-dev depends on:
ii libbrotli1 1.1.0-1
libbrotli-dev recommends no packages.
libbrotli-dev suggests no packages.
-- no debconf information
Bug#1054729: errbot: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Dear Maintainer, After moving conftest.py from package root to tests/ (as upstream did), your package builds fine in a sid chroot environment and all tests pass as well. Kind Regards
Bug#1056384: nvidia-driver: X server shuts down and doesn't return during upgrade.
Package: nvidia-suspend-common Version: 525.147.05-2 The second night in a row that unattended-upgrades hosed my system: screens blank and fan spinning madly. Recovery was possible only with SysReq reisub, and that still left the filesystem in a somewhat unclean state. Relevant logs: 2023-11-23T06:28:55.259601+01:00 dylan systemd[1]: Starting nvidia-hibernate.service - NVIDIA system hibernate actions... 2023-11-23T06:28:55.261933+01:00 dylan hibernate: nvidia-hibernate.service 2023-11-23T06:28:55.262045+01:00 dylan logger[623712]: <13>Nov 23 06:28:55 hibernate: nvidia-hibernate.service 2023-11-23T06:28:55.262720+01:00 dylan systemd[1]: Starting nvidia-resume.service - NVIDIA system resume actions... 2023-11-23T06:28:55.269538+01:00 dylan systemd[1]: Starting nvidia-suspend.service - NVIDIA system suspend actions... 2023-11-23T06:28:55.273485+01:00 dylan suspend: nvidia-resume.service 2023-11-23T06:28:55.273622+01:00 dylan logger[623716]: <13>Nov 23 06:28:55 suspend: nvidia-resume.service 2023-11-23T06:28:55.279771+01:00 dylan suspend: nvidia-suspend.service 2023-11-23T06:28:55.279892+01:00 dylan logger[623719]: <13>Nov 23 06:28:55 suspend: nvidia-suspend.service 2023-11-23T06:28:55.292176+01:00 dylan systemd[1]: nvidia-resume.service: Deactivated successfully. 2023-11-23T06:28:55.292460+01:00 dylan systemd[1]: Finished nvidia-resume.service - NVIDIA system resume actions. 2023-11-23T06:28:56.523975+01:00 dylan nvidia-sleep.sh[623726]: /usr/bin/nvidia-sleep.sh: line 20: echo: write error: Input/output error 2023-11-23T06:28:56.524518+01:00 dylan systemd[1]: nvidia-suspend.service: Main process exited, code=exited, status=1/FAILURE 2023-11-23T06:28:56.524629+01:00 dylan systemd[1]: nvidia-suspend.service: Failed with result 'exit-code'. 2023-11-23T06:28:56.524962+01:00 dylan systemd[1]: Failed to start nvidia-suspend.service - NVIDIA system suspend actions. 2023-11-23T06:28:56.526194+01:00 dylan systemd[1]: nvidia-hibernate.service: Deactivated successfully. 2023-11-23T06:28:56.526436+01:00 dylan systemd[1]: Finished nvidia-hibernate.service - NVIDIA system hibernate actions. << /etc/modprobe.d/nvidia-options.conf >> #options nvidia-current NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 # To grant performance counter access to unprivileged users, uncomment the following line: #options nvidia-current NVreg_RestrictProfilingToAdminUsers=0 # Uncomment to enable this power management feature: #options nvidia-current NVreg_PreserveVideoMemoryAllocations=1 # Uncomment to enable this power management feature: #options nvidia-current NVreg_EnableS0ixPowerManagement=1 ^^ /etc/modprobe.d/nvidia-options.conf ^^ mfg -- Marcello Perathoner marce...@perathoner.de
Bug#1056563: kodi: arm platforms should use gles APP_RENDER_SYSTEM
Dear Jianfeng, I am aware about your patch and appreciate the efforts you put in it. However, I want to be sure all armel / armhf / aarch64 devices will benefit from this change. I raised this question with the team here: https://github.com/xbmc/xbmc/pull/18534 Can you please participate in discussion so I understand how to solve the drmprime issue properly? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#1056570: openjdk-8: Please drop sparc64 from hotspot_archs for the time being
Source: openjdk-8 Version: 8u392-ga-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! The native code generator in openjdk-8 currently segfaults on sparc64 and prevents a successful build. Removing sparc64 from "hotspot_archs" in debian/rules restricts the build to Zero builds which fixes the build. Thus, please disable the native build on sparc64 for the time being until we have sorted out the regression. FWIW, I assume there was some change in the Hotspot code on sparc64 that was most likely implemented for the Solaris port only since the native Linux sparc64 port has been unmaintained in OpenJDK for quite some time. This has happened in the past before. I will try to bisect the problem later and report it upstream. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1050236: FTBFS: 30 - testlpe fails
Hi. Two notes: 1) This doesn't just fail on rscv64 but also on amd64 and i386 with the same error as in the linked build log from the original report: [...] [ RUN ] LPETest.MeasureSegments_multi_px_1_0_2 add_actions_edit_document: no app! add_actions_pages: no app! add_actions_undo: no app! ./testfiles/lpespaths-test.h:96: Failure The difference between pointc[Geom::X] and pointd[Geom::X] is 1.40444821, which exceeds precission, where pointc[Geom::X] evaluates to 297.9448959997, pointd[Geom::X] evaluates to 299.3493439997, and precission evaluates to 1.3999. ./testfiles/lpespaths-test.h:97: Failure The difference between pointc[Geom::Y] and pointd[Geom::Y] is 1.53307541, which exceeds precission, where pointc[Geom::Y] evaluates to 295.8470760002, pointd[Geom::Y] evaluates to 297.3801520001, and precission evaluates to 1.3999. ./testfiles/lpespaths-test.h:96: Failure [...] [ FAILED ] LPETest.MeasureSegments_multi_px_1_0_2 [ FAILED ] LPETest.MeasureSegments_multi_mm_1_0_2 2) If I'm not mistaken, that means that the "forwarded" tag is wrong here (or at least the linked issue is: This is not segfaulting (like the "forwarded" bug) but erroring out on imprecise measurements. If I recall correctly, there is a separate issue on github about this, somehow related to font rendering(?). However, I can't seem to find it anymore. Kind regards, Sven
Bug#1056549: grantlee5: Is there intention to port the lib to Qt6 ?
Greetings, Sune Thank you for your response, On Thu, Nov 23, 2023 at 09:22:21AM +0100, Sune Stolborg Vuorela wrote: On Wednesday, November 22, 2023 3:49:57 PM CET Filippo Rusconi wrote: There appears to be an effort upstream to port Grantlee to Qt6. Is there any intention downstream to actually create binary packages for Qt6 ? Grantlee has been ported to Qt6 and renamed to KTextTemplate https:// invent.kde.org/frameworks/ktexttemplate and will be released in february together with the rest of KDE's frameworks based on Qt6 (and plasma and ...) I see. What we use to do is create packages for Debian but also for MS Windows (our users are biologists and often are not fluent in GNU/Linux...). Looking at the CMakeLists.txt file in the repos, it looks like the Grantlee code in there will depend on KDE, or not ? include(KDEInstallDirs) include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE) include(KDECMakeSettings) include(KDEGitCommitHooks) ~~~ I thus wonder if this port is going to actually solve our portability-related requirements. Any thoughts ? Sincerely, Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Researcher at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org
Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators
On Thu, 23 Nov 2023 at 05:45, Otto Kekäläinen wrote: > > Hi! > > One more clarifying question: > > > > Thus a third thing the README could advise on is how Debian Developers and > > > Debian sysadmins are advised to build CI systems and test upgrade paths > > > for > > > the next 10 years as what worked in the past 10 years does not apply as-is > > > anymore. > > People using CI systems will get an updated debootstrap in the next > > point release and everything will be fine. > > Do you refer above to the next Bookworm point update (scheduled on Dec > 9th according to https://release.debian.org/) or do you mean in > general that all CI upgrades tests will start working after the next > point release of both Bookworm and Bullseye and Buster? > > I am currently struggling to grasp how I should get for example > MariaDB 10.5 / Buster to MariaDB 10.11 / Bookworm testing running > again as usrmerge 38 removed the workaround the CI was relying on. > Example of current CI run: > https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/4945062. > Are you saying that a point release of Buster is going to do something > that CI systems can continue to operate? Just create the chroot for the CI with --merged-usr and all will be fine. Debootstrap in Buster is not going to be updated to do it automatically, only in Bookworm/Bullseye.
Bug#1056549: grantlee5: Is there intention to port the lib to Qt6 ?
On Thursday, November 23, 2023 10:52:56 AM CET Filippo Rusconi wrote: > include(KDEInstallDirs) > include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE) > include(KDECMakeSettings) > include(KDEGitCommitHooks) KDEInstallDirs is basicalyl just GNUInstallDirs slightly improved and extended KDEFrameworkCompilerSettings is just shared setup of c++ standards and default warnings KDECMakeSettings is setting a series of cmake policies and such KDECommitHooks is just setting up git to commit reject certain changes All of these are are part of extra-cmake-modules and is in general well tested for cross platform functionality and it makes writing modern c++ and cmake code simpler and easier. In general, other than an extra line in your build scripts, shouldn't make much of a difference. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#1056571: pelican: please make the build reproducible
Source: pelican
Version: 4.9.1+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
pelican could not be built reproducibly:
├── ./usr/share/doc/pelican/html/content.html
│ @@ -903,15 +903,15 @@
│
│
│
│
│
│
│
│ -Copyright © 2010–2023, https://justinmayer.com";>Justin Mayer, Alexis Metaireau, and
contributors
│ +Copyright © 2010–2024, https://justinmayer.com";>Justin Mayer, Alexis Metaireau, and
contributors
A patch is attached that seeds this date from the SOURCE_DATE_EPOCH
environment variable.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-11-23 10:30:16.704226475
+
@@ -0,0 +1,22 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-23
+
+--- pelican-4.9.1+dfsg.orig/docs/conf.py
pelican-4.9.1+dfsg/docs/conf.py
+@@ -1,5 +1,6 @@
+ import datetime
+ import os
++import time
+ import sys
+
+ if sys.version_info >= (3, 11):
+@@ -28,7 +29,7 @@ extensions = [
+ source_suffix = ".rst"
+ master_doc = "index"
+ project = project_data.get("name").upper()
+-year = datetime.datetime.now().date().year
++year =
datetime.datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH',
time.time(.year
+ copyright = f"2010\u2013{year}"
+ exclude_patterns = ["_build"]
+ release = project_data.get("version")
--- a/debian/patches/series 2023-11-23 10:05:08.543720337 +
--- b/debian/patches/series 2023-11-23 10:17:42.964110770 +
@@ -1,2 +1,3 @@
default_theme.patch
drop-notmyidea-builtin-themes.patch
+reproducible-build.patch
Bug#1052028: pydantic: please update to pydantic 2.x
ITP for (part of) new pydantic: https://bugs.debian.org/1052619 Request for package update: https://bugs.debian.org/1052028
Bug#1056572: maildir-utils: please make the build reproducible
Source: maildir-utils
Version: 1.10.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
maildir-utils could not be built reproducibly:
├── ./usr/share/man/man1/mu-add.1.gz
│ ├── mu-add.1
│ │ @@ -85,15 +85,15 @@
│ │ Dirk-Jan C. Binnema
│ │
│ │ .SH "COPYRIGHT"
│ │ .PP
│ │ This manpage is part of \fBmu\fP 1.10.8.
│ │
│ │ .PP
│ │ -Copyright © 2022-2024 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL version
3
│ │ +Copyright © 2022-2023 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL version
3
│ │ or later \fIhttps://gnu.org/licenses/gpl.html\fP. This is free software:
you are
A patch is attached that seeds this value from the SOURCE_DATE_EPOCH
environment variable.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-11-23 10:29:51.399821031
+
@@ -0,0 +1,21 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-23
+
+--- maildir-utils-1.10.8.orig/man/meson.build
maildir-utils-1.10.8/man/meson.build
+@@ -66,7 +66,13 @@ man_orgs=[
+
+ env = environment()
+ env.set('LANG', 'C')
+-yearmonth = run_command('date', '+%B %Y', check:true, capture:true, env: env)
++cmd = run_command('sh', '-c', 'echo $SOURCE_DATE_EPOCH')
++# https://reproducible-builds.org/docs/source-date-epoch/#meson
++source_date_epoch = cmd.stdout().strip()
++if source_date_epoch == ''
++ source_date_epoch = run_command('date', '+%s').stdout().strip()
++endif
++yearmonth = run_command('date', '-u', '-d', '@' + source_date_epoch, '+%B
%Y', check:true, capture:true, env: env)
+ ym=yearmonth.stdout().strip()
+
+ foreach src : man_orgs
--- a/debian/patches/series 2023-11-23 10:05:00.063724061 +
--- b/debian/patches/series 2023-11-23 10:29:50.287802884 +
@@ -5,3 +5,4 @@
more-man-page-fixes.patch
typo-fixes.patch
remove-mu4e-builddir.patch
+reproducible-build.patch
Bug#1056573: openmrac-data: please make the build reproducible
Source: openmrac-data Version: 1.1-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: umask X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that openmrac-data could not be built reproducibly due to the umask varying within the openmrac.dat tar archive: ├── ./usr/share/openmrac/openmrac.dat │ ├── file list │ │ @@ -1,256 +1,256 @@ │ │ --rw-r--r-- 0 root (0) root (0)74614 1970-01-01 00:00:00.00 asphalt.jpg │ │ --rw-r--r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 asphalt.jpg.3mt │ │ --rw-r--r-- 0 root (0) root (0) 789 1970-01-01 00:00:00.00 barrier.3dm │ │ --rw-r--r-- 0 root (0) root (0) 5357 1970-01-01 00:00:00.00 barrier.png │ │ --rw-r--r-- 0 root (0) root (0) 137 1970-01-01 00:00:00.00 barrier.png.3mt │ │ --rw-r--r-- 0 root (0) root (0) 1365 1970-01-01 00:00:00.00 barriera.png │ │ --rw-r--r-- 0 root (0) root (0) 127 1970-01-01 00:00:00.00 barriera.png.3mt │ │ --rw-r--r-- 0 root (0) root (0)26908 1970-01-01 00:00:00.00 barrierd.png │ │ --rw-r--r-- 0 root (0) root (0)20025 1970-01-01 00:00:00.00 betonova_zed.jpg │ │ --rw-r--r-- 0 root (0) root (0) 142 1970-01-01 00:00:00.00 betonova_zed.jpg.3mt │ │ --rw-r--r-- 0 root (0) root (0) 129 1970-01-01 00:00:00.00 black.png.3mt │ │ --rw-r--r-- 0 root (0) root (0)23570 1970-01-01 00:00:00.00 bricks01.jpg │ │ --rw-r--r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 bricks01.jpg.3mt │ │ --rw-r--r-- 0 root (0) root (0) 163935 1970-01-01 00:00:00.00 bulvar.3dm │ │ --rw-r--r-- 0 root (0) root (0) 396 1970-01-01 00:00:00.00 cars.def │ │ --rw-r--r-- 0 root (0) root (0)24999 1970-01-01 00:00:00.00 chodnik.jpg │ │ --rw-r--r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 chodnik.jpg.3mt │ │ --rw-r--r-- 0 root (0) root (0)41743 1970-01-01 00:00:00.00 concrete.jpg │ │ --rw-r--r-- 0 root (0) root (0) 139 1970-01-01 00:00:00.00 concrete.jpg.3mt │ │ --rw-r--r-- 0 root (0) root (0) 1915 1970-01-01 00:00:00.00 cone.3dm │ │ --rw-r--r-- 0 root (0) root (0) 106 1970-01-01 00:00:00.00 cone.png │ │ --rw-r--r-- 0 root (0) root (0) 91 1970-01-01 00:00:00.00 cone.png.3mt │ │ +-rw-rw-r-- 0 root (0) root (0)74614 1970-01-01 00:00:00.00 asphalt.jpg │ │ +-rw-rw-r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 asphalt.jpg.3mt │ │ +-rw-rw-r-- 0 root (0) root (0) 789 1970-01-01 00:00:00.00 barrier.3dm │ │ +-rw-rw-r-- 0 root (0) root (0) 5357 1970-01-01 00:00:00.00 barrier.png │ │ +-rw-rw-r-- 0 root (0) root (0) 137 1970-01-01 00:00:00.00 barrier.png.3mt │ │ +-rw-rw-r-- 0 root (0) root (0) 1365 1970-01-01 00:00:00.00 barriera.png │ │ +-rw-rw-r-- 0 root (0) root (0) 127 1970-01-01 00:00:00.00 barriera.png.3mt │ │ +-rw-rw-r-- 0 root (0) root (0)26908 1970-01-01 00:00:00.00 barrierd.png │ │ +-rw-rw-r-- 0 root (0) root (0)20025 1970-01-01 00:00:00.00 betonova_zed.jpg │ │ +-rw-rw-r-- 0 root (0) root (0) 142 1970-01-01 00:00:00.00 betonova_zed.jpg.3mt │ │ +-rw-rw-r-- 0 root (0) root (0) 129 1970-01-01 00:00:00.00 black.png.3mt │ │ +-rw-rw-r-- 0 root (0) root (0)23570 1970-01-01 00:00:00.00 bricks01.jpg │ │ +-rw-rw-r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 bricks01.jpg.3mt │ │ +-rw-rw-r-- 0 root (0) root (0) 163935 1970-01-01 00:00:00.00 bulvar.3dm │ │ +-rw-rw-r-- 0 root (0) root (0) 396 1970-01-01 00:00:00.00 cars.def │ │ +-rw-rw-r-- 0 root (0) root (0)24999 1970-01-01 00:00:00.00 chodnik.jpg │ │ +-rw-rw-r-- 0 root (0) root (0) 138 1970-01-01 00:00:00.00 chodnik.jpg.3mt │ │ +-rw-rw-r-- 0 root (0) root (0)41743 1970-01-01 00:00:00.00 concrete.jpg │ │ +-rw-rw-r-- 0 root (0) root (0) 139 1970-01-01 00:00:00.00 concrete.jpg.3mt │ │ +-rw-rw-r-- 0 root (0) root (0) 1915 1970-01-01 00:00:00.00 cone.3dm │ │ +-rw-rw-r-- 0 root (0) root (0) 106 1970-01-01 00:00:00.00 cone.png │ │ +-rw-rw-r-- 0 root (0) root
Bug#1056569: libbrotli-dev: libbrotlidec.a corrupted due to c-p error in 0001-build-static-libraries-by-default.patch
control: severity -1 serious
control: tags -1 patch pending
This is actually regressing freetype autopkgtests
I'll team upload shortly the trivial patch
G.
On Thu, 23 Nov 2023 10:12:43 +0100 Philipp Wolski wrote:
Package: libbrotli-dev
Version: 1.1.0-1
Severity: normal
Dear Maintainer,
libbrotlidec.a is unusable in brotli 1.1.0-1 since it is identical to
libbrotlicommon.a
This happened because patch 0001-build-static-libraries-by-default.patch seems
to contain
a copy paste error:
+add_library(brotlicommon-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlidec-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlienc-static STATIC ${BROTLI_ENC_SOURCES})
I rebuild the package with the line of brotlidec-static changed to BROTLI_DEC_SOURCES
and the library is usable again.
I caught the problem because I tried to link libfreetype statically
which required libbrotlidec.a
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 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 libbrotli-dev depends on:
ii libbrotli1 1.1.0-1
libbrotli-dev recommends no packages.
libbrotli-dev suggests no packages.
-- no debconf information
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1056574: transition: ppp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:ppp Hello Release Team friends, I uploaded ppp-2.5.0-1+1 to experimental back in September, and I think it's time to unleash it on unstable, ideally in the next few days. This is an ABI break both due to the new upstream version but there are also significant changes in this release that may break dependent packages. The upload I'm planning, 2.5.0-1+2, only has a minor fix for loong64 and a changelog fix. As usual this isn't a traditional library package upload so the Ben file looks a bit foreign. See #890204 for a previous time we did this. Thanks, Chris Ben file: title = "ppp"; is_affected = .build-depends ~ /ppp-dev/; is_good = .depends ~ /ppp \(>= 2\.5\.0-1\+~\)/ | .breaks ~ /ppp \(<< 2\.5\.0-1\+~\)/; is_bad = .depends ~ /ppp \(>= 2\.4\.9-1\+~\)/ | .breaks ~ /ppp \(<< 2\.4\.9-1\+~\)/;
Bug#1027268: #1027268 pending, fixed in git
tags 1027268 pending thanks Fixed with https://salsa.debian.org/debian/mini-dinstall/-/commit/d1d92b57e634b8fc740d1665bb0de0a9081a11c2
Bug#1055646: gdb: extremely slow response to basic commands
Hello, On Tue, 21 Nov 2023 13:53:00 +0100 =?UTF-8?B?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= wrote: > Hello, > > On Wed, 15 Nov 2023 at 23:09, tomazzi wrote: > > > To do this, I need to have a complete build log with all the > > compiler/linker flags, compiler warnings, etc. > > Find logs at https://buildd.debian.org/status/logs.php?pkg=gdb&arch=amd64 Many thanks for the link - I have the log, but I need some time to analyze it. > > Unfortunately, the methods described on the official Debian Wiki page > > does not allow to build gdb from source package -> "debuild" fails to > > produce the binary shipped by Debian. (I would say that this deserves a > > separate BUG report). > > I am unsure about that, usually you can build using dpkg-buildpackage. The gdb compiled with: $> dpkg-buildpackage --build=binary --host-type=x86_64-linux-gnu -us -uc reports configuration identical with the installed gdb, but the files are of different size: installed 9.9MiB, compiled 9.3MiB. The newly build gdb is also very slow. I've also compiled the "hacked" gdb with Debian patches applied, and it's fast - so no regression here. Didn't tried sbuild yet. Regards
Bug#1056572: maildir-utils: please make the build reproducible
On 2023-11-23, at 10:34:50 +, Chris Lamb wrote: > Source: maildir-utils > Version: 1.10.8-1 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0], we noticed that > maildir-utils could not be built reproducibly: > > ├── ./usr/share/man/man1/mu-add.1.gz > │ ├── mu-add.1 > │ │ @@ -85,15 +85,15 @@ > │ │ Dirk-Jan C. Binnema > │ │ > │ │ .SH "COPYRIGHT" > │ │ .PP > │ │ This manpage is part of \fBmu\fP 1.10.8. > │ │ > │ │ .PP > │ │ -Copyright © 2022-2024 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL > version 3 > │ │ +Copyright © 2022-2023 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL > version 3 > │ │ or later \fIhttps://gnu.org/licenses/gpl.html\fP. This is free software: > you are Yes, I spotted this as well, and I have already pushed changes to the Salsa repo to fix it. J. signature.asc Description: PGP signature
Bug#1055247: #1055247 pending, fixed in git
tags 1055247 pending thanks Fixed with https://salsa.debian.org/debian/mini-dinstall/-/commit/298f88dfda244285fe681e9787114c9da1bc7858
Bug#1056575: daily cronjob not fetching new articles after switching to systemd-cron
Package: sn Version: 0.3.8-12 After switching to systemd-cron the daily cronjob in /etc/cron.daily/sn does not fetch new articles any more. The problem seems to be that systemd does not allow background jobs in shell scripts. The fix is simple: --- /etc/cron.daily/sn.orig 2012-08-24 23:05:41.0 +0200 +++ /etc/cron.daily/sn 2023-11-23 11:21:57.814847259 +0100 @@ -34,5 +34,5 @@ done if [ "$RUNFROM" = cron ]; then -/usr/sbin/snget >/dev/null 2>&1 & +/usr/sbin/snget >/dev/null 2>&1 Klaus.
Bug#1056238: gcc-13: FTBFS on mips64el: E: Build killed with signal TERM after 150 minutes of inactivity
Control: tags -1 + moreinfo I'm not looking into that, CCing the ports maintainers. Sure, we can disable running the tests on mips64el. On 19.11.23 11:18, Sebastian Ramacher wrote: Source: gcc-13 Version: 13.2.0-6 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=gcc-13&arch=mips64el&ver=13.2.0-6&stamp=1700351970&raw=0 === libstdc++ Summary for unix === # of expected passes3886 # of expected failures 43 # of unsupported tests 139 Running target unix/-fstack-protector Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /<>/src/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp ... FAIL: libstdc++-abi/abi_check Running /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp ... === libstdc++ Summary for unix === # of expected passes158 # of unexpected failures1 # of unresolved testcases 1 Running target unix/-fstack-protector Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /<>/src/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp ... === libstdc++ Summary for unix === # of expected passes3689 # of unexpected failures1 # of expected failures 37 # of unsupported tests 186 Running target unix/-fstack-protector Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /<>/src/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... testsuite still running ... E: Build killed with signal TERM after 150 minutes of inactivity Cheers
Bug#1056576: u-boot: Consider building apple/asahi variant
Source: u-boot Version: 2023.07+dfsg-1 Severity: wishlist X-Debbugs-CC: Tobias Heider , Andreas Henriksson Dear Maintainer, I'm opening this bug report to discuss the potential of building another u-boot variant in a new binary package from src:u-boot for "Apple Silicon" machines. The Asahi Linux project has been working on bringing Linux to the newer ARM based line of laptops and stationary (mac mini) by Apple, a.k.a. M1, M2 and just released generation M3. # The overall picture of booting Linux on apple silicon A normal users boot procedure would look something like: Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) -> generic distro EFI boot managers (grub, systemd-boot, etc) m1n1 stage1 is installed by the Asahi Linux installer. m1n1 stage2 + u-boot + dtbs are bundled together and installed as boot.bin on the EFI partition. Apple/macOS does not make use of EFI. The purpose of u-boot is to provide the EFI environment to allow "generic distro boot". m1n1 stage2 is already in debian, see: https://tracker.debian.org/m1n1 # Upstream status The Asahi Linux project has already upstreamed most of their work so simply building `apple_m1_defconfig` is already possible. However they also maintain their own fork of it at: https://github.com/AsahiLinux/u-boot/tree/asahi-releng This fork currently contains 43 additional patches (some already upstreamed, some posted for review, some simply defconfig changes, some dts updates, etc). I've looked over the 43 patches and here's my *perception* of the current status: The current upstream apple_m1_defconfig should be usable for booting (from internal storage) on M1 machines. The M2 can possibly boot, but keyboard driver is not yet upstream - so no interaction with u-boot possible. M3 is not yet supported at all by Asahi Linux (the usual notice of expect atleast 6 months before this happens has been announced). Notable here is that Apple iBoot does not support USB booting, so booting from external media will have to be happening with the help of U-Boot. Unfortunately U-Boot USB support has a number of as I understand it generic bugs that pretty much prevents real-world usage, eg. not support >2TB usb drives, etc. Patches to fix these problems has been posted for review (with mostly positive feedback): https://lists.denx.de/pipermail/u-boot/2023-October/535517.html https://lists.denx.de/pipermail/u-boot/2023-October/535529.html https://lists.denx.de/pipermail/u-boot/2023-October/535534.html https://lists.denx.de/pipermail/u-boot/2023-October/535535.html This is the bulk of the code changes outside apple specific files in the current 43 patch series living in asahi fork of u-boot. There was previously also an attempt to upstream the Apple Type-C PHY dummy driver: https://lists.denx.de/pipermail/u-boot/2023-July/522961.html Some of the patches updates devicetree files (dts) which are completely apple-specific and should not have any chance to affect anything else, but these are also completely unused so does not neccessarily need to be included. The asahi tools to update the EFI boot.bin that combines m1n1, u-boot and dtbs uses the dtbs from the installed kernel, see: https://tracker.debian.org/asahi-fwextract https://tracker.debian.org/asahi-scripts # considerations 1/ are we willing to add another binary package to src:u-boot building apple_m1_defconfig? 2/ should we name the binary package u-boot-apple or -asahi? The existing third-party packages of the asahi fork calls theirs u-boot-asahi. 3/ do we include patches? 3.1/ No patches. If this is the desired path I can volunteer to test that it boots on my M1 machine. Other machines should probably be considered unsupported for now, even though they might have limited usefulness. 3.2/ Minimal set of patches. We identify what we consider crutial only patches and recruit volunteers to test. M2 keyboard? USB? etc... 3.3/ All asahi patches. We consider it simpler to just sync all patches with the asahi fork (even though some are even unused, like the devicetree patches). We trust the Asahi Linux project in their quest to upstream all their work and that they will rebase on newer releases and make our job easy. Debian has a bananas-team that can take responsibility for testing and maintaining software, see: https://wiki.debian.org/Teams/Bananas Also worth noting is that the asahi fork of u-boot has been uploaded and currently sitting in NEW as src:u-boot-asahi. https://ftp-master.debian.org/new.html As mentioned already on the ITP, I think it's excessive to duplicate all of u-boot over 43 patches (and hopefully shrinking): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471 Thanks for considering, Andreas Henriksson -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (400, 'unstable'), (300, 'experimental') Architecture: arm64 (aarch64) Ker
Bug#1041838: fixed for LLVM 17
this is fixed: $ dpkg -L libclang-rt-17-dev|grep -c wasi 0
Bug#1017811: node-wikibase-cli: FTBFS without Internet access
Hello, I have commented out a pair of test cases which attempted network access in the upload of node-wikibase-cli 15.15.4-5. Could you please check whether FTBFS continues? On Wed, 14 Dec 2022 12:16:39 +0100 Sven Mueller wrote: Interestingly, in our build environment which has some extremely limited network access, the package build fails before tests are even run: Linking /usr/bin/wb-set-label to /usr/share/nodejs/wikibase-cli/bin/wb-set-label Linking /usr/bin/wb-sparql to /usr/share/nodejs/wikibase-cli/bin/wb-sparql Linking /usr/bin/wb-summary to /usr/share/nodejs/wikibase-cli/bin/wb-summary Linking /usr/bin/wb-update-claim to /usr/share/nodejs/wikibase-cli/bin/wb-update-claim Linking /usr/bin/wb-update-qualifier to /usr/share/nodejs/wikibase-cli/bin/wb-update-qualifier Linking /usr/bin/wd to /usr/share/nodejs/wikibase-cli/bin/wd dh_installdocs -i dh_installchangelogs -i dh_installexamples -i debian/rules override_dh_installman make[1]: Entering directory '/<>' help2man wb --name 'command-line interface to Wikibase' --no-info > debian/wb.1 help2man: can't get `--help' info from wb Try `--no-discard-stderr' if option outputs to stderr make[1]: *** [debian/rules:10: override_dh_installman] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary-indep] Error 2 dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit status 2 I do not quite get this, AFAIK tests are run before dh_installman. Thus in your case tests pass, but override_dh_installman fails, right? Thanks, Andrius
Bug#1056577: suspend-to-disk is broken after upgrade Debian 11 --> 12
Package: cryptsetup-initramds Version: 2:2.6.1-4~deb12u1 If you upgrade your Laptop from Debian 11 to 12, then resume from an encrypted swap partition is broken. There is a passphrase dialog at boot time as usual, but the image on the swap partition is ignored. Debian is started from scratch. After installing the cryptsetup-suspend package this problem was gone, but it is not in the dependency chain of cryptsetup-initramfs. Regards Harri
Bug#1056382: missing dependency on systemd-sysv
Hello, PR https://salsa.debian.org/debian/dracut/-/merge_requests/29 . Please let us know if this resolved it or if you have some feedback on the PR. Thanks, Laszlo
Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf
On Thu, 23 Nov 2023 09:01:34 +0100 "Francesco Poli (wintermute)" wrote: > Package: dhcpcd-base > Version: 1:10.0.5-2 > Severity: normal > > It seems to work pretty well, just like isc-dhcp-client, but > I noticed an issue in a network where the DHCP server sends > two domains as "search domains" (let's call them MYDOMAIN > and OTHERDOMAIN). > > When I use dhcpcd-base as a DHCP client, I get the following > resolv.conf file: > > $ cat /etc/resolv.conf > # Generated by dhcpcd from enp0s3.dhcp > # /etc/resolv.conf.head can replace this line > domain MYDOMAIN > nameserver 192.168.0.1 > # /etc/resolv.conf.tail can replace this line > > This lacks the two search domains I was expecting. > To be honest, the isc-dhcp-client Debian package > behaves similarly (somehow failing to write OTHERDOMAIN as > second search domain). > > But Rocky Linux clients (on the same network, with the ISC > DHCP client and ifup/ifdown mechanism) correctly set the > resolv.conf with the two search domains: > > $ cat /etc/resolv.conf > ; generated by /usr/sbin/dhclient-script > search MYDOMAIN. OTHERDOMAIN. > nameserver 192.168.0.1 > > Even Windows clients (on the same network) correctly obtain > the two search domains... You might wanna check whether Rocky Linux has patched their DHCP clients or altered their default dhcpcd.conf to make this succeed. If that's the case, please point me to the relevant changes. > Why cannot I have the two search domains on Debian? The dhcpcd client shipped by Debian is, except for recent patches towards fixing the build on Hurd (missing includes, etc.), whatever upstream ships. If that fails to set more than one search domain, I would suspect an upstream issue. https://github.com/NetworkConfiguration/dhcpcd/issues Martin-Éric
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote: [...] > Patches to fix these problems has been posted for review (with mostly > positive feedback): > https://lists.denx.de/pipermail/u-boot/2023-October/535517.html > https://lists.denx.de/pipermail/u-boot/2023-October/535529.html > https://lists.denx.de/pipermail/u-boot/2023-October/535534.html > https://lists.denx.de/pipermail/u-boot/2023-October/535535.html > > This is the bulk of the code changes outside apple specific files > in the current 43 patch series living in asahi fork of u-boot. > > There was previously also an attempt to upstream the Apple Type-C PHY > dummy driver: > https://lists.denx.de/pipermail/u-boot/2023-July/522961.html [...] My mistake here, the PHY driver has already been upstreamed: https://source.denx.de/u-boot/u-boot/-/commit/b99c6357877da2829dc7fd73a50048e83abc53e2 What I wanted to mention was the firmware loading patches: https://lists.denx.de/pipermail/u-boot/2023-July/522962.html Regards, Andreas Henriksson
Bug#1056578: RFS: profile-cleaner/2.45-3 -- Reduces browser profile size by cleaning their sqlite
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "profile-cleaner": * Package name : profile-cleaner Version : 2.45-3 Upstream contact : graysky * URL : https://github.com/graysky2/profile-cleaner * License : Expat * Vcs : https://salsa.debian.org/debian/profile-cleaner Section : utils The source builds the following binary packages: profile-cleaner - Reduces browser profile size by cleaning their sqlite databases To access further information about this package, please visit the following URL: https://mentors.debian.net/package/profile-cleaner/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/profile-cleaner/profile-cleaner_2.45-3.dsc Changes since the last upload: profile-cleaner (2.45-3) unstable; urgency=medium . * Add VCS fields to control file Regards, -- Peter Blackman
Bug#1055355: RFA: cbor2 -- Concise Binary Object Representation for Python
Hello Bastian, thank you for the fine work! I would like to adopt your package. Best regards, Georges Bastian Germann a écrit : > Package: wnpp > > I do not use cbor2 anymore. > Please consider adopting it if you have the time and skills to maintain it. > It is a low-maintenance package with seldomly release upstream versions. > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1056238: gcc-13: FTBFS on mips64el: E: Build killed with signal TERM after 150 minutes of inactivity
On 2023-11-23 12:22:05 +0100, Matthias Klose wrote: > Control: tags -1 + moreinfo > > I'm not looking into that, CCing the ports maintainers. Sure, we can > disable running the tests on mips64el. It used to be no problem while the faster mips64el buildds were available. But currently we only have the slow ones, where the tests timeout. Best Sebastian > > On 19.11.23 11:18, Sebastian Ramacher wrote: > > Source: gcc-13 > > Version: 13.2.0-6 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > X-Debbugs-Cc: sramac...@debian.org > > > > https://buildd.debian.org/status/fetch.php?pkg=gcc-13&arch=mips64el&ver=13.2.0-6&stamp=1700351970&raw=0 > > > > === libstdc++ Summary for unix === > > > > # of expected passes3886 > > # of expected failures 43 > > # of unsupported tests 139 > > Running target unix/-fstack-protector > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /<>/src/libstdc++-v3/testsuite/config/default.exp as > > tool-and-target-specific interface file. > > Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp > > ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp > > ... > > FAIL: libstdc++-abi/abi_check > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp > > ... > > > > === libstdc++ Summary for unix === > > > > # of expected passes158 > > # of unexpected failures1 > > # of unresolved testcases 1 > > Running target unix/-fstack-protector > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /<>/src/libstdc++-v3/testsuite/config/default.exp as > > tool-and-target-specific interface file. > > Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp > > ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp > > ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp > > ... > > > > === libstdc++ Summary for unix === > > > > # of expected passes3689 > > # of unexpected failures1 > > # of expected failures 37 > > # of unsupported tests 186 > > Running target unix/-fstack-protector > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /<>/src/libstdc++-v3/testsuite/config/default.exp as > > tool-and-target-specific interface file. > > Running /<>/src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp > > ... > > Running > > /<>/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... > > > > testsuite still running ... > > > > E: Build killed with signal TERM after 150 minutes of inactivity > > > > > > Cheers > -- Sebastian Ramacher
Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml
Georg Faerber wrote on Tue, Sep 19, 2023 at 10:19:57AM +: > So, symlinks to the rescue: > > [...] This is horrible. So I obviously did the same. Thanks a lot! I'd be interested in a better solution that'll survive upgrades though -- I agree wth Georg's analysis that this is "just" a problem of loading paths, so either the puppetserver package could add hiera-eyaml in its vendored-jruby-gems (which probably isn't too hard, but debian frowns on vendored stuff in general so I don't see why it'd be better for ruby deps..), or we'll need to look into why system gems cannot be used with jruby... -- Dominique Martinet | Asmadeus
Bug#1056579: ceph: add support for loong64
Source: ceph
Version: 16.2.11+ds-5
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn
Dear Maintainer,
ceph compilation error in loong64 arch, the
attached patch provides some reference.
wuruilong
-- System Information:
Debian Release: trixie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)
Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
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
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
ceph (16.2.11+ds-5) unstable; urgency=high
.
* CVE-2023-43040: security issue with RGW with improperly verified POST keys.
Applied upstream fix: rgw: Fix bucket validation against POST policies
(Closes: #1053690).
Author: Thomas Goirand
Bug-Debian: https://bugs.debian.org/1053690
---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: (upstream|backport|vendor|other), (|commit:)
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By:
Last-Update: 2023-11-23
--- /dev/null
+++ ceph-16.2.11+ds/etc/sysctl/90-ceph-osd.conf
@@ -0,0 +1,2 @@
+fs.aio-max-nr = 1048576
+kernel.pid_max = 4194304
--- ceph-16.2.11+ds.orig/src/boost/boost/predef/architecture.h
+++ ceph-16.2.11+ds/src/boost/boost/predef/architecture.h
@@ -15,6 +15,7 @@ http://www.boost.org/LICENSE_1_0.txt)
#include
#include
#include
+#include
#include
#include
#include
--- /dev/null
+++ ceph-16.2.11+ds/src/boost/boost/predef/architecture/loongarch.h
@@ -0,0 +1,43 @@
+/*
+Copyright Ruilong Wu 2023
+Distributed under the Boost Software License, Version 1.0.
+(See accompanying file LICENSE_1_0.txt or copy at
+http://www.boost.org/LICENSE_1_0.txt)
+*/
+
+#ifndef BOOST_PREDEF_ARCHITECTURE_LOONGARCH_H
+#define BOOST_PREDEF_ARCHITECTURE_LOONGARCH_H
+
+#include
+#include
+
+/* tag::reference[]
+= `BOOST_ARCH_LOONGARCH`
+
+http://en.wikipedia.org/wiki/RISC-V[RISC-V] architecture.
+
+[options="header"]
+|===
+| {predef_symbol} | {predef_version}
+
+| `+__loongarch__+` | {predef_detection}
+|===
+*/ // end::reference[]
+
+#define BOOST_ARCH_LOONGARCH BOOST_VERSION_NUMBER_NOT_AVAILABLE
+
+#if defined(__loongarch__)
+# undef BOOST_ARCH_LOONGARCH
+# define BOOST_ARCH_LOONGARCH BOOST_VERSION_NUMBER_AVAILABLE
+#endif
+
+#if BOOST_ARCH_LOONGARCH
+# define BOOST_ARCH_LOONGARCH_AVAILABLE
+#endif
+
+#define BOOST_ARCH_RISCV_NAME "LoongArch"
+
+#endif
+
+#include
+BOOST_PREDEF_DECLARE_TEST(BOOST_ARCH_LOONGARCH,BOOST_ARCH_LOONGARCH_NAME)
--- ceph-16.2.11+ds.orig/src/boost/boost/predef/other/endian.h
+++ ceph-16.2.11+ds/src/boost/boost/predef/other/endian.h
@@ -125,6 +125,7 @@ information and acquired knowledge:
defined(__ARMEL__) || \
defined(__THUMBEL__) || \
defined(__AARCH64EL__) || \
+ defined(__loongarch__) || \
defined(_MIPSEL) || \
defined(__MIPSEL) || \
defined(__MIPSEL__) || \
--- ceph-16.2.11+ds.orig/src/boost/boostcpp.jam
+++ ceph-16.2.11+ds/src/boost/boostcpp.jam
@@ -607,7 +607,7 @@ rule address-model ( )
return @boostcpp.deduce-address-model ;
}
-local deducable-architectures = arm mips1 power riscv s390x sparc x86 combined
;
+local deducable-architectures = arm loongarch mips1 power riscv s390x sparc
x86 combined ;
feature.feature deduced-architecture : $(deducable-architectures) : propagated
optional composite hidden ;
for a in $(deducable-architectures)
{
@@ -618,9 +618,10 @@ rule deduce-architecture ( properties *
{
local result ;
local filtered = [ toolset-properties $(properties) ] ;
-local names = arm mips1 power riscv s390x sparc x86 combined ;
+local names = arm loongarch mips1 power riscv s390x sparc x86 combined ;
local idx = [ configure.find-builds "default architecture" : $(filtered)
: /boost/architecture//arm
+: /boost/architecture//loongarch
: /boost/architecture//mips1
: /boost/architecture//power
: /boost/architecture//riscv
Bug#1056580: LLVM-17's autopkg tests fail (command1)
Package: src:llvm-toolchain-17 Version: 1:17.0.5-1 Severity: serious Tags: sid trixie [...] 231s clang++-$VERSION -std=c++14 -stdlib=libc++ foo.cpp -lc++experimental -o o 233s /usr/bin/ld: cannot find -lc++experimental: No such file or directory 233s clang++-17: error: linker command failed with exit code 1 (use -v to see invocation) 16 used to pass one more -L flag, 17 is missing that: @@ -17,7 +17,6 @@ -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 --L/usr/lib/llvm-16/bin/../lib -L/lib -L/usr/lib foo.o
Bug#1027267: 1027267 pending, fixed in git
tags 1027267 pending thanks Fixed with https://salsa.debian.org/debian/mini-dinstall/-/commit/d1d92b57e634b8fc740d1665bb0de0a9081a11c2
Bug#1002993: Also seen on chromebook
I just did the simple Linux installation as seen on https://support.google.com/chromebook/answer/9145439 https://www.youtube.com/watch?v=EVWrdrvQ-rU Oh, and then I changed the /etc/apt/sources.list.d/ to get "sid", and also picked beta channel: Google Chrome: Version 120.0.6099.25 (Official Build) beta (32-bit) Platform: 15662.16.0 (Official Build) beta-channel jacuzzi Channel: beta-channel Firmware Version: Google_Fennel.12573.380.0 ARC Enabled: true ARC: 11087447 Enterprise Enrolled: false Developer Mode: false Anyway, yes I read https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md but that's way advanced stuff, over my head. So you will need to send me a script with what commands to run to glean information about my chromebook. Yes I read https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md but that's way advanced stuff, over my head. Anyway, df, mount, stat,.. just tell me what commands to run and I'll post the output here.
Bug#1056581: cups-daemon: CUPS 2.4.2 forces monochrome printing when PPD is using ColorModel CMYK
Package: cups-daemon Version: 2.4.2-3+deb12u4 Severity: important Dear Maintainer, when using PPDs with setting ColorModel=CMYK, then cups will set print-color-mode to monochrome in printers.conf thus forcing all prints to be monochrome. This is a known bug and fixed https://github.com/OpenPrinting/cups/issues/401 https://github.com/OpenPrinting/cups/issues/421 https://github.com/OpenPrinting/cups/pull/500 Please update or patch the cups version in bookworm. Thanks! Christian *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-daemon depends on: ii adduser3.134 ii bc 1.07.1-3+b1 ii init-system-helpers1.65.2 ii libavahi-client3 0.8-10 ii libavahi-common3 0.8-10 ii libc6 2.36-9+deb12u3 ii libcups2 2.4.2-3+deb12u4 ii libdbus-1-31.14.10-1~deb12u1 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii libpaper1 1.1.29 ii libsystemd0252.17-1~deb12u1 ii lsb-base 11.6 ii procps 2:4.0.2-3 ii ssl-cert 1.1.2 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages cups-daemon recommends: pn avahi-daemon pn colord pn cups-browsed pn ipp-usb Versions of packages cups-daemon suggests: ii cups 2.4.2-3+deb12u4 pn cups-bsd ii cups-client2.4.2-3+deb12u4 ii cups-common2.4.2-3+deb12u4 ii cups-filters 1.28.17-3 ii cups-ppdc 2.4.2-3+deb12u4 ii cups-server-common 2.4.2-3+deb12u4 pn foomatic-db-compressed-ppds | foomatic-db ii ghostscript10.0.0~dfsg-11+deb12u2 ii poppler-utils 22.12.0-2+b1 ii printer-driver-cups-pdf [cups-pdf] 3.0.1-14 pn smbclient ii udev 252.17-1~deb12u1 -- Configuration Files: /etc/cups/cups-files.conf changed [not included] -- no debconf information
Bug#1056582: iproute2: [INTL:it] Italian debconf translation
Package: iproute2 Version: 6.6.0-1 Severity: wishlist Tags: l10n patch X-Debbugs-Cc: ce...@oziosi.org Hello, you can find the Italian debconf translation in the attached file. Cheers, -- Ceppo # iproute po-debconf italian translation. # Copyright (C) 2023 iproute2's copyright holder # This file is distributed under the same license as the iproute2 package. # Ceppo , 2023. # msgid "" msgstr "" "Project-Id-Version: iproute2\n" "Report-Msgid-Bugs-To: iprou...@packages.debian.org\n" "POT-Creation-Date: 2018-04-12 12:01+0100\n" "PO-Revision-Date: 2023-07-11 00:00+\n" "Last-Translator: Ceppo \n" "Language-Team: Italian \n" "Language: it\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "Allow ordinary users to run ip vrf exec using capabilities?" msgstr "" "Consentire agli utenti normali di eseguire ip vrf exec usando le capability?" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "iproute2 can be used to configure and use Virtual Routing and Forwarding " "(VRF) functionality in the kernel. This normally requires root permissions, " "but sometimes it's useful to allow ordinary users to execute commands from " "inside a virtual routing and forwarding domain. E.g. ip vrf exec examplevrf " "ping 10.0.0.1" msgstr "" "iproute2 può essere usato per configurare e utilizzare la funzionalità " "Virtual Routing and Forwarding (VRF) del kernel. Questo normalmente richiede " "i permessi di root, ma a volte è utile consentire agli utenti normali di " "eseguire comandi all'interno di un dominio virtuale di instradamento e " "inoltro. Ad esempio ip vrf exec examplevrf ping 10.0.0.1" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "The ip command supports dropping capabilities, making an exception for ip " "vrf exec. The drawback of setting the permissions is that if in the unlikely " "case of a security critical bug being found before the ip command has " "dropped capabilities then it could be used by an attacker to gain root " "permissions. It's up to you to decide about the trade-offs and select the " "best setting for your system. This will give cap_dac_override, cap_net_admin " "and cap_sys_admin to /bin/ip." msgstr "" "Il comando ip consente di invalidare le capability, ad eccezione di ip vrf " "exec. Lo svantaggio di impostare i permessi è che nell'improbabile caso che " "venga scoperto un bug di sicurezza critico prima che il comando ip abbia " "invalidato le capability esso potrebbe essere sfruttato da un attaccante per " "ottenere permessi di root. Bisogna valutare costi e benefici e selezionare " "le impostazioni migliori per il proprio sistema. Questo attribuirà " "cap_dac_override, cap_net_admin e cap_sys_admin a /bin/ip." #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "More information about VRF can be found at: https://www.kernel.org/doc/"; "Documentation/networking/vrf.txt" msgstr "" "Più informazioni su VRF possono essere trovate a: https://www.kernel.org/doc/"; "Documentation/networking/vrf.txt"
Bug#988426: scilab,scilab-cli,scilab-test: metapackages uninstallable on 32-bit architectures
Control: severity -1 wishlist Control: tags -1 wontfix Hi, I am afraid I am missing the point here: it does not hurt anyone if the metapackages are not installable because their dependencies are not. Additionally scilab-test is huge and it makes no sense to make it Architecture: any and duplicate it for every arch. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055778: libamtk-5-dev: Depends: gir1.2-amtk-5 (= 5.6.1-2) but 5.8.0-4 is to be installed
On Sat, Nov 11, 2023 at 5:09 AM Sebastian Ramacher wrote: > Package: libamtk-5-dev > Version: libamtk-5-dev > Severity: serious > Tags: sid trixie > X-Debbugs-Cc: sramac...@debian.org > … > The following packages have unmet dependencies: > libamtk-5-dev : Depends: gir1.2-amtk-5 (= 5.6.1-2) but 5.8.0-4 is to be > installed > E: Unable to correct problems, you have held broken packages. > > > gir1.2-amtk-5 has been taken over by libgedit-amtk. Sebastian, could you help hint this transition through? Affected packages that need to get to Testing are gedit, gedit-plugins, libgedit-amtk, and tepl. I imagine you may need to remove amtk from Testing. Thank you, Jeremy Bícha
Bug#1056583: kaidan: FTBFS with disabled network
Source: kaidan Version: 0.9.1-2 Severity: serious Hello, the package FTBFS trying to call search.jabber.network, something forbidden by policy. 6: QWARN : GroupChatTest::test_GroupChatSearchManager_GroupChatModel() public-group-chat.search: Search request error: Host search.jabber.network not found 6: FAIL! : GroupChatTest::test_GroupChatSearchManager_GroupChatModel() 'spyError.isEmpty()' returned FALSE. () Full log available e.g. here: https://launchpadlibrarian.net/698369989/buildlog_ubuntu-noble-amd64.kaidan_0.9.1-2_BUILDING.txt.gz I think disabling that test function should work as workaround. G. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055778: libamtk-5-dev: Depends: gir1.2-amtk-5 (= 5.6.1-2) but 5.8.0-4 is to be installed
On 2023-11-23 08:43:16 -0500, Jeremy Bícha wrote: > On Sat, Nov 11, 2023 at 5:09 AM Sebastian Ramacher > wrote: > > Package: libamtk-5-dev > > Version: libamtk-5-dev > > Severity: serious > > Tags: sid trixie > > X-Debbugs-Cc: sramac...@debian.org > > > … > > The following packages have unmet dependencies: > > libamtk-5-dev : Depends: gir1.2-amtk-5 (= 5.6.1-2) but 5.8.0-4 is to be > > installed > > E: Unable to correct problems, you have held broken packages. > > > > > > gir1.2-amtk-5 has been taken over by libgedit-amtk. > > Sebastian, could you help hint this transition through? Affected > packages that need to get to Testing are gedit, gedit-plugins, > libgedit-amtk, and tepl. I imagine you may need to remove amtk from > Testing. Is amtk still useful? If not, please file a RM request for unstable against ftp.debian.org. Cheers -- Sebastian Ramacher
Bug#864824: claws-mail: If i have 2 mailbox, Claws-Mail always put my sent messages in the first one.
On Thu, 15 Jun 2017 14:40:49 +0200 luffah wrote: >* What led up to the situation? >i configured 2 mailbox: > - 1 on laposte.net [a] > - 1 on runbox.com [b0]+ 3 identities[b1,b2,b3] (mailbox for smtp > sending) >* What exactly did you do (or not do) that was effective (or > ineffective)? > I don't achieve have the mail sent in claws-mail. > I tested 6 cases, with a config : > 1 - sending mail with [a] -> ok the mail goes in the a/Sent > directory > 2 - sending mail with [b0] -> ko , the sent mail is not saved > 3 - sending mail with [b1] (same with [b2] or [b3]) -> ko, the > mail is saved in a/Sent instead of b/Sent > 4 - i checked Advanced option for [b1] "Save sent mail in .." > b/Sent" which exists, and sending : ko the mail is not saved > 5 - i checked Advanced option for [b2] "Save sent mail in .." > b/SentAs/b2" which didn't exists, and sending : ko the mail is > save in a/Sent > 6 - i checked Advanced option for [b3] "Save sent > mail in .." b/SentAs/b3" which exists, and sending : ko the > mail is not saved This is something that looks like a general bug in Claws (if it still occurs in current Claws version) and should be discussed in us...@lists.claws-mail.org mailing list or reported in the bugtracker: https://www.thewildbeast.co.uk/claws-mail/bugzilla/index.cgi
Bug#1056584: RM: amtk -- RoM; superseded by libgedit-amtk
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: a...@packages.debian.org, sramac...@debian.org Control: affects -1 + src:amtk The upstream amtk project has changed its name to libgedit-amtk so we have changed the source package name to match. Therefore, please remove amtk from Unstable. Note that the binary package gir1.2-amtk-5 is now built by the source package libgedit-amtk On behalf of the Debian GNOME team, Jeremy Bícha
Bug#1054698: pixmap: FTBFS: ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames'
On Fri 27 Oct 2023, Lucas Nussbaum wrote: > Source: pixmap > Version: 2.6.6-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231027 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > /usr/bin/ld: Pixmap.o: in function `Initialize': > > ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames' > > collect2: error: ld returned 1 exit status I've traced this to commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm: Explicitly mark non-static symbols as export or hidden Hides private API from external linkage Signed-off-by: Alan Coopersmith That commit marks those functions as hidden for some reason. I'm contacting the libxpm maintainers. Paul
Bug#1056348: FTBFS: tests fail in clean environment
Hello, On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre wrote: Source: libssh2 Version: 1.9.0-2 Severity: serious Tags: ftbfs patch Hi! Building libssh2 using debuild in a clean local chroot, I get test failures and even a core dump! Thanks for reporting the bug, although I have concerns on its scope. The package you have found the issue is the bullseye one, and the package updates for oldstable are allowed mostly for security patches. Your bug is related to the test suite, and the patch won't change the binary files in the package, so I assume the patch isn't going to be allowed for proposed-updates. I've added the release team to ask for their opinion. Friends from the release team, do you have a feedback on this? /Nicolas
Bug#1056585: RM: hinawa-utils/0.3.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: ken...@xdump.org Here is the some reasons to remove hinawa-utils from testing: * The hinawa-utils depends on libhinawa (2.x), and the newer release of libhinawa (4.x) drops obsolete features. hinawa-utils depends on the obsolete (removed) features. Thus hinawa-utils is useless without it. * The newer release of libhinawa (4.x) should be in next stable release, but because of breaking dependency, it blocks migration of libhinawa (4.x) from unstable. * The upstream author develops such a obsolete feature into separate library - libhitaki, but it is not packaged yet in debian. * hinawa-utils is under maintenance mode, so I have no idea when it supports libhitaki yet. So, I decided to remove it and it should not be part of next stable release (for now) In the future, if libhitaki was packaged in debian and hinawa-utils supports it, then salvage hinawa-utils package which supports libhitaki again. Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056354
Bug#1056586: texlive-bin: Untighten / Remove version check in luazlib
Source: texlive-bin
Version: 2023.20230311.66589-8
Severity: normal
Dear Maintainer,
the luazlib contains a check, which checks if the zlib version it was
linked with (compile time) is the same as which is used during
run time.
texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c
if (strncmp(version, ZLIB_VERSION, 4))
{
lua_pushfstring(L, "zlib library version does not match - header: %s,
library: %s", ZLIB_VERSION, version);
lua_error(L);
}
This check caused a few issues in the past (issue #w/o bug in 2014, #1056183)
Currently the issue has been remedied by relaxing the check. One should
check if it is needed at all.
Hilmar
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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
Bug#1039001: Tests disabled
Source: hera Version: 1.0.0+dfsg-2 Followup-For: Bug #1039001 Control: severity 1039001 wishlist Uploading catch2 v3 also made hera FTBFS (#1054686), and it is not clear whether the catch2 package will provide backwards-compatible headers (#1055237). Since updating hera is not entirely trivial, the fix for #1054686 was to temporarily disable tests. With tests disabled, I'm lowering the severity of this bug. signature.asc Description: PGP signature
Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023
Package: texlive-latex-base
Version: 2023.20231007-1
Severity: normal
With Debian's packages, as of version 2023, some math characters
get replaced. For instance, consider
\documentclass{article}
\pagestyle{empty}
\begin{document}
$x'$ ; $\oplus$ ; $\ominus$ ; $\otimes$ ; $\ell$ ; OK.
\end{document}
I get the following:
x0 ; ⊕ ;
; ⊗ ; ` ; OK.
instead of
x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.
No issue in Debian/stable (12.2). And several users say that an
up-to-date TeX Live 2023 is fine too. (I'll try, but the installation
is still ongoing.)
So this is either a Debian-specific bug or the issue has recently been
fixed upstream.
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-r--r-- 1 root root 4255 2023-11-23 14:57:48 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 23:25:33 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2023-10-08 22:00:45
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2023-10-08 22:00:45
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 475 2023-11-23 14:52:42 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2023-10-08 22:00:45
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2023-10-08 22:00:45 /usr/share/texmf/web2c/updmap.cfg
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5334 2023-11-23 14:53:15
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2015-09-03 02:24:29 mktex.cnf
-rw-r--r-- 1 root root 475 2023-11-23 14:52:42 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 texlive-latex-base depends on:
ii fonts-lmodern 2.005-1
ii tex-common6.18
ii texlive-base 2023.20231007-1
ii texlive-binaries 2023.20230311.66589-8
texlive-latex-base recommends no packages.
Versions of packages texlive-latex-base suggests:
ii texlive-latex-base-doc 2023.20231007-1
pn wp2latex
Versions of packages tex-common depends on:
ii ucf 3.0043+nmu1
Versions of packages tex-common suggests:
ii debhelper 13.11.8
Versions of packages texlive-latex-base is related to:
ii tex-common6.18
ii texlive-binaries 2023.20230311.66589-8
-- no debconf inform
Bug#1055687: khmer ftbfs with Python 3.12
Package: khmer
Followup-For: Bug #1055687
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:
* Fix build against Python 3.12 (LP: #2044383).
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
diff -Nru khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch
khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch
--- khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch 1970-01-01
01:00:00.0 +0100
+++ khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch 2023-11-23
15:24:51.0 +0100
@@ -0,0 +1,24 @@
+Description: Add support for Python 3.12
+ Ever since Python 3.2, configparser.SafeConfigParser has been deprecated in
+ favor of configparser.ConfigParser. An alias existed for backward compability
+ but the alias was dropped from Python 3.12.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2044383
+Bug-Debian: https://bugs.debian.org/1055687
+Forwarded: https://github.com/dib-lab/khmer/pull/1922
+Last-Update: 2023-11-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: khmer-3.0.0~a3+dfsg/versioneer.py
+===
+--- khmer-3.0.0~a3+dfsg.orig/versioneer.py 2019-03-13 14:42:12.0
+0100
khmer-3.0.0~a3+dfsg/versioneer.py 2023-11-23 15:19:50.025827413 +0100
+@@ -339,7 +339,7 @@
+ # configparser.NoOptionError (if it lacks "VCS="). See the docstring at
+ # the top of versioneer.py for instructions on writing your setup.cfg .
+ setup_cfg = os.path.join(root, "setup.cfg")
+-parser = configparser.SafeConfigParser()
++parser = configparser.ConfigParser()
+ with open(setup_cfg, "r") as f:
+ parser.readfp(f)
+ VCS = parser.get("versioneer", "VCS") # mandatory
diff -Nru khmer-3.0.0~a3+dfsg/debian/patches/series
khmer-3.0.0~a3+dfsg/debian/patches/series
--- khmer-3.0.0~a3+dfsg/debian/patches/series 2023-09-09 08:30:33.0
+0200
+++ khmer-3.0.0~a3+dfsg/debian/patches/series 2023-11-23 15:19:31.0
+0100
@@ -17,3 +17,4 @@
stringio-buffer.patch
refresh_cython
find_object_files_at_right_loc.patch
+python3.12-support.patch
Bug#1056348: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote: >Hello, > >On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre wrote: >> Source: libssh2 >> Version: 1.9.0-2 >> Severity: serious >> Tags: ftbfs patch >> >> Hi! >> >> Building libssh2 using debuild in a clean local chroot, I get test >> failures and even a core dump! >> >Thanks for reporting the bug, although I have concerns on its scope. > >The package you have found the issue is the bullseye one, and the package >updates for oldstable are allowed mostly for security patches. > >Your bug is related to the test suite, and the patch won't change the binary >files in the package, so I assume the patch isn't going to be allowed for >proposed-updates. > >I've added the release team to ask for their opinion. > >Friends from the release team, do you have a feedback on this? Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023
On 2023-11-23 15:44:17 +0100, Vincent Lefevre wrote:
> With Debian's packages, as of version 2023, some math characters
> get replaced. For instance, consider
>
> \documentclass{article}
> \pagestyle{empty}
> \begin{document}
> $x'$ ; $\oplus$ ; $\ominus$ ; $\otimes$ ; $\ell$ ; OK.
> \end{document}
>
> I get the following:
>
>
> x0 ; ⊕ ;
>
> ; ⊗ ; ` ; OK.
>
>
> instead of
>
>
> x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.
>
I forgot to say that these are the characters obtained with
pdftotext (the issue is not with the glyphs, but with the
textual part).
--
Vincent Lefèvre - Web:
Bug#1056588: ftp.kaist.ac.kr(ftp.kr.d.o): Not listed in public mirror list
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-list Hello, this is ftp.kaist.ac.kr (known as ftp.kr.debian.org) manager. I checked that we are not listed in the public mirror list. (https://www.debian.org/mirror/list) But, we are already listed in the mirror-master list. (https://mirror-master.debian.org/status/mirror-info/ftp.kaist.ac.kr.html) So, can we get listed both 2 domains (or if only 1 tier, then ftp.kr.d.o) on the public mirror list? Regards, Roul
Bug#1056062: coq: FTBFS in sid (dune update?)
Hi, Le mercredi 22 novembre 2023 à 18:48 +0100, Gianfranco Costamagna a écrit : > control: tags -1 patch > > Hello, not sure why and how, but this upstream commit > fbe9e28b667e795a5ceb41bd7784bd2ea7ab10bf > > https://launchpadlibrarian.net/699029680/coq_8.17.0+dfsg-1build4_8.17.0+dfsg-1ubuntu1.diff.gz > > Subject: [PATCH] make-library-index: use mktemp, general cleanup > > This fixes the "sed: can't read tmp" error on my machine, not that I > understand why it happened. > > Looks fixing the issue > Good: that means the problem will be fixed when I'll be able to upload 8.18.0+dfsg-1 to unstable. control: fixed -1 8.18.0+dfsg-1 Thanks! J.Puydt
Bug#1056589: python3-spidev: i got no spidev devices unter /dev/
Package: python3-spidev Version: 3.6-1+b1 Severity: normal Dear Maintainer, I got no SPI - Device under /dev/ root@raspi2:/dev# ls -hl insgesamt 0 crw--- 1 root root 10, 134 20. Sep 14:15 apm_bios crw-r--r-- 1 root root 10, 235 20. Sep 14:15 autofs drwxr-xr-x 2 root root 260 20. Sep 14:15 block crw--- 1 root root 10, 234 20. Sep 14:15 btrfs-control drwxr-xr-x 3 root root 60 1. Jan 1970 bus crw-rw 1 root video 239, 0 20. Sep 14:15 cec0 drwxr-xr-x 2 root root2,7K 22. Nov 18:59 char crw--w 1 root tty 5, 1 22. Nov 18:59 console crw--- 1 root root 10, 203 20. Sep 14:15 cuse drwxr-xr-x 8 root root 160 1. Jan 1970 disk drwxr-xr-x 3 root root 100 20. Sep 14:15 dri crw-rw 1 root video29, 0 20. Sep 14:15 fb0 lrwxrwxrwx 1 root root 13 1. Jan 1970 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 20. Sep 14:15 full crw-rw-rw- 1 root root 10, 229 20. Sep 14:15 fuse crw--- 1 root root254, 0 20. Sep 14:15 gpiochip0 crw--- 1 root root 10, 183 20. Sep 14:15 hwrng crw-rw 1 root i2c 89, 0 20. Sep 14:15 i2c-0 crw-rw 1 root i2c 89, 1 20. Sep 14:15 i2c-1 crw-rw 1 root i2c 89, 2 20. Sep 14:15 i2c-2 lrwxrwxrwx 1 root root 12 20. Sep 14:15 initctl -> /run/initctl drwxr-xr-x 3 root root 100 20. Sep 14:15 input crw-r--r-- 1 root root 1, 11 20. Sep 14:15 kmsg lrwxrwxrwx 1 root root 28 20. Sep 14:15 log -> /run/systemd/journal/ dev-log brw-rw 1 root disk 7, 0 20. Sep 14:15 loop0 ... crw-rw 1 root disk 10, 237 20. Sep 14:15 loop-control drwxr-xr-x 2 root root 60 20. Sep 14:15 mapper crw-r- 1 root kmem 1, 1 20. Sep 14:15 mem brw-rw 1 root disk179, 0 20. Sep 14:15 mmcblk0 brw-rw 1 root disk179, 1 20. Sep 14:15 mmcblk0p1 brw-rw 1 root disk179, 2 20. Sep 14:15 mmcblk0p2 drwxrwxrwt 2 root root 40 1. Jan 1970 mqueue drwxr-xr-x 2 root root 60 20. Sep 14:15 net crw-rw-rw- 1 root root 1, 3 20. Sep 14:15 null crw-r- 1 root kmem 1, 4 20. Sep 14:15 port crw--- 1 root root108, 0 20. Sep 14:15 ppp crw--- 1 root root 10, 1 20. Sep 14:15 psaux crw-rw-rw- 1 root tty 5, 2 23. Nov 16:00 ptmx drwxr-xr-x 2 root root 0 1. Jan 1970 pts crw-rw-rw- 1 root root 1, 8 20. Sep 14:15 random crw--- 1 root root 10, 242 20. Sep 14:15 rfkill drwxrwxrwt 2 root root 40 20. Sep 14:15 shm crw--- 1 root root 10, 231 20. Sep 14:15 snapshot drwxr-xr-x 3 root root 180 20. Sep 14:15 snd lrwxrwxrwx 1 root root 15 1. Jan 1970 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 1. Jan 1970 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 1. Jan 1970 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root tty 5, 0 20. Sep 14:15 tty ... crw-rw 1 root dialout 204, 64 22. Nov 18:59 ttyAMA0 crw-rw 1 root dialout 4, 64 20. Sep 14:15 ttyS0 crw-rw 1 root dialout 4, 65 20. Sep 14:15 ttyS1 crw-rw 1 root dialout 4, 66 20. Sep 14:15 ttyS2 crw-rw 1 root dialout 4, 67 20. Sep 14:15 ttyS3 crw-rw 1 root dialout 4, 68 20. Sep 14:15 ttyS4 crw--- 1 root root 10, 239 20. Sep 14:15 uhid crw--- 1 root root 10, 223 20. Sep 14:15 uinput crw-rw-rw- 1 root root 1, 9 20. Sep 14:15 urandom crw--- 1 root root 10, 126 20. Sep 14:15 userfaultfd crw--- 1 root root 10, 125 20. Sep 14:15 vchiq crw-rw 1 root tty 7, 0 20. Sep 14:15 vcs ... crw--- 1 root root 10, 127 20. Sep 14:15 vga_arbiter crw-rw 1 root kvm 10, 238 20. Sep 14:15 vhost-net crw-rw 1 root kvm 10, 241 20. Sep 14:15 vhost-vsock crw--- 1 root root 10, 130 20. Sep 14:15 watchdog crw--- 1 root root249, 0 20. Sep 14:15 watchdog0 crw-rw-rw- 1 root root 1, 5 20. Sep 14:15 zero root@raspi2:/dev# i have insert the Modules under etc/modules-load.d/modules.conf spi-bcm2835 spi-bcm2835aux spi-spidev i2c-dev i2c-bcm2835 the modul list under /lib/modules/6.1.0-13-armmp/kernel/drivers/spi insgesamt 528K -rw-r--r-- 1 root root 27K 29. Sep 06:15 spi-aspeed-smc.ko -rw-r--r-- 1 root root 15K 29. Sep 06:15 spi-bcm2835aux.ko -rw-r--r-- 1 root root 25K 29. Sep 06:15 spi-bcm2835.ko -rw-r--r-- 1 root root 9,4K 29. Sep 06:15 spi-butterfly.ko -rw-r--r-- 1 root root 30K 29. Sep 06:15 spi-cadence-quadspi.ko -rw-r--r-- 1 root root 34K 29. Sep 06:15 spi-imx.ko -rw-r--r-- 1 root root 9,0K 29. Sep 06:15 spi-lm70llp.ko -rw-r--r-- 1 root root 17K 29. Sep 06:15 spi-meson-spicc.ko -rw-r--r-- 1 root root 13K 29. Sep 06:15 spi-meson-spifc.ko -rw-r--r-- 1 root root 27K 29. Sep 06:15 spi-omap2-mcspi.ko -rw-r--r-- 1 root root 17K 29. Sep 06:15 spi-orion.ko -rw-r--r-- 1 root root 37K 29. Sep 06:15 spi-pl022.ko -rw-r--r-- 1 root root 12K 29. Sep 06:15 spi-pxa2xx-pci.ko -rw-r--r-- 1 root root 33K 29. Sep 06:15 spi
Bug#1056588: ftp.kaist.ac.kr(ftp.kr.d.o): Not listed in public mirror list
Hi, On Thu, 2023-11-23 at 23:57 +0900, 신도윤 wrote: > Hello, this is ftp.kaist.ac.kr (known as ftp.kr.debian.org) manager. > > I checked that we are not listed in the public mirror list. > (https://www.debian.org/mirror/list) > But, we are already listed in the mirror-master list. > ( > https://mirror-master.debian.org/status/mirror-info/ftp.kaist.ac.kr.ht > ml) That's due to the mirror's current score on the status system (your later link) being 28. The public list is generated based on those mirrors with a score of at least 50. There isn't enough history on the web side at least to see why the score had dropped lower, but it is currently increasing, so it should make its way back on to the public list "soon". Regards, Adam
Bug#1056348: FTBFS: tests fail in clean environment
Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit : Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. OK, makes more sense then. Nevertheless I'm wondering about the seriousness of the bug, I can't reproduce on my environment and all the buildd environments where libssh2 is built don't have the problem. Could your issue be fixed by running something like this? USER=$LOGNAME dpkg-buiildpackage I'm just wondering if the patch is worth applying it to fix a less probable case. /Nicolas
Bug#1056590: dh_movetousr: consider updating symlink targets
Package: debhelper Version: 13.11.4 Severity: normal X-Debbugs-Cc: Helmut Grohne Owner: Helmut Grohne I tried adding "Build-Depends: dh-sequence-movetousr" to parted. The build was apparently successful, but lintian warned me: W: libparted-fs-resize0: lacks-unversioned-link-to-shared-library example: usr/lib/x86_64-linux-gnu/libparted-fs-resize.so [usr/lib/x86_64-linux-gnu/libparted-fs-resize.so.0.0.5] W: libparted2: lacks-unversioned-link-to-shared-library example: usr/lib/x86_64-linux-gnu/libparted.so [usr/lib/x86_64-linux-gnu/libparted.so.2.0.5] This is because libparted-dev has a /usr/lib/x86_64-linux-gnu/libparted.so -> /lib/x86_64-linux-gnu/libparted.so.2 symlink (and similar for libparted-fs-resize.so), but libparted2 now ships /usr/lib/x86_64-linux-gnu/libparted.so.2 instead. Technically this is fine since the /lib -> /usr/lib symlink is now mandatory, but lintian apparently doesn't know that, and I think it's rather confusing. We ought to either change lintian to not warn about this, or change dh_movetousr to fix up the symlinks; either way, developers shouldn't see a warning here. Talking to Helmut at the mini-Debconf in Cambridge, we went back and forth a bit but his gut feeling appeared to be that it would make sense to at least experiment with having dh_movetousr update symlink targets, so I'm filing this bug as a reminder. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1056591: acedb FTBFS against glibc 2.38
Package: acedb
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
Trying to build with glibc 2.38 fails with the following error:
../wh/utils.h:34:7: error: conflicting types for ‘strcasestr’; have ‘char
*(char *, char *)’
34 | char *strcasestr (char *str1, char *str2);
| ^~
In file included from ../wh/mystdlib.h:227,
from ../wh/regular.h:51,
from utils.c:37:
/usr/include/string.h:380:14: note: previous declaration of ‘strcasestr’ with
type ‘char *(const char *, const char *)’
Before glibc 2.38, the strcasestr function was only made available when
building with _GNU_SOURCE. Starting with glibc 2.38, the function is
available by default.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix build against glibc 2.38 (LP: #2044385)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch
acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch
--- acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch1970-01-01
01:00:00.0 +0100
+++ acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch2023-11-23
16:07:13.0 +0100
@@ -0,0 +1,47 @@
+Description: Fix build against glibc 2.38
+ In previous glibc versions, strcasestr would only be available if building
+ with _GNU_SOURCE.
+ Starting with glibc 2.38, strcasestr is now available by default.
+ Ensure that acedb does not redefine the function if we're building with a
modern glibc.
+Author: Olivier Gayot
+Bug:
+Bug-Ubuntu: https://launchpad.net/bugs/2044385
+Forwarded: no
+Last-Update: 2023-11-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: acedb-4.9.39+dfsg.02/w1/utils.c
+===
+--- acedb-4.9.39+dfsg.02.orig/w1/utils.c 2005-10-04 15:15:00.0
+0200
acedb-4.9.39+dfsg.02/w1/utils.c2023-11-23 16:48:20.118800952 +0100
+@@ -774,7 +774,7 @@
+ //
+ /* case-insensitive version of strstr */
+
+-#ifndef DARWIN
++#ifndef HAS_STRCASESTR
+ char *strcasestr(char *str1, char *str2)
+ {
+ g_strup(str1);
+Index: acedb-4.9.39+dfsg.02/wh/utils.h
+===
+--- acedb-4.9.39+dfsg.02.orig/wh/utils.h 2023-11-23 16:19:02.454527757
+0100
acedb-4.9.39+dfsg.02/wh/utils.h2023-11-23 16:47:40.099066905 +0100
+@@ -29,7 +29,16 @@
+ *---
+ */
+
+-#ifndef DARWIN
++/* Ensure that features.h or an equivalent is included. */
++#include
++
++#if defined(DARWIN) || defined(_GNU_SOURCE)
++# define HAS_STRCASESTR
++#elif __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 38
++# define HAS_STRCASESTR
++#endif
++
++#ifndef HAS_STRCASESTR
+ /* case-insensitive version of strstr */
+ char *strcasestr (char *str1, char *str2);
+ #endif
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/series
acedb-4.9.39+dfsg.02/debian/patches/series
--- acedb-4.9.39+dfsg.02/debian/patches/series 2023-08-15 16:23:13.0
+0200
+++ acedb-4.9.39+dfsg.02/debian/patches/series 2023-11-23 16:07:13.0
+0100
@@ -13,3 +13,4 @@
glibc2.32.patch
# drop_gtk2.patch
just_build_efetch.patch
+glibc-2.38.patch
Bug#1027263: #1027263 pending, fixed in git
tags 1027263 pending thanks Fixed with https://salsa.debian.org/debian/mini-dinstall/-/commit/ad12a309987683f89d7e6ac70defbc38b9d44c81
Bug#1056348: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 10:46:34AM -0500, Nicolas Mora wrote: >Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit : >> >> Ah, apologies - that version is bogus, it's just the version on the >> bullseye machine I ran reportbug from. >> >> The tests are failing on current unstable source. >> > >OK, makes more sense then. > >Nevertheless I'm wondering about the seriousness of the bug, I can't >reproduce on my environment and all the buildd environments where libssh2 is >built don't have the problem. AFAICS in a non-interactive environment, USER isn't required to be set but LOGNAME is; see https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Alternatively, the tets should probably be calling get(e)uid and getpwent() rather than relying on the environment here. >Could your issue be fixed by running something like this? >USER=$LOGNAME dpkg-buiildpackage > >I'm just wondering if the patch is worth applying it to fix a less probable >case. The tests failed in a CI system we use at work, so I needed to fix it there. The patch just adds fallback here, and makes things more robust. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#1056592: debos: yaml: line X: did not find expected key
Package: debos
Version: 1.1.2-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Hi Christopher,
Here's a surprising bug report. The version of debos currently in Debian
unstable is a bit broken, in an odd way.
Consider the following recipe:
```
$ cat main.yaml
{{ $ospack := or .ospack "debian" }}
architecture: amd64
actions:
- action: debootstrap
suite: sid
- action: pack
file: {{ $ospack }}.tar.gz
```
If I run with `-t ospack:debian` it fails:
```
$ debos --print-recipe -t ospack:debian main.yaml
2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:05:27
architecture: amd64
actions:
- action: debootstrap
suite: sid
- action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos --template-var 'ospack:"debian"'
/home/user/debos/main.yaml using kvm backend
2023/11/23 16:05:31 yaml: line 6: did not find expected key
```
However if I run without `-t`, it succeeds:
```
$ debos --print-recipe main.yaml
2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:10:55
architecture: amd64
actions:
- action: debootstrap
suite: sid
- action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml using
kvm backend
2023/11/23 16:10:59 debootstrap
2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
[...]
```
Another surprise: this is a regression introduced by package 1.1.2-2. If
I downgrade to version 1.1.2-1, everything works fine.
```
sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
```
I compared the Built-Using fields between both packages:
```
-golang-1.21 (= 1.21.1-1)
+golang-1.21 (= 1.21.4-1)
+golang-github-alessio-shellescape (= 1.4.1-3)
golang-github-cespare-xxhash (= 2.1.1-2)
golang-github-docker-go-units (= 0.4.0-4)
-golang-github-go-debos-fakemachine (= 0.0.6-1)
+golang-github-go-debos-fakemachine (= 0.0.7-1)
golang-github-google-uuid (= 1.3.0-1)
-golang-github-klauspost-compress (= 1.15.12+ds1-3)
+golang-github-klauspost-compress (= 1.17.2+ds1-1)
golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
golang-github-ulikunitz-xz (= 0.5.6-2)
golang-go-flags (= 1.4.0-6)
-golang-golang-x-sys (= 0.9.0-1)
+golang-golang-x-sys (= 0.13.0-1)
golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
golang-yaml.v2 (= 2.4.0-4)
```
I suppose the regression was introduced by one of the dependencies that
changed. I have no idea how to troubleshot that... Tomorrow I'll try to
rebuild a package to see if that magically fixes it.
Can you try to reproduce this issue on your side, just to confirm?
Thanks in advance,
Arnaud
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 debos depends on:
ii busybox1:1.36.1-4
ii debootstrap1.0.133
ii libc6 2.37-12
ii libglib2.0-0 2.78.1-4
ii libostree-1-1 2023.7-3
ii qemu-system-x861:8.1.2+ds-1
ii qemu-user-static 1:8.1.2+ds-1
ii systemd-container 255~rc2-1
Versions of packages debos recommends:
ii bmap-tools 3.7-1
ii bzip2 1.0.8-5+b1
ii dosfstools 4.2-1
ii e2fsprogs 1.47.0-2+b1
ii fdisk 2.39.2-6
ii linux-image-amd64 6.5.10-1
ii mount 2.39.2-6
ii ovmf 2023.05-2
ii parted 3.6-3
ii systemd-resolved 255~rc2-1
ii udev 255~rc2-1
ii xz-utils 5.4.4-0.1
ii zip3.0-13
Versions of packages debos suggests:
pn libslirp-helper
pn user-mode-linux
-- no debconf information
Bug#1056592: debos: yaml: line X: did not find expected key
Hi Arnaud,
On Thu, 2023-11-23 at 23:23 +0700, Arnaud Rebillout wrote:
> Package: debos
> Version: 1.1.2-2
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
>
> Hi Christopher,
>
> Here's a surprising bug report. The version of debos currently in Debian
> unstable is a bit broken, in an odd way.
>
> Consider the following recipe:
>
> ```
> $ cat main.yaml
> {{ $ospack := or .ospack "debian" }}
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: {{ $ospack }}.tar.gz
> ```
>
> If I run with `-t ospack:debian` it fails:
>
> ```
> $ debos --print-recipe -t ospack:debian main.yaml
> 2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:05:27
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos --template-var
> 'ospack:"debian"' /home/user/debos/main.yaml using kvm backend
> 2023/11/23 16:05:31 yaml: line 6: did not find expected key
> ```
For me with debos 1.1.2-2, I seem to reproduce your issue:
Running /debos --artifactdir debos-tests --template-var 'ospack:"debian"'
debos-tests/test-key.yaml using kvm backend
2023/11/23 16:41:30 yaml: line 7: did not find expected key
But with a local checkout of debos upstream built with `go build`, your recipe
runs just fine (notice there are now no single-quotes around the --template-
var argument to the inner debos call):
Running /debos --artifactdir debos-tests --template-var ospack:debdfsa
debos-tests/test-key.yaml using kvm backend
2023/11/23 16:41:46 debootstrap
I think this has something to do with the recent shell escaping patches.
Perhaps there is some go module which isn't up to date in Debian causing the
additional single quotation marks around the inner debos call ?
> However if I run without `-t`, it succeeds:
>
> ```
> $ debos --print-recipe main.yaml
> 2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:10:55
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml
> using kvm backend
> 2023/11/23 16:10:59 debootstrap
> 2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
> 2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
> [...]
> ```
>
> Another surprise: this is a regression introduced by package 1.1.2-2. If
> I downgrade to version 1.1.2-1, everything works fine.
>
> ```
> sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
> ```
>
> I compared the Built-Using fields between both packages:
>
> ```
> -golang-1.21 (= 1.21.1-1)
> +golang-1.21 (= 1.21.4-1)
> +golang-github-alessio-shellescape (= 1.4.1-3)
> golang-github-cespare-xxhash (= 2.1.1-2)
> golang-github-docker-go-units (= 0.4.0-4)
> -golang-github-go-debos-fakemachine (= 0.0.6-1)
> +golang-github-go-debos-fakemachine (= 0.0.7-1)
> golang-github-google-uuid (= 1.3.0-1)
> -golang-github-klauspost-compress (= 1.15.12+ds1-3)
> +golang-github-klauspost-compress (= 1.17.2+ds1-1)
> golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
> golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
> golang-github-ulikunitz-xz (= 0.5.6-2)
> golang-go-flags (= 1.4.0-6)
> -golang-golang-x-sys (= 0.9.0-1)
> +golang-golang-x-sys (= 0.13.0-1)
> golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
> golang-yaml.v2 (= 2.4.0-4)
> ```
>
> I suppose the regression was introduced by one of the dependencies that
> changed. I have no idea how to troubleshot that... Tomorrow I'll try to
> rebuild a package to see if that magically fixes it.
>
> Can you try to reproduce this issue on your side, just to confirm?
>
> Thanks in advance,
>
> Arnaud
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 debos depends on:
> ii busybox 1:1.36.1-4
> ii debootstrap 1.0.133
> ii libc6 2.37-12
> ii libglib2.0-0 2.78.1-4
> ii libostree-1-1 2023.7-3
> ii qemu-system-x86 1:8.1.2+ds-1
> ii qemu-user-static 1:8.1.2+ds-1
> ii systemd-container 255~rc2-1
>
> Versions of packages debos recommends:
> ii bmap-tools 3.7-1
> ii bzip2 1.0.8-5+b1
> ii dosfstools 4.2-1
> ii e2fsprogs 1.47.0-2+b1
> ii fdisk 2.39.2-6
> ii linux-image-amd64 6.5.10-1
> ii mount 2.39.2-6
> ii ovmf 2023.05-2
> ii parted 3.6-3
> ii systemd-resolved 255
Bug#1056593: transmission-remote-gtk: upstrean LOCALEDIR envvar bug avoids loading locale file
Package: transmission-remote-gtk Version: 1.5.1-1 Severity: normal Tags: l10n upstream X-Debbugs-Cc: cano...@9online.fr Dear Maintainer, The current version has a bug which prevents loading the appropriate locale file, so transmission-remote-gtk isn't translated for non-english-speaking users. Upstream fixed this bug in the 1.6.0 version with the following commit : https://github.com/transmission-remote-gtk/transmission-remote-gtk/commit/af7d3d78388da19b691d8773adaa0d5cd7c1b456 Please consider adding this commit to the current package. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.utf8), LANGUAGE=fr_FR Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-remote-gtk depends on: ii libc62.36-9+deb12u3 ii libcurl4 7.88.1-10+deb12u4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgeoip11.6.12-10 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libjson-glib-1.0-0 1.6.6-1 ii libpango-1.0-0 1.50.12+ds-1 ii libproxy1v5 0.4.18-1.2 transmission-remote-gtk recommends no packages. transmission-remote-gtk suggests no packages.
Bug#864824: claws-mail: If i have 2 mailbox, Claws-Mail always put my sent messages in the first one.
On Thu, 23 Nov 2023 14:58:08 +0100 Marco Moock wrote: > This is something that looks like a general bug in Claws (if it still > occurs in current Claws version) and should be discussed in > us...@lists.claws-mail.org mailing list or reported in the bugtracker: > https://www.thewildbeast.co.uk/claws-mail/bugzilla/index.cgi This is looking like user-error to me. with regards Paul
Bug#1056594: mat2: test failure
Source: mat2 Version: 0.13.4-2 Severity: serious Tags: upstream patch ftbfs Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Currently mat2's test suite fails, maybe due to newer libimage-exiftool-perl releases. This can be seen on ci.debian.net, but the same failures occur during the build tests, so the package FTBFS. I've locally added upstream commit https://0xacab.org/jvoisin/mat2/-/commit/bbd5b2817c9d64013e2f5ed670aca8d4738bb484 as a quilt patch, and the tests pass both during build and autopkgtest. Cheers, gregor -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmVfhfFfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgbGDw/+IvB5zN2PAQj7XFfbyVvqdjr3JIp7krnucMzO+qBemoFW2BdVptGFawgD XrEn2nj5XtKmG3EKLnqKjevLLeAcgFILEviUa0U1tM+/2pJkHiFC7J3eK5x8ug+9 JRjLVEh3WpG3vdBbvsOQ52B7xurqahfU9ReqR8Awnd/dQUXYycWgei/CUC320KRS bfuRPcbsR+ibwspLD+3iw8oezikr/WCzXyYjffASJYQDyp7D+LOpHGVfHfFYAVt0 xJby75cKpq0AcMC2Rgg8JYYK0GJ/RJ4a8jptXohl8hcEA8w6htYxUiedA0eaikS3 9t9o2/7yZObpd3TYmpuoGRz00cpQ3bEYATZlYALs1umoCp9WsOjJ8by8tnHKZxUa 7jOfdRhTRF0rkwZ07LoneMFg966HaDTAQeN0TMHKLYvShY7hyVFNf+1AD02qqP8x +guJ2YQw7U5mu4aEJtNvUXv1Pqh8Hl9hbiQNn23yL8IoCvfDzZUAqaEzRmLYjVt2 Ujoj6LHZgOZsBprIEBMch86MgyL65CeCzJr6JZ8wZmb/b//rPcVAv/VElTs+GfzS Ka8qQygGzvulrIsA2t0loJG7QtwRcZk6ckaCq/2IVvgDpFf4UCIOGnAt2qtt0+Ak Xy9Wb0YgnrY0v7BeTMZ+XU5LzWHqWLmj1d3PDvmy+sp9elbUgRU= =mYNd -END PGP SIGNATURE-
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote: > Source: u-boot > Version: 2023.07+dfsg-1 > Severity: wishlist > X-Debbugs-CC: Tobias Heider , Andreas Henriksson > > > Dear Maintainer, > > I'm opening this bug report to discuss the potential of building another > u-boot variant in a new binary package from src:u-boot for "Apple > Silicon" machines. > > The Asahi Linux project has been working on bringing Linux to the newer > ARM based line of laptops and stationary (mac mini) by Apple, a.k.a. > M1, M2 and just released generation M3. > > > # The overall picture of booting Linux on apple silicon > > A normal users boot procedure would look something like: > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) > -> generic distro EFI boot managers (grub, systemd-boot, etc) > > > m1n1 stage1 is installed by the Asahi Linux installer. > m1n1 stage2 + u-boot + dtbs are bundled together and installed > as boot.bin on the EFI partition. > > Apple/macOS does not make use of EFI. The purpose of u-boot is to > provide the EFI environment to allow "generic distro boot". > > m1n1 stage2 is already in debian, see: > https://tracker.debian.org/m1n1 > > > # Upstream status > > The Asahi Linux project has already upstreamed most of their work > so simply building `apple_m1_defconfig` is already possible. > However they also maintain their own fork of it at: > https://github.com/AsahiLinux/u-boot/tree/asahi-releng > This fork currently contains 43 additional patches > (some already upstreamed, some posted for review, some > simply defconfig changes, some dts updates, etc). > > I've looked over the 43 patches and here's my *perception* > of the current status: > > The current upstream apple_m1_defconfig should be usable > for booting (from internal storage) on M1 machines. > > The M2 can possibly boot, but keyboard driver is not yet > upstream - so no interaction with u-boot possible. > > M3 is not yet supported at all by Asahi Linux (the usual notice of > expect atleast 6 months before this happens has been announced). > > > Notable here is that Apple iBoot does not support USB booting, > so booting from external media will have to be happening with > the help of U-Boot. Unfortunately U-Boot USB support has a number of > as I understand it generic bugs that pretty much prevents real-world > usage, eg. not support >2TB usb drives, etc. > Patches to fix these problems has been posted for review (with mostly > positive feedback): > https://lists.denx.de/pipermail/u-boot/2023-October/535517.html > https://lists.denx.de/pipermail/u-boot/2023-October/535529.html > https://lists.denx.de/pipermail/u-boot/2023-October/535534.html > https://lists.denx.de/pipermail/u-boot/2023-October/535535.html > > This is the bulk of the code changes outside apple specific files > in the current 43 patch series living in asahi fork of u-boot. > > There was previously also an attempt to upstream the Apple Type-C PHY > dummy driver: > https://lists.denx.de/pipermail/u-boot/2023-July/522961.html > > > Some of the patches updates devicetree files (dts) which are > completely apple-specific and should not have any chance to affect > anything else, but these are also completely unused so does not > neccessarily need to be included. > The asahi tools to update the EFI boot.bin that combines m1n1, > u-boot and dtbs uses the dtbs from the installed kernel, see: > https://tracker.debian.org/asahi-fwextract > https://tracker.debian.org/asahi-scripts > > > > > # considerations > > 1/ are we willing to add another binary package to src:u-boot >building apple_m1_defconfig? > > 2/ should we name the binary package u-boot-apple or -asahi? >The existing third-party packages of the asahi fork calls >theirs u-boot-asahi. > > 3/ do we include patches? > 3.1/ No patches. If this is the desired path I can volunteer > to test that it boots on my M1 machine. Other machines > should probably be considered unsupported for now, > even though they might have limited usefulness. > 3.2/ Minimal set of patches. We identify what we consider > crutial only patches and recruit volunteers to test. > M2 keyboard? USB? etc... > 3.3/ All asahi patches. We consider it simpler to just sync all patches > with the asahi fork (even though some are even unused, like the > devicetree patches). We trust the Asahi Linux project in their > quest to upstream all their work and that they will rebase on newer > releases and make our job easy. Thank you for the detailed write-up! I think you are right, a new binary package based on the existing u-boot is certainly preferable over having a separate source package. It also looks like there is progress in getting the changes merged upstream. My preferred choices would be 1/ yes, 2/ u-boot-asahi and 3.2/ because keyboard support in u-boot actually is important to boot usb disks if you break your system and that patch shouldn't be hu
Bug#992180: MR with fix available Re: openmm FTBFS on amd64/arm64/ppc64el
On Sun, 15 Aug 2021 12:11:53 +0300 Adrian Bunk wrote: > Source: openmm > Version: 7.5.1+dfsg-1 > Severity: important > Tags: ftbfs > > https://buildd.debian.org/status/package.php?p=openmm&suite=sid > > ... > /<>/openmmapi/include/openmm/internal/vectorize_sse.h:38:10: fatal error: smmintrin.h: No such file or directory > 38 | #include > | ^ > compilation terminated. > make[4]: *** [platforms/cpu/sharedTarget/CMakeFiles/OpenMMCPU.dir/build.make:98: platforms/cpu/sharedTarget/CMakeFiles/OpenMMCPU.dir/__/src/CpuCustomGBForce.cpp.o] Error 1 > > > Nice to have would be a vectorize_generic.h (or using simde), > not sure whether upstream would be interested in doing that. Hello, I opened the merge request below to add SIMDe to this package; I tested on the riscv64 porterbox where the build succeeded, included tests. Likewise on my personal amd64 laptop. https://salsa.debian.org/debichem-team/openmm/-/merge_requests/1 It won't fix the FTBFS on armel / armhf; that's due to them being detected as arm64 and inappropriate NEON intrinsics being used -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056321: elogind conflicts with same version libelogind
Wouldn't it be better, or at least more elegant, to turn libelogind0 into a dummy transitional package that pulls in libsystemd0? Here's the result of trying to install elogind using the apt front end. $ sudo apt install -t testing elogind Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt : Depends: libapt-pkg6.0 (>= 2.7.6) but it is not going to be installed elogind : Depends: dbus (>= 1.9.14) Conflicts: libelogind0 but 246.10-1debian1 is to be installed Recommends: polkitd # [etc] I must note that the aptitude frontend is able to install elogind using the default solution No. 1. $ sudo aptitude install -t testing elogind # [etc] Install the following packages: 1) libsystemd0 [254.5-1 (testing)] Accept this solution? [Y/n/q/?] On the other hand, an "apt full-upgrade" will automatically remove elogind and replace it with systemd, which is NOT what a user that's installed elogind would want. (An "apt upgrade" will abort with an "unmet dependencies" conflict.)
Bug#1056595: dgit: must not override dpkg include lists
Package: dgit Severity: important X-Debbugs-Cc: j...@debian.org dgit overrides the include lists for dpkg, causing packages to include additional .gitignore and similar files which dpkg-source -b will exclude. This creates a significant hurdle to the NMU process and downstream distribution maintainers who have to figure out how to reduce the delta again, because in both cases, unrelated changes should not be present in the diff between the two uploads. Like I had to spend about 20 minutes or so today trying to figure out how to actually get that sorted out for a native package (I was trying -i all the time when I should have passed -I), in turn I discovered some other process issues but that's beside the point :D -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble'), (500, 'mantic-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-10-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.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 dgit depends on: ii apt2.7.6 ii ca-certificates20230311ubuntu1 ii coreutils 9.1-1ubuntu2 ii curl 8.4.0-2ubuntu1 ii devscripts 2.23.6build1 ii dpkg-dev 1.22.1ubuntu2 ii dput 1.1.3ubuntu3 ii git [git-core] 1:2.40.1-1ubuntu1 ii git-buildpackage 0.9.32 ii libdpkg-perl 1.22.1ubuntu2 ii libjson-perl 4.1-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-6 ii libtext-csv-perl 2.03-1 ii libtext-glob-perl 0.11-3 ii libtext-iconv-perl 1.7-8 pn libwww-curl-perl ii perl [libdigest-sha-perl] 5.36.0-9ubuntu1 Versions of packages dgit recommends: ii distro-info-data 0.59 ii liburi-perl 5.21-1 ii openssh-client [ssh-client] 1:9.4p1-1ubuntu1 Versions of packages dgit suggests: ii cowbuilder 0.89 ii pbuilder0.231build1 ii sbuild 0.85.2ubuntu1 -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1030895: qt6-webengine: Enable riscv64 support
Hi, On 21/11/23 06:06, Bo YU wrote: [snip] Let's start here again, okay? :) I just refactor these patches, which should not affect building of other architectures except riscv64. And still we have a 14k+ lines debdiff to apply. My apologies, this is a huge NACK. Get it supported by upstream first and then we can talk.
Bug#1049995: openssh: catalan translation [INTL:ca]
On Fri, Aug 18, 2023 at 04:37:50AM +0200, Pablo Huguet wrote: > I did the catalan translation of it, and I will add the translation is > included > thanks for reading! Hi, Thanks for the translation! However, it contains syntax errors: $ msgmerge -U debian/po/ca.po debian/po/templates.pot debian/po/ca.po:41:59: syntax error debian/po/ca.po:57:27: syntax error msgmerge: found 2 fatal errors Could you please fix these? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1056596: lintian could check if source is NMUable / doesn't cause delta due to non-standard dpkg source options
Package: lintian Severity: wishlist X-Debbugs-Cc: j...@debian.org In Bug##1056595 I outlined how dgit overrides dpkg filters and files like .gitignore appear in tarballs, meaning that if you download the .dsc and try to NMU it, your NMU suddenly misses a lot of files. lintian should check that dpkg-source -x && dpkg-source -b does not * add additional files * remove files * modify files Arguably it may be reasonable to parse the Perl bindings in dpkg to get the ignore list and just check that we don't ship any ignored files. Likewise it can ensure that other options like compression of the tarball matches the dpkg options for that package, i.e. archive defaults or debian/source/options. Maybe this is better solved in something like piuparts, I don't know. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1056597: ffmpeg: drawtext filter missing from ffmpeg binaries
Package: ffmpeg
Version: 7:6.1-4
Severity: normal
Dear Maintainer,
The FFmpeg binaries (i.e. ffplay and ffmpeg) no longer
provides the drawtext filter, useful for embedding text (such
as subtitles and time codes) into a video.
Here's a simple test command using a legally available video.
$ ffplay -i
https://static.fsf.org/nosvn/videos/escape-to-freedom/videos/escape-to-freedom-720p.webm
-vf "drawtext=x=20:y=20:fontsize=24:fontcolor=gold:text='%{localtime \: %T
%Z%n(%F)}'"
The relevant portion of stderr from this command is this:
[AVFilterGraph @ 0x7f6ae4003e40] No such filter: 'drawtext'
[AVFilterGraph @ 0x7f6ae4003e40] Error processing filtergraph: Filter not found
A shallow search for a similar bug turns up the following link
from the ArchLinux bug tracker ("drawtext filter not available",
dated "Wednesday, 22 November 2023, 15:17 GMT"):
https://bugs.archlinux.org/task/80327
The recommended solution is to recompile FFmpeg with the
"--enable-libharfbuzz" option. There is a libharfbuzz-dev
package in Debian, so this should not be a problem (assuming
the ArchLinux bug report is correct).
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Versions of packages ffmpeg depends on:
ii libavcodec607:6.1-3
ii libavdevice60 7:6.1-3
ii libavfilter97:6.1-3
ii libavformat60 7:6.1-3
ii libavutil58 7:6.1-3
ii libc6 2.37-12
ii libpostproc57 7:6.1-3
ii libsdl2-2.0-0 2.28.5+dfsg-2
ii libswresample4 7:6.1-3
ii libswscale7 7:6.1-3
Bug#1056595: dgit: must not override dpkg include lists
Severity: -1 normal
Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg include
lists"):
> dgit overrides the include lists for dpkg, causing packages to include
> additional .gitignore and similar files which dpkg-source -b will
> exclude.
Yes.
This is necessary (1) so that the git trees correspond precisely to
the .dscs (which is the invariant of the dgit git view), and
(2) to comply with our promise to provide people with the source code.
I consider dpkg-source's behaviour, of excluding .gitignore by default,
to be wrong:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
(You may recall that report, since you commented on it.)
> This creates a significant hurdle to the NMU process and downstream
> distribution maintainers who have to figure out how to reduce the
> delta again, because in both cases, unrelated changes should not
> be present in the diff between the two uploads.
I'm afraid I don't understand your scenario precisely. I'm
sympathetic to the goal of removing hurdles for NMUers and downstream
maintainers.
> Like I had to spend about 20 minutes or so today trying to figure out
> how to actually get that sorted out for a native package (I was trying
> -i all the time when I should have passed -I), in turn I discovered
> some other process issues but that's beside the point :D
Were you trying to use dgit to make an NMU? If so what git branch
did you start with? What options did you give to dgit?
Or, are you the maintainer? In which case, I'd like to know more
about what went wrong. Did some NMUer using dgit make an upload that
is causing you trouble?
As background:
I generally recommend that someone doing an NMU which they intend to
upload with dgit, also obtain their baseline package with dgit. Eg,
see
https://manpages.debian.org/bookworm/dgit/dgit-nmu-simple.7.en.html
I recommend that users should *not* use the semi-official Debian git
sources because they're not suitable for non-Debian-experts:
https://diziet.dreamwidth.org/9556.html
Of course if - like you do - you know what you're doing, then you can
start from (eg) a salsa branch. But then I'm afraid that this problem
with .gitignore may be just another one of the strange Debian things
that you have to know.
Even so, I'm open to ideas of ways to make this wrinkle less annoying.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators
> > One more clarifying question: > > > > > > Thus a third thing the README could advise on is how Debian Developers > > > > and > > > > Debian sysadmins are advised to build CI systems and test upgrade paths > > > > for > > > > the next 10 years as what worked in the past 10 years does not apply > > > > as-is > > > > anymore. > > > People using CI systems will get an updated debootstrap in the next > > > point release and everything will be fine. > > > > Do you refer above to the next Bookworm point update (scheduled on Dec > > 9th according to https://release.debian.org/) or do you mean in > > general that all CI upgrades tests will start working after the next > > point release of both Bookworm and Bullseye and Buster? > > > > I am currently struggling to grasp how I should get for example > > MariaDB 10.5 / Buster to MariaDB 10.11 / Bookworm testing running > > again as usrmerge 38 removed the workaround the CI was relying on. > > Example of current CI run: > > https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/4945062. > > Are you saying that a point release of Buster is going to do something > > that CI systems can continue to operate? > > Just create the chroot for the CI with --merged-usr and all will be > fine. Debootstrap in Buster is not going to be updated to do it > automatically, only in Bookworm/Bullseye. Thanks Luca for clarification. So seems we need to get bookworm removed from https://github.com/debuerreotype/debuerreotype/blob/60b625d1ce31bd81525bb67fc3a33f9686bc3433/examples/debian.sh#L183 so that the 'debuerreotype' will run debootstrap for both bookworm and bullseye with '--usr-merged'. Once that is done, we need to wait for to the code in https://github.com/debuerreotype/docker-debian-artifacts/tree/dist-amd64 to run to generate new images of official Debian Docker images at https://hub.docker.com/_/debian. This will fix upgrade testing from Bullseye to Bookworm if I understood correctly. Later the same needs to be done for other Debian derivatives as well (see https://github.com/search?q=repo%3Adebuerreotype%2Fdebuerreotype%20merged-usr&type=code). For that to be done somebody first needs to research what version of each derivative adopted usrmerge version 38, and for Ubuntu and others that carry patches we need to have researched and documented if those patches are material and change the distro release versions when usrmerge is forced or workaround (of usrmerge 38) is removed. And the usrmerge README should definitely be extended to be very clear about that globally everyone who administers Debian systems and have any kind of CI system to test upgrades no longer can do it for Buster to Bookworm tests. While Debian policy always has stated that jumping releases is not possible, it has in practice been possible and now with usrmerge 38 that expectation has a hard reset.
Bug#1056598: librust-trust-dns-resolver-dev: impossible to build with feature dns-over-https-rustls
Package: librust-trust-dns-resolver-dev
Version: 0.22.0-3
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Building with feature "dns-over-https-rustls" fails like this:
error[E0433]: failed to resolve: use of undeclared crate or module
`rustls_native_certs`
-->
/build/sccache-0.7.3/debian/cargo_registry/trust-dns-resolver-0.22.0/src/tls/dns_over_rustls.rs:31:21
|
31 | for cert in rustls_native_certs::load_native_certs().expect("could
not load platform certs") {
| ^^^ use of undeclared crate or module
`rustls_native_certs`
For more information about this error, try `rustc --explain E0433`.
error: could not compile `trust-dns-resolver` due to previous error
The package contains patch use-native-certs.patch which changes feature
"dns-over-rustls" to stop trigger feature (and implicit package
dependency) "webpki-roots".
When not simply removing that, but instead triggering feature/crate
"rustls-native-certs", the build succeeds.
Please adjust the patch accordingly.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVfmZsACgkQLHwxRsGg
ASEazhAArEahifiW09+ZyjgV4Zn7FOJLS0hgatbKv724mtszJ5W2SMm6BqzO4aM5
mNmAvU6WaA5BTzDu5resNt8P6BQ+9gAnE6qeiFyvIJz8g7CdYVeXXxnXR0Gw9Uqt
UYGBCKzKgC0tzgXsT/259hKswWL0myTY/KM9y+JPdnEf0ycLLj/utRn4XqLMcYQz
CCjU+g8lsIgjCYi3lz+QAV9+A45f8NJrz+kYkg5l3dLNLLunKYiV+uCq2YwtL4s2
nR/Zxoj3uodY06axhX3LRyEXWQGDZzy2RMmo5RXhUkKHaUHCLFrW/S2PeuX3w5pK
hg/Bt26JsEk1smRvi4Kw2RaNBio7BgONfv+5if9qM5m83Q/ifOQiJcDEY5kItnAN
T/RsE/1rYPl1Rm8YxBxp59NVJqZJXZl8rMgJZUV7whG+0MWeLIr4AbpXyNC/B/Jk
u7JtbTOHP1fBTekMcCWorcUMLIGaiEoNfGbyz0zaEx2GFL8mm3mUPZeM8OmNFVIz
/ROv0Gs4TxQ/99+EN9JiBJBzrMpOsYFBxWy/ZMJ0MRE9uPRhcC24QrIF3Akb32LB
4qNBYGcsybaaSDv140BOMPMPa+HDr9yc4CTW4AdiN5JhE02n4Ll+aDPKuGnxGf6T
Rq+1nDUuLybt0Sa1dJ2JrGN6EWdckJPzx+rvnRUiQPGzoH4jHTg=
=HRXm
-END PGP SIGNATURE-
Bug#1056348: FTBFS: tests fail in clean environment
Le 2023-11-23 à 11 h 20, Steve McIntyre a écrit : AFAICS in a non-interactive environment, USER isn't required to be set but LOGNAME is; see https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Alternatively, the tets should probably be calling get(e)uid and getpwent() rather than relying on the environment here. Indeed, I also had the same conclusion using other documentation. But then, if LOGNAME is mandatory, I suppose it would be better to use $LOGNAME alone instead of the condition. (I'm not refusing your patch, I just try to see if there's a better and cleaner way to fix it) I'll open a bug upstream to get their feedback on this /Nicolas
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code Xiyue Deng writes: [snip] >[ Xiyue Deng ] >* Sync to latest upstream head (5d7cf21). Have you asked upstream to tag a release? >* Override clean rules in d/rules to fix building. (Closes: >#1052917) I believe you already know that override_dh_auto_clean: /bin/true is an incorrect approach. >* Modernize d/watch using special substitute strings. Ok, but why? >* Add more metadata in d/upstream/metadata. https://github.com/hvesalai/emacs-scala-mode/commits/master is a git history log, not a changelog nor release notes. >* Update year and Upstream-Contact and add myself in d/copyright. Why did you add yourself? https://en.wikipedia.org/wiki/Threshold_of_originality I'm happy to support your claim, but you'll need to work for it in more than a "sweat of the brow"/mechanical sense. >* Use xz compression in d/gbp.conf. Why is this useful when it has been the default since gbp 0.9.15? Best, Nicholas signature.asc Description: PGP signature
Bug#1056599: node-proxy-agents: FTBFS with internet disabled
Source: node-proxy-agents
Version: 0~2023071921-1
Severity: serious
Hello, looks like the package tries to do calls to internet during build.
+ jest --testTimeout 5 --env node --moduleDirectories node_modules
--testRegex test/dnsDomainIs.test.ts test/dnsDomainLevels.test.ts
test/dnsResolve.test.ts test/isInNet.test.ts test/isPlainHostName.test.ts
test/isResolvable.test.ts test/localHostOrDomainIs.test.ts
test/shExpMatch.test.ts test/timeRange.test.ts
PASS test/shExpMatch.test.ts
PASS test/timeRange.test.ts
PASS test/localHostOrDomainIs.test.ts
(node:8627) [DEP0118] DeprecationWarning: The provided hostname "null" is not a
valid hostname, and is supported in the dns module solely for compatibility.
(Use `node --trace-deprecation ...` to show where the warning was created)
PASS test/isInNet.test.ts
FAIL test/dnsResolve.test.ts
● dnsResolve(host) › should return `true` for "www.netscape.com"
assert(received)
Expected value to be equal to:
true
Received:
false
12 | const res = await dnsResolve(input);
13 | if (expected) {
> 14 | assert(typeof res === 'string');
|^
15 | expect(isIP(res)).toEqual(4);
16 | } else {
17 | expect(res).toBeNull();
at test/dnsResolve.test.ts:14:11
PASS test/dnsDomainIs.test.ts
FAIL test/isResolvable.test.ts
● isResolvable(host) › should return `true` for "www.netscape.com"
expect(received).toEqual(expected) // deep equality
Expected: true
Received: false
9 | async ({ input, expected }) => {
10 | const res = await isResolvable(input);
> 11 | expect(res).toEqual(expected);
| ^
12 | }
13 | );
14 | });
at test/isResolvable.test.ts:11:16
PASS test/isPlainHostName.test.ts
PASS test/dnsDomainLevels.test.ts
Test Suites: 2 failed, 7 passed, 9 total
Tests: 2 failed, 37 passed, 39 total
Snapshots: 0 total
Time:4.549 s
Ran all test suites.
dh_auto_test: error: cd ./packages/pac-resolver && sh -ex
../../debian/nodejs/packages/pac-resolver/test returned exit code 1
make: *** [debian/rules:10: binary] Error 25
Gianfranco
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1056600: Please update adcli to 0.9.2
package: src:adcli version: 0.9.1-2 severity: wishlist Hi Laurent, If at all possible, could you please update adcli to 0.9.2? (tagged on Sep 28, 2023) Thanks, -- Mauricio Faria de Oliveira
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2023-11-23, Andreas Henriksson wrote: > I'm opening this bug report to discuss the potential of building another > u-boot variant in a new binary package from src:u-boot for "Apple > Silicon" machines. Thanks! I am guessing this class of hardware may represent a much larger community than many other boards already supported in u-boot. > # The overall picture of booting Linux on apple silicon > > A normal users boot procedure would look something like: > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) > -> generic distro EFI boot managers (grub, systemd-boot, etc) > > > m1n1 stage1 is installed by the Asahi Linux installer. > m1n1 stage2 + u-boot + dtbs are bundled together and installed > as boot.bin on the EFI partition. From u-boot 2023.10 doc/board/apple/m1.rst: $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho So, this suggests to me one has to pick exactly which .dtb to use which is presumably device-specific? Or is there some other process? I am guessing we would not be able to provide all the possible "u-boot.macho" permutations out of the box (unless it is a very small number of variants), but can probably ship all the relevent components as long as they are in debian main. If the .dtb files come from somewhere other than debian main, we would probably have to build it as a contrib package. > m1n1 stage2 is already in debian, see: > https://tracker.debian.org/m1n1 Great! > I've looked over the 43 patches and here's my *perception* > of the current status: > > The current upstream apple_m1_defconfig should be usable > for booting (from internal storage) on M1 machines. > > The M2 can possibly boot, but keyboard driver is not yet > upstream - so no interaction with u-boot possible. Ok, so worst case, there is at least one supported working platform even without patches? > Some of the patches updates devicetree files (dts) which are > completely apple-specific and should not have any chance to affect > anything else, but these are also completely unused so does not > neccessarily need to be included. > The asahi tools to update the EFI boot.bin that combines m1n1, > u-boot and dtbs uses the dtbs from the installed kernel, see: > https://tracker.debian.org/asahi-fwextract > https://tracker.debian.org/asahi-scripts Here is the crux of the question ... can it use the .dtb files from debian main or does it need .dtb files from some sources outside of debian? > # considerations > > 1/ are we willing to add another binary package to src:u-boot >building apple_m1_defconfig? I think that makes sense. > 2/ should we name the binary package u-boot-apple or -asahi? >The existing third-party packages of the asahi fork calls >theirs u-boot-asahi. I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the sunxi community port of allwinner hardware), but with src:u-boot-asashi already in NEW, that makes it a more confusing situation. > 3/ do we include patches? > 3.1/ No patches. If this is the desired path I can volunteer > to test that it boots on my M1 machine. Other machines > should probably be considered unsupported for now, > even though they might have limited usefulness. > 3.2/ Minimal set of patches. We identify what we consider > crutial only patches and recruit volunteers to test. > M2 keyboard? USB? etc... > 3.3/ All asahi patches. We consider it simpler to just sync all patches > with the asahi fork (even though some are even unused, like the > devicetree patches). We trust the Asahi Linux project in their > quest to upstream all their work and that they will rebase on newer > releases and make our job easy. I am inclined towards starting with no patches or a minimal set of patches. The asashi folks do seem to generally do a good job of upstreaming, so support should improve over time. I have been working on getting 2023.10 into unstable, and before too long 2024.01~rc variants should land in experimental, presumably with more upstreamed patches. > Debian has a bananas-team that can take responsibility for testing > and maintaining software, see: > https://wiki.debian.org/Teams/Bananas Glad to know! > Also worth noting is that the asahi fork of u-boot has been uploaded > and currently sitting in NEW as src:u-boot-asahi. > https://ftp-master.debian.org/new.html > As mentioned already on the ITP, I think it's excessive to duplicate all > of u-boot over 43 patches (and hopefully shrinking): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471 Yes, it does seem a shame to duplicate all of u-boot, although it really depends on how the upstreaming progress goes. I can personally tell you reviewing the copyright and licesning information for a project with 2+ files is... arduous. And it would be somewhat ridiculous to do that twice. live well, vagrant signature.asc Description: PGP signature
Bug#1056595: dgit: must not override dpkg include lists
On Thu, Nov 23, 2023 at 05:57:42PM +, Ian Jackson wrote:
> Severity: -1 normal
>
> Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg
> include lists"):
> > dgit overrides the include lists for dpkg, causing packages to include
> > additional .gitignore and similar files which dpkg-source -b will
> > exclude.
>
> Yes.
>
> This is necessary (1) so that the git trees correspond precisely to
> the .dscs (which is the invariant of the dgit git view), and
> (2) to comply with our promise to provide people with the source code.
>
> I consider dpkg-source's behaviour, of excluding .gitignore by default,
> to be wrong:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
> (You may recall that report, since you commented on it.)
I see, I consider dpkg's behavior to be the correct one, and if you
want to override it, do it in debian/source/options, not by passing
arguments to dpkg.
>
> > This creates a significant hurdle to the NMU process and downstream
> > distribution maintainers who have to figure out how to reduce the
> > delta again, because in both cases, unrelated changes should not
> > be present in the diff between the two uploads.
>
> I'm afraid I don't understand your scenario precisely. I'm
> sympathetic to the goal of removing hurdles for NMUers and downstream
> maintainers.
>
> > Like I had to spend about 20 minutes or so today trying to figure out
> > how to actually get that sorted out for a native package (I was trying
> > -i all the time when I should have passed -I), in turn I discovered
> > some other process issues but that's beside the point :D
>
> Were you trying to use dgit to make an NMU? If so what git branch
> did you start with? What options did you give to dgit?
No, I have no intention to ever use dgit. I believe its design is
directly opposed to what I consider the right workflow.
In my case it was not actually an NMU but I was building a prepared
merge downstream in Ubuntu which removed files that were present
in the Debian upload, but it's the same issue NMUers in Debian
face.
If I start with the .dsc, have no intention of ever touching dgit,
I need to manually figure out why files go missing vs the previous
upload and how to make them not disappear.
Like for both NMUs, and downstream work, what we care about is not
"oh rebuild is cleaning out some garbage in the tarball" (normally
we are happy about that), but about maintaining the smallest possible
change to the base version.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#1056601: No module named
Package: ansible
Version: 7.7.0+dfsg-3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
When trying to use the community.general.ssh_config module, I receive:
An exception occurred during task execution. To see the full traceback, use
- -vvv. The error was: ModuleNotFoundError: No module named 'paramiko' fatal:
[localhost]: FAILED! => {"changed": false, "msg": "Failed to import the
required Python library (PARAMIKO) on [hostname]'s Python /usr/bin/python3.
Please read the module documentation and install it in the appropriate
location. If the required library is installed, but Ansible is using the wrong
Python interpreter, please consult the documentation on
ansible_python_interpreter"}
Regards, Daniel
- -- System Information:
Debian Release: trixie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 ansible depends on:
ii ansible-core 2.14.11-2
ii openssh-client 1:9.4p1-1
ii python33.11.4-5+b1
ii python3-distutils 3.11.5-1
ii python3-dnspython 2.4.2-1
ii python3-httplib2 0.20.4-3
ii python3-jinja2 3.1.2-1
ii python3-netaddr0.8.0-2
ii python3-yaml 6.0.1-1
Versions of packages ansible recommends:
ii python3-argcomplete 3.1.4-1
ii python3-cryptography 38.0.4-4
ii python3-jmespath 1.0.1-1
ii python3-kerberos 1.1.14-3.1+b7
ii python3-libcloud 3.4.1-5
ii python3-selinux 3.5-1
ii python3-winrm 0.4.3-1
ii python3-xmltodict 0.13.0-1
Versions of packages ansible suggests:
pn cowsay
ii sshpass 1.09-1+b1
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmVfoxMACgkQS80FZ8KW
0F05SA//efTf36NuG0AAA/KlctZC9MsqhtNHUtlN8lxqeRrMJ4gEqOJtHimwt+3n
iE4ofPaFwU/fYWjKpmDbLoiu7WQ8AlDlgz1Xy3c4xue/KjGi6e5RvUBq70uEOuIq
qErnRFc5yiSRtOEGLeEGpfGsHw0UZrahpGVO9p1DMIWCwbLRaRcohbe1ok7Mlo6f
ynkK00Npvs8cumobsDolbyT7ofZo47NPZFAH3WugGLNsvcuHeCjLsxmpRzDq5UzS
XeaFUEIwRS5rTX6a3e+iKj/HBlIo5Oleorus0Ehyprkgbo9tyMqZEOY/+Cdexhud
VSt3bA/8fprfdOvl0JAftNTM71XwdlppwioO6NLpfQBiYtVzTZ2w3461QbSKzTHs
0rSUFgGYMzEzas54Bvra9ygCyk5hxc6IJVkwC+jX8q3ME07bej3G1PjX78z72RQY
PWCPU92/Oa7shAEwn+Xtd/MMNZEU5wCALql6WGdaVgq9NhT3CYtQNOCwf2M1z27L
SfAoVXVXKGTve8spwZxhI6QGMpD1431IarWVRsFNr3qolk/YgseWWmz27T3rdxQA
Gi97MnqvMPSL48Q7GMzavzZ1u9nqdS+4gmPigtDOjNEi3eh8k3473TXctzJpqi5K
TUSNCCNA74BbblacuNlBdMIyJrNF226ubnM3zwoakpOu2E007So=
=bCRB
-END PGP SIGNATURE-
Bug#1056602: RM: rust-boxfnonce -- ROM; Unmaintained upstream, no more rdeps
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: rust-boxfno...@packages.debian.org Control: affects -1 + src:rust-boxfnonce Please remove rust-boxfnonce. It's unmaintained upstream, as described in #104. There are no more reverse dependencies. Cheers
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: > On 2023-11-23, Andreas Henriksson wrote: > > I'm opening this bug report to discuss the potential of building another > > u-boot variant in a new binary package from src:u-boot for "Apple > > Silicon" machines. > > Thanks! I am guessing this class of hardware may represent a much larger > community than many other boards already supported in u-boot. > > > > # The overall picture of booting Linux on apple silicon > > > > A normal users boot procedure would look something like: > > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) > > -> generic distro EFI boot managers (grub, systemd-boot, etc) > > > > > > m1n1 stage1 is installed by the Asahi Linux installer. > > m1n1 stage2 + u-boot + dtbs are bundled together and installed > > as boot.bin on the EFI partition. > > From u-boot 2023.10 doc/board/apple/m1.rst: > > $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho > > So, this suggests to me one has to pick exactly which .dtb to use which > is presumably device-specific? Or is there some other process? > > I am guessing we would not be able to provide all the possible > "u-boot.macho" permutations out of the box (unless it is a very small > number of variants), but can probably ship all the relevent components > as long as they are in debian main. If the .dtb files come from > somewhere other than debian main, we would probably have to build it as > a contrib package. Not really, including multiple dtbs is possible. In fact the original Asahi distribution based on Arch and Asahi Fedora both do that (and use the dtbs provided by the kernel package). See: https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1#L20 > > > > m1n1 stage2 is already in debian, see: > > https://tracker.debian.org/m1n1 > > Great! > > > > I've looked over the 43 patches and here's my *perception* > > of the current status: > > > > The current upstream apple_m1_defconfig should be usable > > for booting (from internal storage) on M1 machines. > > > > The M2 can possibly boot, but keyboard driver is not yet > > upstream - so no interaction with u-boot possible. > > Ok, so worst case, there is at least one supported working platform even > without patches? Indeed, plus some with partial support. > > > > Some of the patches updates devicetree files (dts) which are > > completely apple-specific and should not have any chance to affect > > anything else, but these are also completely unused so does not > > neccessarily need to be included. > > The asahi tools to update the EFI boot.bin that combines m1n1, > > u-boot and dtbs uses the dtbs from the installed kernel, see: > > https://tracker.debian.org/asahi-fwextract > > https://tracker.debian.org/asahi-scripts > > Here is the crux of the question ... can it use the .dtb files from > debian main or does it need .dtb files from some sources outside of > debian? > That really depends on which kernel you are going to use as both are developed in tandem. Since we don't have a working kernel in the debian archive most people will use a 3rd party build including more up-to-date dtbs. I think this will really start to matter once we are nearing a release. > > > # considerations > > > > 1/ are we willing to add another binary package to src:u-boot > >building apple_m1_defconfig? > > I think that makes sense. > > > > 2/ should we name the binary package u-boot-apple or -asahi? > >The existing third-party packages of the asahi fork calls > >theirs u-boot-asahi. > > I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the > sunxi community port of allwinner hardware), but with src:u-boot-asashi > already in NEW, that makes it a more confusing situation. We can drop the one in new. There is no need to have both. > > > > 3/ do we include patches? > > 3.1/ No patches. If this is the desired path I can volunteer > > to test that it boots on my M1 machine. Other machines > > should probably be considered unsupported for now, > > even though they might have limited usefulness. > > 3.2/ Minimal set of patches. We identify what we consider > > crutial only patches and recruit volunteers to test. > > M2 keyboard? USB? etc... > > 3.3/ All asahi patches. We consider it simpler to just sync all patches > > with the asahi fork (even though some are even unused, like the > > devicetree patches). We trust the Asahi Linux project in their > > quest to upstream all their work and that they will rebase on newer > > releases and make our job easy. > > I am inclined towards starting with no patches or a minimal set of > patches. The asashi folks do seem to generally do a good job of > upstreaming, so support should improve over time. > > I have been working on getting 2023.10 into unstable, and before too > long 2024.01~rc variants should land in experimental, presumably with > more upstreamed patches. Tha
Bug#1056603: netbase: please add coap(s) to /etc/services
Package: netbase Version: 6.4 Severity: wishlist X-Debbugs-Cc: a...@koalatux.ch Dear maintainer, The Constrained Application Protocol (CoAP) as specified in RFC 7252 is an emerging protocol used in many IoT applications. In Debian there are at least two CoAP implementations: libcoap3 and aiocoap. The former is a C library and the latter is a Python module, while both of them provide simple command line clients. IANA assigned the port 5683 to unencrypted CoAP using TCP and UDP and it assigned the port 5684 to (D)TLS-secured CoAP. Please add something like the following to /etc/services: coap5683/tcp # Constrained Application Protocol coap5683/udp # Constrained Application Protocol coaps 5684/tcp # Constrained Application Protocol over TLS coaps 5684/udp # Constrained Application Protocol over DTLS Cheers, Adi
Bug#1056604: libcpp-httplib-dev: wrong version number in pkgconfig file
Package: libcpp-httplib-dev Version: 0.14.1+ds-1 Severity: important X-Debbugs-Cc: davidjamescastor...@proton.me Dear Maintainer, If this package is based on upstream v0.14.1 (as the package version suggests), then cpp-httplib.pc has the wrong version number (0.14.0). This prevents it from being linked against by projects expecting that version e.g. https://github.com/citra-emu/citra -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/12 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=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcpp-httplib-dev depends on: ii libbrotli-dev 1.0.9-2+b6 ii libcpp-httplib0.14 0.14.1+ds-1 ii libssl-dev 3.0.11-1 ii zlib1g-dev 1:1.2.13.dfsg-3 libcpp-httplib-dev recommends no packages. libcpp-httplib-dev suggests no packages. -- no debconf information
Bug#1056605: ITP: licenserecon -- Reconcile licenses from debian/copyright against license-check
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com * Package name : licenserecon Version : 1.0 Upstream Contact: Peter Blackman * URL : https://salsa.debian.org/PeterB/licenserecon * License : BSD-2-clause Programming Lang: Pascal Description : Reconcile debian/copyright licenses against licensecheck output Uses licensecheck to determine file licences and, if not 'UNKNOWN', checks them against Dep5 debian/copyright. Is intended as a partial replacement for license-reconcile (removed in 2019). I use this package for checking debian/copyright in other packages I maintain. Will need a sponsor. From the man page; === lrc DESCRIPTION Lrc parses a valid DEP-5 copyright file and notes the licenses of files in the source tree. Licensecheck is then run, and the results compared. Differences between licenses in debian/copyright and the output of licensecheck are reported. It should be run in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The source tree should be clean, otherwise results will be contaminated by spurious reports on the build's generated files. It is advisable to run lintian first to ensure correct syntax of debian/copyright. The results are indicative only, and not a substitute for manual checking. It is intended to report obvious errors. The design intends to minimise false positives as much as is practical. However, false positives will occur if the spelling of the license short-string is not identical between the file and debian/copyright. This is quite likely with complex licensing such as 'and'/'or' constructs and specific exceptions. Only files with a copyright header are checked. False negatives may occur if licensecheck cannot determine a file's license. Files named copyright, copying, readme etc. are not checked as they often specify the licenses of other files rather than their own. EXIT CODES 0: No differences found 1: Failure to run (no debian/copyright etc) 3: License differences found SAMPLE OUTPUT Sample output invoking lrc. SUCCESS: Parsing Source Tree Running licensecheck No differences found DIFFERENCES: Parsing Source Tree Running licensecheck d/copyright | licensecheck LGPL-2.1+ | GPL-2+ test/src/config/chan.c GPL-2+ | public-domain share/lua/int/dummy.lua GPL-2+ | LGPL-2.1+ modules/access/sr_common.h AUTHOR Peter Blackman SEE ALSO licensecheck (1) 2023-11-21 1 lrc(1) Manual page lrc(1) line 7/56 (END) (press h for help or q to quit)
Bug#976805: Progress?
On Sun, 31 Jul 2022 22:14:33 -0700 "M. Zhou" wrote: > https://salsa.debian.org/pkg-security-team/imhex > I forgot the current status. In my fuzzy memory there > are some new dependencies to be packaged. > > On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote: > > Hi. Is this coming along? What needs to happen to get this into the > > repos? Do you need help? > > > > Thanks! > > > Hi, any update on this ? This would be great to have in debian. best, -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056120: mariadb-server: debian-start uses obsolate hardcoded /etc/mysql/debian.cnf
Severity: wishlist Version 1:10.11.5-3 You are correct in that there are still calls to '--defaults-file=/etc/mysql/debian.cnf' in the package scripts and that they have been deprecated. They are obsolete on new installs. However on old installs that upgraded from MariaDB 10.x they are still needed. We likely have to wait for several years before removing those, and additionally there needs to be scripts that delete/rename the all the legacy /etc/mysql/debian.cnf files before that.
