Bug#1028705: xraylarch: FTBFS: build-dependency not installable: python-numpy-doc
Control: tags -1 + pending On Sat, 14 Jan 2023 13:54:02 +0100 Lucas Nussbaum wrote:> > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: python-numpy-doc but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. xraylarch builds successfully without python-numpy-doc. I have removed it and pushed to salsa. Andrius
Bug#1029061: ITP: gosa-plugins-sudo -- sudo plugin for GOsa²
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gosa-plugins-sudo Version : 2.8~ Upstream Author : GONICUS GmbH * URL : https://github.com/gosa-project/gosa-plugins-sudo * License : GPL-2+ Programming Lang: PHP Description : sudo plugin for GOsa² This package includes the LDAP schema needed by the GOsa sudo plugin. . GOsa² is a combination of system-administrator and end-user web interface, designed to handle LDAP based setups. . This package will be maintained by the Debian Edu Packaging Team.
Bug#1029057: llvm-toolchain-15 cannot be built without git
Hello Le 17/01/2023 à 06:53, Jian-Hon Pan a écrit : Package: llvm-toolchain-15 Version: 1:15.0.6-4 When I try to build llvm-toolchain-15 by myself, it shows the error: CMake Warning at cmake/modules/VersionFromVCS.cmake:49 (message): Git not found. Version cannot be determined. Call Stack (most recent call first): CMakeLists.txt:992 (get_source_info) Then, I trace the code [1] and make sure it needs git for build. I think git should be in the Build-Depends of llvm-toolchain-15, too. [1]: https://github.com/llvm/llvm-project/blob/8dfdcc7b7bf66834a761bd8de445840ef68e4d1a/llvm/cmake/modules/VersionFromVCS.cmake#L7-L50 Jian-Hong Pan it is a warning, not an error. Cheers Sylvestre
Bug#1029060: ITP: gosa-plugins-pwreset -- Password Management Add-On for GOsa²
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gosa-plugins-pwreset Version : 2.8~ Upstream Author : Mike Gabriel * URL : https://github.com/gosa-project/gosa-plugins-pwreset * License : GPL-2+ Programming Lang: PHP Description : Password Management Add-On for GOsa² Password management and reset tool for GOsa². Administratively mass-reset user passwords based on various approaches. New passwords can be auto-generated or uploaded in CSV format. . GOsa² is a combination of system-administrator and end-user web interface, designed to handle LDAP based setups. . This package will be maintained by the Debian Edu Packaging Team.
Bug#1029059: ITP: gosa-plugins-systems -- systems plugin for GOsa²
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gosa-plugins-systems Version : 2.8~ Upstream Author : GONICUS GmbH * URL : https://github.com/gosa-project/gosa-plugins-systems * License : GPL-2+ Programming Lang: PHP Description : systems plugin for GOsa² Systems management base plugin. . GOsa² is a combination of system-administrator and end-user web interface, designed to handle LDAP based setups. . This package will be maintained by the Debian Edu Packaging Team.
Bug#916605: Same bug in bookworm
Encountered the same issue as OP in bookworm. I was not using the deb package before, so not sure if the bug existed in previous releases. Had to do the following steps to get the browser to launch after completing the automatic download using "Launch Tor Browser" and completing the download: $ cd ~/.local/share/torbrowser/tbb/x86_64/tor-browser $ ./start-tor-browser.desktop --register-app This creates a new entry in the menu "Tor Browser" that can be used to launch tor. If the "Launch Tor Browser" is selected, it again downloads the browser but does not launch. Note that the package should also have Depends: desktop-file-utils since the update-desktop-database command is required by the start-tor-browser.desktop script.
Bug#1023540: snapshot.debian.org: 504 Gateway Time-out
Hi, i am also seeing a Gateway Timeout on: https://snapshot.debian.org/package/gcc-6/6.0.1-2/ This was while trying to replay the gcc transition from jessie to stretch. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature
Bug#1029058: lvm2: lvmdevices symlink missing
Package: lvm2 Version: 2.03.16-2 Severity: normal Dear Maintainer, when using the use_devicesfile directive in LVM, the documented way to add devices to said file is to run `lvmdevices --adddev`. However, on Debian lvmdevices does not exist. As most (all?) LVM commands, it is a symlink to lvm itself, but this symlink is missing from Debian. thanks, -Christian -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/40 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.185-2 ii dmsetup2:1.02.185-2 ii libaio10.3.113-3 ii libblkid1 2.38.1-4 ii libc6 2.36-8 ii libdevmapper-event1.02.1 2:1.02.185-2 ii libedit2 3.1-20221030-2 ii libselinux13.4-1+b4 ii libsystemd0252.4-1 ii libudev1 252.4-1 ii lsb-base 11.5 ii sysvinit-utils [lsb-base] 3.06-2 Versions of packages lvm2 recommends: pn thin-provisioning-tools lvm2 suggests no packages. -- Configuration Files: /etc/lvm/lvm.conf changed [not included] -- no debconf information
Bug#1028541: lvm2: LVM filters render server unbootable
Dear Bastian, update: we were told by upstream that there is a known instability between lvm and udev-generated symlinks and a devices file should be used instead. So that's what we're going to do. In related news, I'll create another bug report shortly, but it's a small one. thanks, -Christian -- Dr. Christian Herzog support: +41 44 633 26 68 Head, IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://isg.phys.ethz.ch/
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas, Thank you for your commit on salsa. The VTK API is generally stable enough and some little things might have to be modified in the source code. However, my experience with transition to a new VTK version is that it may cause some problem in the way 3D rendering is handled, which is harder to tackle. I have not tested CamiTK with VTK9 yet, but I will try to do so in the next few days and will get back to you ASAP. Kind regards and thanks again for the time and attention Emmanuel On 14/01/2023 08:42, Andreas Tille wrote: Control: tags -1 upstream Control: tags -1 help Control: forwarded -1 Emmanuel Promayon, Celine Fouard Hi Emmanuel and Celine, Debian has dropped support for VTK 6/7 and camitk needs to be ported to VTK9. Currently libvtk9-qt-dev is not installable to do a test build. It would be great if you could confirm that camitk builds with VTK9. Kind regards Andreas. -- Emmanuel Promayon Professeur Univ. Grenoble Alpes - Polytech Grenoble Laboratoire TIMC - équipe GMCAO
Bug#1029055: Debian Expat and SPDX MIT License Text
SPDX itself might have an answer that is satisfactory: "The original replaceable text appears on the SPDX License List webpage in red text." "Omittable text appears on the SPDX License List webpage in blue text." https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/[1] On Monday, January 16, 2023 11:48:48 PM MST Soren Stoutner wrote: > There appears to be some question of opinion as to if the Debian MIT (Expat) > License is the same as the SPDX MIT License. > > https://www.debian.org/legal/licenses/mit[1] > > https://spdx.org/licenses/MIT.html[2] > > Can somebody at Debian Legal please comment? -- Soren Stoutner so...@stoutner.com [1] https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/ signature.asc Description: This is a digitally signed message part.
Bug#1029055: Debian Expat and SPDX MIT License Text
Hi, Soren Stoutner wrote: > There appears to be some question of opinion Not opinion. Just the point of what the meaning of _text colors_ *rollingeyes* in a license do mean. I just ignored them and then those two licenses differ. > as to if the Debian MIT (Expat) License is > the same as the SPDX MIT License. […] > Can somebody at Debian Legal please comment? Yes, thanks! I'd prefer to have a good explanation, too. Please also note that I didn't mark the bug report as wontfix, just as moreinfo. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1029055: Debian Expat and SPDX MIT License Text
There appears to be some question of opinion as to if the Debian MIT (Expat) License is the same as the SPDX MIT License. https://www.debian.org/legal/licenses/mit[1] https://spdx.org/licenses/MIT.html[2] Can somebody at Debian Legal please comment? -- Soren Stoutner so...@stoutner.com [1] https://www.debian.org/legal/licenses/mit [2] https://spdx.org/licenses/MIT.html signature.asc Description: This is a digitally signed message part.
Bug#1029055: MIT License Text
Axel Beckert wrote: > As mentioned before exactly that exception is the reason why I think > that these two license texts are not the same. I though see no > explanation what the meaning of the colors on the SPDX website is. > Until that is clarified, for me, the two texts clearly differ for me. And just to state the obvious, this is the wdiff which I made for myself during our previous discussion in #1002053: $ dwdiff mit expat [-MIT License-] Copyright (c) [- -] {+1998, 1999, 2000 Thai Open Source Software Center Ltd+} Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice [-(including the next paragraph)-] shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1029056: [Pkg-deepin-devel] Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common
Thank you for the quick response. Your argument makes logical sense. In practice, on a Debian Bullseye system, there are unfortunately many packages which fail to declare the needed dependency. I guess in theory it would be possible to reverse the logic and ask: why should a file manager know what kind of icons it will be asked to display? A hard dependency on an svg rendering library makes as little sense at that end. So where should it be declared? But anyway, until there's some kind of framework to connect providers and consumers, a Recommends: from papirus-icon-theme will help, and someone assembling a desktop from scratch can add librsvg2-common to the default install list. Best wishes, John
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, Thanks all who have contributed to the descussion! Much appreciated. On Mon, Jan 16, 2023 at 03:08:22PM -0700, Sam Hartman wrote: > > "Moritz" == Moritz Mühlenhoff writes: > Moritz> Not moving to 6.1.x (which is most likely the next Linux > Moritz> kernel LTS) is by far a worse regression since it applies to > Moritz> every single Debian system. > > Moritz> As a community distro without paid, full time kernel > Moritz> maintainers we can't just randomly stick to an older kernel > Moritz> tree and decide to assess/backport hundreds of patches sent > Moritz> to stable@ every week. > > I think we're all agreed on that point. > What we can do is delay the release if we have a serious enough bug that > is not fixed yet. > I think what people are saying on this bug is that this issue is serious > enough it should be considered as a release blocker---something that > could actually delay the release. I do agree, this is defintively an issue we would not would want to have in a stable release, so the assessment of marking it RC is defintively right. While 6.0.y is now EOL, and 6.1 was aimed to be the LTS release, and the reason we would like to pick that for bookworm, there was not yet an official announce for it, in part because of reported regressions, cf. https://lore.kernel.org/all/y53bputyk+3dj...@kroah.com/ and https://lore.kernel.org/all/20230114084719.ga6...@1wt.eu/ for some context. > From where I sit, thinking about what I've deployed in the last five > years, I agree with that analysis: this *might* be serious enough to > delay the release until there is a fix. > Given that we can't stick on 6.0, I think we should try to get this > into testing as soon as possible so we can see how big of an impact it > is in practice. > I don't like to see testing broken, but I like to see stable broken in > serious ways even less. > And so I'd recommend we see how badly this is going to hurt us. I will bite the bullet (taking full responsibility for it if necessary, don't blame the other kernel team members) and ask here now the release team: Can we let linux 6.1.4-1 despite the RC bug reported, migrate to testing, so we can move on to 6.1.y? Let's keep the bug as RC severity. I'm currently working on uploading as well 6.1.6 or 6.1.7 (depending on the timing) further after that to unstable. Unfortuantely there is still not a solution to address #1028451 but will contain other important fixes (including security ones). Thank you for considering it, Odyx, I feel sorry, this will knowingly impact your and others! Regards, Salvatore
Bug#1029055: MIT License Text
Control: tag -1 + moreinfo Hi, thanks for the separate bug report. Soren Stoutner wrote: > I just noticed that AppStream specifies that their licenses use the text > listed by SPDX. > > As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is > the same as the > Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit > (except for the > instructions in blue), As mentioned before exactly that exception is the reason why I think that these two license texts are not the same. I though see no explanation what the meaning of the colors on the SPDX website is. Until that is clarified, for me, the two texts clearly differ for me. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1029057: llvm-toolchain-15 cannot be built without git
Package: llvm-toolchain-15 Version: 1:15.0.6-4 When I try to build llvm-toolchain-15 by myself, it shows the error: CMake Warning at cmake/modules/VersionFromVCS.cmake:49 (message): Git not found. Version cannot be determined. Call Stack (most recent call first): CMakeLists.txt:992 (get_source_info) Then, I trace the code [1] and make sure it needs git for build. I think git should be in the Build-Depends of llvm-toolchain-15, too. [1]: https://github.com/llvm/llvm-project/blob/8dfdcc7b7bf66834a761bd8de445840ef68e4d1a/llvm/cmake/modules/VersionFromVCS.cmake#L7-L50 Jian-Hong Pan
Bug#1029056: [Pkg-deepin-devel] Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common
Hi, 在 2023-01-17星期二的 13:56 +0900,John Crawley写道: > Package: papirus-icon-theme > Version: 20210201-1 > Severity: normal > X-Debbugs-Cc: j...@bunsenlabs.org > > Dear Maintainer, > > * What led up to the situation? > On a Debian Bullseye system without librsvg2-common installed, Papirus icons > were not correctly displayed. > > * What exactly did you do that was effective? > Install librsvg2-common. > > * What was the outcome of this action? > Icons were correctly displayed. > > ( This might have been the underlying issue in bug #982901 ) > > Because it is a dependency of many other packages, librsvg2-common will > often already be installed, hiding the dependency from papirus-icon-theme. > > gnome-icon-theme depends on, and adwaita-icon-theme recommends librsvg2- > common. > As a theme using svg icons, papirus-icon-theme could be expected to depend > on, or at least recommend, librsvg2-common too. Logically I very much dislike the idea of adding dependency from an icon theme to some package that provides the SVG parsing functionality (e.g., librsvg2- common). Such dependency should be handled by whoever *consumes* SVG icons (e.g., spacefm), not the package that *provides* SVG icons. Why should an icon theme package know that some random desktop software will need a "librsvg2- common" to parse SVG correctly? What if that desktop software actually needs some other SVG parsing library (e.g., libqt5svg5) ? Why *should* I know that? This does not make any sense. Back to actual packaging: I could add a recommendation to librsvg2-common, but I will definitely not opt to go for a hard dependency. I will make the upload shortly. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common
Package: papirus-icon-theme Version: 20210201-1 Severity: normal X-Debbugs-Cc: j...@bunsenlabs.org Dear Maintainer, * What led up to the situation? On a Debian Bullseye system without librsvg2-common installed, Papirus icons were not correctly displayed. * What exactly did you do that was effective? Install librsvg2-common. * What was the outcome of this action? Icons were correctly displayed. ( This might have been the underlying issue in bug #982901 ) Because it is a dependency of many other packages, librsvg2-common will often already be installed, hiding the dependency from papirus-icon-theme. gnome-icon-theme depends on, and adwaita-icon-theme recommends librsvg2-common. As a theme using svg icons, papirus-icon-theme could be expected to depend on, or at least recommend, librsvg2-common too. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) 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 papirus-icon-theme depends on: ii hicolor-icon-theme 0.17-2 papirus-icon-theme recommends no packages. Versions of packages papirus-icon-theme suggests: pn libreoffice-style-papirus -- no debconf information -- John
Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed
Control: tags 1028343 pending On 2023-01-11, Karsten Merker wrote: > On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote: >> Definitely would be good to mention to upstream. Please Cc me if you do! > > I've sent the bugreport upstream: > https://lists.denx.de/pipermail/u-boot/2023-January/504466.html Thanks, that worked well! A patch was submitted upstream, and I've tested and committed the patch to the packaging for Debian, so should be included in the next upload: https://salsa.debian.org/debian/u-boot/-/commit/8ebfba031bc7dad7594669ed00eb8a17c6ed3808 https://salsa.debian.org/debian/u-boot/-/commit/f2aad8950a124f011c926445361b90efe76c8dd2 live well, vagrant signature.asc Description: PGP signature
Bug#1029055: MIT License Text
I just noticed that AppStream specifies that their licenses use the text listed by SPDX. As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is the same as the Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit (except for the instructions in blue), there probably shouldn’t be any question that these are simply two different names for the same license (for reasons that probably shouldn’t surprise me, open-source people can’t just get along and agree on a name). -- Soren Stoutner so...@stoutner.com [1] https://spdx.org/licenses/MIT.html signature.asc Description: This is a digitally signed message part.
Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)
I created a new bug report to discuss this issue as the root cause ends up being different than what was originally reported here. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055[1] -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055 signature.asc Description: This is a digitally signed message part.
Bug#1013222: Private headers
On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Maintaining Qt already takes a lot of time, adding private headers > only makes things worse. So if you want to do porting and the headers > are not yet there you will have to build Qt itself or fix the problem > where it really belongs: upstream. Upstream? Where it's not a problem, because they ship and install the private headers? No, this is an issue in Debian, because the headers are being specifically excluded from packaging, rather than installed. Other distributions provide these files without such politics. Why is it so hard to maintain in Debian? Fedora, OpenSUSE, Arch, etc… all have these files available for installation and developing against. So, surely the "maintenance burden" is not so high, right? Debian has britney to run autopackage tests, specifically to prevent things breaking, no? Those things still are going to break, when those files aren't provided, since they can no longer build, no? There is nothing speculative here. The files are required to build many things against Qt, regardless of whether it is version 5 or 6. Leaving the files out, only makes it harder for anyone to rely on distribution provided packages. These are necessary for shipping KDE Plasma 6, and many other things, in Debian.
Bug#1029055: lintian: Lintian does not recognize the AppStream's metainfo.xml MIT license is the same as Debian's Expat license
Package: lintian Version: 2.115.3 Severity: wishlist Debian has recently started requesting that graphical programs install AppStream metainfo.xml files. https://appstream.debian.org/sid/main/issues/electrum.html The AppStream specification has a very restricted listed of possible licenses for the metainfo.xml file. FSFAP MIT 0BSD CC0-1.0 CC-BY-3.0 CC-BY-4.0 CC-BY-SA-3.0 CC-BY-SA-4.0 GFDL-1.1 GFDL-1.2 GFDL-1.3 BSL-1.0 FTL FSFUL https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license No specific text is given for what they mean by the MIT license. The MIT license is a bit problematic because there are more than one license that has been called the MIT license over the years. https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants https://www.gnu.org/licenses/license-list.en.html#Expat When most people say MIT they mean Expat, so it is standard in the industry to assume that when no specific text is given MIT == Expat. Debian prefers the Expat name to the MIT name for this reason. https://www.debian.org/legal/licenses/mit The documentation for the Debian machine-readable copyright file says the following. "There are many versions of the MIT license. Please use Expat instead, when it matches." https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name The Electrum package, which is licensed upstream as MIT, is listed as Expat in debian/copyright according to the instructions in the copyright format and because the upstream MIT license matches exactly the Debian legal Expat example. Because the AppStream metainfo.xml file does not allow the use of the Expat name, or it will fail validation with appstreamcli, I licensed the metainfo.xml file as MIT. This made it easy to submit it upstream, which has already accepted it for the next release. In the meantime, I included the metadata.xml file in the debian directory for the current release. However, Lintian complained that Expat != MIT. I considered creating a override, but according to the instruction at https://lintian.debian.org/manual/index.html#overrides it seemed more appropriate to file a bug against Lintian, as every time there is an AppStream file with a MIT license this will create a false positive if matched against Expat. To work around this, I currently created a duplicate section in debian/copyright, which doesn't seem like an efficient long-term solution. https://salsa.debian.org/sorenstoutner/electrum/-/blob/master/debian/copyright I personally wish that those creating licenses had been more careful about the naming thereof. Secondarily, I wish that AppStream had followed best practices and allowed the use of the Expat name. However, given that neither of those things are within my control, the next best option is to make Lintian smart enough to work around this specific situation. This was originally discussed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002053 but was moved to this separate bug report because it didn't end up being the same root problem.
Bug#1028649: Segmentation fault invoking bus.get_unique_name()
Package: python3-pystemd Version: 0.7.0-5+b2 Followup-For: Bug #1028649 FWIW this bug still exists with version 0.11.0 installed via pip. -MD -- - Michael Deegan Hugaholic https://www.deegan.id.au/ Jung, zr jbeel? --
Bug#1013222: Private headers
Hi! El lun, 16 de ene. de 2023 21:59, Rodney Dawes escribió: > On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi > > > > Private packages have only been created when required for other Qt > > submodules or key plasma packages, no more. > > They are required for key plasma packages here, as well. It is > necessary to use these private headers to be able to write plugins to > Qt itself, such as for providing support for additional wayland > protocols in Qt, and to provide input method support on Wayland using > Qt API. I found this issue as I was getting build errors on doing some > work to port the wayland code in maliit-framework to Qt6. You will probably need to build qt yourself to do that in the meantime. > > > That's because kwin required those headers. As soon as kwin switches > > to Qt6 we will know if we need to make them available. > > If kwin is also using them, then you can be assured they will still be > needed, as very little has changed in QtWayland in 6.x from 5.x. As I > have found, they are still needed for the on-screen keyboard support. > Then when time comes the packages will be added > And no, existing private headers are not free, it is a real pain > > because they normally just make transitions more complicated. > > > > Ideally people should work with Qt upstream in order to avoid > > requiring private headers. > > Most of these needs are long standing issues which I'm sure Qt upstream > is well aware of. Third party style plugins for example is a well known > case where one must use private API, and it is still the case. > Migrating things from private to public API is never a simple task, and > even if we could get it done, it would likely take years to get there. > I know, I have been complaining about that for over a decade now. With upstream :-) Maintaining Qt already takes a lot of time, adding private headers only makes things worse. So if you want to do porting and the headers are not yet there you will have to build Qt itself or fix the problem where it really belongs: upstream.
Bug#1027844: btrfsmaintenance: noted BTRFS_BALANCE_PERIOD default in /etc/default/btrfsmaintenance is inconsistent w/systemd timer
hello - thanks for the feedback... some comments inline. i must stress that while i am a multi-year user of btrfs i do not read the linux-btrfs mailing list and my opinions should be given appropriate weight. On Sat, 2023-01-14 at 21:47 -0500, Nicholas D Steeves wrote: > [...] > Oh yeah! I had forgotten about this minor issue. The reason I > hadn't > harmonised the files, doing this implicitly says that I (and Debian) > might recommend weekly balanced, or recommend monthly balances. > > From what I've been able to gather, metadata balances have been > considered to be actively harmful for some time; This is mostly at > the > level of tribal knowledge on the linux-btrfs mailing list. It's also > the case that empty block groups are now automatically reclaimed by > the > kernel, so a periodic balance only seems to be useful in > space-constrained situations where a lot of [meta]data churn occurs. regarding balance recommendations, my initial thought would be to make the language in the README.Debian stronger. i had read that "Some advocate not running it at all" but to me that implies "may be unnecessary" rather than "may be actively harmful." on the basis of the latter i am certainly considering setting the balance.timer back to disabled. alternatively/additionally are there default options that might make it safe(r)? e.g., Marc MERLIN's `btrfs-scrub`[1] (which i used previously) suggested that "a null [metadata] rebalance should help corner cases." from my pov i'd still like to see the values harmonized. i originally noticed the inconsistency because what i believed was the default setting was creating a seemingly unnecessary systemd override file. this became a nagging question to resolve :) if the (informed) user has chosen to enable the btrfs-balance.timer then i would say harmonize the value at "monthly" (1/4 the opportunity for issues). > Thus, if I do anything, I'm inclined to set the period for balance to > "none" everywhere. given that one already needs to manually enable the service via `systemctl enable btrfs-balance.timer` i don't think it's necessary to set the default value to "none." this would result in the (imho) counter-intuitive behavior of enabling something only to have it do nothing. although an add'l comment re: the potential for harm in `/etc/default/btrfs` that one would hopefully see when changing the value from "none" to e.g., "monthly" may be the best way to ensure that they are an informed user. so i could go either way on that. > Also, what do you think about enabling the systemd patch watcher, so > that the timers are updated automatically when > /etc/default/btrfsmaintenance is modified? as a sysadmin the steps of modifying a file and then running a command for it to take effect is a normal part of my workflow. so i'm fine leaving it disabled by default. other users might feel differently. thank you... andy 1. https://marc.merlins.org/linux/scripts/btrfs-scrub -- andy diatribes
Bug#1029054: starts consuming 100% CPU
Package: mate-applets-common Version: 1.24.1-1 Severity: normal X-Debbugs-Cc: p...@rosnix.net battstat-applet installed by default with Mate, on upgraded system. A couple of times per week, battstat-applet start consuming 100% of CPU, increasing system load highly. No obvious connection to, for example, external power changes, and seemingly not directly after interacting with the app. -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 4 (chimaera) Release:4 Codename: chimaera Architecture: x86_64 Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mate-applets-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 mate-applets-common recommends no packages. mate-applets-common suggests no packages. -- no debconf information
Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata
On Sat, 2023-01-14 at 18:41 +0100, Guillem Jover wrote: > I otherwise do not know how we can mark patches as forwarded when > for example you send them directly to upstream via email or to a mailing > list that has no public archive or similar. Just as you can mark a BTS bug as forwarded to an email address, presumably you could do something similar for patches? Then people wanting to know the status could email that address to find out. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1013222: Private headers
On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi > > Private packages have only been created when required for other Qt > submodules or key plasma packages, no more. They are required for key plasma packages here, as well. It is necessary to use these private headers to be able to write plugins to Qt itself, such as for providing support for additional wayland protocols in Qt, and to provide input method support on Wayland using Qt API. I found this issue as I was getting build errors on doing some work to port the wayland code in maliit-framework to Qt6. > > That's because kwin required those headers. As soon as kwin switches > to Qt6 we will know if we need to make them available. If kwin is also using them, then you can be assured they will still be needed, as very little has changed in QtWayland in 6.x from 5.x. As I have found, they are still needed for the on-screen keyboard support. > And no, existing private headers are not free, it is a real pain > because they normally just make transitions more complicated. > > Ideally people should work with Qt upstream in order to avoid > requiring private headers. Most of these needs are long standing issues which I'm sure Qt upstream is well aware of. Third party style plugins for example is a well known case where one must use private API, and it is still the case. Migrating things from private to public API is never a simple task, and even if we could get it done, it would likely take years to get there.
Bug#1013222: Private headers
Hi El lun, 16 de ene. de 2023 19:03, Rodney Dawes escribió: > On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF- > 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= > wrote: > > Hi! > > > > I would really love to know why Telegram developers require so many > > private headers from Qt. They shouldn't be using them at all, and if > > they really require some private part they need to work with upstream > > to make it public API. > > This isn't only an issue for Telegram. Many projects require private > headers for various reasons, because developing plugins to Qt itself is > necessary to improve the system. The Qt packages have a long history of > including `-private-dev` packages for the various components which > provide private API that may be necessary to use in certain situations. > Private packages have only been created when required for other Qt submodules or key plasma packages, no more. > > There is no reason for that to stop happening with Qt 6.x. Qt6 is following the same rule. Believe me, I have been involved in Qt packaging since Qt4 :-) Especially > given the upstream source is installing them during the build. The > qtwayland5-private-dev package is available in Debian, and so should a > qt6-wayland-private-dev package be made available containing the > includes, cmake files, libraries, etc… necessary to use the QtWayland > private API with Qt6. That's because kwin required those headers. As soon as kwin switches to Qt6 we will know if we need to make them available. And no, existing private headers are not free, it is a real pain because they normally just make transitions more complicated. Ideally people should work with Qt upstream in order to avoid requiring private headers.
Bug#1029053: lintian: Should report Vcs-Browser fields pointing to Salsa/Gitlab/Github and ending in .git
Package: lintian Version: 2.115.4~git Severity: wishlist In https://salsa.debian.org/lintian/lintian/-/merge_requests/390#note_367701 Willian Desportes (X-Debbugs-Cc'ed) suggested to implement the same as Lintian MR !390 (GitHub and GitLab URLs shouldn't end with .git) also for Vcs-Browser. With which I agree. Edward Betts figured out that there are indeed about 1800 packages in Debian where this tag would be emitted: https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+Vcs-Browse.*salsa.*git=0 Then again Gitlab (and hence also Salsa) as well as Github do a redirect to the correct URL if you access these URLs with a browser. So I'd say at most "Severity: info", maybe even only "Severity: pedantic". -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii clzip [lzip-decompressor] 1.13-4 ii diffstat1.65-1 ii dpkg1.21.18 ii dpkg-dev1.21.18 ii file1:5.44-2 ii gettext 0.21-10 ii gpg 2.2.40-1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.12.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.32-1+b1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 ii libdigest-sha-perl 6.03-1+b1 ii libdpkg-perl1.21.18 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.634-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.001+ds-1+b1 ii libsereal-encoder-perl 5.001+ds-2 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.28-1 ii libterm-readkey-perl2.38-2+b1 ii libtext-levenshteinxs-perl 0.03-5+b1 ii libtext-markdown-discount-perl 0.16-1 ii libtext-xslate-perl 3.5.9-1+b2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b1 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2 ii liburi-perl 5.17-1 ii libwww-mechanize-perl 2.15-1 ii libwww-perl 6.67-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.84+ds-1+b1 ii lunzip [lzip-decompressor] 1.13-4 ii lzip [lzip-decompressor]1.23-4 ii lzop1.04-2 ii man-db 2.11.2-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-7 ii plzip [lzip-decompressor] 1.10-4 ii t1utils 1.41-4 ii unzip 6.0-27 ii xlunzip [lzip-decompressor] 0.7-6 ii xz-utils5.4.1-0.0 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.40-2 ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1029052: black: might want to strengthen the dependency on python3-click to the 8 release in bookworm
Package: black Version: 22.12.0-1 Severity: normal Dear Maintainer, I ran ansible-lint which depends on black. It outputted a warning: WARNING Ignore loading rule from /usr/lib/python3/dist-packages/ansiblelint/rules/jinja.py due to cannot import name 'ParameterSource' from 'click.core' (/usr/lib/python3/dist-packages/click/core.py) If I upgrade from python3-lick 7.1.2-1 bullseye to bookworm 8.1.3-2 this warning disappear. ansible-lint has no direct dependency on python3-click. This dependency is pulled via ansible-lint dependency on black. Cheers, Alban -- System Information: Debian Release: 11.6 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages black depends on: ii python33.10.6-1 ii python3-click 8.1.3-2 ii python3-mypy-extensions0.4.3-2 ii python3-pathspec 0.10.1-1 ii python3-pkg-resources 59.6.0-1.2 ii python3-platformdirs 2.5.2-1 ii python3-tomli 1.2.2-2~bpo11+1 ii python3-typing-extensions 3.7.4.3-1 black recommends no packages. Versions of packages black suggests: pn python-black-doc -- no debconf information
Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
Hi, Axel Beckert wrote: > Aurelien Jarno wrote: > > Given we got no decision from the MIPS porters before the toolchain > > freeze, we'll have to live with the executable stack on mips*el for > > bookworm. > > > > Therefore I believe it's a good idea to disable that tag on mips*el on > > the lintian side. > > Ok, thanks. Will look into it now. Fixed in git with this commit, referring to #1025436 and #1022787: https://salsa.debian.org/lintian/lintian/-/commit/80ec3ca960e73a0717719d1329331f86d387c4ae Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1028336: adduser: [INTL:nl] Dutch translation for the adduser package
Hi, Marc Haber schreef op ma 16-01-2023 om 21:26 [+0100]: > Hi, > > thanks for your work. Can you add a license statement please and update > the Project-Id-Version? Sure and done. Attached is an updated po file Greetings, Frans nl.po.gz Description: application/gzip
Bug#1029051: ITP: ruby-puppetserver-ca-cli
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : ruby-puppetserver-ca-cli Version : 2.3.6 Upstream author : Puppet, Inc. URL : https://github.com/puppetlabs/puppetserver-ca-cli License : Apache-2.0 Programming Lang : Ruby Description : configuration management system, ca cli library Puppet is a configuration management system that allows you to define the state of your IT infrastructure, then automatically enforces the correct state. This gem provides the functionality behind the Puppet Server CA interactions Thanks, -- Jerome
Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)
Control: tags -1 + unreproducible On Mon, 16 Jan 2023 14:28:05 +0100 Santiago Ruano Rincón wrote: [...] > I am not able to reproduce this with my current setup. Nor am I! :-o > I can successfully run dhclient -x and it stops the related process. I tried again today and now I can also use the "-x" option and the "ifdown" command, as well, without any unexpected behavior. That's really awkward. What's different in my box, with respect to yesterday?!? There have been other package upgrades, of course, but no one looks related to AppArmor or to isc-dhcp-client. There has been a poweroff and a boot (well, actually, two of them, if I recall correctly), but we are talking about Debian GNU/Linux here, not about That Other Operating System™ that needs to be rebooted for each and every little trifle!;-) Hence I would be a little surprised, if it turned out that the reboot helped... What else could have changed the result? > > Anyway, could you please test the attached patch? Thanks for preparing the patch, but I am not going to test it for the time being, since I am currently unable to reproduce the bug... [...] > > Moreover, even the first strategy (ifdown/ifup) now seems to fail to > > work perfectly. After issueing the following command: > > > > # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE > ... > > Do you see the same apparmor DENIED messages? Yes, I saw the same AppArmor error message in /var/log/kern.log, when I tried ifdown yesterday. Somehow everything seems to work flawlessly today. Hence, I am tagging this bug report as 'unreproducible' and leaving the 'moreinfo' tag. If I don't come back with additional information for some time, please feel free to close the bug report. And many thanks for your prompt and kind reply! Bye.:-) -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpOiLCsblQOQ.pgp Description: PGP signature
Bug#1029050: gcc-snapshot: FTBFS on hurd-i386 (and other archs?)
Source: gcc-snapshot Version: 20230108-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org Hi, gcc-snapshot in sid FTBFS on hurd-i386 due to that some patches are not applied when building gcc-snapshot. After the statement in rules.patch ifeq ($(single_package),yes) debian_patches = endif previously defined patches are cleared, causing the build failure, see below. debian/ files causing the problem: debian/rules.defs: ifneq (,$(findstring gcc-snapshot, $(PKGSOURCE))) single_package = yes trunk_build = yes debian/rules.patch: ifeq ($(single_package),yes) debian_patches = endif Thanks!
Bug#1028451: 2nd DisplayPort doesn't get video
> "Moritz" == Moritz Mühlenhoff writes: Moritz> Not moving to 6.1.x (which is most likely the next Linux Moritz> kernel LTS) is by far a worse regression since it applies to Moritz> every single Debian system. Moritz> As a community distro without paid, full time kernel Moritz> maintainers we can't just randomly stick to an older kernel Moritz> tree and decide to assess/backport hundreds of patches sent Moritz> to stable@ every week. I think we're all agreed on that point. What we can do is delay the release if we have a serious enough bug that is not fixed yet. I think what people are saying on this bug is that this issue is serious enough it should be considered as a release blocker---something that could actually delay the release. From where I sit, thinking about what I've deployed in the last five years, I agree with that analysis: this *might* be serious enough to delay the release until there is a fix. Given that we can't stick on 6.0, I think we should try to get this into testing as soon as possible so we can see how big of an impact it is in practice. I don't like to see testing broken, but I like to see stable broken in serious ways even less. And so I'd recommend we see how badly this is going to hurt us. signature.asc Description: PGP signature
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello, I opened an issue upstream [1] to ask for feedbacks. Azat suggest to change the function signature from void evutil_secure_rng_add_bytes(const char *buf, size_t n); to: int evutil_secure_rng_add_bytes(const char *buf, size_t n) and make evutil_secure_rng_add_bytes to return -1, to make it more explicit that the function is no-oped. I understand and I tend to agree with this suggestion, but I'm wondering if this solution is correct for this bug? The symbol would still be the same, but would the signature change introduce problems in the libevent package dependencies and build-deps? Any thoughts? /Nicolas [1] https://github.com/libevent/libevent/issues/1393
Bug#1013222: Private headers
On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF- 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= wrote: > Hi! > > I would really love to know why Telegram developers require so many > private headers from Qt. They shouldn't be using them at all, and if > they really require some private part they need to work with upstream > to make it public API. This isn't only an issue for Telegram. Many projects require private headers for various reasons, because developing plugins to Qt itself is necessary to improve the system. The Qt packages have a long history of including `-private-dev` packages for the various components which provide private API that may be necessary to use in certain situations. There is no reason for that to stop happening with Qt 6.x. Especially given the upstream source is installing them during the build. The qtwayland5-private-dev package is available in Debian, and so should a qt6-wayland-private-dev package be made available containing the includes, cmake files, libraries, etc… necessary to use the QtWayland private API with Qt6.
Bug#993589: distro-info-data: Please consider shipping default mirror URLs per distro
Hi Johannes (2023.01.16_21:28:53_+) > I like the idea of distro-info & distro-info-data taking on more > responsibility, but it probably means we need to redesign the data > schema. I'm thinking YAML/toml data. > > That in turn means rewriting the distro-info libraries (at least to > provide a new API for the new data). To expand on that. I think Debian and Ubuntu have got a little closer in their release models. Both now have LTS and ELTS (with different semantics). If we start including more distros (like Devuan), we should probably try harder to have the same code for working with all the distros data, and have it be more configuration-driven. At the moment the Ubuntu and Debian code in distro-info is quite different. We'll also probably need a script to generate data in the old CSV format, for current stable releases. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
Hi Aurelien, your reply is just in time! Because about five minutes ago, I started to continue working on Lintian for this evening. The plan: Making the long overdue upload as I fixed the last part of arm64 autopkgtest failures last night. :-) Aurelien Jarno wrote: > Given we got no decision from the MIPS porters before the toolchain > freeze, we'll have to live with the executable stack on mips*el for > bookworm. > > Therefore I believe it's a good idea to disable that tag on mips*el on > the lintian side. Ok, thanks. Will look into it now. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1029049: vim: please backport patch 9.0.1080
Source: vim Version: 2:9.0.1000 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, could you please consider backporting patch 9.0.1080? It is needed to fix the keyprotocol option on the foot terminal, according to this upstream bug report: https://github.com/vim/vim/issues/11781 Thank you! - -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 -BEGIN PGP SIGNATURE- iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY8XEXRQcYW5kcmVhQHBh cHBhY29kYS5pdAAKCRBKkgiiRVB3p4VHAQDZd1dcTYGJqznuA/yr06TlCBxKvQDc mBryv33hDyJ0OgEAwopHjy9lTATjeR1Pw3IrEUXwKsQZPuignkxI+aaQigc= =lowV -END PGP SIGNATURE- >From afa3f1cc7258d34c32a299a3cc6aece89f67fb47 Mon Sep 17 00:00:00 2001 From: Bram Moolenaar Date: Mon, 19 Dec 2022 18:56:48 + Subject: [PATCH] patch 9.0.1080: the "kitty" terminfo entry is not widespread Problem:The "kitty" terminfo entry is not widespread, resulting in the kitty terminal not working properly. Solution: Go back to using "xterm-kitty" and avoid the problems it causes in another way. --- runtime/doc/term.txt | 11 +++--- src/os_unix.c| 5 - src/term.c | 51 +--- src/version.c| 2 ++ 4 files changed, 33 insertions(+), 36 deletions(-) diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt index 50ba187ab969..146ef478fe53 100644 --- a/runtime/doc/term.txt +++ b/runtime/doc/term.txt @@ -306,9 +306,14 @@ One of the problems is that the value for $TERM is set to "xterm-kitty". For Vim this is an indication that the terminal is xterm-compatible and the builtin xterm termcap entries should be used. Many other terminals depend on this. However, Kitty is not fully xterm compatible. The author suggested to -ignore the "xterm-" prefix and use the terminfo entry anyway, but that -conflicts with what is needed for other terminals. Therefore Vim removes the -"xterm-" prefix from "xterm-kitty" when it comes from $TERM. +ignore the "xterm-" prefix and use the terminfo entry anyway, so that is what +happens now, the builtin xterm termcap entries are not used. However, the +t_RV is set, otherwise other things would not work, such as automatically +setting 'ttymouse' to "sgr". + +It is not clear why kitty sets $TERM to "xterm-kitty", the terminal isn't +really xterm compatible. "kitty" would be more appropriate, but a terminfo +entry with that name is not widespread. Note that using the kitty keyboard protocol is a separate feature, see |kitty-keyboard-protocol|. diff --git a/src/os_unix.c b/src/os_unix.c index bd75ccae1403..9d8d466507ca 100644 --- a/src/os_unix.c +++ b/src/os_unix.c @@ -2353,6 +2353,8 @@ mch_restore_title(int which) /* * Return TRUE if "name" looks like some xterm name. * This matches "xterm.*", thus "xterm-256color", "xterm-kitty", etc. + * Do not consider "xterm-kitty" an xterm, it is not fully xterm compatible, + * using the "xterm-kitty" terminfo entry should work better. * Seiichi Sato mentioned that "mlterm" works like xterm. */ int @@ -2360,7 +2362,8 @@ vim_is_xterm(char_u *name) { if (name == NULL) return FALSE; -return (STRNICMP(name, "xterm", 5) == 0 +return ((STRNICMP(name, "xterm", 5) == 0 +&& STRNICMP(name, "xterm-kitty", 11) != 0) || STRNICMP(name, "nxterm", 6) == 0 || STRNICMP(name, "kterm", 5) == 0 || STRNICMP(name, "mlterm", 6) == 0 diff --git a/src/term.c b/src/term.c index 7a70af450ca3..cd6b3b9cf62b 100644 --- a/src/term.c +++ b/src/term.c @@ -1675,6 +1675,12 @@ static char *(key_names[]) = #endif #ifdef HAVE_TGETENT +/* + * Get the termcap entries we need with tgetstr(), tgetflag() and tgetnum(). + * "invoke_tgetent()" must have been called before. + * If "*height" or "*width" are not zero then use the "li" and "col" entries to + * get their value. + */ static void get_term_entries(int *height, int *width) { @@ -2033,14 +2039,6 @@ set_termname(char_u *term) #endif parse_builtin_tcap(term); - // Use the 'keyprotocol' option to adjust the t_TE and t_TI - // termcap entries if there is an entry maching "term". - keyprot_T kpc = match_keyprotocol(term); - if (kpc == KEYPROTOCOL_KITTY) - apply_builtin_tcap(term, builtin_kitty, TRUE); - else if (kpc == KEYPROTOCOL_MOK2) - apply_builtin_tcap(term, builtin_mok2, TRUE); - #ifdef FEAT_GUI if (term_is_gui(term))
Bug#1028452: unblock: golang-1.19/1.19.5-1
Am Thu, Jan 12, 2023 at 09:17:18PM +0100 schrieb Paul Gevers: > On 12-01-2023 16:50, Shengjing Zhu wrote: > > > But this bug report triggered me: did the golang security situation > > > already improved during this release cycle. I may be misremembering, but > > > I recall the problems on the security archive side haven't been fixed, > > > have they? > > > > For some reference, I did several security updates for golang-1.15 for > > bullseye, but we didn't rebuild other packages. These security updates > > are not urgent enough anyway. > > And others also update some Go packages for bullseye. In general, we > > just do the usual update for stable release. > > > > As for the security archive, IIRC, for bullseye, the security team did > > need to ask ftp-master to copy some individual packages manually. I'm > > not sure how it is going now. But given the low update frequency I > > overseved for bullseye, probably that works. > > Do you agree with this view for bookworm? I know you want the situation > improved, but as far as I am aware nobody (from either side) has been > pushing this forward so it feels a bit late to make this blocking. I agree with what Shengjing wrote. The situation around Go isn't great, but it's pretty much identical to what we had in past releases, so no specific concerns there. Let's simply carry over the existing entry from the release notes. The biggest blocker to fixing this on the toolchain level (like e.g. a script which programatically detects dependencies in need of rebuilds and issues binNMUs) is still the split ftp.d.o/security.d.o, which prevents binNMUs and causes a lot of churn with Built-Using whenever a Go-based program is updated. One possible solution discussed was to import all of each stable distro into security.debian.org, but that disk space demand would mean to move security-master to baremetal (it's currently a Ganeti VM). I don't think there has ever been a solution/outcome so far TTBOMK. Cheers, Moritz
Bug#1029048: torsocks: Consider update Debian Package with latest upstream commits on master branch
Package: torsocks Version: 2.3.0-3 Severity: wishlist Hi, upstream has some interesting commits in the Master branch (but no release). Notably, it seems now to handle syscall passthrough instead of dropping them with a warning. We might want that in Bookworm (but this need to happen soon). https://gitweb.torproject.org/torsocks.git/commit/?id=67cee6c7976b4e103e6f9c3a70e767ffe54368e0 Thanks Unit193 for pointing that out! Cheers, -- nodens -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages torsocks depends on: ii libc6 2.36-7 Versions of packages torsocks recommends: ii tor 0.4.7.12-1 torsocks suggests no packages. -- no debconf information
Bug#1029047: software-properties-qt: software-property-qt should depends on lazr
Package: software-properties-qt Version: 0.99.30-3 Severity: grave Justification: renders package unusable Dear Maintainer, When launching software-properties-qt, I get the following message : ❯ /usr/bin/software-properties-qt Traceback (most recent call last): File "/usr/bin/software-properties-qt", line 36, in from softwareproperties.qt.SoftwarePropertiesQt import SoftwarePropertiesQt File "/usr/lib/python3/dist-packages/softwareproperties/qt/SoftwarePropertiesQt.py", line 45, in from softwareproperties.SoftwareProperties import SoftwareProperties File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 62, in from softwareproperties.shortcuts import shortcut_handler File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line 23, in from softwareproperties.ppa import PPAShortcutHandler File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 25, in from lazr.restfulclient.errors import (NotFound, BadRequest, Unauthorized) ModuleNotFoundError: No module named 'lazr' The package should include a runtime depends on python3-lazr.uri. Thanks, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages software-properties-qt depends on: ii debconf-kde-helper 1.1.0-1 ii python3 3.11.1-1 ii python3-pyqt55.15.7+dfsg-3+b3 ii python3-software-properties 0.99.30-3 ii software-properties-common 0.99.30-3 software-properties-qt recommends no packages. Versions of packages software-properties-qt suggests: ii plasma-discover 5.26.5-2 -- no debconf information -- Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net Société Libre, Logiciel Libre http://www.april.org/adherer Parinux, logiciel libre à Paris : http://www.parinux.org
Bug#1028451: 2nd DisplayPort doesn't get video
Am Mon, Jan 16, 2023 at 12:46:37PM + schrieb Didier 'OdyX' Raboud: > > I understand that would be annoying for you, but I don't think that it would > > affect the majority of our users. > > Hrm. More and more laptops come with usb-c only, and dongles/docks become more > and more common. > > It's clearly a serious regression, as such setups "just worked" with 6.0. Not moving to 6.1.x (which is most likely the next Linux kernel LTS) is by far a worse regression since it applies to every single Debian system. As a community distro without paid, full time kernel maintainers we can't just randomly stick to an older kernel tree and decide to assess/backport hundreds of patches sent to stable@ every week. Cheers, Moritz
Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack
Hi, On 2023-01-16 13:26, Guillem Jover wrote: > Hi! > > On Mon, 2023-01-16 at 12:47:23 +0100, Axel Beckert wrote: > > Aurelien Jarno wrote: > > > On 2022-10-26 22:09, Aurelien Jarno wrote: > > > > Note that the other official architecture still have a kernel > > > > compatibility set to 3.2, so that will make a difference between > > > > architectures. There are discussions to increase it upstream, but this > > > > won't happened for bookworm. > > > > > > > > On 2022-10-25 21:07, Simon McVittie wrote: > > > > > Or, if the mips porters consider this backwards compatibility to be > > > > > more important than the security hardening of a non-executable stack, > > > > > then Lintian should stop issuing warnings about the executable stack > > > > > on > > > > > mips*el to improve its signal/noise ratio. > > > > > > > > At this stage there is nothing that can be done on the glibc side, the > > > > decision has to be taken by the mips porters. > > > > > > We are getting very close to the toolchain freeze. Any decision about > > > that? > > > > JFYI: There is the request to disable this tag completely on MIPS > > architectures in https://bugs.debian.org/1025436 > > > > Now I wonder if this would actually help or worsen the situation for > > the glibc maintainers. > > > > Guillem: You wrote something about "bullseye" in #1025436. I think you > > meant "bookworm" instead. Am I right? > > Indeed, sorry, I was going by Aurelien's comment, but botched the > release name. :) But in any case, I'll defer to whatever take Aurelien > or other glibc maintainers have on this. Given we got no decision from the MIPS porters before the toolchain freeze, we'll have to live with the executable stack on mips*el for bookworm. Therefore I believe it's a good idea to disable that tag on mips*el on the lintian side. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1029046: Wayland session doesn't get back to life post-suspend
Package: linux-image-6.1.0-1-amd64 Version: 6.1.4-1 Severity: important Hello there, this is a regression from 6.0.0 too; after post-suspend wakeup, my plasma wayland session stays frozen; the two DisplayPort screens light up, backgrounds are shown, but the mouse doesn't move, nothing works. I'm reportbug'ging this from a SysRQ-R, Ctrl-Alt-F2 text tty. >From cursory dmesg reading, it seems amdgpu has an "IB test failed" _before_ kernel suspend. This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't light up", so feel free to close the bug; I'll test if I get the same symptoms on an unpatched kernel anyway :-) Best, OdyX -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.1.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.1.0-1-amd64 recommends: ii apparmor 3.0.8-1 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.1.0-1-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii grub-efi-amd64 2.06-7 pn linux-doc-6.1
Bug#993589: distro-info-data: Please consider shipping default mirror URLs per distro
Hi Johannes (2021.09.03_09:09:02_-0400) > we currently carry Debian mirror URLs in many different packages. It > would be great if there could be one package that shipped a machine > readable list of the currently correct mirror URLs for each distro. I've put some thought into this bug (and similar ones) over the years. I like the idea of distro-info & distro-info-data taking on more responsibility, but it probably means we need to redesign the data schema. I'm thinking YAML/toml data. That in turn means rewriting the distro-info libraries (at least to provide a new API for the new data). I'd be tempted to write the canonical implementation in rust and have bindings in Perl/Python/C. But we could also have completely separate implementations as we do right now. So, basically, from my PoV, the reason this bug has languished is because these are big changes and I haven't felt the urge to start on them. If somebody were to propose a data model, I'd be happy to review it and discuss next steps. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1028423: RFS: spek/0.8.5-1 [ITP] [RC] -- acoustic spectrum analyser
Hi Bastian, thank you for your precious help. I think I've fixed everything, I just don't know what do you mean with > Please drop debian/autoreconf.*. There is no file named autoreconf.*. inside the debian dir. What exactly should I do? You can download the DFSG package with dget: dget -x https://mentors.debian.net/debian/pool/main/s/spek/spek_0.8.5+dfsg-1.dsc Please, I think we can make it! I'm trying to be as fast as possible. Forgive my ignorance: many things are new to me. Have a good night. -- Matteo Bini
Bug#747303: openssh-server: Please move pam_selinux open call higher in the session PAM stack
control: user selinux-de...@lists.alioth.debian.org control: usertag -1 selinux Hi, an improved patch, which also reorders pam_motd, can be found at https://salsa.debian.org/ssh-team/openssh/-/merge_requests/20.
Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t
Hi Axel, On 15-01-2023 23:07, Axel Beckert wrote: TL;DR: [...] You're awesome. And indeed, what a shame of your time. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1029045: ledgersmb: login page Perl error in default config
Package: ledgersmb Version: 1.6.9+ds-2+deb11u3 Severity: important X-Debbugs-Cc: j-dbug.666.114.1...@x.firehead.org Dear Maintainer, I installed LedgerSMB with defaults on Debian-11 with systemd. It starts fine with Starman, but when I go to http://localhost:5762/login.pl it shows only this message: - Error! Can't locate object method "new" via package "Template" at /usr/share/ledgersmb/bin/../lib/LedgerSMB/Template.pm line 599. dbversion: , company: 1.6.9 - Thus leaving the package in an unusable state. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads) 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 ledgersmb depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.12 ii libcarp-always-perl 0.16-1 ii libcgi-emulate-psgi-perl 0.23-1 ii libcgi-simple-perl 1.115-2 ii libclass-c3-xs-perl 0.15-1+b1 ii libconfig-inifiles-perl 3.03-1 ii libdata-uuid-perl 1.226-1+b1 ii libdatetime-format-strptime-perl 1.7800-1 ii libdatetime-perl 2:1.54-1 ii libdbd-pg-perl 3.14.2-1+b1 ii libdbi-perl 1.643-3+b1 ii libhtml-escape-perl 1.10-1+b3 ii libhttp-exception-perl 0.04007-1 ii libio-stringy-perl 2.111-3 ii libjs-dojo-dijit 1.15.4+dfsg1-1+deb11u1 ii libjson-perl 4.03000-1 ii liblocale-codes-perl 3.66-1 ii liblocale-maketext-lexicon-perl 1.00-1.1 ii liblog-log4perl-perl 1.54-1 ii libmime-lite-perl 3.031-1 ii libmime-types-perl 2.18-1 ii libmoose-perl 2.2014-2 ii libmoosex-nonmoose-perl 0.26-1.1 ii libnamespace-autoclean-perl 0.29-1 ii libnumber-format-perl 1.75-1.1 ii libpgobject-perl 2.2.0-1 ii libpgobject-simple-perl 3.02-1.1 ii libpgobject-simple-role-perl 2.02-1.1 ii libpgobject-type-bigfloat-perl 2.001-1 ii libpgobject-type-bytestring-perl 1.2.3-1 ii libpgobject-type-datetime-perl 2.02-1 ii libpgobject-util-dbadmin-perl 1.4.0-1 ii libpgobject-util-dbmethod-perl 1.00.003-1 ii libplack-builder-conditionals-perl 0.05-1.1 ii libplack-middleware-reverseproxy-perl 0.16-1 ii libplack-perl 1.0048-1 ii libplack-request-withencoding-perl 0.14-1 ii libtemplate-perl 2.27-1+b3 ii libtext-markdown-perl 1.31-3 ii libtry-tiny-perl 0.30-1 ii libversion-compare-perl 0.14-1.1 ii libxml-simple-perl 2.25-1 ii perl 5.32.1-4+deb11u2 ii postgresql-client 13+225 ii postgresql-client-13 [postgresql-client] 13.9-0+deb11u1 ii postgresql-contrib 13+225 ii starman 0.4015-1 ii ucf 3.0043 Versions of packages ledgersmb recommends: pn libjson-xs-perl pn liblatex-driver-perl pn libmath-bigint-gmp-perl pn libtemplate-plugin-latex-perl pn libtex-encode-perl ii lighttpd 1.4.59-1+deb11u2 pn texlive-latex-recommended Versions of packages ledgersmb suggests: pn default-mta | mail-transport-agent pn latex-cjk-all pn libimage-size-perl pn libopenoffice-oodoc-perl pn libx12-parser-perl pn lpr ii postgresql 13+225 pn texlive-xetex -- debconf information: * ledgersmb/lsmb_proxy: Lighttpd * ledgersmb/admin_login: lsmb_dbadmin
Bug#1004226: autopkgtest: qemu only boots qcow2 images
Control: tags -1 pending On Sat, 22 Jan 2022 19:35:49 -0800 Ryan Tandy wrote: I'm attaching a patch to use format=qcow2 for the overlay image. Please let me know if you'd prefer a Salsa merge request instead. Thanks. Pushed to salsa. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#984229: mccs: diff for NMU version 1:1.1-9.1
Hi Adrien, On Mon, Jan 16, 2023 at 07:34:53PM +0200, Adrian Bunk wrote: > I've prepared an NMU for mccs (versioned as 1:1.1-9.1) and uploaded > it to DELAYED/14. Please feel free to tell me if I should cancel it. thanks a lot, I just uploaded version 1.1-10, which includes your patch, to unstable. Cheers -Ralf.
Bug#1028336: adduser: [INTL:nl] Dutch translation for the adduser package
Hi, thanks for your work. Can you add a license statement please and update the Project-Id-Version? Greetings Marc On Mon, Jan 09, 2023 at 05:54:07PM +0100, Frans Spiesschaert wrote: > Please find attached the updated Dutch po file for the adduser package. > A draft was posted a few weeks ago to the debian-l10n-dutch mailing list > asking for review. > Please add it to your next package revision. > It should be put as "po/nl.po" in your package build tree. > > > -- > Kind regards, > Frans Spiesschaert > -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1029044: gcc-12-cross-mipsen: source and binary version go out of sync
Source: gcc-12-cross-mipsen Version: 1+c2 Severity: serious Dear maintainer, The current version in unstable is stuck, because the mips64el build is kept in Uploaded state. Asking around on #d-buildd, I got the following discussion: [20:09:34] mips64el 3days in uploaded state feels like an issue, right? https://buildd.debian.org/status/package.php?p=gcc-12-cross-mipsen [20:18:32] probably means dak rejected it [20:18:45] Your upload included the binary package cpp-12-mips-linux-gnu, version 12.2.0-13cross1, for mips64el, [20:18:48] however unstable already has version 12.2.0-14cross2. [20:19:09] coccia:/srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c1_mips64el-buildd.changes.reason [20:29:57] the higher version is [20:29:57] Source: gcc-12-cross-mipsen (2+c1) [20:30:23] so the generated version numbers are broken [20:32:07] not for the first time afair [[21:04:30] adsb: thanks for looking; but the source is 3+c1, no? or did the older one generate a newer binary? You may want to check your logic. Paul
Bug#1029043: AttributeError: module 'adonthell' has no attribute 'audio_load_wave'
Package: adonthell Version: 0.3.8-2.1 Severity: normal X-Debbugs-Cc: davide.pr...@null.net Dear Mainteiner, I have installed the adonthell package, but if I try to execute it I get: $ adonthell-wastesedge Traceback (most recent call last): File "/usr/share/games/adonthell/games/wastesedge/scripts/init.py", line 234, in adonthell.audio_load_wave (0, "audio/select.wav") ^ AttributeError: module 'adonthell' has no attribute 'audio_load_wave' exec_file: init load failed: I don't know Python language... I have done some search and found that adonthell.audio_load_wave do not exists but exists adonthell.audio.load_wave I have see that there are a lot similar problems in the init.py file and not only this one. Ciao Davide -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 6.0.12-dp-20221218 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 adonthell depends on: ii libc62.36-8 ii libgcc-s112.2.0-13 ii libpython3.113.11.1-2 ii libsdl2-2.0-02.26.2+dfsg-1 ii libsdl2-mixer-2.0-0 2.6.2+dfsg-2 ii libsdl2-ttf-2.0-02.20.1+dfsg-2 ii libstdc++6 12.2.0-13 ii python3 3.10.6-3+b1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages adonthell recommends: ii adonthell-data 0.3.8-1 adonthell suggests no packages. -- no debconf information
Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)
Hi Soren, Soren Stoutner wrote: > On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote: > > > Debian, of course, prefers the Expat name as it is more precise. > > > > According to > > https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a > > nd_SPDX SPDX does not have the Expat license. They do have though the "MIT > > License" (the one and only ;-), so that would imply that they're not the > > same license. > > Anyone who tells you there is a One And Only MIT License is trolling you. ;) Seems as if I should used more smileys on that sentence. Consider having been trolled by myself. ;-) > https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants Or said otherwise: I read exactly that page (and https://www.gnu.org/licenses/license-list.en.html#Expat) before sending my reply. > "The name 'MIT License' is potentially ambiguous. Yes, but IMHO https://spdx.org/licenses/ managed to get quite a good list on all the variants including unamigous short names for them. Except that they miss the "Expat license". Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1029042: jenkins-job-builder: flaky autopkgtest (host dependent)
Source: jenkins-job-builder Version: 3.11.0-4 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails on amd64. The failures seem related on the host that runs the test. ci-worker13 is a beefy machine [1], while the other amd64 workers are much more moderate [2]. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://metal.equinix.com/product/servers/m3-large/ [2] https://aws.amazon.com/ec2/instance-types/m5/ OpenPGP_signature Description: OpenPGP digital signature
Bug#1029041: O: gftp -- X/GTK+ and console FTP client (metapackage)
Package: wnpp Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gftp I intend to orphan the gftp package. It looked like upstream would migrate to gtk3 and was a bit active, but since then the activity seems to have died off. For users using this, filezilla seems like a reasonable replacement. (Which I too have migrated to). The package description is: gFTP is a multithreaded FTP client, available in two versions: * version for X, written using GLib and GTK+ * version for the console, using only GLib . This is an upgrade convenience package, it's only useful for depending on.
Bug#1028964: noweb: Want to use documentclass scrbook instead of book
Hello Hubert, then I will prepare it for an upload. What is your preferred way? Should I do it as anew revision and register my name into debian/control? Or should I do it as NMU? Kind regards 'Mechtilde Am 16.01.23 um 03:57 schrieb Hubert Chathi: On Sun, 15 Jan 2023 12:47:04 +0100, Mechtilde Stehmann said: At upstream there is an additional line, so there it is line 16. I also filled a patch. You can find a patch under https://github.com/nrnrnr/noweb/pull/28/files Most of the changes look pretty straightforward, but why did you remove the "\def\nwgitversion{|GITVERSION|}" line? (Also, I'd recommend that you give your PR a more descriptive name)
Bug#1029040: 389-ds-base: systemd unit file not restarting ldap server after segfault
Package: 389-ds-base Version: 1.4.4.11-2 Severity: normal Dear Maintainer, I recently noticed that the systemd unit file distributed with this package does not specify any Restart= policy. According to the systemd documentation, this means the implicit default of Restart=no is used. This is rather sad, as any bug in the server (such as one that leads to its segfault) will render the service disabled without recovering automatically. I've recently ran into that situation: Jan 16 16:17:07 REDACTED ns-slapd[166]: [16/Jan/2023:16:17:07.675187250 +] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 1 pages freed Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Main process exited, code=killed, status=11/SEGV Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Failed with result 'signal'. Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Consumed 3h 5min 10.445s CPU time. Now of course in an ideal world processed would never segfault. However, that's besides the point. A vital service like LDAP should attempt to recover/respawn after it crashes for whatever reason. So I would like to suggest that a "Restart=always" line is added to the dirsrv@.service file. -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages 389-ds-base depends on: ii 389-ds-base-libs 1.4.4.11-2 ii acl 2.2.53-10 ii adduser 3.118 ii debconf [debconf-2.0]1.5.77 ii ldap-utils 2.4.57+dfsg-3+deb11u1 ii libc62.31-13+deb11u5 ii libcrypt11:4.4.18-4 ii libdb5.3 5.3.28+dfsg1-0.8 ii libicu67 67.1-7 ii libldap-2.4-22.4.57+dfsg-3+deb11u1 ii libmozilla-ldap-perl 1.5.3-3+b2 ii libnetaddr-ip-perl 4.079+dfsg-1+b5 ii libnspr4 2:4.29-1 ii libnss3 2:3.61-1+deb11u2 ii libpam0g 1.4.0-9+deb11u1 ii libsasl2-2 2.1.27+dfsg-2.1+deb11u1 ii libsasl2-modules-gssapi-mit 2.1.27+dfsg-2.1+deb11u1 ii libsnmp405.9+dfsg-4+deb11u1 ii libsocket-getaddrinfo-perl 0.22-3 ii libsystemd0 247.3-7+deb11u1 ii perl 5.32.1-4+deb11u2 ii python3 3.9.2-3 ii python3-lib389 1.4.4.11-2 ii python3-selinux 3.1-3 ii python3-semanage 3.1-1+b2 ii python3-sepolicy 3.1-1 ii systemd 247.3-7+deb11u1 389-ds-base recommends no packages. 389-ds-base suggests no packages. -- Configuration Files: /etc/dirsrv/config/certmap.conf [Errno 13] Permission denied: '/etc/dirsrv/config/certmap.conf' /etc/dirsrv/config/ldap-agent.conf [Errno 13] Permission denied: '/etc/dirsrv/config/ldap-agent.conf' /etc/dirsrv/config/slapd-collations.conf [Errno 13] Permission denied: '/etc/dirsrv/config/slapd-collations.conf' /etc/dirsrv/config/template-initconfig [Errno 13] Permission denied: '/etc/dirsrv/config/template-initconfig' /etc/dirsrv/schema/99user.ldif [Errno 13] Permission denied: '/etc/dirsrv/schema/99user.ldif' -- no debconf information
Bug#1029039: shiro: CVE-2023-22602
Source: shiro X-Debbugs-CC: t...@security.debian.org Severity: normal Tags: security Hi, The following vulnerability was published for shiro. CVE-2023-22602[0]: | When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, | a specially crafted HTTP request may cause an authentication bypass. | The authentication bypass occurs when Shiro and Spring Boot are using | different pattern-matching techniques. Both Shiro and Spring Boot | 2.6 default to Ant style pattern matching. Mitigation: Update to | Apache Shiro 1.11.0, or set the following Spring Boot configuration | value: `spring.mvc.pathmatch.matching-strategy = ant_path_matcher` https://lists.apache.org/thread/dzj0k2smpzzgj6g666hrbrgsrlf9yhkl Given that we don't include Spring Boot in Debian, this has little impact. I doubt mixing Shiro as packaged in Debian with an externally deployed Spring Boot is any realistic scenario... If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-22602 https://www.cve.org/CVERecord?id=CVE-2023-22602 Please adjust the affected versions in the BTS as needed.
Bug#1029037: radare2: CVE-2023-0302
Source: radare2 X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for radare2. CVE-2023-0302[0]: | Failure to Sanitize Special Elements into a Different Plane (Special | Element Injection) in GitHub repository radareorg/radare2 prior to | 5.8.2. https://huntr.dev/bounties/583133af-7ae6-4a21-beef-a4b0182cf82e/ https://github.com/radareorg/radare2/commit/961f0e723903011d4f54c2396e44efa91fcc74ce If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-0302 https://www.cve.org/CVERecord?id=CVE-2023-0302 Please adjust the affected versions in the BTS as needed.
Bug#1029038: zip4j: CVE-2023-22899
Source: zip4j X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for zip4j. CVE-2023-22899[0]: | Zip4j through 2.11.2, as used in Threema and other products, does not | always check the MAC when decrypting a ZIP archive. https://github.com/srikanth-lingala/zip4j/issues/485 https://github.com/srikanth-lingala/zip4j/commit/597b31afb473a40e8252de5b5def1876bab198d3 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-22899 https://www.cve.org/CVERecord?id=CVE-2023-22899 Please adjust the affected versions in the BTS as needed.
Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar
On Mon, Jan 16, 2023 at 08:33:07AM -0800, tony mancill wrote: > On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote: > > > https://lists.debian.org/debian-legal/2023/01/msg5.html > > > https://lists.debian.org/debian-mentors/2023/01/msg00097.html > > Roberto, Tobias, thanks for your answers. > > > > I have removed MagicSFver2.sf2 from the package and added a note to > > README.Debian. > > The new package now depends on fluid-soundfont-gm, see > > https://mentors.debian.net/package/tuxguitar/ > > > > The package builds and runs on amd64 and in Qemu for arm64. It looks pretty > > good to me now. > > Maybe someone can take a look and upload it? > > If there is anything more I can do, just let me know. > > Hello Helmar, > > I am reviewing the updated package now and will either sponsor an upload > if everything looks good or provide feedback. The update looks great! I have updated debian/copyright to document the files that are licensed under a license other than the LGPL, but otherwise everything looks good. I will upload today. For the time-being, I will push the updated sources and tag to the current java-team repo [1], but we may want adjust that before the bullseye release since the package is no longer team-maintained. Thank you for your work on this! tony [1] https://salsa.debian.org/java-team/tuxguitar
Bug#1028496:
+1 It would be great if you could package the 525.xx version, as none of the GeForce RTX 40 series is currently supported in Debian, not through the proprietary drivers nor nouveau. Thanks, Alessio
Bug#1029036: inventor: includes non-free source
Source: inventor Version: 2.1.5-10-25 Severity: serious Your package cointains stdmacro with the comment: .\"Copyright (c) 1984 AT .\" All Rights Reserved .\" THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT .\" The copyright notice above does not evidence any actual .\" or intended publication of such source code. This file is non-free, so please repack to get rid of it.
Bug#1029035: ncl: includes non-free source
Source: ncl Version: 6.6.2-12 Severity: serious Your source package includes lex.yy_linux.c which has: /* Copyright (c) 1989 AT */ /*All Rights Reserved */ /* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */ /* The copyright notice above does not evidence any*/ /* actual or intended publication of such source code. */ Please repack getting rid of that file.
Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)
On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote: > > Debian, of course, prefers the Expat name as it is more precise. > > According to > https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a > nd_SPDX SPDX does not have the Expat license. They do have though the "MIT > License" (the one and only ;-), so that would imply that they're not the > same license. Anyone who tells you there is a One And Only MIT License is trolling you. ;) https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants[1] "The name 'MIT License' is potentially ambiguous. The Massachusetts Institute of Technology has been using many licenses for software since its creation; for example, MIT offers four licensing options for the FFTW[2] C source code library, one of which is the GPL v2.0[3] and the other three of which are not open-source[4]. The term 'MIT License' has also been used to refer to the *Expat License* (used for the XML parsing library Expat[5]) and to the *X11 License* (also called '*MIT/X Consortium License'*; used for X Window System[6] by the MIT X Consortium[7]). Furthermore, the 'MIT License' as published by the Open Source Initiative[8] is the same as the Expat License. Due to this differing use of terms, some prefer to avoid the name 'MIT License'. The Free Software Foundation[9] argues that the term is misleading and ambiguous, and recommends against its use.” https://www.gnu.org/licenses/license-list.html#Expat[10] As noted in the quote above, and in the second link, the license that is most commonly called the MIT License is what is appropriately referred to as the Expat license in Debian. https://www.debian.org/legal/licenses/mit[11] If you prefer I can open a separate bug about this issue, as it is my belief that Lintian should consider an Expat license in debian/copyright to not be a conflict with a MIT license in an AppStream metainfo.xml file. -- Soren Stoutner so...@stoutner.com [1] https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants [2] https://en.wikipedia.org/wiki/FFTW [3] https://en.wikipedia.org/wiki/GNU_General_Public_License [4] https://en.wikipedia.org/wiki/Open-source_software [5] https://en.wikipedia.org/wiki/Expat_(library) [6] https://en.wikipedia.org/wiki/X_Window_System [7] https://en.wikipedia.org/wiki/MIT_X_Consortium [8] https://en.wikipedia.org/wiki/Open_Source_Initiative [9] https://en.wikipedia.org/wiki/Free_Software_Foundation [10] https://www.gnu.org/licenses/license-list.html#Expat [11] https://www.debian.org/legal/licenses/mit signature.asc Description: This is a digitally signed message part.
Bug#1029034: snack: includes non-free source
Source: snack Version: 2.2.10.20090623-dfsg-10 Severity: serious jkFormant.c contains the following license info: /* formant.c */ /* * This software has been licensed to the Centre of Speech Technology, KTH * by AT Corp. and Microsoft Corp. with the terms in the accompanying * file BSD.txt, which is a BSD style license. * *"Copyright (c) 1987-1990 AT, Inc. *"Copyright (c) 1986-1990 Entropic Speech, Inc. *"Copyright (c) 1990-1994 Entropic Research Laboratory, Inc. * All rights reserved" * * Written by: David Talkin * Revised by: John Shore * */ [...] /* Copyright (c) 1987, 1988, 1989 AT */ /*All Rights Reserved */ /* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */ /* The copyright notice above does not evidence any*/ /* actual or intended publication of such source code. */ /* downsample.c */ While the file part that is copied from formant.c is okay to be included in Debian, the part from downsample.c is not. Please repack the source package getting rid of the file.
Bug#1029033: RFS: ruby-mdl/0.12.0-2 -- Markdown lint tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ruby-mdl": * Package name : ruby-mdl Version : 0.12.0-2 Upstream contact : ["p...@ipom.com"] * URL : https://github.com/markdownlint/markdownlint * License : MIT * Vcs : https://salsa.debian.org/nbehrnd/ruby-mdl Section : ruby The source builds the following binary packages: ruby-mdl - Markdown lint tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ruby-mdl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-2.dsc Changes since the last upload: ruby-mdl (0.12.0-2) unstable; urgency=medium . * Source only upload for migration to testing Regards, -- Norwid Behrnd
Bug#1029032: ITP: python-google-api-core -- Google API client core library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: python-google-api-core Version : 1.34.0 Upstream Author : 2014- Google Inc. * URL : https://github.com/googleapis/python-api-core * License : Apache-2.0 Programming Lang: Python Description : Google API client core library This library is not meant to be stand-alone. Instead it defines common helpers used by all Google API clients.
Bug#1029031: dcap: includes non-free source
There are more affected files in plugins/gssapi. I guess you have to get rid of dcap-tunnel-gsi. As you are the maintainer for the only reverse dependency gfal2-plugin-dcap you can coordinate the uploads.
Bug#1029031: dcap: includes non-free source
Source: dcap Severity: serious Version: 2.47.12-4 plugins/gssapi/gssIoTunnel.c has the following comment: * Copyright (c) 2000,2001,2002 DESY Hamburg DMG-Division * All rights reserved. * * THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF * DESY Hamburg DMG-Division * * Copyright (c) 1997 - 2002 Kungliga Tekniska H�gskolan (Royal Institute of * Technology, Stockholm, Sweden). All rights reserved. Please repack the source package to get rid of the file.
Bug#1021079: NMU w/o ppc64el?
On Mon, Jan 16, 2023 at 08:26:37AM +0200, Konstantinos Margaritis wrote: > On 15/1/23 03:33, Adam Borowski wrote: > > Hi! > > As you're apparently too busy to either fix ppc or suggest a different plan, > > I'd make a NMU dropping ppc64el for now so the package can be released with > > Bookworm. > > > > Please say if I shouldn't. > It is true that I am busy during this period, which may explain the lack of > communication. Now regarding vectorscan w/o ppc64le, I have 2 serious bugs I > want to fix before a new version upload (5.4.9), one is on Arm (a regression > compared to x86) and the other is the failure on ppc64le. How long do I have > to make an upload and ensure bookworm release? If that is too soon, then I > will make an upload asap myself disabling ppc64le until I fix this locally. Feb 12 is the cut-off; the package must be in testing at that time. Then if you have autopkgtests (vectorscan does), there's two more months before hard freeze. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1029030: [INTL:es] Spanish translation of the debconf template
Package: diaspora-installer Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# diaspora-installer po-debconf translation to Spanish. # Copyright (C) 2015 Software in the Public Interest # This file is distributed under the same license as the diaspora-installer package. # # Changes: # - Initial translation # Jonathan Bustillos , 2015. # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans msgid "" msgstr "" "Project-Id-Version: diaspora-installer\n" "Report-Msgid-Bugs-To: diaspora-instal...@packages.debian.org\n" "POT-Creation-Date: 2017-04-27 12:48+0530\n" "PO-Revision-Date: 2023-01-05 17:46+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: Poedit 2.4.2\n" #. Type: string #. Description #: ../diaspora-common.templates:1001 msgid "Host name for this instance of Diaspora:" msgstr "Nombre de equipo para esta instancia de Diaspora:" #. Type: string #. Description #: ../diaspora-common.templates:1001 msgid "" "Please choose the host name which should be used to access this instance of " "Diaspora." msgstr "" "Elija el nombre de equipo que se debe utilizar para acceder a esta instancia " "de Diaspora." #. Type: string #. Description #: ../diaspora-common.templates:1001 msgid "" "This should be the fully qualified name as seen from the Internet, with the " "domain name that will be used to access the pod." msgstr "" "Debe ser el nombre completamente cualificado como se ve a través de " "Internet, con el nombre de dominio que se utilizará para acceder al «pod»." #. Type: string #. Description #: ../diaspora-common.templates:1001 msgid "" "If a reverse proxy is used, give the hostname that the proxy server responds " "to." msgstr "" "Si se utiliza un proxy inverso, introduzca el nombre de equipo del servidor " "proxy." #. Type: string #. Description #: ../diaspora-common.templates:1001 msgid "" "This host name should not be modified after the initial setup because it is " "hard-coded in the database." msgstr "" "El nombre de equipo no debe ser modificado después de la configuración " "inicial ya que está codificado en la base de datos." #. Type: note #. Description #: ../diaspora-common.templates:2001 msgid "PostgreSQL application password" msgstr "Introduzca la contraseña de PostgreSQL" #. Type: note #. Description #: ../diaspora-common.templates:2001 msgid "" "You can leave the PostgreSQL application password blank, as the \"ident\" " "authentication method is used, allowing the diaspora user on the system to " "connect to the Diaspora database without a password." msgstr "" "Puede dejar la contraseña de PostgreSQL en blanco, ya que se utiliza el " "método de autenticación «ident», que permite al usuario de diaspora " "conectarse a la base de datos de Diaspora sin contraseña." #. Type: boolean #. Description #: ../diaspora-common.templates:3001 msgid "Enable https?" msgstr "¿Activar https?" #. Type: boolean #. Description #: ../diaspora-common.templates:3001 msgid "" "Enabling https means that an SSL/TLS certificate is required to access this " "Diaspora instance (as Nginx will be configured to respond only to https " "requests). A self-signed certificate is enough for local testing (and can be " "generated using, for instance, the package easy-rsa), but will not be " "accepted for federation with other Diaspora pods." msgstr "" "Activar https significa que se requiere un certificado SSL/TLS para acceder " "a esta instancia de Diaspora (debido a que Nginx se configurará sólo para " "responder a las solicitudes https). Un certificado autofirmado es suficiente " "para una prueba local (y se puede generar utilizando, por ejemplo, el " "paquete easy-rsa), pero no será aceptado para la federación con otros «pods» " "de Diaspora." #. Type: boolean #. Description #: ../diaspora-common.templates:3001 msgid "" "Some certificate authorities like Let's Encrypt (letsencrypt.org), StartSSL " "(startssl.com) offer free SSL/TLS certificates that work with Diaspora; " "however, certificates provided by CAcert will not work with Diaspora." msgstr "" "Algunas autoridades de certificación como
Bug#1029029: [INTL:es] Spanish translation of the debconf template
Package: mini-buildd Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# mini-buildd po-debconf translation to Spanish # Copyright (C) 2010-2013 Software in the Public Interest # This file is distributed under the same license as the mini-buildd package. # # Changes: # - Initial translation # Francisco Javier Cuadrado , 2010 # # - Updates # Matías Bellone , 2013 # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # msgid "" msgstr "" "Project-Id-Version: mini-buildd 0.8.13\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-12-28 19:22+\n" "PO-Revision-Date: 2023-01-05 15:59+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian l10n Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.4.2\n" #. Type: note #. Description #: ../mini-buildd.templates:2001 msgid "mini-buildd data purge warning" msgstr "Advertencia sobre purga de datos de mini-buildd" #. Type: note #. Description #: ../mini-buildd.templates:2001 msgid "You have chosen to purge mini-buildd." msgstr "Ha seleccionado purgar mini-buildd." #. Type: note #. Description #: ../mini-buildd.templates:2001 msgid "" "As a consequence, the mini-buildd user will be removed along with all the " "files it owns, possibly including Debian repositories." msgstr "" "Como resultado de esta acción, se eliminará el usuario mini-buildd junto con " "todos los archivos que le pertenecen, entre los que posiblemente se " "encuentren repositorios Debian." #. Type: note #. Description #: ../mini-buildd.templates:2001 msgid "To keep this data, you need to back it up now." msgstr "" "Si quiere mantener estos datos, debe realizar una copia de seguridad ahora." #. Type: string #. Description #: ../mini-buildd.templates:3001 msgid "Home path:" msgstr "Ruta del directorio personal («/home»):" #. Type: string #. Description #: ../mini-buildd.templates:3001 msgid "" "Please choose the directory where mini-buildd data will be stored. The " "directory will also be the home directory for the mini-buildd user." msgstr "" "Seleccione el directorio donde se almacenarán los datos de mini-buildd. Este " "directorio también será el directorio personal («/home») del usuario mini-" "buildd." #. Type: string #. Description #: ../mini-buildd.templates:3001 msgid "" "It should have enough space for all the builders and repositories you plan " "to use." msgstr "" "Debe tener suficiente espacio para todos los constructores y repositorios " "que planea utilizar." #. Type: password #. Description #: ../mini-buildd.templates:4001 msgid "Administrator password for mini-buildd:" msgstr "Contraseña del administrador de mini-buildd:" #. Type: password #. Description #: ../mini-buildd.templates:4001 msgid "" "Please choose the password for the administrative user of mini-buildd. This " "password will be used for the \"admin\" user in mini-buildd's web interface " "and API." msgstr "" "Elija una contraseña para el usuario administrador de mini-buildd. Se " "utilizará esta contraseña para el usuario «admin» en la interfaz web de mini-" "buildd y en la API." #. Type: password #. Description #: ../mini-buildd.templates:4001 msgid "" "If you enter a password, this will also trigger the creation of a local " "\"admin\" user (if not existing already)." msgstr "" "Si introduce una contraseña se creará un usuario «admin» local (si aún no " "existe)." #. Type: password #. Description #: ../mini-buildd.templates:4001 msgid "" "If you leave this empty, nothing will be done (no potential \"admin\" user " "creation, no password change)." msgstr "" "Si deja este campo vacío no se realizará ninguna acción (no se creará ningún " "usuario «admin» ni tampoco se cambiará la contraseña)." #. Type: string #. Description #: ../mini-buildd.templates:5001 msgid "Extra options:" msgstr "Opciones adicionales:" #. Type: string #. Description #: ../mini-buildd.templates:5001 msgid "" "Using no extra options is perfectly fine, and would run (unencrypted) HTTP " "on port 8066." msgstr "" "Si no configura ninguna opción adicional, el servicio se ejecutará sin " "cifrar (HTTP) en el puerto 8066." #. Type: string #. Description #:
Bug#1029028: [INTL:es] Spanish translation of the debconf template
Package: nova Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# nova po-debconf translation to Spanish. # Copyright (C) 2013 Software in the Public Interest # This file is distributed under the same license as the nova package. # # Changes: # - Initial translation # Jonathan Bustillos , 2012. # # - Updates # Jonathan Bustillos , 2012, 2013, 2014. # Matías Bellone , 2013. # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans msgid "" msgstr "" "Project-Id-Version: nova\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-12-28 19:45+\n" "PO-Revision-Date: 2023-01-05 15:47+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: Poedit 2.4.2\n" #. Type: string #. Description #: ../nova-common.templates.in:2001 msgid "Value for my_ip:" msgstr "Valor para my_ip:" #. Type: string #. Description #: ../nova-common.templates.in:2001 msgid "This value will be stored in the my_ip directive of nova.conf." msgstr "" "Este valor será almacenado en la directiva «my_ip» del archivo «nova.conf»." #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "Neutron server URL:" msgstr "URL del servidor Neutron:" #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "Please enter the URL of the Neutron server." msgstr "Introduzca la URL del servidor Neutron." #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Neutron admin tenant name:" msgstr "Nombre del inquilino («tenant») administrador del servidor Neutron:" #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "" "Nova needs to be able to communicate with Neutron through Keystone. " "Therefore Nova needs to know the Neutron admin tenant, username and password." msgstr "" "Nova necesita comunicarse con Neutron a través de Keystone. Por lo tanto, " "Nova debe conocer el inquilino («tenant») administrador de Neutron, el " "usuario y la contraseña." #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Please enter the name of the admin tenant for Neutron." msgstr "" "Introduzca el nombre del inquilino («tenant») administrador para Neutron." #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Neutron administrator username:" msgstr "Nombre del administrador de Neutron:" #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Please enter the username of the Neutron administrator." msgstr "Introduzca el nombre de usuario del administrador de Neutron." #. Type: password #. Description #: ../nova-common.templates.in:6001 msgid "Neutron administrator password:" msgstr "Contraseña del administrador de Neutron:" #. Type: password #. Description #: ../nova-common.templates.in:6001 msgid "Please enter the password of the Neutron administrator." msgstr "Introduzca la contraseña del administrador de Neutron." #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "Metadata proxy shared secret:" msgstr "Secreto compartido del proxy de metadatos:" #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "" "VM instances using Neutron to handle networking retrieve their metadata " "through the Neutron metadata agent, which serves as a proxy to the Nova " "metadata REST API server." msgstr "" "Las máquinas virtuales que utilizan Neutron para gestionar la red, obtienen " "sus metadatos a través del agente de metadatos de Neutron, que actúa como un " "proxy para el servidor de metadatos de la API REST de Nova." #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "" "Please enter the password that should be used to protect communications " "between the Neutron metadata proxy agent and the Nova metadata server. The " "same shared password should be used when setting up the neutron-metadata-" "agent package." msgstr "" "Introduzca la contraseña que se utilizará para proteger las comunicaciones " "entre el agente proxy de metadatos de Neutron y el servidor de metadatos de " "Nova. Debe usar la misma contraseña compartida cuando configure el paquete "
Bug#1029027: [INTL:es] Spanish translation of the debconf template
Package: uptimed Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# uptimed po-debconf translation to spanish # Copyright (C) 2004 Software in the Public Interest # This file is distributed under the same license as the uptimed package. # # Changes: # - Initial translation # Rudy Godoy , 2006 # # # Traductores, si no conoce el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/coordinacion # especialmente las notas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # msgid "" msgstr "" "Project-Id-Version: uptimed 0.3.8\n" "Report-Msgid-Bugs-To: upti...@packages.debian.org\n" "POT-Creation-Date: 2018-01-28 22:11+0800\n" "PO-Revision-Date: 2023-01-05 08:04+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian l10n Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.4.2\n" #. Type: string #. Description #: ../uptimed.templates:2001 msgid "Delay between database updates (seconds):" msgstr "Demora entre actualizaciones de la base de datos (en segundos):" #. Type: string #. Description #: ../uptimed.templates:2001 msgid "" "Uptimed will update its database regularly so that the uptime doesn't get " "lost in case of a system crash. You can set how frequently this will happen " "(use higher values if you want to avoid disk activity, for instance on a " "laptop)." msgstr "" "Uptimed actualizará su base de datos periódicamente para evitar que se " "pierda el tiempo de actividad en caso de que el sistema colapse. Puede " "configurar la frecuencia de actualización (use valores altos si desea evitar " "actividad del disco, por ejemplo, en un equipo portátil)." #. Type: string #. Description #: ../uptimed.templates:3001 msgid "Number of records that should be kept:" msgstr "Número de registros que desea mantener:" #. Type: string #. Description #: ../uptimed.templates:3001 msgid "" "Uptimed can limit the number of records to be kept to the highest n, to keep " "an unlimited number of records set this value to 0" msgstr "" "Uptimed puede limitar el número de registros que desea conservar hasta un " "valor máximo de «n». Si quiere mantener un número ilimitado de registros, " "configure este valor a «0»" #. Type: string #. Description #: ../uptimed.templates:3001 msgid "" "Be aware that uptime data will be lost if the limit has been reached and/or " "the number records is reduced." msgstr "" "Tenga en cuenta que los datos de tiempo de actividad se perderán si se ha " "alcanzado el límite y/o se ha reducido el número de registros." #. Type: select #. Choices #: ../uptimed.templates:4001 msgid "Never" msgstr "Nunca" #. Type: select #. Choices #: ../uptimed.templates:4001 msgid "Record" msgstr "Marca" #. Type: select #. Choices #: ../uptimed.templates:4001 msgid "Milestone" msgstr "Hito" #. Type: select #. Choices #: ../uptimed.templates:4001 msgid "Both" msgstr "Ambos" #. Type: select #. Description #: ../uptimed.templates:4002 msgid "Send mails if a milestone or record is reached:" msgstr "Enviar correos si se alcanza un hito o una marca:" #. Type: select #. Description #: ../uptimed.templates:4002 msgid "" "Uptimed can be configured to send a mail each time a record is broken or a " "\"milestone\" is reached. You can choose whether you:" msgstr "" "Puede configurar Uptimed para enviar un correo cada vez que se bate una " "marca o se alcance un hito. Puede elegir entre las siguientes opciones:" #. Type: select #. Description #: ../uptimed.templates:4002 msgid "" " * never want to receive these mails;\n" " * want to be notified only when a record is broken;\n" " * would like to know about milestones;\n" " * are interested in both." msgstr "" " * no quiero recibir este tipo de correos;\n" " * quiero recibir notificaciones sólo cuando se alcance una marca;\n" " * me gustaría recibir notificaciones de los hitos;\n" " * me interesa recibir ambas notificaciones." #. Type: string #. Description #: ../uptimed.templates:5001 msgid "Uptimed email recipient:" msgstr "Dirección de correo electrónico para notificaciones de Uptimed:" #. Type: string #. Description #: ../uptimed.templates:5001 msgid "" "Since you have chosen to be sent emails, you should specify where to send " "these mails." msgstr "" "Puesto que ha elegido que se envíen notificaciones, debe indicar
Bug#1029026: [INTL:es] Spanish translation of the debconf template
Package: unattended-upgrades Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# unattended-upgrades po-debconf translation to Spanish. # Copyright (C) 2007 Software in the Public Interest, SPI Inc. # This file is distributed under the same license as the unattended-upgrades package. # # Changes: # - Initial translation # Fernando González de Requena , 2009. # -Reviewers: # Javier Fernandez-Sanguino # # Traductores, si no conoce el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # # Si tiene dudas o consultas sobre esta traducción consulte con el último # traductor (campo Last-Translator) y ponga en copia a la lista de # traducción de Debian al español () # msgid "" msgstr "" "Project-Id-Version: unattended-upgrades 0.37debian1\n" "Report-Msgid-Bugs-To: unattended-upgra...@packages.debian.org\n" "POT-Creation-Date: 2017-12-12 23:02+0100\n" "PO-Revision-Date: 2022-12-29 18:58+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.4.2\n" #. Type: boolean #. Description #: ../templates:2001 msgid "Automatically download and install stable updates?" msgstr "" "¿Desea descargar e instalar automáticamente las actualizaciones de la " "versión estable?" #. Type: boolean #. Description #: ../templates:2001 msgid "" "Applying updates on a frequent basis is an important part of keeping systems " "secure. By default, updates need to be applied manually using package " "management tools. Alternatively, you can choose to have this system " "automatically download and install important updates." msgstr "" "Para mantener el sistema seguro es importante instalar las actualizaciones " "regularmente. De manera predeterminada, para poder realizar una " "actualización tiene que utilizar una herramienta de gestión de paquetes. " "Como alternativa, puede elegir que el sistema descargue e instale " "automáticamente las actualizaciones importantes."
Bug#1029025: [INTL:es] Spanish translation of the debconf template
Package: linux-base Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Cheers, -- Camaleón# linux po-debconf translation to Spanish # This file is distributed under the same license as the linux package. # # Changes: #- Initial translation # Omar Campagne 2010, 2011 # #- Review and update # Javier Fernandez-Sanguino, December 2010 # Matías Bellone , 2014 # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # msgid "" msgstr "" "Project-Id-Version: linux-2.6 2.6.32+5\n" "Report-Msgid-Bugs-To: linux-b...@packages.debian.org\n" "POT-Creation-Date: 2016-06-06 16:37+0100\n" "PO-Revision-Date: 2022-12-29 18:55+0100\n" "Last-Translator: Camaleón \n" "Language-Team: Debian l10n Spanish \n" "Language: es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: Poedit 2.4.2\n" #. Type: title #. Description #: ../linux-base.templates:2001 msgid "Removing ${package}" msgstr "Eliminando ${package}" #. Type: boolean #. Description #: ../linux-base.templates:3001 msgid "Abort kernel removal?" msgstr "¿Desea cancelar la eliminación del núcleo?" #. Type: boolean #. Description #: ../linux-base.templates:3001 msgid "" "You are running a kernel (version ${running}) and attempting to remove the " "same version." msgstr "" "Su sistema está ejecutando el núcleo (versión ${running}), y está intentando " "eliminar la misma versión del núcleo." #. Type: boolean #. Description #: ../linux-base.templates:3001 msgid "" "This can make the system unbootable as it will remove /boot/vmlinuz-" "${running} and all modules under the directory /lib/modules/${running}. This " "can only be fixed with a copy of the kernel image and the corresponding " "modules." msgstr "" "Puede que el sistema no pueda arrancar posteriormente, ya que eliminaría «/" "boot/vmlinuz-${running}» y todos los módulos en el directorio «/lib/modules/" "${running}». Esto sólo se puede arreglar con una copia de la imagen del " "núcleo y los correspondientes módulos." #. Type: boolean #. Description #: ../linux-base.templates:3001 msgid "" "It is highly recommended to abort the kernel removal unless you are prepared " "to fix the system after removal." msgstr "" "Se recomienda encarecidamente cancelar la eliminación del núcleo, a menos " "que esté preparado para arreglar el sistema después de la eliminación."
Bug#1028637: Spyder stops showing indent guides after restart
On Mon, Jan 16, 2023 at 05:48:11PM +0100, local10 wrote: > Tried the above twice, the indented block guides do NOT appear for me. > Flipping the "Show indent guides" menu option also doesn't bring the block > guides back, not sure why it worked before. > > Closing the tab and then restoring it with Ctrl+Shft+T does bring the indent > guides back. Oh this is super weird. I found that just waiting wasn't the thing; I needed to wait and then move my mouse or something similar. There's definitely something funny here. Hopefully the upstream developers will have some ideas. Best wishes, Julian
Bug#1027383: xen-tools: FTBFS in bullseye (missing build-depends on mount)
Hi. The relevant paragraph in Policy is this one: If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). Note that this is a MUST requirement in policy. Moreover, this policy 4.2 item is a release goal: Packages must list any packages they require to build beyond those that are "build-essential" in the appropriate Build-Depends: fields. Ref: 4.2 Source: https://release.debian.org/testing/rc_policy.txt So if you want to downgrade the bug, go ahead, but as explained, it would be wrong. Thanks.
Bug#1026103: aflplusplus: FTBFS on s390x
On Sun, Jan 15, 2023 at 12:12:39AM +0100, Bastian Germann wrote: >... > So the issue is > [!] LTO llvm_mode failed > [!] llvm_mode LTO instrumentlist feature compilation failed > [!] llvm_mode LTO persistent mode feature compilation failed The Ubuntu diff contains a change that was likely done to workaround this issue: aflplusplus (4.04c-2ubuntu2) lunar; urgency=medium * Disable lld support on s390x for now, making the build fail. -- Gianfranco Costamagna Wed, 21 Dec 2022 10:40:50 +0100 cu Adrian
Bug#993589: distro-info-data: Please consider shipping default mirror URLs per distro
Hi, On Fri, 03 Sep 2021 15:09:02 +0200 Johannes Schauer Marin Rodrigues wrote: > we currently carry Debian mirror URLs in many different packages. It > would be great if there could be one package that shipped a machine > readable list of the currently correct mirror URLs for each distro. > > This is useful, because we have already gone through many iterations of > mirror URLs like http.debian.net, httpredir.debian.org, deb.debian.org. > Now with bullseye we switched the security mirror from stable/updates to > stable-security. And currently on debian-devel there is a discussion > about http versus https as a default for the mirrors. > > If we shipped the information in one central package like > distro-info-data, then whenever we change it, we'd only need to change > this package and not all the many packages that require this > information. Which packages are currently shipping that information? I agree that it would be good to have this information in a central place. But the scope is more complex if we count in Ubuntu. Ubuntu has http://ports.ubuntu.com/ for non-x86 architectures. Ubuntu also does not have an equivalent to deb.debian.org - so consumers might need to have a list of mirrors to select from. -- Benjamin Drung Debian & Ubuntu Developer
Bug#984229: mccs: diff for NMU version 1:1.1-9.1
Control: tags 984229 + patch Control: tags 984229 + pending Dear maintainer, I've prepared an NMU for mccs (versioned as 1:1.1-9.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru mccs-1.1/debian/changelog mccs-1.1/debian/changelog --- mccs-1.1/debian/changelog 2020-05-28 12:52:06.0 +0300 +++ mccs-1.1/debian/changelog 2023-01-16 19:28:52.0 +0200 @@ -1,3 +1,12 @@ +mccs (1:1.1-9.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build with -std=gnu++14 to workaround FTBFS with gcc >= 11. +(Closes: #984229) + * Build with -g to add debug symbols to mccs-dbgsym. + + -- Adrian Bunk Mon, 16 Jan 2023 19:28:52 +0200 + mccs (1:1.1-9) unstable; urgency=medium [ Ondřej Nový ] diff -Nru mccs-1.1/debian/rules mccs-1.1/debian/rules --- mccs-1.1/debian/rules 2020-05-28 12:52:06.0 +0300 +++ mccs-1.1/debian/rules 2023-01-16 19:28:52.0 +0200 @@ -1,5 +1,7 @@ #!/usr/bin/make -f +export DEB_LDFLAGS_MAINT_APPEND += -std=gnu++14 -g + %: dh $@ --no-parallel
Bug#1029024: isc-dhcp-server: apparmor blocks reading files outside /etc/dhcpd
Package: isc-dhcp-server Version: 4.4.3-P1-1.1 Severity: normal Dear Maintainer, After upgrading from version 4.4.3-P1-1 to 4.4.3-P1-1.1 the added apparmor configurations block the include of files outside /etc/dhcp/, like DDNS TSIG keys definition that are usually installed under /etc/bind. I can understand avoiding to read files everywhere, but the use of TSIG keys defined by bind with is quite a common usage, that stop working with misleading permission denied error for readable files. This break previously working configurations, whitout a note in the changelog. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 isc-dhcp-server depends on: ii debconf [debconf-2.0] 1.5.80 ii debianutils5.7-0.4 ii libc6 2.36-7 ii lsb-base 11.5 ii sysvinit-utils [lsb-base] 3.06-2 Versions of packages isc-dhcp-server recommends: ii isc-dhcp-common 4.4.3-P1-1.1 ii policycoreutils 3.4-1 Versions of packages isc-dhcp-server suggests: ii ieee-data 20220827.1 pn isc-dhcp-server-ldap pn policykit-1 -- Configuration Files: /etc/dhcp/dhcpd.conf changed: authoritative; ddns-update-style standard; option local-pac-server code 252 = text; option local-pac-server "http://proxy.institute.lan:80/wpad.dat;; allow booting; include "/etc/bind/bookworm.institute.lan.key"; zone institute.lan. { primary 127.0.0.1; key bookworm.institute.lan; } subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.100 ; option domain-name-servers 192.168.1.1; option domain-name "institute.lan"; option routers 192.168.1.1; option ntp-servers 192.168.1.1; default-lease-time 86400; max-lease-time 172800; next-server 192.168.1.1; } zone 1.168.192.in-addr.arpa. { primary 127.0.0.1; key bookworm.institute.lan; } option architecture-type code 93 = unsigned integer 16; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; if option architecture-type = 00:00 { filename "/pxelinux.0"; } elsif option architecture-type = 00:09 { filename "/efi/syslinux.efi"; } elsif option architecture-type = 00:07 { filename "/efi/syslinux.efi"; } elsif option architecture-type = 00:06 { filename "/efi/syslinux.efi"; } } include "/etc/fuss-server/dhcp-reservations"; include "/etc/dhcp/dhcpd-added.conf"; -- debconf information: isc-dhcp-server/interfaces:
Bug#993590: distro-info-data: Store a mapping from distro to gpg keyring
Hi, On Fri, 03 Sep 2021 15:16:54 +0200 Johannes Schauer Marin Rodrigues wrote: > please consider storing a mapping from distro to keyring in > /usr/share/keyring. Currently there is no reliable way to retrieve the > authoritative keyring for a given distro name. Even when limiting > oneself to only Debian, it is not obvious for which suites one needs > /usr/share/keyrings/debian-archive-keyring.gpg and for which one needs > /usr/share/keyrings/debian-archive-removed-keys.gpg. I am not sure whether distro-info-data is the right place for it. Are there rules when keys move from debian-archive-keyring.gpg to debian- archive-removed-keys.gpg? Shouldn't that information better be shipped by debian-archive-keyring? Who would be the consumers? How would that information be used? -- Benjamin Drung Debian & Ubuntu Developer
Bug#1029023: puppet agent fails as regular user in default configuration
Package: puppet-agent Version: 7.21.0-2 When executing "puppet agent --test" as a regular user, in a default configuration, the command will fail with: Warning: /File[/var/lib/puppet/ssl]: Could not stat; permission denied Error: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Error: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Wrapped exception: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Error: /File[/var/lib/puppet/ssl]/ensure: change from 'absent' to 'directory' failed: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl This happens because in Debian the default setting for "ssldir" in Puppet is "/var/lib/puppet/ssl", whereas upstream uses "$confdir/ssl". A workaround is to run "puppet config set ssldir '$confdir/ssl'" to set "ssldir = $confdir/ssl" in "puppet.conf".
Bug#1029022: git should honour -c safe.directory
Package: git Version: 1:2.20.1-2+deb10u6 I have a script which I use for privsep builds of Rust stuff. Since a recent stable security update, I get this: fatal: detected dubious ownership in repository at '/home/ian/Rustup/Arti/arti' To add an exception for this directory, call: git config --global --add safe.directory /home/ian/Rustup/Arti/arti I understand the reason for this. However, my tool deliberately arranges to trust a repository owned by a different user: indeed, it is about to execute code from that user's directory. The build user trusts (must trust) the source code user, so this is fine. So I would like to pass -c safe.directory=* However This config setting is only respected when specified in a system or global config, not when it is specified in a repository config or via the command line option -c This is preventing me from disabling this check. I don't understand why we wouldn't trust the command line. 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#1029021: mutt-wizard: /usr/bin/mailsync is already shipped by the mailsync package
Package: mutt-wizard Version: 3.3.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Preparing to unpack .../mutt-wizard_3.3.1-1_all.deb ... Unpacking mutt-wizard (3.3.1-1) ... dpkg: error processing archive /var/cache/apt/archives/mutt-wizard_3.3.1-1_all.deb (--unpack): trying to overwrite '/usr/bin/mailsync', which is also in package mailsync 5.2.7-3.1+b1 Errors were encountered while processing: /var/cache/apt/archives/mutt-wizard_3.3.1-1_all.deb These files are in conflict: /usr/bin/mailsync /usr/share/man/man1/mailsync.1.gz cheers, Andreas mailsync=5.2.7-3.1+b1_mutt-wizard=3.3.1-1.log.gz Description: application/gzip
Bug#1029020: nmu: appstream-generator_0.8.8-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: appstream-genera...@packages.debian.org Control: affects -1 + src:appstream-generator I happened to notice that appstream-generator was keeping an old libphobos2-ldc-shared98 binary package installed on one of my systems. ldc's runtime library had a transition from libphobos2-ldc-shared98 to libphobos2-ldc-shared100 back in August, but the single package that depends on it (appstream-generator) was never rebuilt against the new libphobos2-ldc-shared98, making it uninstallable in unstable. I'm not sure why the release team's transition-detection tools didn't spot this at the time, but please consider: nmu appstream-generator_0.8.8-1 . amd64 arm64 i386 . unstable . -m "rebuild with libphobos2-ldc-shared100" I gave back the failed armel, armhf and s390x builds, of which armhf already succeeded, armel is in progress, and s390x has never succeeded so it's probably uninteresting. smcv
Bug#1029019: tzdata: [INTL:nl] Dutch translation of debconf messages
Package: tzdata Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of tzdata debconf messages. A draft was posted a few weeks ago to the debian-l10n-dutch mailing list asking for review. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#1027383: xen-tools: FTBFS in bullseye (missing build-depends on mount)
Hello Santiago Vila, While I do consider this a valid (wishlist) bug report, ... On Fri, Dec 30, 2022 at 07:04:32PM +0100, Santiago Vila wrote: > Package: src:xen-tools > Version: 4.9-1 > Severity: serious > Tags: ftbfs patch [...] > CPUs, using a reduced chroot with only build-essential packages (plus > debhelper). [...] This IMHO means you're using an *unsupported* system setup! None of the debootstrap variants lacks `Priority: required` packages and I don't think this warrants a release-critical severity. (You might argue about the exact wording of policy, but I think you should better do that in a policy bug report or their mailing list. This is not a practical problem until you use an unsupported setup, which means you get to keep all the pieces. The name of the priority level should be pretty self-explanatory - *required*, not recommended.) As already mentioned, I think wishlist is the proper severity. (And as said, I don't mind this being considered a bug or fixing it which is simple... however with a relevant severity.) Regards, Andreas Henriksson
Bug#1029018: glibc: [INTL:nl] Dutch translation of debconf messages
Package: glibc Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of glibc debconf messages. A draft was posted a few weeks ago to the debian-l10n-dutch mailing list asking for review. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip