Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
Control: tag -1 - patch + moreinfo After looking into this some more, I don't think this is necessarily a bug in dwz, but it could also be either someone using rogue DW_OP_* definitions with values 0x00 and 0x01 or a buggy compiler/assembler backend emitting junk. While applying the patch probably won't hurt, it will most probably not help either. @Diego: Could you still provide us with the unstripped shared library? That would make tracking this down much easier. Regards, Dennis
Bug#975535: elpy's autopkg tests fail with Python 3.9
On Sat, Jan 30, 2021 at 10:09:03PM -0500, Nicholas D Steeves wrote: > Hi Adrian, Hi Nicholas, > Thank you for checking in with this bug! Please let me know ASAP if > another autoremoval exception will be provided, because if necessary I > can do the shady thing of disabling tests to buy time...but I'd really > prefer not to! I am not a member of a release team, just a normal developer. Personally, I would go with disabling some (or all) tests if the package is overally working and the tests are the only worry for missing bullseye. > Regards, > Nicholas cu Adrian
Bug#876647: Provide facility to reload a profile when included snippets shipped by other packages are added/updated/removed
See also https://bugs.debian.org/872266, which is also about policy that confine programs shipped in other packages.
Bug#876647: dh-apparmor: Please support /etc/apparmor.d/apache
Control: retitle -1 Provide facility to reload a profile when included snippets shipped by other packages are added/updated/removed Hi, FTR, there's no real-world example in testing anymore of the exact use case why this was requested initially: - kopano-webapp was orphaned, removed from testing, and it's unlikely to come back any time soon. - We don't ship usr.lib.apache2.mpm-prefork.apache2 anymore. But: - We still ship usr.sbin.apache2 with "#include ". - It's no surprise that other packages don't do this sort of things, given it's not well supported by our packaging machinery. So I'm generalizing this bug report. Notes to whoever will work on this: - To me it screams "dpkg triggers", since they provide the kind of facility we need here, i.e. ensure package X is informed it shall do something whenever package Y is installed/updated/removed. In the example at hand, libapache2-mod-apparmor would be triggered and would reload the usr.sbin.apache2 profile, whenever a package adds/updates/removes bits in /etc/apparmor.d/apache2.d/. - I think the right thing to do depends on how the plugin integration is done wrt. non-AppArmor aspects. For example, if adding/updating/removing a plugin package does *not* restart the affected program, then I think we should not reload the AppArmor policy either: otherwise, we would confine an older, already running, version of the code, with a new version of the AppArmor policy, and they may very well be incompatible. Cheers!
Bug#978552: 978552: conventions for writing Linux man pages
Hi Felix, On 2021-02-06 00:13, Felix Lechner wrote: > Hi Andrius, > > On Fri, Feb 5, 2021 at 1:57 AM Andrius Merkys wrote: >> Within the man-pages project, the necessary updates to these timestamps >> are handled automatically > I like your idea, but how can the dates—being handled > automatically—ever be wrong? Do the scripts neglect to adjust manual > pages provided by Debian's maintainers? Thanks for reviewing my proposal! My proposal aims at the manpages that are written manually or semi-automatically. Particularly 'man-pages' project is not the aim here, I cite their conventions just to show that Debian manpages are supposed to follow the conventions of .TH structure. Best wishes, Andrius
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Hi, intrigeri (2021-01-08): > Christian Boltz (2021-01-07): >> I'd argue that this is a problem that is already solved ;-) >> >> Starting with AppArmor 3.0, all[1] upstream abstractions come with a >> rule like (example taken from abstractions/base): >> >> include if exists >> >> so if you create that directory and place a file there, it will be >> included by the abstraction. > >> [...] > >> For abstractions shipped by individual package (like libvirt), it would >> also make sense to add an include if exists >> rule to make it easy to add something to an abstraction. > > I like what Christian Boltz is proposing (thanks!): as far as > I understand, it can happen in libvirt upstream, will benefit even > non-Debian distros, and does not require modifying dh-apparmor. > > Christian Ehrhardt, how does it sound? Any reason why the approach you > initially suggested on this bug report is better? Ping? I'd like to add that one of the reasons for adding support for "include if exists" in AppArmor upstream was to cancel the need for distros to manage local override files via packaging machinery, which long term will allow us to simplify things like dh-apparmor, making them easier to maintain and to use :)
Bug#981430: RM: arduino [all] -- ROM; arduino-core abandoned, melted into arduino
Hello Ivo, Am 03.02.21 um 13:17 schrieb Ivo De Decker: [snip] > It seems the depends is versioned (arduino-core (>= 1:1.0+dfsg-8)). An > unversioned provides doesn't satisfy a versioned dependency. Apart from that, > I don't know if the dak rm dependency checking correctly handles provides. yes, the Depends in arduino-mk is versioned and the Provides in arduino is non versioned. That's the reason why it did not work automatically, I wasn't aware of this detail and have learned something for the future. [snip] >> I see the following info on the tracker site for arduino >> >>> Issues preventing migration: >>> missing build on all >>> arch:all not built yet, autopkgtest delayed >> >> So I was assuming that any old all cruft is around and that's why I >> created this report here. > > That is correct. You'll need to remove the moreinfo tag from this bug to get > it removed. If the fix for arduino-mk is coming soon, it might be best to wait > for that. Agreed. I've uploaded arduino-mk with the corrected Depends to delayed/3 after I've tested all this together locally. The delayed/3 will end tomorrow so if all goes well the potential migration issues for arduino should be gone on Friday 12th February next week as arduino-mk should migrate to testing then. Let's wait to see if new issues arise, if not I'm going to remove the moreinfo tag within next week. Thanks for helping to get the things sorted out and resetting removal counters! -- Regrads Carsten
Bug#982061: package-update-indicator throws GLib-ERROR and does not run
Package: package-update-indicator Version: package-update-indicator 7 package-update-indicator stopped working under debian sid 2 days ago. When I tried to launch it from command line this error message is thrown. ❯ package-update-indicator (package-update-indicator:4430): GLib-ERROR **: 09:37:44.786: ../../../glib/gmem.c:112: failed to allocate 94447068159347 bytes [1]4430 trace trap package-update-indicator This error started after a libelf1 update but I am not sure it is directly connected. I am using 5.10.0-3-amd64 #1 SMP Debian 5.10.12-1 (2021-01-30) x86_64 GNU/Linux other info: libc6/unstable,now 2.31-9 amd64 [installed] libc6/unstable,now 2.31-9 i386 [installed] libelf1/unstable,now 0.182+20210205-1 amd64 [installed] libelf1/unstable,now 0.182+20210205-1 i386 [installed,automatic] Regards
Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too
Package: hurd Version: DVD Binary-1 20200731-17:45 --- Please enter the report below this line. --- Having been aware of the GNU/HURD for some years and seeing that Debian offered it (and being subject to the general slow down in life in the era of COVID-19) I though it was worth having a go and trying to install it on a spare system. However, now I have found #959221 I have to say that trying to install onto a real machine with this later and different image does not seem any better. Some parts of the UI work acceptably fast but others, like around disk partitioning are dangerously unresponsive, fortunately I was working on a spare machine with only a single, empty SATA hard-drive otherwise it would have been easy for unhandled but stacked up key presses to damage existing OSes installed elsewhere in the system. In effect you press a key, and... ... nothing happens, so you think "oh that wasn't valid there" and press another key, and again... ... nothing happens ... after a while ... nothing happens ... then suddenly! Nothing continues to happen ... finally, the first key that you pressed takes effect, then the next, then the next - but by then the "cursor" is in the wrong place and the wrong thing happens! Now I am aware of this Bug I will try again when I can get to the machine (it is elsewhere) and this time be very sure and deliberate about which keys I press and where - and try and note down which bits are okay and which are like wading through concrete. Stephen --- System information. --- Auto-generated details suppressed because this is not from the system concerned and I did not get far enough in to get much to report back. "Dell" something or other Desktop PC with 2.8GHz Pentium D 1GB Memory 2x SATA: 500GB HDD 2x PATA: DVD-ROM drive connected --- Package information. - Not applicable. signature.asc Description: OpenPGP digital signature
Bug#982060: run-mailcap: special characters in file names break "open"
Package: mailcap Version: 3.68 Tags: security Dear Maintainer, run-mailcap fails if run as "open" on file names containing special characters. It also allows shell command injection from file names (again: https://www.debian.org/security/2014/dsa-3114). Example: $ echo 'text/plain; ls -l %s' >~/.mailcap $ file='foo bar.txt' $ touch "$file" $ run-mailcap "$file" # ok lrwxrwxrwx 1 mnz mnz 21 Feb 5 04:40 /tmp/tmp.34oUM9lQ1a -> '/home/mnz/foo bar.txt' $ open "$file" # broken ls: cannot access '/home/mnz/foo': No such file or directory ls: cannot access 'bar.txt': No such file or directory Warning: program returned non-zero exit code #512 $ file='$(rm -fr *).txt' $ touch "$file" $ run-mailcap "$file" # ok (the 'rm' is not executed) lrwxrwxrwx 1 mnz mnz 25 Feb 5 04:43 /tmp/tmp.LkHbZAUlGQ -> '/home/mnz/$(rm -fr *).txt' $ open "$file" # successful injection (the 'rm' is executed) ls: cannot access '/home/mnz/.txt': No such file or directory Warning: program returned non-zero exit code #512 -- The problem originates from this commit: https://salsa.debian.org/debian/mailcap/-/commit/66f82f13d86d565ebe249a8b56da8dd0cb63e2ef > Prevent run-mailcap from creating a temporary copy when run as "open". It's not a temporary copy but a temporary symlink. The TempFile function is only used to generate a name for the link. Currently run-mailcap makes temporary copies only when decompressing or reading from standard input. The man page is giving false information, please fix this too: SECURITY A temporary copy of the file is opened if the file name matches the Perl regular expression "[^[:alnum:],.:/@%^+=_-]", in order to protect from the injection of shell commands, and to make sure that the name can always be displayed in the current locale. An alternative to making a temporary symlink would be to properly quote special characters in the file name (as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980345). Thanks, MNZ
Bug#980632: cloud-sptheme: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
On Friday, January 29 2021, Andreas Tille wrote: > Hi, > > I have updated Git[1] to the latest upstream version to potentially > solve this issue. Unfortunately the build stops with: > > ... > copying cloud_sptheme/ext/static/auto_redirect.html_t -> > /build/cloud-sptheme-1.10.1.post20200504175005/.pybuild/cpython3_3.9/build/cloud_sptheme/ext/static > copying cloud_sptheme/ext/static/auto_redirect.css -> > /build/cloud-sptheme-1.10.1.post20200504175005/.pybuild/cpython3_3.9/build/cloud_sptheme/ext/static > python3 -m sphinx /build/cloud-sptheme-1.10.1.post20200504175005/docs > /build/cloud-sptheme-1.10.1.post20200504175005/html > Running Sphinx v3.4.3 > making output directory... done > > Theme error: > no theme named 'cloud' found (missing theme.conf?) > make[1]: *** [debian/rules:8: override_dh_auto_build] Error 2 > make[1]: Leaving directory '/build/cloud-sptheme-1.10.1.post20200504175005' > > > Since I'm not involved into the packaging of this package I rather stop > here and hope my commits are helpful to solve this issue. I was also > running routine-update to modernise the packaging - I hope you agree > with those changes. If not feel free to revert. Thanks for the work here, Andreas. I took some time today and fixed the remaining issues with the package. It's all in the git repo, but I thought it'd be good to write some summary of what I did here. In a nutshell: 1) I solved the problem with building the documentation by forcing sphinx to use the "classic" theme. I know, it's "strange" not to use the cloud theme to build cloud's docs, but I found this solution to be easier/cleaner to implement than fiddling with PYTHONPATH and other paths. 2) After solving the docs problem, I stumbled upon failures in the testsuite. This one took me a bit more time to figure out, but I found that it's a problem with Python 3.9 + mock 4. The fix is a one-liner and (hopefully) simple to understand. I don't know if it makes much sense to submit it upstream, because I don't know if it will break the setup of people using older versions of Python/mock. In any case, the patch is there with 'Forwarded: not-yet'. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Package: manpages-de,psmisc Severity: serious Version: manpages-de/4.2.0-1 Version: psmisc/23.4-1 Hi, there seems a new file conflict between manpages-de (uploaded in December) and the most recent psmisc upload: As I first run into it: Unpacking psmisc (23.4-1) over (23.3-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-IViNm3/17-psmisc_23.4-1_i386.deb (--unpack): trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in package manpages-de 4.2.0-1 But of course also happens the opposite way: Unpacking manpages-de (4.2.0-1) ... dpkg: error processing archive /var/cache/apt/archives/manpages-de_4.2.0-1_all.deb (--unpack): trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in package psmisc 23.4-1 Please decide which package should ship that man page. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) 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
Bug#982058: RFS: ruby-ae/1.8.2-2 [Team] -- assertive expressive (ae) is an assertions library
Package: sponsorship-requests Severity: normal Owner: sergi...@debian.org Dear mentors, I am looking for a sponsor for my package "ruby-ae": * Package name: ruby-ae Version : 1.8.2-2 Upstream Author : RubyWorks * URL : http://rubyworks.github.com/ae * License : Custom, BSD-2-clause * Vcs : https://salsa.debian.org/ruby-team/ruby-ae Section : ruby It builds those binary packages: ruby-ae - assertive expressive (ae) is an assertions library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ruby-ae/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/ruby-ae/ruby-ae_1.8.2-2.dsc Changes since the last upload: ruby-ae (1.8.2-2) unstable; urgency=medium . * Team upload. * Add debian/upstream/metadata. * debian/control: - Add Rules-Requires-Root: no. - Bump debhelper to version 13 and removal debian/compat. - Bump Standards-Version: 4.5.1. - Update VCS-Git and VCS-Browser fields to Salsa. * debian/copyright: - Add Upstream-Contact optional field according DEP-5. - Update format field to URL secure. - Add myself. * debian/watch: - Bump version of 3 to 4. - Change to gemwatch service. Regards, -- Leandro Cunha
Bug#187391: Fencetech Visitors Info List Details
Hello, Hope you and your family is doing well and safe. I am just following up to see if you are interested in acquiring the Attendees/Visitors list of, Fencetech-2021 23 - 26 Feb 2021 Nashville, USA Count = 10953 Each record of the list contains Contact Name, Email Address, Phone No, Title, Company Name, URL/Website, City, Country, Zip code. Let me know your thoughts so that we can send you the cost and additional information. Best Regards, Olivia Collins Business Executive
Bug#981635: [Debian-iot-maintainers] Bug#981635: Device database is not installed
Hello, Le 2021-02-02 à 06 h 44, Arto Jantunen a écrit : Under version 1.6 the device database isn't being installed since the packaging wasn't updated to do that when upgrading from version 1.5. I have created an MR on Salsa with the fix: https://salsa.debian.org/debian-iot-team/openzwave/-/merge_requests/1 Thanks for pointing out and thanks for the fix, the next package will fix the issue. /Nicolas OpenPGP_0xFE82139440BD22B9.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#981744: plasma-discover: Plasma-Discover immediately crashes
Hi, The latest round of updates (appstream specifically I think) appears to have resolved this issue. Cheers, Gerald
Bug#979492: jami: Package description should be improved
Hi Bruno, :-) Thank you for your patch. I've opened a merge request with improvements to both the package description and the appstream metadata: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/5 Alexandre, would you please merge this? Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#980571: jami-daemon: [patch] Get SIP calls to Zoom working
Hello and thanks to you both. :-) I opened a merge request adding this patch to d/patches for now: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/6 Alexandre, would you please merge this MR? Also, once this and the other MR are merged, let's do a new upload that would hopefully make it into testing on time before the freeze. Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#982048: wpasupplicant 2.2.7 on Debian 10 will not authnticate hotspot ap using NetworkManager debian 9 and 11 work downgradeing to 2.4 fixes
Package: wpasupplicant Version: 2:2.7+git20190128+0c1e29f-6+deb10u2 amd64 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wpasupplicant depends on: ii adduser 3.118 ii libc6 2.28-10 ii libdbus-1-3 1.12.20-0+deb10u1 ii libnl-3-200 3.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libpcsclite1 1.8.24-1 ii libreadline7 7.0-5 ii libssl1.0.2 1.0.2u-1~deb9u3 ii lsb-base 10.2019051400 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl pn wpagui -- no debconf information
Bug#932924: tt-rss: Packaging work for new upstream release 21.1
On 05/02/21 4:24 pm, Sebastian Reichel wrote: [...] > > I had some pending work from last year doing some of these changes > and some additional things. Back then I stopped when reaching the > gettext part wondering how to be solve it (IIUIC upstream's version > has some security fixes). Anyways your solution is better than doing > nothing, so I merged everything together and just uploaded a new > version. Just to summarize the situation with php-gettext: the library had a single security issue with use of eval() when parsing plural expressions (#976135). In Debian, it now has a proper fix through the implementation of a plural expression parser instead of using eval(). While there is no response from upstream for the merge request, tt-rss apparently picked up the fix in its vendored copy of gettext library. In Debian, tt-rss uses the Debian package for php-gettext. So, every thing is in good shape for this security issue. Other security issues found and fixed in upstream tt-rss (CVE-2020-25787 CVE-2020-25788 CVE-2020-25789) are unrelated to this. > > Your changes all looked sane and I'm mostly busy in the kernel world > these days and your help is appreciated. If I saw it correctly you are > not a DD, so I just gave you full permissions to the tt-rss repository. > Feel free to work directly in the repository without doing pull requests. Many thanks for permissions to the repository, the recent upload and in general for tt-rss. -- Sunil OpenPGP_signature Description: OpenPGP digital signature
Bug#981441: trapperkeeper-scheduler-clojure: FTBFS on all
Thanks to help from pabs, it seems the testsuite fails when network is not available. I didn't catch this since I use sbuild. It is not immediately obvious to me why the testsuite requires networking, but I'll try debugging further. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#956548: python-cassandra-driver: FTBFS on 32 bit arches
Hi, Thanks for the report. THis issues need investigation, for the new upstream release I skip that tests, but is just a workaround with aim to have the new version before Debian freeze. I'll can work on this, but not before Debian Freeze. Cheers, Emmanuel
Bug#982056: cgroup: cgroup2: unknown option "memory_recursiveprot"
Package: src:linux Version: 4.19.171-2 Severity: normal On my notebook boot use this version kernel,there is this error info display: cgroup: cgroup2: unknown option "memory_recursiveprot" This error info don't display in other version kernel. -- Package-specific info: ** Version: Linux version 4.19.0-14-rt-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PREEMPT RT Debian 4.19.171-2 (2021-01-30) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-14-rt-amd64 root=UUID=328e6c55-ebc0-4f3b-bd6d-bb97d31387c5 ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Timi product_name: TM1612 product_version: chassis_vendor: Timi chassis_version: Chassis Version bios_vendor: INSYDE Corp. bios_version: A05 board_vendor: Timi board_name: TM1612 board_version: MP ** Loaded modules: hidp ctr ccm rfcomm cmac bnep binfmt_misc nls_utf8 isofs nls_ascii nls_cp437 vfat loop fat uvcvideo btusb btrtl videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 btbcm btintel videobuf2_common bluetooth videodev media drbg ansi_cprng ecdh_generic intel_rapl wmi_bmof x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi kvm_intel snd_hda_codec_realtek arc4 joydev snd_hda_codec_generic kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlmvm evdev intel_cstate mac80211 intel_uncore intel_rapl_perf sg iwlwifi serio_raw iTCO_wdt pcspkr iTCO_vendor_support cfg80211 rfkill idma64 snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress battery snd_hda_intel int3403_thermal intel_hid snd_hda_codec sparse_keymap ac snd_hda_core wmi snd_hwdep i915 snd_pcm snd_timer pcc_cpufreq video int3400_thermal mei_me processor_thermal_device snd acpi_thermal_rel acpi_pad drm_kms_helper int340x_thermal_zone soundcore mei intel_soc_dts_iosf i2c_algo_bit button drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb hid_rmi rmi_core hid_generic sd_mod i2c_designware_platform i2c_designware_core crc32c_intel ahci xhci_pci libahci xhci_hcd aesni_intel aes_x86_64 libata intel_lpss_pci crypto_simd usbcore intel_lpss cryptd i2c_hid glue_helper i2c_i801 scsi_mod mfd_core usb_common hid fan thermal ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:190c] (rev 08) Subsystem: Xiaomi Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [1d72:1501] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 515 [8086:191e] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Xiaomi HD Graphics 515 [1d72:1501] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Skylake Processor Thermal Subsystem [8086:1903] (rev 08) Subsystem: Xiaomi Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [1d72:1501] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) (prog-if 30 [XHCI]) Subsystem: Xiaomi Sunrise Point-LP USB 3.0 xHCI Controller [1d72:1501] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) Subsystem: Xiaomi Sunrise Point-LP Serial IO I2C Controller [1d72:1501] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) Subsystem: Xiaomi Sunrise Point-LP Serial IO I2C Controller [1d72:1501] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
Bug#980836: pulseaudio: Internal speakers and microphone not automatically selected when headset is unplugged from jack
Package: pulseaudio Followup-For: Bug #980836 This seems to be a regression in 14.1, fixed upstream in 14.2: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1096 This affected me as well after upgrading to 14.1-1, but seems to be fixed after installing 14.2-1 from sid. -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pulseaudio depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libasound2 1.2.4-1.1 ii libasound2-plugins 1.2.2-2 ii libc6 2.31-9 ii libcap2 1:2.44-1 ii libdbus-1-3 1.12.20-1 ii libgcc-s1 10.2.1-6 ii libice6 2:1.0.10-1 ii libltdl7 2.4.6-15 ii liborc-0.4-0 1:0.4.32-1 ii libpulse0 14.2-1 hi libsm6 2:1.2.3-1 ii libsndfile1 1.0.31-1 ii libsoxr0 0.1.3-4 ii libspeexdsp1 1.2~rc1.2-1.1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.2-5 ii libtdb1 1.4.3-1+b1 ii libudev1 247.2-5 ii libwebrtc-audio-processing1 0.3-1+b1 ii libx11-6 2:1.7.0-2 ii libx11-xcb1 2:1.7.0-2 ii libxcb1 1.14-2.1 ii libxtst6 2:1.2.3-1 ii lsb-base 11.1.0 ii pulseaudio-utils 14.2-1 Versions of packages pulseaudio recommends: ii dbus-user-session 1.12.20-1 ii libpam-systemd [logind] 247.2-5 ii rtkit 0.13-4 Versions of packages pulseaudio suggests: ii paprefs 1.1-2 ii pavucontrol 4.0-2 pn pavumeter ii udev 247.2-5 -- Configuration Files: /etc/pulse/default.pa changed [not included] -- no debconf information
Bug#982055: O: dia -- Diagram editor
Package: wnpp Severity: normal I intend to orphan the dia package. The package description is: Dia is an editor for diagrams, graphs, charts etc. There is support for UML static structure diagrams (class diagrams), Entity-Relationship diagrams, network diagrams and much more. Diagrams can be exported to postscript and many other formats.
Bug#981703: slop: Improve man page for better apropos results
Control: tag -1 +moreinfo On 2021-02-03 01:16:10, GSR wrote: > Package: slop > Version: 7.5-1+b1 > Severity: minor > Tags: patch > > Hello: > > The man page could be improved to have better apropos(1) results. IOW, > to make the program appear with search terms that come to mind first, > as "select operation" is true but too abstract. See attached patch. > > Background: managed to find forgotten maim(1) via slop, but realized > both have rather short name blocks, making them rather invisible to > apropos unless you get the right word (of two possible). man -K uses > full man page text (slow, also in the sense of having to hit C-d many > times), while man -k or apropos seem to only use the one line name > part. Would you mind submitting this upstream at: https://github.com/naelstrof/slop/pulls It seems silly to carry such a patch only in Debian... Thanks! -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager
Bug#981632: RFS: materia-gtk-theme/20200916-0.1 [NMU] -- Material Design theme for GNOME/GTK+ based desktop environments
X-Debbugs-CC: debian-ment...@lists.debian.org Hi, Package listed in deferred uploads awaiting response from the maintainer in 2 days. [1] https://ftp-master.debian.org/deferred.html -- Cheers, Leandro Cunha Debian Contributor and developer.
Bug#982035: tasksel depends on man-pages-it which has been removed
Hi, Holger Wansing wrote: > I will file a new bug as a reminder, to re-add manpages-it to the > task-italian task again, when that package arrives in unstable. That's #982043 -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#982043: tasksel: please re-add manpages-it to 'task-italian' task, when available in unstable
Package: tasksel Severity: wishlist Tags: l10n Hi, manpages-it has been remove from tasksel's depends, since package was kicked out of unstable (see #982035 and #979034). It should be re-added to unstable some day though, so filing this bug as a reminder to reinstate the corresponding dependency. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#892275: redshift: Unable to connect to GeoClue
On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville wrote: > The problem is that the geoclue agent is started via a xdg autostart > file and redshift is started via a systemd user file meaning that the > ordering between these two is uncertain. Thank you for your advice. It's useful for me as i3 window manager. I can just use redshift on Debian sid as following: ``` $ sudo apt install redshift-gtk $ grep autostart ~/.i3/config | tail -1 exec ~/.i3/autostart $ head -1 ~/.i3/autostart /usr/libexec/geoclue-2.0/demos/agent & ``` Best regards, -- Kiwamu Okabe
Bug#982035: tasksel depends on man-pages-it which has been removed
Control: tags -1 + pending Paul Gevers wrote: > man-pages-it has been removed from unstable. Don't ask me how that is > possible as your package still depends on it, but it happened. Please > drop the dependency. The RM bug #979034 suggests the data now lives > elsewhere, albeit I don't know where. The data (italian translations) have been moved from manpages-it package to the manpages-l10n source-package (and translations updated). If manpages-l10n will be uploaded the next time from current git, manpages-it gets re-added to unstable again. Might not be in time for bullseye though... Because of that, I have removed manpages-it from tasksel depends for now. I will file a new bug as a reminder, to re-add manpages-it to the task-italian task again, when that package arrives in unstable. Tagging this bug as pending Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#982054: librdp-taxonomy-tree-java: FTBFS with OpenJDK 17 due to javadoc errors
Source: librdp-taxonomy-tree-java Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 librdp-taxonomy-tree-java fails to build with OpenJDK 17 due to a javadoc error: make[1]: Entering directory '/<>' jh_build rdp-taxonomy-tree.jar src warning: [options] bootstrap class path not set in conjunction with -source 7 warning: [options] source value 7 is obsolete and will be removed in a future release warning: [options] target value 7 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 4 warnings src/edu/msu/cme/rdp/taxatree/interfaces/TreeVisitor.java:31: error: @param name not found * @param taxon ^ src/edu/msu/cme/rdp/taxatree/interfaces/TreeVisitor.java:31: warning: no description for @param * @param taxon ^
Bug#982038: selinux-policy-src: policy archive contains dead modules.conf link
Package: selinux-policy-src Version: 2:2.20210203-1 Dear Maintainer, the extracted policy source (from /usr/src/selinux-policy-src.tar.gz) contains a dead link `modules.conf -> modules.conf.mls`. Its probably caused by https://salsa.debian.org/selinux-team/refpolicy/-/blob/debian/debian/rules#L164 Best regards, Christian Göttsche
Bug#932924: tt-rss: Packaging work for new upstream release 21.1
Hi Sunil, On Thu, Feb 04, 2021 at 08:56:28AM +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Johannes Schauer Marin Rodrigues (2021-02-04 08:50:51) > > oh wow! Thanks a ton for all your work! This is phantastic. :) > > while this still stands Ack. > > Do you want to do the upload yourself? Just add yourself to Uploaders as > > well > > while you are at it, you seem to know what you are doing and I'd love > > somebody > > to help out with packaging. Feel free to just put your commits directly into > > the packaging repo on salsa! That's already part of the changes :) > let me retract this -- somehow I didn't read "tt-rss" and confused packages XD > > It should of course not be me but Sebastian Reichel to make this call. :) I had some pending work from last year doing some of these changes and some additional things. Back then I stopped when reaching the gettext part wondering how to be solve it (IIUIC upstream's version has some security fixes). Anyways your solution is better than doing nothing, so I merged everything together and just uploaded a new version. Your changes all looked sane and I'm mostly busy in the kernel world these days and your help is appreciated. If I saw it correctly you are not a DD, so I just gave you full permissions to the tt-rss repository. Feel free to work directly in the repository without doing pull requests. Thanks, -- Sebastian signature.asc Description: PGP signature
Bug#982053: commons-httpclient: FTBFS with OpenJDK 17 due to com.sun.net.ssl removal
Source: commons-httpclient Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 commons-httpclient fails to build with OpenJDK 17 due to the removal of the com.sun.net.ssl package: [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ commons-httpclient --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 102 source files to /<>/target/test-classes Use of target 1.6 is no longer supported, switching to 7 Use of source 1.6 is no longer supported, switching to 7 [INFO] /<>/src/test/org/apache/commons/httpclient/TestHttpVersion.java: Some input files use or override a deprecated API that is marked for removal. [INFO] /<>/src/test/org/apache/commons/httpclient/TestHttpVersion.java: Recompile with -Xlint:removal for details. [INFO] /<>/src/test/org/apache/commons/httpclient/auth/TestChallengeProcessor.java: Some input files use unchecked or unsafe operations. [INFO] /<>/src/test/org/apache/commons/httpclient/auth/TestChallengeProcessor.java: Recompile with -Xlint:unchecked for details. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[49,23] package com.sun.net.ssl does not exist [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[50,23] package com.sun.net.ssl does not exist [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[51,23] package com.sun.net.ssl does not exist [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[57,20] cannot find symbol symbol: class SSLContext location: class org.apache.commons.httpclient.ssl.SimpleSSLTestProtocolSocketFactory [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[59,20] cannot find symbol symbol: class SSLContext location: class org.apache.commons.httpclient.ssl.SimpleSSLTestProtocolSocketFactory [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java:[87,20] cannot find symbol symbol: class SSLContext location: class org.apache.commons.httpclient.ssl.SimpleSSLTestProtocolSocketFactory [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java:[45,23] package com.sun.net.ssl does not exist [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java:[46,23] package com.sun.net.ssl does not exist [ERROR] /<>/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java:[47,23] package com.sun.net.ssl does not exist
Bug#982052: beckon-clojure: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6
Source: beckon-clojure Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 beckon-clojure fails to build with OpenJDK 17 because it invokes javac with the source/target options set to 6. Since OpenJDK 12 the minimum version supported is 7. make[1]: Entering directory '/<>' cat debian/header.html > /<>/CHANGES.html sed -i'' -e 's#@TITLE@#beckon changelog#g' /<>/CHANGES.html markdown /<>/CHANGES.md >> /<>/CHANGES.html cat debian/footer.html >> /<>/CHANGES.html cat debian/header.html > /<>/README.html sed -i'' -e 's#@TITLE@#beckon#g' /<>/README.html markdown /<>/README.md >> /<>/README.html cat debian/footer.html >> /<>/README.html jh_build --javacopts="-target 1.6 -source 1.6 -Xlint:-options" beckon.jar src/java error: Source option 6 is no longer supported. Use 7 or later. error: Target option 6 is no longer supported. Use 7 or later. jh_build: error: find src/java -name '*.java' -and -type f -print0 | xargs -s 512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp /usr/share/java/clojure.jar:debian/_jh_build.beckon -d debian/_jh_build.beckon -target 1.6 -source 1.6 -Xlint:-options -encoding ISO8859-1 returned exit code 123 make[1]: *** [debian/rules:14: override_jh_build] Error 25 make[1]: Leaving directory '/<>'
Bug#946882: blk-availability.service: may fail or unmount filesystems too soon
Control: tags -1 patch Control: retitle -1 blkdeactive hardcodes wrong path to sort On Mon, Dec 16, 2019 at 04:38:45PM -0800, Rob Leslie wrote: > On systems upgraded from stretch and without the usrmerge package installed, > /sbin/blkdeactivate (ExecStop= of blk-availability.service) gives the > following error during system shutdown: > > blkdeactivate[12003]: /sbin/blkdeactivate: line 345: /bin/sort: No such > file or directory It seems blkdeactive hardcodes /bin/sort as path to sort, while the correct path to sort is /usr/bin/sort (which is different on non-usrmerged systems). Obvious patch to fix this attached. Cheers, Ivo diff -Nur lvm2_2.03.11-2/scripts/blkdeactivate.sh.in lvm2_2.03.11-2i/scripts/blkdeactivate.sh.in --- lvm2_2.03.11-2/scripts/blkdeactivate.sh.in 2021-01-08 09:10:11.0 + +++ lvm2_2.03.11-2i/scripts/blkdeactivate.sh.in 2021-02-05 23:54:56.249130804 + @@ -60,7 +60,7 @@ LSBLK="/bin/lsblk -r --noheadings -o TYPE,KNAME,NAME,MOUNTPOINT" LSBLK_VARS="local devtype local kname local name local mnt" LSBLK_READ="read -r devtype kname name mnt" -SORT_MNT="/bin/sort -r -u -k 4" +SORT_MNT="/usr/bin/sort -r -u -k 4" # Do not show tool errors by default (only done/skipping summary # message provided by this script) and no verbose mode by default.
Bug#982051: com-hypirion-io-clojure: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6
Source: com-hypirion-io-clojure Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 com-hypirion-io-clojure fails to build with OpenJDK 17 because it invokes javac with the source/target options set to 6. Since OpenJDK 12 the minimum version supported is 7. make[1]: Entering directory '/<>' jh_build --javacopts="-target 1.6 -source 1.6 -Xlint:-options" hypirion-io.jar src error: Source option 6 is no longer supported. Use 7 or later. error: Target option 6 is no longer supported. Use 7 or later. jh_build: error: find src -name '*.java' -and -type f -print0 | xargs -s 512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp :debian/_jh_build.hypirion-io -d debian/_jh_build.hypirion-io -target 1.6 -source 1.6 -Xlint:-options -encoding ISO8859-1 returned exit code 123 make[1]: *** [debian/rules:16: override_jh_build] Error 25 make[1]: Leaving directory '/<>'
Bug#981924: trying to overwrite shared '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different from other instances of package libelf1:i386
Dear maintainers, I apologize, the bug 981924 has vanished from version 0.182+20210205-1 ; my mistake was due to the two successive updates 0.182+20210203-1.1 and 0.182+20210203-1.1+b1 that were both presenting the bug. Thanks for the fix Best, Ara
Bug#980571: please forward to upstream
Petter Reinholdtsen writes: > Control: forwarded -1 > https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/406 > > The SIP patch was applied to upstream master branch three days ago, > https://git.jami.net/savoirfairelinux/ring-daemon/-/commit/27504587e5dafadf986796f5ce0b1f065a3800bc > >. > > The FFMPEG patch has been included in the Debian package in bullseye > since 2021-01-29. Thanks for the update. Alexandre, since we are likely not pulling in a new upstream release for Debian testing last minute (there have been a few large upstream changes over the past ~2 weeks), let's apply this patch here on the Debian side. Also, I'll open an MR against the repo with a slightly revised patch for #979492, and once we've merged these two changes let's do a new upload to unstable asap so that hopefully it can make it into testing in time before the freeze next week. Best, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#966395: Double building?
Hi! > There is also the GnuTLS ability to load multiple certificates for > virtual-hosting HTTPS websites which OpenSSL simply cannot do itself. I > know a few users are liking that. I'm trying to make a double building like you suggested, but I don't think we'll make it in time for Bullseye. When changing the build rules I find some weird things like: On current build we ship usr/share/squid/mime.conf on squid-common, but on my build it gets installed on etc/squid/mime.conf, which place is the right one? Regards.
Bug#982050: There are fresh upstream releases (8.9.11 ATM) which address security and other issues
Package: htcondor Version: 8.6.8~dfsg.1-2 Severity: normal 8.6.8~dfsg.1-1 was uploaded over 3 years ago. Since then multiple upstream releases were made, possibly (didn't check) addressing CVE of Bugs with severity grave 1) #963777 condor: CVE-2019-18823 and possibly Bugs with severity serious 2) #925657 condor: ftbfs with GCC-9 3) #966726 condor: Unversioned Python removal in sid/bullseye In our case we also encountered "buffer overflow detected" upon running condor_q -json and it is unlikely worth filing a new issue without checking first if a upstream work of the past 3 years has likely addressed it. So it would be great to see a newer version of condor be shipped in Debian. Cheers, -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'unstable-debug'), (100, 'stable-updates'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages htcondor depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-5 pn libcgroup1 pn libclassad8 ii libcom-err2 1.45.6-1 ii libcurl4 7.72.0-1 ii libdate-manip-perl6.83-1 ii libexpat1 2.2.10-1 ii libgcc-s1 [libgcc1] 10.2.1-1 pn libglobus-callout0 pn libglobus-common0 pn libglobus-ftp-client2 pn libglobus-gass-transfer2 pn libglobus-gram-client3 pn libglobus-gram-protocol3 pn libglobus-gsi-callback0 pn libglobus-gsi-cert-utils0 pn libglobus-gsi-credential1 pn libglobus-gsi-openssl-error0 pn libglobus-gsi-proxy-core0 pn libglobus-gsi-proxy-ssl1 pn libglobus-gsi-sysconfig1 pn libglobus-gss-assist3 pn libglobus-gssapi-error2 pn libglobus-gssapi-gsi4 pn libglobus-io3 pn libglobus-openssl-module0 pn libglobus-rsl2 pn libglobus-xio0 ii libgomp1 10.2.1-1 ii libgssapi-krb5-2 1.18.3-4 ii libk5crypto3 1.18.3-4 ii libkrb5-3 1.18.3-4 ii libkrb5support0 1.18.3-4 ii libldap-2.4-2 2.4.56+dfsg-1 ii libltdl7 2.4.6-14 ii libpcre3 2:8.39-13 ii libssl1.1 1.1.1h-1 ii libstdc++610.2.1-1 ii libuuid1 2.36.1-2 ii libvirt0 6.9.0-1+b2 ii libx11-6 2:1.7.0-2 ii libxext6 2:1.3.3-1+b2 ii libxss1 1:1.2.3-1 ii lsb-base 11.1.0 ii perl 5.32.0-6 pn python ii zlib1g1:1.2.11.dfsg-2 Versions of packages htcondor recommends: pn dmtcp pn ecryptfs-utils Versions of packages htcondor suggests: pn coop-computing-tools ii docker.io 20.10.0+dfsg2-1 ii singularity-container 3.5.2+ds1-1 pn slurm-client
Bug#980571: please forward to upstream
Control: forwarded -1 https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/406 The SIP patch was applied to upstream master branch three days ago, https://git.jami.net/savoirfairelinux/ring-daemon/-/commit/27504587e5dafadf986796f5ce0b1f065a3800bc >. The FFMPEG patch has been included in the Debian package in bullseye since 2021-01-29. -- Happy hacking Petter Reinholdtsen
Bug#982016: [Pkg-utopia-maintainers] Bug#982016: avahi-daemon: a broken link left
control: tags -1 + confirmed Am 05.02.21 um 18:53 schrieb Patrice Duroux: Package: avahi-daemon Version: 0.8-4 Severity: minor Dear Maintainer, Upgrading it there is now a broken link left on many of my systems (laptop and servers): $ ls -l /etc/network/if-post-down.d/avahi-daemon.dpkg-backup lrwxrwxrwx 1 root root 23 26 mai2020 /etc/network/if-post-down.d/avahi- daemon.dpkg-backup -> ../if-up.d/avahi-daemon Since /etc/network/if-post-down.d/avahi-daemon is a symlink, I don't think we should remove it via maintscript/rm_conffile. Afair, symlinks are not marked as conffiles, so simply dropping it from the package should be enough. Now that we have a /etc/network/if-post-down.d/avahi-daemon.dpkg-backup, we probably needs some manual cleanup though. OpenPGP_signature Description: OpenPGP digital signature
Bug#982049: gdbserver: 32-bit segments are not set properly?
Package: gdbserver Version: 10.1-1.7 Severity: normal Dear Maintainer, I was using gdbserver to run 32-bit binary on a 64-bit machine. I ran `gdbserver localhost:1234 ./32bit-exe` on one terminal, and `gdb -ex "target remote :1234" -ex "c"` on another terminal. At this point, it segfaults somewhere in glibc when trying to access a gs memory segment: 0xf7de43ea <__ctype_init+10> push ebx 0xf7de43eb <__ctype_init+11> movedx, DWORD PTR [eax-0x16c] 0xf7de43f1 <__ctype_init+17> movebx, DWORD PTR [eax-0x140] → 0xf7de43f7 <__ctype_init+23> movedx, DWORD PTR gs:[edx] 0xf7de43fa <__ctype_init+26> movedx, DWORD PTR [edx] 0xf7de43fc <__ctype_init+28> movecx, DWORD PTR [edx+0x24] 0xf7de43ff <__ctype_init+31> addecx, 0x100 0xf7de4405 <__ctype_init+37> movDWORD PTR gs:[ebx], ecx 0xf7de4408 <__ctype_init+40> movecx, DWORD PTR [edx+0x28] Obviously, it was expected for this to not segfault here and crash, but it crashed here. Here I wrote a simple PoC of the same reproducable bug except without glibc (i.e. freestanding statically-linked binary) to show that the same error seems to exist, tho this time you would have to single-step through gdb through gdbserver in order to trigger the segfault bug: https://gist.github.com/theKidOfArcrania/cdba7c7ff42f95a0cfa2be897ca928db This bug seems to be the underlying cause of this other bug in pwntools (which directly uses gdbserver to open up a gdb instance): https://github.com/Gallopsled/pwntools/issues/1783 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdbserver depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 gdbserver recommends no packages. gdbserver suggests no packages. -- no debconf information
Bug#980885: manpages-es-extra: Suitable for Bullseye?
Hello Javier, as Helge already wrote, manpages-es-extra is far too outdated to worth shipping it in Bullseye. It is *now* the time to get rid of this package. Tomorrow we will release a new version of manpages-l10n, which will contain Spanish translations for the first time, after manpages-es vanished from Debian (for good reasons). I'm almost finished with the import of the plain text translations from manpages-es-extra, so I think the .po files will be available for translators a few days after the upcoming release. This means in return: Because manpages-l10n doesn't distinguish between »es« and »es-extra« files, the release in march will include the newly imported .po files – and raise file conflicts. I think you agree with me that it's better to have 100 .po files (at least 80% translated) which are up-to-date than 200 terribly outdated plain text translations which nobody benefits of. Best Regards, Mario
Bug#832683: Bug#818907
Still Debian Reference tells uppercase letters are ok for package name: https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names The regexes in table 2.16 are invalid, see https://bugs.launchpad.net/ubuntu/+source/debian-reference/+bug/1913869
Bug#981820: r-bioc-purecn: autopkgtest failure
On Fri, Feb 05, 2021 at 09:48:14PM +0100, Andreas Tille wrote: > Control: tags -1 help > > On Thu, Feb 04, 2021 at 12:44:46PM +0200, Adrian Bunk wrote: > > ══ Failed tests > > > > ── Error (test_annotateTargets.R:2:1): (code run outside of `test_that()`) > > ─ > > Error: there is no package called ‘TxDb.Hsapiens.UCSC.hg19.knownGene’ > > Backtrace: > > █ > > 1. └─base::library(TxDb.Hsapiens.UCSC.hg19.knownGene) > > test_annotateTargets.R:2:0 > > That's really strange. This line > > > https://salsa.debian.org/r-pkg-team/r-bioc-purecn/-/blob/master/debian/tests/run-unit-test#L23 > > was added to autopkgtest to remove test_annotateTargets.R which works > perfectly fine for me. Is there any strange reason why the removal does > not work on some other test environment? run-unit-testPASS pkg-r-autopkgtestFAIL non-zero exit status 1 You fixed this for the run-unit-test, what fails is the autopkgtest-pkg-r enabled in debian/control. > Kind regards > > Andreas. cu Adrian
Bug#981808: luajit: Minetest crash with luajit from the Debian buster arm64 repo
* AdrianLai [210205 22:22]: > Source: luajit [..] > I have tried to uninstall luajit from the Debian repo and built luajit from > source (https://github.com/LuaJIT/LuaJIT, branch v2.1). Minetest doesn't > crash in this case. In the github issue, sfan5 also reported that the > game works fine on Arch Linux ARM. Therefore, I think there are problems > in the Debian luajit build for arm64. Maybe the version is too old that > something has been fixed in the luajit v2.1 branch, or some Debian > specific patches break luajit for arm64. Well, which version of luajit did you use from Debian? In testing/bullseye, we have some arm64 patches, maybe they help. Chris
Bug#982047: wordwarvi: invalid Uploaders field: missing comma between Ricardo Mones & Joseph Nahmias
Source: wordwarvi Version: 1.0.3-1 Severity: serious Justification: Policy 5.6.3 wordwarvi 1.0.3-1 introduced an invalid uploaders field, that is missing a comma between Ricardo Mones & Joseph Nahmias. $ apt-cache showsrc wordwarvi | grep -E '^$|^Version|^Uploaders' Version: 1.00+dfsg1-5 Uploaders: Ricardo Mones Version: 1.0.3-1 Uploaders: Ricardo Mones Joseph Nahmias According to Debian policy 5.6.3 the Uploaders field must separate individual uploaders using commas: List of the names and email addresses of co-maintainers of the package, if any. ... The format of each entry is the same as that of the Maintainer field, and multiple entries must be comma separated. https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#981176: RFP: doas -- minimal replacement for sudo
On Wed, Jan 27, 2021 at 10:59:58AM +0100, Bernd Zeimetz wrote: > * Package name: doas > * URL : https://github.com/Duncaen/OpenDoas > Description : minimal replacement for sudo > > > OpenDoas: a portable version of OpenBSD's doas command > > With the regular security issues in sudo it would make sense > to have an alternative tools with a much smaller codebase. Qouting https://packages.debian.org/bullseye/pleaser please, a polite, regex-first sudo clone Delegate accurate least privilege access with ease. There are times when what is intended to be executed can be expressed easily with a regex to expose only what is needed and nothing more. Groeten Geert Stappers -- Silence is hard to parse
Bug#981153: cargo: Please package new upstream (blocks Firefox 85)
On Fri, Feb 05, 2021 at 09:53:52PM +0100, Leo "Costela" Antunes wrote: > On Fri, 5 Feb 2021 17:17:25 +0100 Geert Stappers wrote: > > Where can I find more information about "relax-cargo-deb.patch"? > > https://bazaar.launchpad.net/~mozillateam/firefox/firefox.groovy/view/head:/debian/patches/relax-cargo-dep.patch Closes thing to a "commit message" I could find about it is * Make cargo 0.47 aka 1.46.0 sufficient - debian/patches/relax-cargo-dep.patch Hope this Helps Groeten Geert Stappers -- Silence is hard to parse
Bug#978552: 978552: conventions for writing Linux man pages
Hi Andrius, On Fri, Feb 5, 2021 at 1:57 AM Andrius Merkys wrote: > > Within the man-pages project, the necessary updates to these timestamps > are handled automatically I like your idea, but how can the dates—being handled automatically—ever be wrong? Do the scripts neglect to adjust manual pages provided by Debian's maintainers? Kind regards Felix Lechner
Bug#981987: RFS: cbonsai/0.0~git20210115.e107005-1 [ITP] -- terminal-based bonsai tree generator
On Fri, Feb 05, 2021 at 03:40:31PM +0100, Robin Gustafsson wrote: > * Package name: cbonsai >Version : 0.0~git20210115.e107005-1 > cbonsai (0.0~git20210115.e107005-1) unstable; urgency=medium > . >* Initial release (Closes: #981965) Looks good, in NEW. The yellow color works only in some terminals, excluding eg. Linux console, despite yellow being among 16 basic colors. This happens only in curses modes, -p works ok. Glancing at |tee, I see that yellow gets output as \e[93m which Linux handles well (I've added this support myself in 4.9); I haven't investigated further what could be wrong. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#981812: nodejs: wrong timezone offset
Le jeu. 4 févr. 2021 à 08:06, Andrey Nikitin a
écrit :
> Package: nodejs
> Version: 12.20.1~dfsg-3
> Severity: normal
>
> Hi.
>
> Since "Dec 27 2020" TZ Europe/Volgograd = Europe/Moscow,
> with +03h offset.
>
> But nodejs use old (now wrong) +04h offset.
>
> $ env TZ="Europe/Moscow" nodejs -e 'console.log((new
> Date().getTimezoneOffset())/60)'
> -3
> $ nodejs -e 'console.log((new Date().getTimezoneOffset())/60)'
> -4
> $ env TZ="Europe/Volgograd" nodejs -e 'console.log((new
> Date().getTimezoneOffset())/60)'
> -4
>
> $ zdump -c 2020,2021 -V /usr/share/zoneinfo/Europe/Volgograd
> /usr/share/zoneinfo/Europe/Volgograd Sat Dec 26 21:59:59 2020 UT = Sun
> Dec 27 01:59:59 2020 +04 isdst=0 gmtoff=14400
> /usr/share/zoneinfo/Europe/Volgograd Sat Dec 26 22:00:00 2020 UT = Sun
> Dec 27 01:00:00 2020 +03 isdst=0 gmtoff=10800
>
> $ date +"%z (%Z)"
> +0300 (+03)
>
> $ strace nodejs -e 'console.log((new Date().getTimezoneOffset())/60)' 2>&1
> | grep zone
> stat("/usr/share/zoneinfo-icu/44/le/zoneinfo64.res", 0x7ffea7585330) = -1
> ENOENT (Нет такого файла или каталога)
> readlink("/etc/localtime", "../usr/share/zoneinfo/Europe/Vol"..., 4095) =
> 38
> stat("/usr/share/zoneinfo-icu/44/le/timezoneTypes.res", 0x7ffea7583570) =
> -1 ENOENT (Нет такого файла или каталога)
actually while icu fails to find files in zoneinfo-icu (i suppose it's a
compatibility thing with ubuntu),
it does parse /usr/share/zoneinfo/Europe/Volgograd
so i guess something's wrong in icu when it does that part.
Also i checked other browsers and they all have the same "issue":
- google chrome, official 88 release
- firefox
but they don't all depend on icu ?
Also i checked upstream nodejs version and
Welcome to Node.js v12.20.1.
Type ".help" for more information.
> var d = new Date("2021-04-13T00:00:00.000+08:00");
undefined
> d.toLocaleString('en-US', { timeZone: 'Europe/Moscow' })
'4/12/2021, 7:00:00 PM'
> d.toLocaleString('en-US', { timeZone: 'Europe/Volgograd' })
'4/12/2021, 8:00:00 PM'
bug is there too.
Jérémy
Bug#981747: network-manager: NetworkManager does not start in sysvinit system
* Luis MB : > > If you install the "orphan-sysvinit-scripts" package, that contains an init > script for (among other things) network-manager. > > > > HTH, > > Matthew > > Is this actually the case? I can't find documentation on this anywhere on > NetworkManager's page, nor can I find a page listing such orphaned scripts in > the Debian wiki, nor can I find the required path > (/etc/init.d/network-manager) > listed in packages.debian.org [1]. The data used by packages.debian.org appears to be outdated and sometimes missing nowadays. That's something you could have checked yourself by going to https://packages.debian.org/sid/orphan-sysvinit-scripts and clicking "list of files". > I feel like, as the person responsible for (intentionally and > unapologetically) > breaking the behaviour of the package, Michael Biebl could have documented > this > better and more officially. Or simply *not* have broken the behaviour of the > package. > > I'd like to refute the degradationof the package severity to Wishlist and > request that it be uplifted to at least "grave" or "important". Alternatively > I'd like an official wording on whether Debian developers are allowed to > intentionally break the behaviour of packages in a sysvinit system *and* > intentionally and continually refuse a fix or a patch. You are extremely disrespectful and unhelpful here. Please stop replying to this bug until you read up on the relevant decisions the project has made. Chris
Bug#982046: golang-github-avast-apkverifier: Missing test dependency on ca-certificates
Source: golang-github-avast-apkverifier Version: 0.0~git20191015.7330a51-4 Severity: serious https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-avast-apkverifier/10269472/log.gz ... autopkgtest [21:30:24]: test command1: ./runtests.sh autopkgtest [21:30:24]: test command1: [--- + [ -d apksig_for_tests ] + git clone --depth=1 -b android-o-mr1-iot-release-1.0.14 https://android.googlesource.com/platform/tools/apksig apksig_for_tests Cloning into 'apksig_for_tests'... fatal: unable to access 'https://android.googlesource.com/platform/tools/apksig/': server certificate verification failed. CAfile: none CRLfile: none autopkgtest [21:30:25]: test command1: ---] autopkgtest [21:30:25]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL non-zero exit status 128 autopkgtest [21:30:25]: test command1: - - - - - - - - - - stderr - - - - - - - - - - + [ -d apksig_for_tests ] + git clone --depth=1 -b android-o-mr1-iot-release-1.0.14 https://android.googlesource.com/platform/tools/apksig apksig_for_tests Cloning into 'apksig_for_tests'... fatal: unable to access 'https://android.googlesource.com/platform/tools/apksig/': server certificate verification failed. CAfile: none CRLfile: none ...
Bug#982009: Please, drop the obsolete /var for PIDFile in systemd unit file.
control: tags -1 confirmed > "Francesco" == Francesco Paolo Lovergine writes: Francesco> Syslog warns about that. Francesco> systemd[1]: /lib/systemd/system/krb5-kdc.service:7: Francesco> PIDFile= references a path below legacy directory Francesco> /var/run/, updating /var/run/krb5-kdc.pid → Francesco> /run/krb5-kdc.pid; please update the unit file Francesco> accordingly. Thanks. We're past the point for this sort of update for bullseye (at least unless there's another reason to change krb5), but I'll try to get to this early in the next release.
Bug#982045: libssw: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6
Source: libssw Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 libssw fails to build with OpenJDK 17 because it invokes javac with the source/target options set to 6. Since OpenJDK 12 the minimum version supported is 7. javac -target 1.6 -source 1.6 ssw/Aligner.java javac -target 1.6 -source 1.6 ssw/Alignment.java warning: [options] bootstrap class path not set in conjunction with -source 6 error: Source option 6 is no longer supported. Use 7 or later. error: Target option 6 is no longer supported. Use 7 or later. make[2]: *** [Makefile:51: ssw/Aligner.class] Error 2 make[2]: *** Waiting for unfinished jobs warning: [options] bootstrap class path not set in conjunction with -source 6 error: Source option 6 is no longer supported. Use 7 or later. error: Target option 6 is no longer supported. Use 7 or later. make[2]: *** [Makefile:51: ssw/Alignment.class] Error 2
Bug#970689: live-build: fails when lilo can't be installed, even if unused
Do you know if there's a workaround to this bug? Even if the devs won't fix it, it would still be nice to be able to compile an iso.
Bug#968448: telegram-desktop: Again no preview for images in file selection dialog
Hi, an chance that this annyoing bug will be fixed before the freeze? Kind regards Andreas. -- http://fam-tille.de
Bug#982044: lcm: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6
Source: lcm
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17
lcm fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum
version supported is 7.
make[3]: Entering directory '/<>/lcm-java'
chmod 755 lcm-logplayer-gui
chmod 755 lcm-spy
mkdir -p /<>/lcm-java/build
CLASSPATH=/<>/lcm-java/build:.//<>/lcm-java/build${CLASSPATH:+":$CLASSPATH"}
/usr/bin/javac -d /<>/lcm-java/build -source 1.6 -target 1.6
-classpath /usr/share/java/jchart2d.jar lcm/logging/LogDiagnostic.java
lcm/logging/Log.java lcm/logging/JScrubberListener.java
lcm/logging/LogPlayer.java lcm/logging/JScrubber.java
lcm/spy/LCMTypeDatabase.java lcm/spy/Spy.java lcm/spy/ObjectPanel.java
lcm/spy/ZoomableChartScrollWheel.java lcm/spy/ChartData.java
lcm/spy/SpyPlugin.java lcm/spy/ChannelData.java lcm/lcm/LCM.java
lcm/lcm/Provider.java
lcm/lcm/TCPProvider.java lcm/lcm/TCPService.java
lcm/lcm/LCMSubscriber.java lcm/lcm/LogFileProvider.java
lcm/lcm/MessageAggregator.java
lcm/lcm/MemqProvider.java lcm/lcm/UDPMulticastProvider.java
lcm/lcm/LCMEncodable.java lcm/lcm/LCMDataOutputStream.java
lcm/lcm/LCMDataInputStream.java
lcm/lcm/URLParser.java lcm/util/ParameterGUI.java
lcm/util/BufferedRandomAccessFile.java lcm/util/ColorMapper.java
lcm/util/ParameterListener.java
lcm/util/ClassDiscoverer.java lcm/util/TableSorter.java
lcm/util/JImage.java
warning: [options] bootstrap class path not set in conjunction with -source 6
error: Source option 6 is no longer supported. Use 7 or later.
error: Target option 6 is no longer supported. Use 7 or later.
make[3]: *** [Makefile:415: classnoinst.stamp] Error 2
make[3]: Leaving directory '/<>/lcm-java'
Bug#982042: linux-image-4.19.0-13-amd64: linux-image 4.19.0-14 fails to load a shorewall iptables based firewall due to address varible tests
Package: src:linux Version: 4.19.160-2 Severity: normal Dear Maintainer, -- Package-specific info: ** Version: Linux version 4.19.0-13-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-13-amd64 root=UUID=33214629-da09-4d68-9b1e-6c6f256f51b4 ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Red Hat product_name: KVM product_version: RHEL-7.6.0 PC (Q35 + ICH9, 2009) chassis_vendor: Red Hat chassis_version: RHEL-7.6.0 PC (Q35 + ICH9, 2009) bios_vendor: SeaBIOS bios_version: 1.11.0-2.el7 ** Loaded modules: xt_recent xt_statistic xt_addrtype ipt_REJECT nf_reject_ipv4 xt_multiport xt_comment nft_chain_route_ipv4 xt_conntrack xt_mark xt_connmark nft_chain_nat_ipv4 nf_nat_ipv4 xt_nat xt_CT xt_tcpudp nft_compat nft_counter nfnetlink_log xt_NFLOG nf_log_ipv4 nf_log_common xt_LOG nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink fuse virtio_gpu ttm drm_kms_helper joydev evdev drm iTCO_wdt virtio_balloon virtio_console iTCO_vendor_support serio_raw pcspkr qemu_fw_cfg button tcp_illinois virtio_rng rng_core ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper hid_generic aes_x86_64 usbhid hid virtio_blk virtio_net net_failover failover ahci libahci libata scsi_mod xhci_pci xhci_hcd psmouse crc32c_intel usbcore i2c_i801 lpc_ich mfd_core usb_common virtio_pci virtio_ring virtio ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] Subsystem: Red Hat, Inc QEMU Virtual Machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- BAR=0 offset= size= Capabilities: [70] Vendor Specific Information: VirtIO: Notify BAR=2 offset=3000 size=1000 multiplier=0004 Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg BAR=2 offset=2000 size=1000 Capabilities: [50] Vendor Specific Information: VirtIO: ISR BAR=2 offset=1800 size=0800 Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg BAR=2 offset=1000 size=0800 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:02.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [54] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #16, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt- SltCap: AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Slot #0, PowerLimit 0.000W; Interlock+ NoCompl- SltCtl: Enable: AttnBtn+ PwrFlt- MRL- PresDet- CmdCplt+ HPIrq+ LinkChg- Control: AttnInd Off, PwrInd On, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not
Bug#981153: [Pkg-rust-maintainers] Bug#981153: cargo: Please package new upstream (blocks Firefox 85)
On Fri, 5 Feb 2021 17:17:25 +0100 Geert Stappers wrote: > Where can I find more information about "relax-cargo-deb.patch"? > I did get the clue 'ubuntu', can I get a deep link? Here you go: https://bazaar.launchpad.net/~mozillateam/firefox/firefox.groovy/view/head:/debian/patches/relax-cargo-dep.patch Cheers, Leo
Bug#982040: ruby-password: annotate test dependencies
Source: ruby-password Version: 0.5.3-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs ruby-password fails to cross build from source, because it transitively requests a host architecture ruby executable and fails running it. I looked into the dependency tree and noticed that this is due to the ruby-termios dependency. Then I looked what it was needed for and found that both wamerican and ruby-termios are used for running tests. Please consider applying the attached patch to annotate them . Helmut diff --minimal -Nru ruby-password-0.5.3/debian/changelog ruby-password-0.5.3/debian/changelog --- ruby-password-0.5.3/debian/changelog2013-09-26 15:38:08.0 +0200 +++ ruby-password-0.5.3/debian/changelog2021-02-05 19:40:56.0 +0100 @@ -1,3 +1,10 @@ +ruby-password (0.5.3-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test dependencies . (Closes: #-1) + + -- Helmut Grohne Fri, 05 Feb 2021 19:40:56 +0100 + ruby-password (0.5.3-4) unstable; urgency=low * Team upload diff --minimal -Nru ruby-password-0.5.3/debian/control ruby-password-0.5.3/debian/control --- ruby-password-0.5.3/debian/control 2013-09-26 15:37:30.0 +0200 +++ ruby-password-0.5.3/debian/control 2021-02-05 19:40:54.0 +0100 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Ruby Extras Maintainers Uploaders: Micah Anderson , Gunnar Wolf , Ryan Niebur -Build-Depends: debhelper (>= 7.0.50~), gem2deb (>= 0.5~), cracklib-runtime, libcrack2-dev, wamerican | wordlist, ruby-termios (>= 1.0.0~) +Build-Depends: debhelper (>= 7.0.50~), gem2deb (>= 0.5~), cracklib-runtime, libcrack2-dev, wamerican | wordlist , ruby-termios (>= 1.0.0~) Standards-Version: 3.9.4 Vcs-Git: git://anonscm.debian.org/pkg-ruby-extras/ruby-password.git Vcs-Browser: http://anonscm.debian.org/gitweb?p=pkg-ruby-extras/ruby-password.git;a=summary
Bug#982041: scilab: reduce Build-Depends
Source: scilab Version: 6.1.0+dfsg1-7 User: debian-cr...@lists.debian.org Usertags: cross-satisfiability scilab cannot be cross built from source, because its Build-Depends are not satisfiable. Instead of looking into such a difficult problem, I looked into easily droppable dependencies. Since scilab is normally reproducible, I looked for dependencies that would not change output artifacts when dropped. A nocheck build with the following dependencies moved to Build-Conflicts exactly reproduces the binary artifacts of a regular build: * chrpath * libreadline-dev * procps * mpi-default-dev * libcobertura-java Of these, mpi-default-dev likely is a red herring as something else likely pulls libopenmpi-dev. The other dependencies look droppable to me, but some may be used for unit tests. Please either annotate them or drop them entirely. Helmut
Bug#981820: r-bioc-purecn: autopkgtest failure
Control: tags -1 help On Thu, Feb 04, 2021 at 12:44:46PM +0200, Adrian Bunk wrote: > ══ Failed tests > > ── Error (test_annotateTargets.R:2:1): (code run outside of `test_that()`) > ─ > Error: there is no package called ‘TxDb.Hsapiens.UCSC.hg19.knownGene’ > Backtrace: > █ > 1. └─base::library(TxDb.Hsapiens.UCSC.hg19.knownGene) > test_annotateTargets.R:2:0 That's really strange. This line https://salsa.debian.org/r-pkg-team/r-bioc-purecn/-/blob/master/debian/tests/run-unit-test#L23 was added to autopkgtest to remove test_annotateTargets.R which works perfectly fine for me. Is there any strange reason why the removal does not work on some other test environment? Kind regards Andreas. -- http://fam-tille.de
Bug#982039: xerces-c FTCBFS: uses AC_RUN_IFELSE
Source: xerces-c Version: 3.2.3+debian-3 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs xerces-c fails to cross build from source, because it uses AC_RUN_IFELSE to check for two wchar functions. It actually tests whether those functions behave as expected and such a test cannot be performed during cross building. I propose degrading the check to a function existence test during cross builds while keeping the elaborate check for native builds. Please consider applying the attached patch. Helmut --- xerces-c-3.2.3+debian.orig/configure.ac +++ xerces-c-3.2.3+debian/configure.ac @@ -227,6 +227,7 @@ AC_DEFINE_UNQUOTED([HAVE_MBRLEN], 0, [Define to 1 if you have the `mbrlen' function.]) ] ) +AC_CHECK_FUNC([wcsrtombs],[ AC_MSG_CHECKING([for wcsrtombs]) AC_RUN_IFELSE( [AC_LANG_PROGRAM([[#include #include ]], @@ -247,8 +248,17 @@ [ AC_MSG_RESULT([no]) AC_DEFINE_UNQUOTED([HAVE_WCSRTOMBS], 0, [Define to 1 if you have the `wcsrtombs' function.]) +], +[ + AC_MSG_RESULT([cross. guessing yes]) + AC_DEFINE_UNQUOTED([HAVE_WCSRTOMBS], 1, [Define to 1 if you have the `wcsrtombs' function.]) ] ) +], +[ + AC_DEFINE_UNQUOTED([HAVE_WCSRTOMBS], 0, [Define to 1 if you have the `wcsrtombs' function.]) +]) +AC_CHECK_FUNC([mbsrtowcs],[ AC_MSG_CHECKING([for mbsrtowcs]) AC_RUN_IFELSE( [AC_LANG_PROGRAM([[#include #include ]], @@ -269,8 +279,16 @@ [ AC_MSG_RESULT([no]) AC_DEFINE_UNQUOTED([HAVE_MBSRTOWCS], 0, [Define to 1 if you have the `mbsrtowcs' function.]) +], +[ + AC_MSG_RESULT([cross. guessing yes]) + AC_DEFINE_UNQUOTED([HAVE_MBSRTOWCS], 1, [Define to 1 if you have the `mbsrtowcs' function.]) ] ) +], +[ + AC_DEFINE_UNQUOTED([HAVE_MBSRTOWCS], 0, [Define to 1 if you have the `mbsrtowcs' function.]) +]) AC_MSG_CHECKING([if iconv uses const pointers]) AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[#include ]],
Bug#978965: materia-gtk-theme: Issue with Gnome 3.38
On Fri, 01 Jan 2021 16:18:48 +0530 Kushagra Karira wrote: > Just the release needs to be bumped up for it to properly work with gnome 3.38 > https://tracker.debian.org/pkg/materia-gtk-theme Has a new upstream version available and it should fix the problems. > > Hi Sagar, I am making a Non-maintainer upload for package materia-gtk-theme in Debian now (20200916-0.1) onto DELAYED/2. If you have any doubts, please let me know immediately (via email) so that we could solve it together before Debian 11 release freeze, as well as keeping materia- gtk-theme compatible with GNOME 3.38. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#982036: emboss: FTBFS with OpenJDK 17 due to com.sun.net.ssl removal
Control: tags -1 help On Fri, Feb 05, 2021 at 09:07:40PM +0100, Emmanuel Bourg wrote: > emboss fails to build with OpenJDK 17 due to the removal of the > com.sun.net.ssl package: We need help for this issue since upstream of emboss is dead and we need to solve this inside Debian. Kind regards Andreas. -- http://fam-tille.de
Bug#964423: dspdfviewer: diff for NMU version 1.15.1-1.1
Control: tags 964423 + patch Control: tags 964423 + pending Dear maintainer, I've prepared an NMU for dspdfviewer (versioned as 1.15.1-1.1) and uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru dspdfviewer-1.15.1/debian/changelog dspdfviewer-1.15.1/debian/changelog --- dspdfviewer-1.15.1/debian/changelog 2016-11-04 00:34:42.0 +0200 +++ dspdfviewer-1.15.1/debian/changelog 2021-02-05 22:16:29.0 +0200 @@ -1,3 +1,10 @@ +dspdfviewer (1.15.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Don't build with -Werror. (Closes: #964423) + + -- Adrian Bunk Fri, 05 Feb 2021 22:16:29 +0200 + dspdfviewer (1.15.1-1) unstable; urgency=medium * New upstream point release diff -Nru dspdfviewer-1.15.1/debian/patches/no-Werror.patch dspdfviewer-1.15.1/debian/patches/no-Werror.patch --- dspdfviewer-1.15.1/debian/patches/no-Werror.patch 1970-01-01 02:00:00.0 +0200 +++ dspdfviewer-1.15.1/debian/patches/no-Werror.patch 2021-02-05 22:16:29.0 +0200 @@ -0,0 +1,15 @@ +Description: Don't build with -Werror +Author: Adrian Bunk +Bug-Debian: https://bugs.debian.org/964423 + +--- dspdfviewer-1.15.1.orig/cmake/compiler_gnu_gcc.cmake dspdfviewer-1.15.1/cmake/compiler_gnu_gcc.cmake +@@ -30,7 +30,7 @@ add_definitions( + ) + + # Turn all warnings into errors +-add_definitions(-Werror -pedantic-errors) ++#add_definitions(-Werror -pedantic-errors) + + # These warnings produce false positives on some older qt4 libraries + # (this failed debian s390x compilation), therefore tune them back diff -Nru dspdfviewer-1.15.1/debian/patches/series dspdfviewer-1.15.1/debian/patches/series --- dspdfviewer-1.15.1/debian/patches/series 2016-11-04 00:33:43.0 +0200 +++ dspdfviewer-1.15.1/debian/patches/series 2021-02-05 22:16:29.0 +0200 @@ -1 +1,2 @@ 0001-fix-ftbfs-with-plus-in-version-number.patch +no-Werror.patch
Bug#981864: libinih: Please provide libinih1-udeb
Tags: patch
On Thu, 4 Feb 2021 18:17:29 +0100 Bastian Germann wrote:
xfsprogs recently became a reverse dependency of your package.
#981662 documents that for the xfsprogs' udeb variant, a libinih1-udeb
to link against is needed. Please provide that package.
A patch to introduce that package is enclosed.
From: Bastian Germann
Date: Fri, 5 Feb 2021 21:12:58 +0100
Subject: Add libinih1-udeb for Debian Installer
---
debian/control | 13 +
debian/libinih1-udeb.install | 1 +
2 files changed, 14 insertions(+)
create mode 100644 debian/libinih1-udeb.install
diff --git a/debian/control b/debian/control
index 84ce2da..2423d1d 100644
--- a/debian/control
+++ b/debian/control
@@ -36,6 +36,19 @@ Description: simple .INI file parser
compatible with Python's ConfigParser style of .INI files, including
RFC 822-style multi-line syntax and name: value entries.
+Package: libinih1-udeb
+Package-Type: udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: simple .INI file parser - udeb
+ inih (INI Not Invented Here) is a simple .INI file parser written in C.
+ It's only a couple of pages of code, and it was designed to be small and
+ simple, so it's good for embedded systems.
+ .
+ This is a version for use with the Debian Installer.
+ Do not install it on a normal system.
+
Package: libinireader0
Architecture: any
Multi-Arch: same
diff --git a/debian/libinih1-udeb.install b/debian/libinih1-udeb.install
new file mode 100644
index 000..9362fe5
--- /dev/null
+++ b/debian/libinih1-udeb.install
@@ -0,0 +1 @@
+usr/lib/*/libinih.so.* usr/lib
Bug#957055: bristol: diff for NMU version 0.60.11-3.1
Control: tags 957055 + pending
Dear maintainer,
I've prepared an NMU for bristol (versioned as 0.60.11-3.1) and uploaded
it to DELAYED/1. Please feel free to tell me if I should cancel it.
cu
Adrian
diff -Nru bristol-0.60.11/debian/changelog bristol-0.60.11/debian/changelog
--- bristol-0.60.11/debian/changelog 2016-09-09 15:04:38.0 +0300
+++ bristol-0.60.11/debian/changelog 2021-02-05 22:08:58.0 +0200
@@ -1,3 +1,10 @@
+bristol (0.60.11-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch from Logan Rosen for FTBFS with gcc 10. (Closes: #957055)
+
+ -- Adrian Bunk Fri, 05 Feb 2021 22:08:58 +0200
+
bristol (0.60.11-3) unstable; urgency=medium
* Team upload.
diff -Nru bristol-0.60.11/debian/patches/04-gcc_10.patch bristol-0.60.11/debian/patches/04-gcc_10.patch
--- bristol-0.60.11/debian/patches/04-gcc_10.patch 1970-01-01 02:00:00.0 +0200
+++ bristol-0.60.11/debian/patches/04-gcc_10.patch 2021-02-05 22:08:55.0 +0200
@@ -0,0 +1,243 @@
+--- a/brighton/brightonCLI.c
b/brighton/brightonCLI.c
+@@ -136,7 +136,6 @@
+ // if (RESOURCES->resources[btty.p].devlocn[btty.i].to == 1.0f)
+ // if (DEVICE(btty.i).to == 1.0f)
+
+-brightonEvent event;
+ extern void printBrightonHelp(int);
+
+ typedef int (*clicom)();
+--- a/brighton/brightonMixerMenu.c
b/brighton/brightonMixerMenu.c
+@@ -1179,11 +1179,10 @@
+ return(NULL);
+ }
+
+-brightonEvent event;
+-
+ int
+ doAlarm()
+ {
++ brightonEvent event;
+ event.type = BRIGHTON_FLOAT;
+ event.value = 0.0;
+
+--- a/include/bristol/bristolblo.h
b/include/bristol/bristolblo.h
+@@ -39,7 +39,7 @@
+ #define BLO_COSINE 6
+ #define BLO_PULSE 7
+
+-struct {
++struct blo {
+ int flags;
+ int harmonics;
+ int cutin;
+@@ -47,7 +47,8 @@
+ int min;
+ float fraction;
+ float samplerate;
+-} blo;
++};
++extern struct blo blo;
+
+ extern float blosine[BRISTOL_BLO_SIZE];
+ extern float blosquare[BRISTOL_BLO_SIZE];
+--- a/bristol/blo.c
b/bristol/blo.c
+@@ -33,6 +33,8 @@
+
+ static int init = 1;
+
++struct blo blo;
++
+ float blosine[BRISTOL_BLO_SIZE];
+ float blocosine[BRISTOL_BLO_SIZE];
+ float blosquare[BRISTOL_BLO_SIZE];
+--- a/bristol/arpdco.c
b/bristol/arpdco.c
+@@ -39,7 +39,8 @@
+ #include "bristolblo.h"
+ #include "arpdco.h"
+
+-float note_diff, *zbuf;
++static float note_diff;
++float *zbuf;
+
+ #define BRISTOL_SQR 4
+
+--- a/bristol/cs80osc.c
b/bristol/cs80osc.c
+@@ -41,8 +41,8 @@
+ #include "cs80osc.h"
+ #include "bristolcs80.h"
+
+-float note_diff;
+-int samplecount;
++static float note_diff;
++static int samplecount;
+
+ static void fillWave(float *, int, int);
+ static void buildCs80Sound(bristolOP *, bristolOPParams *);
+--- a/bristol/dco.c
b/bristol/dco.c
+@@ -39,7 +39,7 @@
+ #include "bristolblo.h"
+ #include "dco.h"
+
+-float note_diff;
++static float note_diff;
+
+ /*
+ * The name of this operator, IO count, and IO names.
+--- a/bristol/expdco.c
b/bristol/expdco.c
+@@ -40,7 +40,7 @@
+ #include "bristolblo.h"
+ #include "expdco.h"
+
+-float note_diff;
++static float note_diff;
+
+ /*
+ * The name of this operator, IO count, and IO names.
+--- a/bristol/filter2.c
b/bristol/filter2.c
+@@ -147,7 +147,6 @@
+ }
+
+ #define ROOT2 1.4142135623730950488
+-double pidsr;
+
+ /*
+ * Reset any local memory information.
+--- a/bristol/granulardco.c
b/bristol/granulardco.c
+@@ -38,8 +38,8 @@
+ #include "bristol.h"
+ #include "granulardco.h"
+
+-float note_diff;
+-float samplerate;
++static float note_diff;
++static float samplerate;
+
+ #define BRISTOL_SQR 4
+
+--- a/bristol/hammond.c
b/bristol/hammond.c
+@@ -45,8 +45,8 @@
+ #include "bristol.h"
+ #include "hammond.h"
+
+-float note_diff;
+-int samplecount;
++static float note_diff;
++static int samplecount;
+
+ static void fillWave(float *, int, int);
+ static void buildHammondSound(bristolOP *, unsigned char);
+@@ -70,8 +70,8 @@
+ static int *waveindex;
+ static int *percussion;
+
+-float *wave1;
+-float *wave2;
++static float *wave1;
++static float *wave2;
+
+ /*
+ * This can be a single list, it is used to generate the different pipes.
+--- a/bristol/junodco.c
b/bristol/junodco.c
+@@ -39,7 +39,7 @@
+ #include "bristolblo.h"
+ #include "junodco.h"
+
+-float note_diff;
++static float note_diff;
+
+ #define BRISTOL_SQR 8
+
+--- a/bristol/lfo.c
b/bristol/lfo.c
+@@ -38,7 +38,7 @@
+ #include "bristol.h"
+ #include "lfo.h"
+
+-float note_diff;
++static float note_diff;
+
+ /*
+ * The name of this operator, IO count, and IO names.
+--- a/bristol/midihandlers.c
b/bristol/midihandlers.c
+@@ -633,7 +633,7 @@
+ * previous frequency * (2^^(1/12))
+ * Since A is constand whole numbers we can calcuate each octave from A.
+ */
+-float samplerate;
++static float samplerate;
+
+ int
+ initFrequencyTable(float rate)
+--- a/bristol/prophetdco.c
b/bristol/prophetdco.c
+@@ -47,7 +47,7 @@
+ #include "bristolblo.h"
+ #include "prophetdco.h"
+
+-float note_diff;
++static float
Bug#981924: trying to overwrite shared '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different from other instances of package libelf1:i386
Package: libelf1 Version: 0.182+20210203-1.1+b1 Followup-For: Bug #981924 X-Debbugs-Cc: ara.ke...@gmail.com Dear maintainers, the bug is still present, when both libelf1:i386 and libelf1:amd64 are installed: upon installation, one gets Unpacking libelf1:i386 (0.182+20210203-1.1+b1) over (0.182-3) ... dpkg: error processing archive /var/cache/apt/archives/libelf1_0.182+20210203-1.1+b1_i386.deb (--unpack): trying to overwrite shared '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different from other instances of package libelf1:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libelf1_0.182+20210203-1.1+b1_i386.deb Error: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit packagekit.service is masked. E: Sub-process /usr/bin/dpkg returned an error code (1) dpkg: dependency problems prevent configuration of libdw1:i386: libdw1:i386 depends on libelf1 (= 0.182+20210203-1.1+b1); however: Version of libelf1:i386 on system is 0.182-3. dpkg: error processing package libdw1:i386 (--configure): dependency problems - leaving unconfigured dpkg: error processing package libelf1:amd64 (--configure): package libelf1:amd64 0.182+20210203-1.1+b1 cannot be configured because libelf1:i386 is at a different version (0.182-3) dpkg: dependency problems prevent configuration of libdw1:amd64: libdw1:amd64 depends on libelf1 (= 0.182+20210203-1.1+b1); however: Package libelf1:amd64 is not configured yet. dpkg: error processing package libdw1:amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libdebuginfod1:amd64: libdebuginfod1:amd64 depends on libelf1 (= 0.182+20210203-1.1+b1); however: Package libelf1:amd64 is not configured yet. libdebuginfod1:amd64 depends on libdw1 (= 0.182+20210203-1.1+b1); however: Package libdw1:amd64 is not configured yet. dpkg: error processing package libdebuginfod1:amd64 (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.31-9) ... Errors were encountered while processing: libdw1:i386 libelf1:amd64 libdw1:amd64 libdebuginfod1:amd64 Current status: 3 (-1) broken, 1 (-3) upgradable. Best, Ara -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN 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) LSM: AppArmor: enabled Versions of packages libelf1 depends on: ii libc6 2.31-9 ii zlib1g 1:1.2.11.dfsg-2 libelf1 recommends no packages. libelf1 suggests no packages. -- no debconf information
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi intrigeri, On 05-02-2021 18:02, intrigeri wrote: > First, I'm wondering if this bug might be related to the problem you > recently fixed in debci's LXC containers AppArmor configuration. That was only on one particular ppc64el host, so that shouldn't impact the other architectures. > What about giving it another try? After the above, does that really make sense? > If that's not enough, then I'd like to come back to what we discussed > a few months ago: [...] >> Sure, will do right away in a private email. > > It seems I failed to follow up on this, sorry! > > I suppose it'll be easier to coordinate this via IRC (although > I don't have a permanently-connected client). No, I forgot to follow up. I'll give further instructions in private. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#982037: ayatana-webmail: ships usr/share/icons/hicolor/scalable/status/indicator-messages{,-new}.svg, already in ayatana-indicator-messages
Package: ayatana-webmail Version: 21.1.25+dfsg1-2 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 .../ayatana-webmail_21.1.25+dfsg1-2_all.deb ... Unpacking ayatana-webmail (21.1.25+dfsg1-2) ... dpkg: error processing archive /var/cache/apt/archives/ayatana-webmail_21.1.25+dfsg1-2_all.deb (--unpack): trying to overwrite '/usr/share/icons/hicolor/scalable/status/indicator-messages-new.svg', which is also in package ayatana-indicator-messages 0.8.1-2 Errors were encountered while processing: /var/cache/apt/archives/ayatana-webmail_21.1.25+dfsg1-2_all.deb cheers, Andreas ayatana-indicator-messages=0.8.1-2_ayatana-webmail=21.1.25+dfsg1-2.log.gz Description: application/gzip
Bug#982036: emboss: FTBFS with OpenJDK 17 due to com.sun.net.ssl removal
Source: emboss Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 emboss fails to build with OpenJDK 17 due to the removal of the com.sun.net.ssl package: compile: [javac] /<>/jemboss/build.xml:69: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Using javac -source 1.4 is no longer supported, switching to 7 [javac] Using javac -target 1.4 is no longer supported, switching to 7 [javac] Compiling 131 source files to /<>/jemboss/build/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 7 [javac] warning: [options] source value 7 is obsolete and will be removed in a future release [javac] warning: [options] target value 7 is obsolete and will be removed in a future release [javac] warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. [javac] /<>/jemboss/org/emboss/jemboss/FileManager.java:45: error: package com.sun.net.ssl.internal.ssl does not exist [javac] com.sun.net.ssl.internal.ssl.Provider p = [javac] ^ [javac] /<>/jemboss/org/emboss/jemboss/FileManager.java:46: error: package com.sun.net.ssl.internal.ssl does not exist [javac] new com.sun.net.ssl.internal.ssl.Provider(); [javac] ^ [javac] /<>/jemboss/org/emboss/jemboss/FileManager.java:56: error: package com.sun.net.ssl.internal.www.protocol.https does not exist [javac] return new com.sun.net.ssl.internal.www.protocol.https.Handler(); [javac] ^ [javac] /<>/jemboss/org/emboss/jemboss/Jemboss.java:116: error: package com.sun.net.ssl.internal.ssl does not exist [javac] com.sun.net.ssl.internal.ssl.Provider p = [javac] ^ [javac] /<>/jemboss/org/emboss/jemboss/Jemboss.java:117: error: package com.sun.net.ssl.internal.ssl does not exist [javac] new com.sun.net.ssl.internal.ssl.Provider(); [javac] ^ [javac] /<>/jemboss/org/emboss/jemboss/Jemboss.java:127: error: package com.sun.net.ssl.internal.www.protocol.https does not exist [javac] return new com.sun.net.ssl.internal.www.protocol.https.Handler(); [javac] ^
Bug#962596: Backport to stretch?
Yes On Tue, 2 Feb 2021 17:09:33 +0530 Utkarsh Gupta wrote: > Hi, > > On Mon, Feb 1, 2021 at 9:48 PM Julien Cristau wrote: > > stretch is EOL, so I am not planning on touching it myself. > > Cc:ing the team that looks after stretch-lts in case they want to handle > > this. > > Thanks, I'll start to take a look at it. > IIUC, this commit[1] needs a backport to stretch, correct? > > [1]: > https://salsa.debian.org/debian/ca-certificates/-/commit/62a6fc666ddc27baa0150e2b210814ecf1fc587e > > > - u > >
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1"
Control: tag + upstream patch
X-Debbugs-Cc: d.fil...@web.de
dwz source code comes with outdated (August 2019) copies of
dwarf2.def, dwarf2.h and dwarfnames.c from gcc/libiberty.
The patch updates them and proposes a long-term solution.
Hopefully this will fix any dh_dwz issues.
Regards,
Dennis.
Description: Update DWARF definition files to latest gcc master
Upstream devs haven't updated some files copied from gcc/libiberty in
a while. This patch for dwz/0.13-2 updates them to the ones in gcc
master@b2d84e9f9cccbe4ee662f7002b83105629d09939 allowing it to
recognize newly introduced DWARF tags produced by current
gcc/binutils/etc.
.
A better approach would build-depend on libiberty-dev (20210106-1 has
them), include/copy them and update COPYRIGHT_YEARS with
contrib/release/gen-copyright-years.sh.
Author: Dennis Filder
Bug-Debian: https://bugs.debian.org/968670
Last-Update: 2021-02-05
---
diff -u -r dwz-0.13+20210126/COPYRIGHT_YEARS dwz-0.13+20210126/COPYRIGHT_YEARS
--- dwz-0.13+20210126/COPYRIGHT_YEARS 2021-01-19 08:36:09.0 +0100
+++ dwz-0.13+20210126/COPYRIGHT_YEARS 2021-02-05 20:31:33.0 +0100
@@ -1,3 +1,3 @@
--DFSF_YEARS='"1992-2019"'
+-DFSF_YEARS='"1992-2021"'
-DRH_YEARS='"2001-2021"'
-DSUSE_YEARS='"2019"'
diff -u -r dwz-0.13+20210126/dwarf2.def dwz-0.13+20210126/dwarf2.def
--- dwz-0.13+20210126/dwarf2.def 2019-08-11 17:16:07.0 +0200
+++ dwz-0.13+20210126/dwarf2.def 2021-02-05 20:31:09.0 +0100
@@ -1,7 +1,7 @@
/* -*- c -*-
Declarations and definitions of codes relating to the DWARF2 and
DWARF3 symbolic debugging information formats.
- Copyright (C) 1992-2019 Free Software Foundation, Inc.
+ Copyright (C) 1992-2021 Free Software Foundation, Inc.
Written by Gary Funck (g...@intrepid.com) The Ada Joint Program
Office (AJPO), Florida State University and Silicon Graphics Inc.
@@ -805,3 +805,14 @@
DW_IDX (DW_IDX_GNU_internal, 0x2000)
DW_IDX (DW_IDX_GNU_external, 0x2001)
DW_END_IDX
+
+/* DWARF5 Unit type header encodings */
+DW_FIRST_UT (DW_UT_compile, 0x01)
+DW_UT (DW_UT_type, 0x02)
+DW_UT (DW_UT_partial, 0x03)
+DW_UT (DW_UT_skeleton, 0x04)
+DW_UT (DW_UT_split_compile, 0x05)
+DW_UT (DW_UT_split_type, 0x06)
+DW_UT (DW_UT_lo_user, 0x80)
+DW_UT (DW_UT_hi_user, 0xff)
+DW_END_UT
diff -u -r dwz-0.13+20210126/dwarf2.h dwz-0.13+20210126/dwarf2.h
--- dwz-0.13+20210126/dwarf2.h 2019-08-11 17:16:07.0 +0200
+++ dwz-0.13+20210126/dwarf2.h 2021-02-05 20:31:17.0 +0100
@@ -1,6 +1,6 @@
/* Declarations and definitions of codes relating to the DWARF2 and
DWARF3 symbolic debugging information formats.
- Copyright (C) 1992-2019 Free Software Foundation, Inc.
+ Copyright (C) 1992-2021 Free Software Foundation, Inc.
Written by Gary Funck (g...@intrepid.com) The Ada Joint Program
Office (AJPO), Florida State University and Silicon Graphics Inc.
@@ -55,6 +55,7 @@
#define DW_CFA_DUP(name, value) , name = value
#define DW_IDX(name, value) , name = value
#define DW_IDX_DUP(name, value) , name = value
+#define DW_UT(name, value) , name = value
#define DW_FIRST_TAG(name, value) enum dwarf_tag { \
name = value
@@ -77,6 +78,9 @@
#define DW_FIRST_IDX(name, value) enum dwarf_name_index_attribute { \
name = value
#define DW_END_IDX };
+#define DW_FIRST_UT(name, value) enum dwarf_unit_type { \
+ name = value
+#define DW_END_UT };
#include "dwarf2.def"
@@ -94,6 +98,8 @@
#undef DW_END_CFA
#undef DW_FIRST_IDX
#undef DW_END_IDX
+#undef DW_FIRST_UT
+#undef DW_END_UT
#undef DW_TAG
#undef DW_TAG_DUP
@@ -108,6 +114,7 @@
#undef DW_CFA_DUP
#undef DW_IDX
#undef DW_IDX_DUP
+#undef DW_UT
/* Flag that tells whether entry has a child or not. */
#define DW_children_no 0
@@ -316,7 +323,6 @@
#define DW_CIE_ID 0x
#define DW64_CIE_ID 0xULL
-#define DW_CIE_VERSION 1
#define DW_CFA_extended 0
@@ -451,19 +457,6 @@
DW_RLE_start_end = 0x06,
DW_RLE_start_length = 0x07
};
-
-/* Unit types in unit_type unit header field. */
-enum dwarf_unit_type
- {
-DW_UT_compile = 0x01,
-DW_UT_type = 0x02,
-DW_UT_partial = 0x03,
-DW_UT_skeleton = 0x04,
-DW_UT_split_compile = 0x05,
-DW_UT_split_type = 0x06,
-DW_UT_lo_user = 0x80,
-DW_UT_hi_user = 0xff
- };
/* @@@ For use with GNU frame unwind information. */
@@ -489,19 +482,36 @@
#define DW_EH_PE_indirect 0x80
/* Codes for the debug sections in a dwarf package (.dwp) file.
- Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFissionDWP. */
+ (From the pre-standard formats Extensions for Fission.
+ See http://gcc.gnu.org/wiki/DebugFissionDWP). */
enum dwarf_sect
- {
-DW_SECT_INFO = 1,
-DW_SECT_TYPES = 2,
-DW_SECT_ABBREV = 3,
-DW_SECT_LINE = 4,
-DW_SECT_LOC = 5,
-DW_SECT_STR_OFFSETS = 6,
-DW_SECT_MACINFO = 7,
-DW_SECT_MACRO = 8,
-DW_SECT_MAX = 8
- };
+{
+ DW_SECT_INFO = 1,
+ DW_SECT_TYPES = 2,
+ DW_SECT_ABBREV = 3,
+ DW_SECT_LINE = 4,
+ DW_SECT_LOC = 5,
Bug#982035: tasksel depends on man-pages-it which has been removed
Package: tasksel Version: 3.63 Severity: serious Justification: not installable Hi, man-pages-it has been removed from unstable. Don't ask me how that is possible as your package still depends on it, but it happened. Please drop the dependency. The RM bug #979034 suggests the data now lives elsewhere, albeit I don't know where. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#982034: forked-daapd: autopkgtest regression in testing: Job for forked-daapd.service failed.
Source: forked-daapd Version: 26.4+dfsg1-2 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent change somewhere outside of your package the autopkgtest of your package started to fail. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? As a service, I have also generated a diff between the installed packages during the test of the last successful run on amd64 and the first that failed. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/f/forked-daapd/10113463/log.gz autopkgtest [22:13:27]: test basic: [--- Job for forked-daapd.service failed. See "systemctl status forked-daapd.service" and "journalctl -xe" for details. autopkgtest [22:13:30]: test basic: ---] paul@mulciber /tmp $ diff -u passed/testbed-packages failed/testbed-packages --- passed/testbed-packages 2020-11-19 22:54:43.0 +0100 +++ failed/testbed-packages 2020-11-27 03:18:26.0 +0100 @@ -6,7 +6,7 @@ binutils 2.35.1-2 binutils-common2.35.1-2 binutils-x86-64-linux-gnu 2.35.1-2 -bsdutils 1:2.36-3+b2 +bsdutils 1:2.36.1-1 bzip2 1.0.8-4 coreutils 8.32-4+b1 dash 0.5.11+git20200708+dd9ef66-2 @@ -17,7 +17,7 @@ dialog 1.3-20190808-1 diffutils 1:3.7-3 dirmngr2.2.20-1 -dmsetup2:1.02.171-3 +dmsetup2:1.02.173-1 dpkg 1.20.5 dpkg-dev 1.20.5 e2fsprogs 1.45.6-1 @@ -40,8 +40,8 @@ gzip 1.10-2 hostname 3.23 ifupdown 0.8.36 -init 1.58 -init-system-helpers1.58 +init 1.59 +init-system-helpers1.59 iproute2 5.9.0-1 isc-dhcp-client4.4.1-2.1+b2 libacl12.2.53-8 @@ -53,7 +53,7 @@ libaudit-common1:2.8.5-3.1 libaudit1 1:2.8.5-3.1 libbinutils2.35.1-2 -libblkid1 2.36-3+b2 +libblkid1 2.36.1-1 libbsd00.10.0-1 libbz2-1.0 1.0.8-4 libc-bin 2.31-4 @@ -71,7 +71,7 @@ libdb5.3 5.3.28+dfsg1-0.6 libdbus-1-31.12.20-1 libdebconfclient0 0.255 -libdevmapper1.02.1 2:1.02.171-3 +libdevmapper1.02.1 2:1.02.173-1 libdns-export1110 1:9.11.19+dfsg-1 libdpkg-perl 1.20.5 libeatmydata1 105-9 @@ -85,27 +85,27 @@ libgcrypt201.8.7-2 libgdbm-compat41.18.1-5.1 libgdbm6 1.18.1-5.1 -libgmp10 2:6.2.0+dfsg-6 +libgmp10 2:6.2.1+dfsg-1 libgnutls303.6.15-4 libgpg-error0 1.38-2 -libgssapi-krb5-2 1.17-10 +libgssapi-krb5-2 1.18.3-4 libhogweed63.6-2 -libidn2-0 2.3.0-3 +libidn2-0 2.3.0-4 libip4tc2 1.8.6-1 libisc-export1105 1:9.11.19+dfsg-1 libjson-c5 0.15-1 -libk5crypto3 1.17-10 +libk5crypto3 1.18.3-4 libkeyutils1 1.6.1-2 libkmod2 27+20200310-2 -libkrb5-3 1.17-10 -libkrb5support01.17-10 +libkrb5-3 1.18.3-4 +libkrb5support01.18.3-4 libksba8 1.4.0-2 libldap-2.4-2 2.4.56+dfsg-1 libldap-common 2.4.56+dfsg-1 liblz4-1 1.9.2-2 liblzma5 5.2.4-1+b1 libmnl01.0.4-3 -libmount1 2.36-3+b2 +libmount1 2.36.1-1 libncurses66.2+20200918-1 libncursesw6 6.2+20200918-1 libnettle8 3.6-2 @@ -117,7 +117,7 @@ libpam-modules 1.3.1-5 libpam-modules-bin 1.3.1-5 libpam-runtime 1.3.1-5 -libpam-systemd 246.6-2 +libpam-systemd 246.6-4 libpam0g 1.3.1-5 libpcre2-8-0 10.34-7 libpcre3 2:8.39-13 @@ -133,19 +133,19 @@ libsemanage-common 3.1-1 libsemanage1 3.1-1+b1 libsepol1 3.1-1 -libsmartcols1 2.36-3+b2 +libsmartcols1 2.36.1-1 libsqlite3-0 3.33.0-1 libss2 1.45.6-1 libssl1.1 1.1.1h-1 libstdc++6 10.2.0-16 -libsystemd0246.6-2 +libsystemd0246.6-4 libtasn1-6 4.16.0-2 libtinfo6 6.2+20200918-1 libtirpc-common1.2.6-3 libtirpc3 1.2.6-3 -libudev1 246.6-2 +libudev1 246.6-4 libunistring2 0.9.10-4 -libuuid1 2.36-3+b2 +libuuid1 2.36.1-1 libwrap0 7.6.q-31 libxtables12 1.8.6-1 libzstd1 1.4.5+dfsg-4 @@ -155,7 +155,7 @@ lsb-base 11.1.0 make 4.3-4 mawk 1.3.4.20200120-2 -mount 2.36-3+b2 +mount 2.36.1-1 ncurses-base 6.2+20200918-1 ncurses-bin6.2+20200918-1 net-tools 1.60+git20181103.0eebece-1 @@ -173,16 +173,16 @@ python3-minimal3.8.6-1 python3.8-minimal 3.8.6-1 readline-common8.1~rc2-2 -runit-helper 2.9.0 +runit-helper 2.10.2 sed4.7-1 sensible-utils 0.0.12+nmu1 -systemd246.6-2 -systemd-sysv 246.6-2 -systemd-timesyncd 246.6-2 +systemd246.6-4 +systemd-sysv 246.6-4 +systemd-timesyncd 246.6-4 sysvinit-utils 2.96-5 tar1.30+dfsg-7 tzdata 2020d-1 ucf3.0043 -util-linux 2.36-3+b2 +util-linux 2.36.1-1 xz-utils 5.2.4-1+b1 zlib1g 1:1.2.11.dfsg-2
Bug#982033: dnf,dnf-doc: both ship usr/share/doc/dnf/README.Debian
Package: dnf,dnf-doc Version: 4.5.2-3 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 each others files. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../dnf-doc_4.5.2-3_all.deb ... Unpacking dnf-doc (4.5.2-3) ... dpkg: error processing archive /var/cache/apt/archives/dnf-doc_4.5.2-3_all.deb (--unpack): trying to overwrite '/usr/share/doc/dnf/README.Debian', which is also in package dnf 4.5.2-3 Errors were encountered while processing: /var/cache/apt/archives/dnf-doc_4.5.2-3_all.deb dh_installdocs in current debhelper levels installs documentation in -doc packages in the main package doc dir /usr/share/doc/ cheers, Andreas dnf=4.5.2-3_dnf-doc=4.5.2-3.log.gz Description: application/gzip
Bug#982032: golang-github-jouyouyun-hardware: Binary package should be arch:all instead of arch:any
Source: golang-github-jouyouyun-hardware Version: 0.1.6-1 Severity: important X-Debbugs-CC: claysta...@gmail.com Since golang-github-jouyouyun-hardware only ships go source files, it does not make sense to make the binary package to be arch:any. Please use arch:all instead. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#982031: parl-desktop-world depends on hunspell-se which has been removed
Package: parl-desktop-world Version: 1.9.26 Severity: serious Justification: not installable Hi Jonas, hunspell-se has been removed from unstable. Don't ask me how that is possible as your package still depends on it, but it happened. Please drop the dependency. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#860557: gprename: diff for NMU version 20201214-0.1
Control: tags 860557 + patch
Control: tags 860557 + pending
Control: tags 912880 + patch
Control: tags 912880 + pending
Dear maintainer,
I've prepared an NMU for gprename (versioned as 20201214-0.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru gprename-20140325/bin/gprename gprename-20201214/bin/gprename
--- gprename-20140325/bin/gprename 2014-03-26 00:47:15.0 +0200
+++ gprename-20201214/bin/gprename 2020-12-14 22:16:44.0 +0200
@@ -13,18 +13,13 @@
# file COPYING that came with this software for details.
# Home Page: http://gprename.sourceforge.net
-# Wikipedia: http://en.wikipedia.org/wiki/GPRename
# Subversion Web Browsing : http://gprename.svn.sourceforge.net/viewvc/gprename
-# Subversion Manual: http://svnbook.red-bean.com/
-# GTK2-Perl FAQ: http://live.gnome.org/GTK2-Perl/FrequentlyAskedQuestions
-# GTK2-Perl Tutorials : http://gtk2-perl.sourceforge.net/doc
-# GTK2-Perl POD: http://gtk2-perl.sourceforge.net/doc/pod/index.html
-# Makefile tutorial: http://mrbook.org/tutorials/make/
-# GNOME Human Interface Guidelines : http://developer.gnome.org/projects/gup/hig/2.0/index.html
-# Linux Filesystem Hierarchy : http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
+# Perl Gtk3: https://metacpan.org/pod/Gtk3
+# Gtk-Perl : https://wiki.gnome.org/Projects/GTK-Perl
+# GNOME Human Interface Guidelines : https://developer.gnome.org/hig/stable/
# Tutorial on gettext : http://cpan.uwinnipeg.ca/htdocs/gettext/README.html
-# Gnu gettext : http://www.gnu.org/software/gettext/
-# .desktop specification : http://www.freedesktop.org/wiki/Howto_desktop_files/
+# GNU gettext : https://www.gnu.org/software/gettext/
+# .desktop specification : https://www.freedesktop.org/wiki/Howto_desktop_files/
# To create a gprename.po template file :
# cd bin
@@ -45,32 +40,37 @@
# Initialisation #
##
-use Gtk2 -init;
+use strict; # require variables to be declared before using them and distrust barewords
+use warnings; # print warning messages on the command line
+use Gtk3 -init;
use File::Spec::Functions;# for the tree
use Cwd; # to get the current directory
use Encode qw(decode encode); # to handle accents, with the encode and decode function
use Fcntl ':flock'; # for the flock function in _settings
-use strict; # require variables to be declared before using them and distrust barewords
-use warnings; # print warning messages on the command line
use Glib qw/TRUE FALSE/; # to use the bareword TRUE and FALSE
use utf8; # Because this file is in UTF8 and because we're using hardcoded accent in Help/About
-use Gtk2::Pango; # To use text markup in TextView
+use Pango;# To use text markup in TextView
use POSIX;# for setlocale()
use Locale::gettext; # for l18n
-use Gtk2::Gdk::Keysyms; # for keyboard shortcuts
# set the locale
setlocale(LC_ALL, '');
bindtextdomain( 'gprename', '/usr/local/share/locale');
textdomain( 'gprename' );
-# Change the font to courier new for the Tree and the SimpleList
-Gtk2::Rc->parse_string(<<__);
-style 'my_text' { font_name ='courier new' }
-widget '*TreeView' style 'my_text'
-__
+sub gtext {
+my $text = shift;
+my $local_text = decode('utf8', gettext($text));
+if ($local_text && length($local_text) > 0) {
+ return $local_text;
+}
+return $text;
+}
# Declaration of global variables
+# TODO: This should respect XDG_CONFIG_HOME
+# See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
+# for details.
my $setting_file = "$ENV{'HOME'}/.config/gprename/gprename";
my $log_file = "$ENV{'HOME'}/.config/gprename/gprename_log";
if ( ! -e "$ENV{'HOME'}/.config" ) { `mkdir "$ENV{'HOME'}/.config"`; }
@@ -91,14 +91,14 @@
my $status_bar_files=0;
my $status_bar_dirs=0;
my $status_bar_selected=0;
-my $str_gprename_version='5';
+my $str_gprename_version='20201214';
# Hold a list of the Name and New Name column of files or directories
# These are filled when calling
my @column_name=();
my @column_new_name=();
-# Load settings file "~/.gprename"
+# Load settings
$settings{'trim_spaces'}= TRUE;
$settings{'auto_preview'} = 0;
$settings{'zero_autofill'} = TRUE;
@@ -110,33 +110,44 @@
$settings{'show_hidden_files'} = 0;
_settings;
+# Override style for GtkTreeView to Courier New with fallback.
+my $css_provider = Gtk3::CssProvider->new;
Bug#980134: Keep shaarli (and dependencies) out of Bullseye? (Was: Bug#980134: shaarli: Missing minified js and css for frontend)
Hi David, On 2/3/21 2:46 PM, David Prévot wrote: > Hi James, > > Le Thu, Jan 14, 2021 at 07:05:21PM -0500, James Valleroy a écrit : > […] >> While the packaged shaarli is technically usable, it is missing both >> functionality and styling that would be expected by users. Therefore >> it should be kept out of stable releases until this issue is fixed. > > Given the above (and the freeze schedule), it looks like shaarli won’t > be part of Bullseye. Do you intend to also request the removal of its > (build-)dependencies (e.g., via such kind of RC-bug), or do you intend > to maintain them all during the Bullseye lifetime (wrt security issues)? I agree with keeping the dependencies out of Bullseye also. I will try to start filing bugs this weekend. Regards, James OpenPGP_signature Description: OpenPGP digital signature
Bug#982030: nmu: libpod_libpod
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu It seems that there is a problem with the image cache in podman 3.0-rc2, which turns out to be a bug in 'buildah'. I've uploaded a fix to unstable as golang-github-containers-buildah_1.19.3+dfsg1-2, but now we also need to get src:libpod rebuilt. nmu libpod_3.0.0~rc2+dfsg1-2 . ANY . unstable . -m 'Rebuild against golang-github-containers-buildah_1.19.3+dfsg1-2 to fix #981849' dw libpod_3.0.0~rc2+dfsg1-2 . ANY . -m 'golang-github-containers-buildah (>= 1.19.3+dfsg1-2)' Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled
Bug#956041: fixed in libmaxminddb 1.5.0-2
Hi Faidon, >I didn't make lowdown the default, because there is an outstanding bug >specifically affecting libmaxminddb, for which I'm waiting for a new >lowdown release to fix. ouch, okay. >It will become the default eventually, but I wanted to offer it as an >alternative among a few other changes, and do the swap as a "small >targeted fix" when the lowdown issue is fixed, which may or may not be >after the Feb 12th freeze. Good point. >I thought that in the meantime (or also in case we don't make the >freeze) it would help you with manual builds for bootstrapping. It >sounded like this was something you did manually by patching the package >before, so I felt this would be better than nothing. Yes, let’s just keep this bug open until the fix is usable via normal buildd procedures as manually bootstrapping things is a last-resort action from a porter PoV. >Also, note that there is also support for the "nodoc" option & profile >now, which was also previously requested by Helmut in this bug; hope >this potentially helps in the meantime as well. This will help the bootstrapping per se, yes. bye, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Bug#981814: Re : Bug#981814: lilypond-doc: Unable to upgrade
Le 05/02/2021 19:54:49, Anthony Fok a écrit : > Also, it would help immensely if we know which version of lilypond-doc > etc. you were upgrading from. > To help us investigate, could you please kindly reply, > copy-and-pasting what you see with the following commands? > ls -ld /usr/share/info/lilypond drwxr-xr-x 2 root root 4096 14 janv. 18:48 /usr/share/info/lilypond > ls -ld /usr/share/info/lilypond/user lrwxrwxrwx 1 root root 40 29 juin 2017 /usr/share/info/lilypond/user -> ../doc/lilypond/html/Documentation/user/ > ls -l /usr/share/info/lilypond/user lrwxrwxrwx 1 root root 40 29 juin 2017 /usr/share/info/lilypond/user -> ../doc/lilypond/html/Documentation/user/ > grep lilypond /var/log/dpkg.log 2021-02-02 07:34:46 upgrade lilypond-doc:all 2.22.0-5 2.22.0-6 2021-02-02 07:34:46 status half-configured lilypond-doc:all 2.22.0-5 2021-02-02 07:34:47 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 07:34:47 status half-installed lilypond-doc:all 2.22.0-5 2021-02-02 07:34:48 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 07:34:49 status installed lilypond-doc:all 2.22.0-5 2021-02-02 07:34:50 upgrade lilypond-doc-html:all 2.22.0-5 2.22.0-6 2021-02-02 07:34:50 status half-configured lilypond-doc-html:all 2.22.0-5 2021-02-02 07:34:50 status unpacked lilypond-doc-html:all 2.22.0-5 2021-02-02 07:34:50 status half-installed lilypond-doc-html:all 2.22.0-5 2021-02-02 07:38:18 status unpacked lilypond-doc-html:all 2.22.0-6 2021-02-02 07:38:35 upgrade lilypond-doc-pdf:all 2.22.0-5 2.22.0-6 2021-02-02 07:38:35 status half-configured lilypond-doc-pdf:all 2.22.0-5 2021-02-02 07:38:36 status unpacked lilypond-doc-pdf:all 2.22.0-5 2021-02-02 07:38:36 status half-installed lilypond-doc-pdf:all 2.22.0-5 2021-02-02 07:38:48 status unpacked lilypond-doc-pdf:all 2.22.0-6 2021-02-02 07:46:46 configure lilypond-doc-html:all 2.22.0-6 2021-02-02 07:46:46 status unpacked lilypond-doc-html:all 2.22.0-6 2021-02-02 07:46:46 status half-configured lilypond-doc-html:all 2.22.0-6 2021-02-02 07:46:46 status installed lilypond-doc-html:all 2.22.0-6 2021-02-02 07:48:17 configure lilypond-doc-pdf:all 2.22.0-6 2021-02-02 07:48:17 status unpacked lilypond-doc-pdf:all 2.22.0-6 2021-02-02 07:48:17 status half-configured lilypond-doc-pdf:all 2.22.0-6 2021-02-02 07:48:18 status installed lilypond-doc-pdf:all 2.22.0-6 2021-02-02 13:59:00 upgrade lilypond-doc:all 2.22.0-5 2.22.0-6 2021-02-02 13:59:00 status half-configured lilypond-doc:all 2.22.0-5 2021-02-02 13:59:01 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 13:59:01 status half-installed lilypond-doc:all 2.22.0-5 2021-02-02 13:59:02 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 13:59:03 status installed lilypond-doc:all 2.22.0-5 2021-02-02 18:13:19 upgrade lilypond-doc:all 2.22.0-5 2.22.0-6 2021-02-02 18:13:19 status half-configured lilypond-doc:all 2.22.0-5 2021-02-02 18:13:19 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 18:13:19 status half-installed lilypond-doc:all 2.22.0-5 2021-02-02 18:13:20 status unpacked lilypond-doc:all 2.22.0-5 2021-02-02 18:13:20 status installed lilypond-doc:all 2.22.0-5 2021-02-03 07:32:23 upgrade lilypond-doc:all 2.22.0-5 2.22.0-8 2021-02-03 07:32:23 status half-configured lilypond-doc:all 2.22.0-5 2021-02-03 07:32:23 status unpacked lilypond-doc:all 2.22.0-5 2021-02-03 07:32:23 status half-installed lilypond-doc:all 2.22.0-5 2021-02-03 07:32:24 status unpacked lilypond-doc:all 2.22.0-5 2021-02-03 07:32:24 status installed lilypond-doc:all 2.22.0-5 2021-02-03 07:32:25 upgrade lilypond-doc-html:all 2.22.0-6 2.22.0-8 2021-02-03 07:32:25 status half-configured lilypond-doc-html:all 2.22.0-6 2021-02-03 07:32:25 status unpacked lilypond-doc-html:all 2.22.0-6 2021-02-03 07:32:25 status half-installed lilypond-doc-html:all 2.22.0-6 2021-02-03 07:34:20 status unpacked lilypond-doc-html:all 2.22.0-8 2021-02-03 07:34:34 upgrade lilypond-doc-pdf:all 2.22.0-6 2.22.0-8 2021-02-03 07:34:34 status half-configured lilypond-doc-pdf:all 2.22.0-6 2021-02-03 07:34:34 status unpacked lilypond-doc-pdf:all 2.22.0-6 2021-02-03 07:34:34 status half-installed lilypond-doc-pdf:all 2.22.0-6 2021-02-03 07:34:48 status unpacked lilypond-doc-pdf:all 2.22.0-8 2021-02-03 07:52:06 configure lilypond-doc-html:all 2.22.0-8 2021-02-03 07:52:06 status unpacked lilypond-doc-html:all 2.22.0-8 2021-02-03 07:52:07 status half-configured lilypond-doc-html:all 2.22.0-8 2021-02-03 07:52:07 status installed lilypond-doc-html:all 2.22.0-8 2021-02-03 07:53:36 configure lilypond-doc-pdf:all 2.22.0-8 2021-02-03 07:53:36 status unpacked lilypond-doc-pdf:all 2.22.0-8 2021-02-03 07:53:36 status half-configured lilypond-doc-pdf:all 2.22.0-8 2021-02-03 07:53:36 status installed lilypond-doc-pdf:all 2.22.0-8 2021-02-03 12:45:06 upgrade lilypond-doc:all 2.22.0-5 2.22.0-8 2021-02-03 12:45:06 status half-configured lilypond-doc:all 2.22.0-5 2021-02-03 12:45:07 status unpacked lilypond-doc:all 2.22.0-5 2021-02-03 12:45:08 status half-installed lilypond-doc:all
Bug#956822: Bug#981715: RFS: xpra/3.0.9+dfsg1-1.1 [NMU] [RC] -- tool to detach/reattach running X programs
control: tags -1 pending
Uploaded the following thanks!
diff -Nru xpra-3.0.9+dfsg1/debian/changelog xpra-3.0.9+dfsg1/debian/changelog
--- xpra-3.0.9+dfsg1/debian/changelog 2021-02-03 07:22:38.0 +0100
+++ xpra-3.0.9+dfsg1/debian/changelog 2021-02-05 20:23:02.0 +0100
@@ -1,3 +1,12 @@
+xpra (3.0.9+dfsg1-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ [ Antonio Russo ]
+ * Add xvfb runtime dependency on armhf (Closes: #921700, #956822)
+- This should fix autopkgtests
+
+ -- Gianfranco Costamagna Fri, 05 Feb 2021
20:23:02 +0100
+
xpra (3.0.9+dfsg1-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru xpra-3.0.9+dfsg1/debian/control xpra-3.0.9+dfsg1/debian/control
--- xpra-3.0.9+dfsg1/debian/control 2021-02-03 00:47:00.0 +0100
+++ xpra-3.0.9+dfsg1/debian/control 2021-02-05 20:23:00.0 +0100
@@ -42,6 +42,7 @@
,python3-gi-cairo
,x11-xserver-utils
,xserver-xorg-video-dummy
+,xvfb [armhf]
# Packet Encoding (http://xpra.org/trac/wiki/PacketEncoding):
,python3-rencode
Recommends: ${misc:Recommends}
On Fri, 5 Feb 2021 07:46:16 -0700 Antonio Russo wrote:
> control: tag -1 patch
>
> On 2/5/21 3:22 AM, Gianfranco Costamagna wrote:
> > control: reopen -1
> > control: notfixed -1 3.0.9+dfsg1-1.1
> >
> > Hello, I reuse this bug, to point out that now the package has an
> > autopkgtest failure on armhf, probably due to an incomplete patch or a
> > missing xvfb dependency on debian/tests/control
>
>
> Thanks---digging into this more, I think I understand what's going on:
>
> xpra/scripts/config.py:detect_xvfb_command specifically wants Xvfb
> In particular:
>
> if platform.uname()[4].startswith("arm"):
> #arm struggles to launch Xdummy, so use Xvfb:
>
> (But, why this _is_ working on arm64, I do _not_ understand---presumably,
> some other case-handling causes xpra to change its mind elsewhere.)
>
> It would, then, seem that all we need is to depend on Xvfb on the failure
> architecture:
>
> diff --git a/debian/control b/debian/control
> index 6befbb9..77ef63c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -42,6 +42,7 @@ Depends: ${misc:Depends}, ${python3:Depends},
> ${shlibs:Depends}
> ,python3-gi-cairo
> ,x11-xserver-utils
> ,xserver-xorg-video-dummy
> +,xvfb [armhf]
> # Packet Encoding (http://xpra.org/trac/wiki/PacketEncoding):
> ,python3-rencode
> Recommends: ${misc:Recommends}
xpra_3.0.9+dfsg1-1.2.debian.tar.xz
Description: application/xz
Bug#982029: imgui: crash with floating point exception
Source: imgui
Version: 1.79+ds-1
Severity: serious
Hi,
I tried to build an application that uses imgui, but it crashes
with a "Floating point exception".
Then I tried to build the examples included in the libimgui-dev package
and noticed that they crash as well in the same function.
Steps to reproduce:
$ mkdir /tmp/imgui
$ cp
/usr/share/doc/libimgui-dev/examples/{example_null/main.cpp,imgui_impl_opengl3.*}
/tmp/imgui/
$ cd /tmp/imgui
$ g++ main.cpp imgui_impl_opengl3.cpp $(pkg-config imgui glew stb --cflags
--libs)
$ ./a.out
Floating point exception
$ gdb ./a.out
(gdb) run
Starting program: /tmp/imgui/a.out
Program received signal SIGFPE, Arithmetic exception.
0x77e2773f in stbrp__skyline_find_best_pos (height=64, width=64,
c=0x5560fbb0) at stb_rect_pack.c:350
350 stb_rect_pack.c: No such file or directory.
(gdb) bt
#0 0x77e2773f in stbrp__skyline_find_best_pos (height=64, width=64,
c=0x5560fbb0) at stb_rect_pack.c:350
#1 stbrp__skyline_pack_rectangle (height=64, width=65, context=0x5560fbb0)
at stb_rect_pack.c:447
#2 stbrp_pack_rects (context=0x5560fbb0, rects=0x5560fde0,
num_rects=2) at stb_rect_pack.c:563
#3 0x55596563 in ImFontAtlasBuildPackCustomRects(ImFontAtlas*, void*)
()
#4 0x555999e8 in ImFontAtlasBuildWithStbTruetype(ImFontAtlas*) ()
#5 0x5559a53f in ImFontAtlas::GetTexDataAsAlpha8(unsigned char**,
int*, int*, int*) ()
#6 0x5559a5f5 in ImFontAtlas::GetTexDataAsRGBA32(unsigned char**,
int*, int*, int*) ()
#7 0x7e15 in main ()
(gdb) p *c
$1 = {
width = 511,
height = 32767,
align = 0,
init_mode = 0,
heuristic = 0,
num_nodes = 21845,
active_head = 0x211,
free_head = 0x77ab1be0 ,
extra = {{
x = 7136,
y = 63403,
next = 0x0
}, {
x = 0,
y = 0,
next = 0x41077b4210bb410f
}}
}
stb_rect_pack.h from libstb-dev (0.0~git20200713.b42009b-1) contains the
function stbrp__skyline_find_best_pos:
static stbrp__findresult stbrp__skyline_find_best_pos(stbrp_context *c, int
width, int height)
{
...
width -= width % c->align;
As seen above in gdb, c->align is 0, so this line will cause a division by zero,
which triggers the exception.
I'm not sure if the problem is really in imgui which does not initialize the
stb context properly, or if it's a problem in libstb.
Kind regards,
Reiner
signature.asc
Description: PGP signature
Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
On Fri, 5 Feb 2021 15:32:29 +0100 Helmut Grohne wrote: > The standalone package will not happen. Consider opensysusers to be > the standalone one. > > [...] > > I think you should rethink this. The standalone one will not > materialize. You have news that I don't have. Is there a statement from systemd maintainers that says that they have give up with the standalone package, maybe some IRC chat or it's just your sixth sense? Lorenzo
Bug#976735: fixed in spyder 4.2.1+dfsg1-1
Thank you, Julien! :-) On Fri, 05 Feb 2021 14:49:37 + Debian FTP Masters wrote: > Source: spyder > Source-Version: 4.2.1+dfsg1-1 > Done: Julian Gilbey > > We believe that the bug you reported is fixed in the latest version of > spyder, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 976...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Julian Gilbey (supplier of updated spyder package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Fri, 05 Feb 2021 07:03:54 + > Source: spyder > Architecture: source > Version: 4.2.1+dfsg1-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Science Maintainers > > Changed-By: Julian Gilbey > Closes: 946035 946451 976735 976966 > Changes: > spyder (4.2.1+dfsg1-1) unstable; urgency=medium > . > [ Julian Gilbey ] > * New upstream version: lots of dependency changes. > Closes: #976966, #976735, #946451, #946035 > * Bump Standards-Version to 4.5.1. > . > [ Drew Parsons ] > * debian/copyright: update Files-Excluded for spyder 4 > (help utils now in plugins) > * New upstream release. > Checksums-Sha1: > e9edfc3de350de08293c1c31e623575b0bcc8f32 3091 spyder_4.2.1+dfsg1-1.dsc > df45cd636b7e5faf67536647b45deca85053 2130436 > spyder_4.2.1+dfsg1.orig.tar.xz > 19603d76186917d3568c66f922999fd575b8a741 30856 > spyder_4.2.1+dfsg1-1.debian.tar.xz > de69fe5b089f90812b752767359273e8157230f3 15965 > spyder_4.2.1+dfsg1-1_amd64.buildinfo > Checksums-Sha256: > 24d1934510cab9e337fb4553934ba11cab3360325f6a3f0a64a378d1979c3594 3091 > spyder_4.2.1+dfsg1-1.dsc > 68f23385f977da741cbac2c2d755eca81be69302347ee8ea480970ba8962b95b 2130436 > spyder_4.2.1+dfsg1.orig.tar.xz > 3bcb21fccc32956d2b238945bdb401cc72cbd4394a1ecaa4cd540a5019c13677 30856 > spyder_4.2.1+dfsg1-1.debian.tar.xz > 1a183f3495a86d7b3cc17739f57a556ac6a1c1d6a2b791fd802fa747c378cce9 15965 > spyder_4.2.1+dfsg1-1_amd64.buildinfo > Files: > 4b2fb2489b9a55b48e2d8ba6c91c19d6 3091 science optional > spyder_4.2.1+dfsg1-1.dsc
Bug#982028: gnumeric: Toolbar icons are not displayed
Package: gnumeric Version: 1.12.48-1+b2 Severity: normal X-Debbugs-Cc: cplo...@gmail.com Dear Maintainer, * What led up to the situation? Opening the application * What exactly did you do (or not do) that was effective (or ineffective)? Nothing in particular. This is a fresh debian installation, and it was the first gnumeric launch. This has been happening since debian jessie, at least for me. * What was the outcome of this action? Gnumeric launched and a new spreadsheet was automatically created, but eventhough the toolbars are visible and the tooltips can be seen when passing the mouse over them, the icons are not displayed. * What outcome did you expect instead? Toolbar icons should be visible. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8), LANGUAGE=es_MX:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.74 ii gnumeric-common1.12.48-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.5 ii libatk1.0-02.36.0-2 ii libc6 2.31-9 ii libcairo2 1.16.0-5 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.4-1 ii libgoffice-0.10-10 0.10.48-1 ii libgsf-1-114 1.14.47-1 ii libgtk-3-0 3.24.24-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libxml22.9.10+dfsg-6.3+b1 ii procps 2:3.3.16-5 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gnumeric recommends: ii evince3.38.0-3 ii gnumeric-doc 1.12.48-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: pn fonts-liberation | ttf-mscorefonts-installer pn gnumeric-plugins-extra pn libgsf-1-dev -- debconf information: gnumeric/existing-process-title: gnumeric/existing-process: false
Bug#982027: nexus: FTBFS with OpenJDK 17 due to javadoc errors
Source: nexus Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 nexus fails to build with OpenJDK 17 due to javadoc errors: Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/ncsa/hdf/hdflib/HDFException.html... Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/ncsa/hdf/hdflib/HDFJavaException.html... Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/ncsa/hdf/hdflib/HDFNativeData.html... /<>/bindings/java/ncsa/hdf/hdflib/HDFNativeData.java:123: error: unknown tag: returns * @returns an array of 'datasize' numbers of 'dataType ^ /<>/bindings/java/ncsa/hdf/hdflib/HDFNativeData.java:125: error: reference not found * @see ncsa.hdf.hdfobject.HDFGR ^ /<>/bindings/java/ncsa/hdf/hdflib/HDFNativeData.java:126: error: reference not found * @see ncsa.hdf.hdfobject.HDFSDS ^ Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/ncsa/hdf/hdflib/HDFNotImplementedException.html... Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/org/nexusformat/AttributeEntry.html... Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/org/nexusformat/NexusException.html... Generating /<>/obj-x86_64-linux-gnu/bindings/java/apidoc/org/nexusformat/NexusFile.html...
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On 2/5/21 7:57 PM, Adrian Bunk wrote: > The only problem for testing migration are stale old binaries on an > architecture On a release architecture, that is. Anything in ports doesn't affect testing migration at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On Fri, Feb 05, 2021 at 07:55:50AM +0100, Rafael Laboissière wrote: >... > If I > understand correctly, the right way to cope with the issue is to contact > individually the maintainers of each architecture with FTBFS and ask them to > upload a correctly built binary package. This will have to be done for each > new release of the package. >... This was never the correct action, and since the start of the bullseye release cycle, binaries that were not built on the buildds are blocked from entering testing.[1] The only problem for testing migration are stale old binaries on an architecture, if a package never built on a release architecture or after removal of the stale binaries FTBFS on some architectures are not a problem for testing migration. > Best, > > Rafael cu Adrian [1] packages in contrib and non-free are exceptions
Bug#982026: guacamole-client: FTBFS with OpenJDK 17 due to new compiler warning (primitive constructors marked for removal)
Source: guacamole-client Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 guacamole-client fails to build with OpenJDK 17 because javac is invoked with the -Werror option and a new warning is now emitted when the primitive constructors are used: [INFO] - [WARNING] COMPILATION WARNING : [INFO] - [WARNING] /<>/guacamole-ext/src/main/java/org/glyptodon/guacamole/properties/IntegerGuacamoleProperty.java:[43,30] [removal] Integer(String) in Integer has been deprecated and marked for removal [WARNING] /<>/guacamole-ext/src/main/java/org/glyptodon/guacamole/form/NumericField.java:[84,15] [removal] Integer(String) in Integer has been deprecated and marked for removal [WARNING] /<>/guacamole-ext/src/main/java/org/glyptodon/guacamole/properties/LongGuacamoleProperty.java:[43,29] [removal] Long(String) in Long has been deprecated and marked for removal [INFO] 3 warnings [INFO] - [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] error: warnings found and -Werror specified [INFO] 1 error [INFO] -
Bug#981814: lilypond-doc: Unable to upgrade
Control: tags -1 moreinfo unreproducible Hello Nicolas, Thank you for reporting. On Thu, Feb 4, 2021 at 1:30 AM Nicolas Patrois wrote: > > Package: lilypond-doc > Version: 2.22.0-5 > Severity: normal > > Dear Maintainer, > > I can’t upgrade lilypond-doc because of a file conflict. > > dpkg-maintscript-helper: error: file '/usr/share/info/lilypond/user' not owned > by package 'lilypond-doc:all' > dpkg-maintscript-helper: error: directory '/usr/share/info/lilypond' contains > files not owned by package lilypond-doc > :all, cannot switch to symlink > > dpkg: erreur de traitement de l'archive /tmp/user/0/apt-dpkg- > install-8VsaYi/33-lilypond-doc_2.22.0-8_all.deb (--unpack) : This may or may not be a bug of LilyPond packaging, as I am unaware that any version of the Debian lilypond* binary packages, or any other Debian packages, ever contained /usr/share/info/lilypond/user . So, there is a possibility that /usr/share/info/lilypond/user, whether it be a regular file, a directory, or a symlink, whatever it is, might exist on your specific system only. Also, it would help immensely if we know which version of lilypond-doc etc. you were upgrading from. To help us investigate, could you please kindly reply, copy-and-pasting what you see with the following commands? ls -ld /usr/share/info/lilypond ls -ld /usr/share/info/lilypond/user ls -l /usr/share/info/lilypond/user grep lilypond /var/log/dpkg.log grep lilypond /var/log/dpkg.log.1 Many thanks! Cheers, Anthony
Bug#982025: libnb-javaparser-java: FTBFS with OpenJDK 17: reference to FileSystems.newFileSystem() is ambiguous
Source: libnb-javaparser-java Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 libnb-javaparser-java fails to build with OpenJDK 17 due to ambiguous calls to FileSystems.newFileSystem() -do-compile: [mkdir] Created dir: /<>/make/netbeans/nb-javac/build/empty [mkdir] Created dir: /<>/make/netbeans/nb-javac/build/generated-sources/ap-source-output [javac] Compiling 588 source files to /<>/make/netbeans/nb-javac/build/classes [javac] /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java:519: error: reference to newFileSystem is ambiguous [javac] this.fileSystem = FileSystems.newFileSystem(archivePath, null); [javac] ^ [javac] both method newFileSystem(Path,ClassLoader) in FileSystems and method newFileSystem(Path,Map) in FileSystems match [javac] /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java:380: error: reference to newFileSystem is ambiguous [javac] FileSystems.newFileSystem(file, null).close(); [javac]^ [javac] both method newFileSystem(Path,ClassLoader) in FileSystems and method newFileSystem(Path,Map) in FileSystems match [javac] /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java:77: error: reference to newFileSystem is ambiguous [javac] try (FileSystem fs = FileSystems.newFileSystem(ctSymFile, null); [javac] ^ [javac] both method newFileSystem(Path,ClassLoader) in FileSystems and method newFileSystem(Path,Map) in FileSystems match [javac] /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java:122: error: reference to newFileSystem is ambiguous [javac] ctSym2FileSystem.put(file, fs = FileSystems.newFileSystem(file, null)); [javac] ^ [javac] both method newFileSystem(Path,ClassLoader) in FileSystems and method newFileSystem(Path,Map) in FileSystems match [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 4 errors
